Единица 8 / 11

Евалуација и мониторинг на RAG

Добивки:

  • Дефинирање на метрика кои го мерат задржувањето и квалитетот на генерирањето одделно
  • Поставете златен сет на прашања и извршете автоматска евалуација со LLM-како судија
  • Одржување на квалитетот преку повратни информации, следење и регресивно тестирање во производството

Реченицата „Го инсталирав асистентот, се чини дека работи добро“ не е инженерска изјава. Системите RAG тивко се распаѓаат: нов тип на документ го измамува пронаоѓањето, брзата промена ја намалува точноста, индексот станува застарен. Единствениот начин да се реализира ова е да се измери. Во оваа единица, покриваме како да се измери квалитетот на RAG (посебно преземање и генерирање), автоматска евалуација (LLM-as-judge) и одржување на квалитетот во производството (мониторинг, регресија). „Не можеш да го подобриш она што не го мериш“ е мотото на оваа единица.

Измерете две посебни работи

RAG има две нозе и мора да се мери одделно бидејќи проблемот може да е во која било од нив:

  1. Квалитет на пронаоѓање: пристигна точниот дел?
  2. Квалитет на генерацијата: Дали точниот одговор беше произведен од дојдовниот дел?

Ако одговорот е лош, прво треба да знаете која нога е лоша. Ако десниот дел никогаш не пристигне, дури и најдоброто известување не може да зачува (проблем со пронаоѓање). Ако дојде точниот дел, но моделот погрешно го прочитал, подобрувањето на пребарувањето е залудно (проблем на генерацијата).

Метрика за пронаоѓање

Преземањето е проблем со сортирање/пристап; мерено со класични метрики за пронаоѓање информации. За ова мора да го имате златниот кластер: знаењето кое парче е „точно“ за секое прашање.

метрички

Кои мерки

Едноставна дефиниција

Recall@k

Дали е точното парче во горниот к?

Правилна стапка на фаќање делови

прецизност@k

Колку од вратените k парчиња се релевантни?

Чистење на донесеното

MRR (среден реципрочен ранг)

По кој редослед е точното парче?

Наградите се во првите редови

Стапка на удари

Пристигна ли барем едно правилно парче?

Најосновната мерка за успех

Практичен коментар: Ако Recall@k е низок, стратегијата за делење или пребарување (хибрид, k, повторно рангирање) треба да се преработи. Ако прецизноста е мала, но отповикувањето е високо, додавањето на повторно рангирање е добар потег.

Генерација метрика

Кога ќе пристигне правилниот дел, го мериме квалитетот на одговорот произведен од моделот. Три основни димензии:

  • Верност: Дали секое тврдење во одговорот е поддржано од контекст? Дали има некакво вклопување? Тоа е директна мерка за халуцинација.
  • Релевантност на одговорот: Дали одговорот всушност одговара на прашањето или е надвор од темата?
  • Комплетност: Дали се искористени сите релевантни информации во контекстот или недостасуваат?

Тие често се бодуваат на оценета основа (на пр. 1-5), наместо бинарни како „точно/неточно“.

Совет: следете ја верноста како посебна метрика. Ако верноста се намалува како што се намалува точноста, проблемот е генерирањето; Ако верноста е висока, но одговорот е погрешен, проблемот е во погрешното парче (пронаоѓање). Заедно, овие две метрики се компас што ја покажува локацијата на дефектот.

Воспоставување златен сет на прашања

Секое мерење бара златен сет / база на податоци за евалуација: реални прашања + очекувани точни одговори + точни изворни парчиња. Да се ​​почне со 30-50 добро избрани прашања е подобро од 500 случајни прашања. Вклучете го следново во сетот: често поставувани вистински прашања, познати тешки прашања, прашања без одговори (треба да се каже „не знам“), прашања со контрадикторни извори.

# Пример за златен кластер (концептуален)[ {"прашање": "Колку дена годишен одмор?", "очекуван_одговор": "14 дена за 1-5 години стаж", "correct_part_id": "два-дел-3", "категорија": "напуштање"}, {"прашање": "Каде е компанијата? „NO_INFORMATION“, # trap: не знам „correct_part_id“: null, „category“: „trap“}]

LLM-како-судија: Автоматско оценување

Додавањето стотици одговори со рака е заморно. Моделот LLM-as-judge е кога еден модел постигнува и го оправдува одговорот на друг модел врз основа на одредени критериуми. Добриот судиски момент јасно ги дефинира критериумите, дава примери и бара оправдување.

# Прашање за LLM-as-judge (концептуално) Вие сте непристрасен оценувач. Оценете го ОДГОВОРОТ подолу според дадениот КОНТЕКСТ и ОЧЕКУВАН ОДГОВОР. Оценете (1-5) и оправдајте:- верност: дали секое тврдење во одговорот е поддржано во контекст?- точност: дали одговорот се совпаѓа со очекуваниот одговор?- комплетност: дали релевантните информации се целосни? Посебно: ако одговорот содржи информации кои не се во контекстот, дајте верност1 и наведете кое тврдење е измислено. КОНТЕКСТ: {context}ОЧЕКУВАНО: {очекувано}ОДГОВОР: {answer}Излез: {верност, точност, комплетност, оправдување}

Внимание: LLM-како-судија не е совршен; Тие можат да имаат свои предрасуди (долг одговор, претпочитајќи свој стил). Исто така, потврдете го судијата: имајте некои одговори дадени и од судијата и од човекот и измерете ја согласноста меѓу нив. Ако судијата е доследен на човечките резултати, можете да му верувате.

Слаб/силен рејтинг

Слаб („тоа беше добро за мене“):

Поставив неколку прашања и одговорите изгледаа добри. Го имам во живо.# Проблем: нема мерења, регресија незабележлива, подобрување слепо.

Моќен (златен кластер + дискретна метрика + автоматско расудување + регресија):

Златен кластер од 40 прашања. Со секоја промена, recall@5, верноста и точноста се мерат автоматски. Ако резултатот падне, промената се враќа назад. Во производството, повратните информации од корисниците се собираат и се додаваат во сетот.

Мониторинг и регресија во производството

Евалуацијата не се прави еднаш и завршена. Три постојани практики:

  • Тестирање на регресија: Автоматско активирање на златен кластер при секое известување/пронаоѓање/промена на моделот. Ако резултатот се намали, промената се менува. Ова спречува „да го скршиш додека се обидуваш да го подобриш“.
  • Набљудување на производството: стапката „Не можев да најдам информации“ во реални прашања, просечно доцнење, цена, повратни информации од корисниците (👍/👎) се следат. Ненадејното зголемување на „не знам“ е често првиот знак за дефект на индексот или пронаоѓањето.
  • Јамка за повратни информации: Вистинските прашања обезбедени од корисникот 👎 се прегледуваат и се додаваат на златниот куп; Така, комплетот со текот на времето станува побогат и слепите точки на системот се затвораат.

Три мини футроли

Случај 1 - Тивка регресија. Тим го измени барањето за да го „подобри“; Општата точност се зголеми, но верноста се намали за 30% во стапицата прашања (моделот почна да се вклопува повеќе). Немаше да се забележи ако не беа прашањата за стапица во златниот кластер; Тестирањето за регресија ја врати промената.

Случај 2 - Исправување на погрешната нога. Кај еден асистент одговорите беа лоши; Тимот работеше на барањето со недели. Кога ја измеривме метриката за пронаоѓање, отповикувањето@5 беше само 48% - проблемот беше во пронаоѓањето, а не во генерирањето. Кога се додаде хибрид + повторно рангирање, отповикувањето се зголеми на 89%, а прецизноста исто така се зголеми.

Случај 3 - Предупредување за производство. Еден ден, стапката „Не можев да најдам информации“ за помошник за поддршка скокна од 6% на 34%. Тракпадот предупреди; Причината беше што работата за индексирање, која работи ноќе, тивко пропадна и не беа поставени нови статии. Без мониторинг, неточните изјави „не знам“ ќе продолжија со денови.

Вообичаени грешки

  • Да се биде задоволен со „добро ми функционираше“: Без мерење, регресијата останува незабележана.
  • Не одвојување на пронаоѓањето и генерирањето: ќе ја поправите погрешната нога и ќе изгубите време.
  • Не поставувајќи прашања за стапица: Тенденцијата да се измислуваат работите не се појавува во златниот кластер.
  • Не верификува судија: Пристрасната порота дава лажна доверба.
  • Не се следи производството: Неуспехот на индексот, експлозијата на трошоците продолжува тивко.

Сумирано

  • Во RAG, квалитетот на пронаоѓањето и генерирањето се мерат одделно; Прво мора да се утврди која нога е оштетена.
  • recall@k, precision@k, MRR за пронаоѓање; Верноста, соодветноста, комплетноста се користат за генерирање.
  • Секое мерење бара златен кластер; Ставете во него вистински, тешки, замки и контрадикторни прашања.
  • LLM-како судија авто-оценки за големи сетови; но самиот судија мора да биде оправдан против човекот.
  • Тестирањето на регресија, следењето на производството и јамката за повратни информации го одржуваат квалитетот со текот на времето.

Задача за апликација

(1) Направете златен сет од најмалку 15 прашања за вашиот сопствен асистент: вклучете најмалку 3 стапици (без одговори), 3 тешки, 2 контрадикторни изворни прашања. Напишете го очекуваниот одговор и точниот дел за секое прашање. (2) Рачно споредете две различни промптни верзии со овој сет; На секој одговор дајте 1-5 поени за верност и точност. (3) Приспособете го горенаведеното барање за LLM-as-judge на вашите сопствени критериуми. (4) Идентификувајте 3 метрики што ќе ги следите во производството и за секоја прашајте „на кој праг да алармувам? напишете ја вредноста.

листа за проверка

  • [ ] Можам да го измерам квалитетот на задржувањето и генерирањето со посебни метрики.
  • [ ] Знам што значат метрика како recall@k, верност.
  • [ ] Можам да изградам златен кластер кој вклучува вистински, тешки, замки и контрадикторни прашања.
  • [ ] Можам да поставам автоматско оценување и да го потврдам судијата со LLM-како судија.
  • [ ] Можам да работам со тестирање на регресија, следење на производството и циклус за повратни информации.