Шысьць паказнікаў ацэнкі RAG, якія маюць значэнне ў практычным выкарыстоўванні

У пачатковых нарадчыках з RAG шлях выглядае простым: раздзеліць дакументы, уключыць іх, зберагчы вектары, выбраць маленькую кантэнцію top_k, вызваць модель. Такы падход можа здавацца эфектывным у дэме. Але ў рэальных умовах все інакш.

З’яўляюцца складныя запытанні. Автэнтычныя дакументы супераслігаюць адзін з другім. Дзеякі запытанні трэба падтрымліваць доказамі з кальколька месцаў адразу. Карыстувачы ствараюць фразаванні, якіх няма ў первісным наборе тэстаў. Система, якая добра прабавалася на стандартных тэстах, пачынае даваць адпаведзі, якія здаюцца надта нестабільнымі.

Пры налагоджэнні механізма пошуку для асистента у корпаратыўнам стылі гэтыя проблемы сталі явнымі. Недастатак доказаў змусіў команду падняць глыбіну пошуку. Рэзультаты пашуку без з’ўязку з інтернетам падняліся, а рэгрэт такса таксама. Паперовыя показнікі паказвалі «лепшы» стан, але якосьасць генераваных адпаведзей падгорэла.

Дадзеныя дапаможнікавалі не аднойчы. Інодзе гэта было болюча. Спраўныя фрагменты прыходзілі з супернакладамі, слабкімі суседзямі і часамы канфліктамі.

Гэты дазнаўніцкі досвядзець пераканал падход да ацэнкі. Запыт перастаў быць «чы гэта быў правільны файл?» і стаў «чы кожны этап працэсу можа паказаць, што выканана яго задача?»

Адлагоджэнне робочых систем RAG быстра раздзеляе канкрэтныя аспекты, якія ў дэманстрацыйных прыкладах зліваюцца ў адну оцэнку: насколькі добра вы выкарыстоўваете інфармацыю, насколькі добра ранжуеце её, якія якосці адпаведзення, чы тверджэнні ўзгадваюць реальнасць, сколькі часу чакаюць корыстнікі і сколькі коштае кожны запыт. Наступныя запыты, якія задаюць усе — як нам выбраць размер фрагменту і параметры top-k? — больш не патрабуюць стандартных цифраў.

Спрыяйце прыбліжэнню проблемы як аптимізацыі па змоўгу: створыце базовую правду, змяркуйце неабходныя показнікі, назвыце компромісы, пераканайцеся ў правільнасці незнакомых запытоў, а потым парабяжцеся, што рэшэння застаецца эфектываў у практычным выкарыстоўванні.

Шас мераў ёсць выключна корыстныя: Recall@K, nDCG, MRR, Faithfulness, Latency і Cost. Кожная з яных адкрывае разны тип неяўнасці. Разам яны адказваюць на пытанне, як пратэтып ператвараецца ў систему, яю можна апераваць.

Пачніце з адзысквання інфармацыі

Калі якасць адказоў падупае, верніцеся да пачатку процесу прыемлень інфармацыі, перш чым прабаваць перапісваць запиты, зменшыць модулі чы прыўязваць дадатковыя элементы. Задайце простае пытанне: чы воўсе знаходзіцца неабходная інфармацыя? Модуль не можа выкарыстоўваць матэрыял, які ніколі не прайшоў у вікно контексту.

1. Recall@K — ступень пакрыцча неабходных доказоў

Recall@K выявляе, які частака сапраўдна значамых элементаў з’являецца сярод першых K результатаў.

Узьмімо бота ITSM, які сталкнуўся з запытам: «Служба платежоў не працюе пасля переключэння базы дадзенаў — якія крокі восстанавлення мне трэба выконаць?» Падазроўваецца, што патрабуецца пяць фактов. Серед першых пяці результатаў бота є толькі чатыры з іх. Recall@5 станавіць 0.80.

Эта адзіная цифра вже керуе процэсам дыбаггінгу. Генератор можа не быць вінаватым; 20 процэнтаваў неабходных доказоў так і не прыбылі. Практычная правіла: паспрабуйце паўнейша перадзеясніць тое, што бачыць модель, прычаму ўжо звычайна крытыкаваць спосаб её напісання.

Гэта таксама пояснюе, чаму фіксаваная значэнне top_k = 5 не є абавязковай. Якщо зменіць K з 5 на 10, то рэкалі ўзростае з 0.80 да 0.94, што указвае на тое, што індэкс мае неабходны матэрыял, але фільтрацыя занадта слабая. Падвоўкі K таксама можа прызваць перэплыв запросу шумам — саме таму далей ідуць паказнікі ранжыравання.

2. nDCG — чыя лепшыя рэзультаты знаходзяцца ў верхней частыне?

Толькі паверхневая аналіз не ўсё. Важны таксама порядак.

Две системы можу выкарыстоўваць аднаковы набор інструкцый. Адна ставіць іх першымі, потым іншыя корыстныя процедуры, а пасля — менш значымы элементы. Іншая ж ховае ція інструкцыйі на восьмай пазычці, між слабкая зв’язанымі сторонкамі. Рэкалі схожы; але рэзультаты зусім разныя.

nDCG (нормаваныя зніжаныя кумуляванныя практычныя значэння) ацэнкаваі relevантнасць і надае большых балоў за тое, каб сильныя элементы былі размешаны ў пачатку. Класычная праця Järvelin і Kekäläinen па зніжаным практычным значэннях створаная саме з гэтай прычыны.

Reranking рэалізуе гэта для RAG. Адзначаюцца двадцать кандыдаатаў, для модэлю застаецца пяць, і самэ раштучак двадцаті выбірае, чы ўсё-такі гэтыя пяць будуць корыстнымі. Высокая рэкалія з слабым ранжыраваннем можа заставіць правильны абзац у списку, але пазначыць яго не ў фінальным запитаў.

Рэкалія пераканваецца ў адкрыцыі інфармацыі. nDCG пераканваецца ў розумным раштучаку.

3. MRR — калі будзе першы корыстны рэзультат?

Середняе взаімнае ранжыраванне сфокусавана на першым рэлевантным рэзультате:

[
RR = \frac{1}{\text{rank of first relevant result}}
]

Ранг 1 → RR 1.0. Ранг 5 → RR 0.2. Середнічаючы па набору запытанняў, MRR ёсць чысты сігнал, калі першы хорашы рэзультат домінюе ў выніках.

Інтэрактыўныя асистэнты часта зупыняюцца пасля першага значныя фрагмента тэксту. Агент, який хавае правыя інструкціі на дзевятай пазіцыі, можа выглядаць эфектываў у тэсте Recall@20, але ў інтэрфейсе продавацца неэфектываў.

Калі «больш контэксту» пагубнае

Пасля павышэння колькісных показнікаў агента якасць адпаведзенняў застаўся низкім. Модель патрапляла ў ситуацыю з надмерным і суперасунковым тэкстам. Показнікі ранжыравання адказаў паводзяць да гэтай проблемы: большая значэння K без кращага порядку дапамагае шуму прасачыцца ў запит, што спрычыняе неабходнасць перапрацоўкі адказа.

4. Адданасць — твэрджэння, звязаныя з адзначаным тэкстам

Адданасць абязначае, чыя твэрджэння ў адказе падтрымваюцца адзначаным контэкстам. Плавны, але неаснованны тэкст, який выдумвае новы крок, праграматныя граніцы чы саўмешчае два правіла ў адно, не падтрымвае адданасць, нават якщо звучыць впэўнена.

Трэба розлічваць адданасць і правильнасць.

Падзеймі, што корпус усё ўсё мае застарэлую правілу пароля — выгорае кожныя 60 дзён. Модель яе знаходзіць і павтарае. Адпаведзь можа быць абсалютна верныя знайдзенай сторанцы, але ўсё равна некоректной па вазначаным источніку правды.

• Вернасць: чым падтрымвана вернасць? Чым было знайдзена інфармацыя?
• Коректнасць: чы супарадзіваеся з вазначанай політікай?

Этае раздзеленне мае значэнне кожны час, калі базы знаёмых адрэсуюцца пад жывую систему.

5. Затрымка — чакаць якую можу карыстальнікі

Якосьць паўтарнага выкарыстання без з’яноў канчаткаецца, якщо продукт не можа сабе пэўніць у чаканні.

Пораўняймо два варыянты. А даходзіць да 91% точнасці адпаведзей з затрымкай 120 мс. B даходзіць да 93% з затрымкай 650 мс. B выграе толькі па тачнасці. Адметкі продукту вяршаюць, чы B на самай працоўнае кращы. Інтэрактывныя асистэнты з строгім лімітам часу на адпаведзь могу адхіліць такую затрымку, а выкарыстанне інфармацыі — толькі частка абоўсумнага часу.

Жывыя запиты можаць включаць перапісву, выявленне даных, переранжаванне, стварэнне контексту і генераванне. Неабяжна зьмераць асэтапны прыем падзеяў і весь шлях ад початку да канца. Лепш выкарыстоўваць распады данных, чым сярэднія значэння. Сярэднее значэньне 400 мс з P95 у розмяре 1,8 секунды зовсім не адпавядае системе, у якой значэньні P50/P95/P99 застаюцца низкімі.

З самага пачатку трэба уключыць показнік затрымкі ў план ацэнкі — а не як метрыку керування пасля таго, як архітектура будзе зафіксавана.

6. Косц — што відбываецца пад мільйонамі запытанняў

Эканоміка стае значным фактам як толькі пратэты практычна ператвараецца ў продукт.

Падвышэньне колькасці элементаў у топ-к вплывае не толькі на кантроль над результатамі, але і на велічыну роботы пры переранжаванні, розмяр фінальнага контексту, колькасць токэнаў увайсу, затрымку і навантажэнь на інфраструктуру.

Якщо кожны фрагмент складаеся з 600 токэнаў, тады:

Final K = 5

уводзіцца апошней прыбліжна 3 000 выявленых токэнаў. Перайсці да:

Final K = 15

і вы якраз набліжаецеся да 9 000 — гэта у трох разоў больш за массу, якая была знайдзена. Міліяны запытак ператвараюць гэта на вароўкі для выбору продукту. Параметр Top-k адразу ж вплывае на якасць, час адпаведзі і вартасць.

Што на самай працо значыць «налаштаваць размер частак і параметр Top-k»

У запытанні на адзінку не прасягаюць пра два „чароўныя“ числы. Прасігаюць пра эксперыментальную структуру.

Складзіце прыбліжна 200 репрэзентатывных запытак, якія стосуюцца адлагоджэння проблем, процедураў, інцидэтаў/RCA, правілаў, неяснасцей, багатоэтапных процесаў і крайніх случаяў. Некампетэнтыям у галузі нехай ацэнююць актуальнасць.

Перагляньце размеры частак, напрыклад:

Chunk sizes:
256
512
1024
2048

і перасягі сетак / кандыдатаў-K, напрыклад:

Overlap:
64
128
256Candidate K:
5
10
20

Сетка 4 × 3 × 3 дае або 36 конфігурацый. Оценіце кожную за аднакоўнальнасцю больш чым адной цифры:

Recall@K
nDCG@K
MRR
Answer correctness
Faithfulness
Latency
Cost

Потым выберце парадакт, які важнаўствае для якасці / часу адпаведзі / вартасці — не за звычай максимальны рэкал чы F1.

Рэзультаты эксперымента, протыраннія з логікай

Дзеяўся прыпуск, што тры конфігурацыі даюць такія рэзультаты:

• A: Recall@10 0.94, nDCG@10 0.81, точнасць 0.89, адпаведнасць 0.95, P95 510 мс, $0.025
• B: Recall@10 0.91, nDCG@10 0.88, точнасць 0.94, адпаведнасць 0.96, P95 560 мс, $0.027
• C: Recall@10 0.97, nDCG@10 0.79, точнасць 0.86, адпаведнасць 0.76, P95 820 мс, $0.034

Толькі па параметру Recall C выглядае найкраща. Аднак яна дае найслабейшыя рэзультаты — адночасна выкарыстоўванне дадатковых методаў адшукання, вочыма, пагаршвае якасць генеравання. У B меньшы показнік Recall, але ёй прывілейваюць nDCG, точнасць і адпаведнасць за рахунак лёгкага падвышэння часу адпаведзення і вартоў. Самэй гэтая конфігурацыя варта дакладнейшага аналізу, і самэй таму правило «перамагае найвышэйшы бал за адшукання» є некоректным узэўсюдным правілам. Неабходна оптымацыя па рэальных цілях продукту.

Няудача → наступны аналіз

• Слабы показнік Recall@K → часткова обробка дадзенняў, вставкі, індэксы, фільтры метадаў, форматаванне запыткаў, стратегія адшукання

Сильная здатнасць да адгадвання, слабы показнік nDCG → ранжаванне/пераранжаванне

Сильныя навыкі адшукаўання, слабая точнасць адпаведзей → складанне контэксту, аранжаванне, стварэнне запытак, генераванне

Працэпадныя, але не падтрымваныя адпаведзі → аддасць/аполяганне

Хораша якасць, пакія латэнс → аналіз кожнага этапу

Хораша якасць, высокія затраты → выбор K-значэння, фінальне K-значэння, размер частак, стысненне, кэшаванне, выбор моделі, эфектыўнасць токэнаў

Гэты список ператак ператварае адлагоджэнне на стандартную процедуру.

Зберагаеце цыкл у працоўным режыме

Одноразовы тэст не є канцэльнай стадіяй. Вам патрэбна непаўзліва ацэнка. Рэальны трафік не падобаецца створаным набрам: зменшваюцца формулі запытак, документы зменяюцца, правілы адкорэгулююцца, з’яўляюцься новыя службы, прыходзяць экстремальныя ситуацыі. Расшироўваеце набор для ацэнкі на базе працоўных неудач.

Развіты карточкі ацэнкі

Няхай яка-небудзь адна метрыка не можа расказаць всю історію. Корыстная карточка адзначае пакрыць, ранг, правильнасць, аддыктнасць, перцэнтылі затрымкі і эканоміку аб’екта ўсё разам.

Задайце вопыты пры налагоджэнні

Калі хтось захоць вялічыну фрагмента і параметр top-k, спачатку задайце вопыты: што мы оптымізуем, як выглядае набор з атрыбутамі, і сколькі коштае неправильнае выкарыстоўванне данных? З гэтымі адказамі налаштаванні стаюць рэзультатамі эксперыментаў.

Адны з можлівых рэзультатаў можа быть:

512 tokens
128 overlap
Candidate K = 20
Final K = 5

Іншы:

1024 tokens
64 overlap
Candidate K = 10
Final K = 4

Семантычнае раздзелэнне на фрагменты можа перамогчы і тое, і другое. Реранкер можа зробіць фінальны параметр K важлівейшым за кандыдатскі параметр K.

Не трэба даваць веры уяўным ценносцям без прамеравання. Система RAG не ўважаецца „хорашай“ таму, што яна знаходзіць больш мацеряла, робіць гэта быстрей чыста таму, што звучыць пераканальна. Яна ўважаецца хорашай, калі знаходзіць правильныя доказы, належным чынам іх ранжуе, задае модэлю правильную колькасць контексту, стварае адпаведныя та падтрыманыя фактамі адпаведзі, і залишаецца ў межах практычных параметраў прысоедзення часу та вартасці продукту.

Гэта разлік — межа між простым падключэнням элементаў та стварэнням робочай системы — і є сутнасцю праблемы.

Хавайце гадаць пра настройкі

Няма міфічнай дужыны фрагментаў, няма універсальнага показніка top-k, і няма жаднага адзінога паметрагу, які мог бы стварыць умовы для готавасці до выводу. Нават высокі показнік Recall@K можа зашкодзіць якасці адпаведзей. Сильная здатнасць да пошуку мацеряла можа дазволіць робіць тыя тверджэння, якія не падтрымваюцца доказамі. Высока тачнасць таксама може не прыняцься, якщо пры збільшэнні масштаба ростуць прысоедзення часу чы вартасці.

Падберайце баланс межаў покрыцча, ранжыравання, стварэння адпаведзей на падставе доказаў, прысоедзення часу та вартасці для тых завадак, якія вы насправды обслугавалі.

Прыяжнае падчыненне: абсалютная правда → крэты для выкарыстоўвання дадзеных → пераконтроль ранжыравання → якосц адпаведзення з початку да канца → пераконтроль часу адпаведзення/вытрат → дадзеныя, якія не былі паказаны → стежэнне за працэю ў рэальным часе → адказы за невялікія працэўнікі, якія зноў пракладаюцца ў набор.

Тады chunk_size=512 або top_k=5 ўжо є доказам, а не фольклорам.

Размішчэнне шасцях паметрактароў на адной стороне

Практычны карточкі ацэнкі для ўсётыжневага адзору RAG можа выглядаць так:

• Recall@K і MRR для падтверджэння: «Чы сапраўды мы знаходзім доказы, і як шыбка?»
• nDCG для падтверджэння: «Чы мы ставім лепшыя доказы першымі?»
• Адданасць і правильнасц адпаведзення для падтверджэння: «Чы генераванне адпаведзення застаўся правдзівым?»
• P50/P95 час адпаведзення для падтверджэння: «Чы корыстувальнікі можаць чакаць?»
• Вытраты на адна успешная адпаведзь для падтверджэння: «Чы фінансы можаць чакаць?»

Разглядзіце іх разам. Падыш у показніку Recall@K паўзрастанням надзеянасці не ёсьць успехам. Скорачэнне затрымкі, якае прыводзіць да падышу nDCG, таксама не ёсьць успехам. Мета шасцях метрычных показнікаў — адкрыць гэтыя компромісы, замест таго каб спрытаць іх у адзін показнік F1.

Абсалютная правда — гэта рэдкі ресурс

Метрычныя показнікі ўсё толькі настолькі хорашы, насколькі хорашыя ярлыкі, якіе стояць пад імі. Якшо эксперты ў данай галіні ніколі не ацэнювалі, якія фрагменты є релевантнымі, то Recall@K стае проста формальнасцю. Якшо ніхто не пазначаў ступеня релевантнасці, то nDCG ператвараецца на шумны бінарны показнік. Якшо ацэнка надзеянасці є неоднаковай, то рэзультаты метрык таксама змінююцца.

Неабходна выдзеліць час на пазначэння ярлыкаў так сама, як і час на експерыменты з усаджэнням данных. Двеста ретка ацэнаваных запытак зазвычай даюць больш маёмасці, чым два тысячі безярлыковых. Апдэйтуйце гэты набор на адной з карточак пра проблемы: кожны «неправільна вырачаныя витраты», «застарэлыя правіла пароля» і «празначаныя етапы, якія не былі выкарыстоўваны» є кандыдатамі на аналіз.

З эксперыменту да к контролю змян

Калі якае-небудзь настройкаванне паспела ў тэстовым режыме, яго трэба апрацаваць так жа, як і будь-яю іншую зміну ў працоўным сервісе. Запісваюцца параметры, якія былі выкараны, паспелы настройкавання, рэзультаты тестаў для іншых настройкаў, а таксама параметры затрымкі/выдаткаў, якія былі прыйняты. Потым трэба стежыць за тымі ж паметрамі ў рэальным трафіку прынаследжваючы певны час. Якщо рэзультаты запытаў у працоўным сервісе будуць іншымі, неудачныя кейсы трэба падаць знову ў той жа набор данных і перзапусціць процедуру тэставання. Саме гэты цыкл — а не стандартны розмер частак у блог-пастах — і ўражае разлік межы налаштаванага системы і проста ўдачнай дэманстрацыі.

Чаму пратотыпы моўцуюць неправду

У дэмавыях нотбуках зазвычай выліковваецца набор запитоў, фіксуецца корпус даных, а затрымка выконання падае за счэт адной-едзінай вызову. У рэальных умовах все адбываецца наадворс: запиты змінююцца, дакументы перерастаюць, а корыстувальнікі пакідаюць медленныя адпаведзі. Самэй таго конфігурацыя, якая здавалася чудовай на статычным тэстах, пасля запуску можа здавацца ненадзеяной. Шэсць вышапераказаных паметрак ёсць спосабом зробіць гэтыя скрытыя аспекты відкрытымі яшчэ до выпуску продукту, а таксама падтрымліць іх відкрытымі пасля выпуску.

Калі хтось запытаеся пра стандартны розмер частакі і стандартную колькасць элементаў top-k, перакладзіце гэты запит у план експерыменту. Указаце цель, набор дадзеных з меткамі, ліміт затрымкі і верхнюю межу витак. Пасля чаго нехай сітка вырашыць цифры. Усё інше — гадання, адзначана як інжынерная праця.

Зберагачыце табліцу паметрак у візуальным формате пад час ўсэх тыжневых аналізаў, каб компромісы заставаліся відкрытымі для всіх членаў команды.