Ако вашата RAG система няма eval set, всяка промяна на prompt е release базиран на усещане. Добрата новина: можете да изградите полезен eval set за седмица. Не перфектен — полезен. Перфектното е капанът, който задържа екипите от това изобщо да имат evals.
Ето рецептата, която използваме в ангажименти, където клиентът има 0–5 evals в ден първи и се нуждае от 200 до края на седмицата.
Формата
Искате три неща:
- Замразен corpus — реалните документи, върху които вашата система прави retrieval, snapshot-нати в един момент във времето.
- 200 въпроса, които реален потребител би задал, с ground-truth отговори и цитати.
- Held-out set — 30 от тези 200, заключени, никога използвани за tuning на нищо.
Held-out set-ът е най-важен и най-често пропускан. Ще се върнем към него.
Ден 1–2: Извличане на реални въпроси
Пропуснете уъркшопите „какво биха попитали потребителите?“. Те произвеждат въпроси, които никой потребител никога не е задавал. Идете към източниците си:
- Support tickets, които споменават някоя тема, която RAG покрива.
- Search logs от съществуващата ви search bar, ако имате такава.
- Slack канали, където хората задават въпроса вътрешно.
- Chat logs от текущата ви LLM система, ако имате такава работеща.
Целете 250 raw въпроса. Dedupe, нормализирайте формулировки, изхвърлете очевидно out-of-scope. Ще се озовете на ~200.
Ден 3: Таги за сложност и тема
Категоризирайте всеки въпрос:
- Сложност: тривиален (отговорът е в един параграф), среден (отговорът изисква синтез на 2–3 документа), труден (изисква разбиране на процедура или правило).
- Тематична област — обикновено 5–15 кофи, в зависимост от вашия домейн.
- Adversarial flag — въпроси, проектирани да задействат известни failure modes (out-of-scope, противоречива информация, скоро обновена информация).
Искате микс. Suite, който е 90% тривиални въпроси, ще ви каже, че системата ви е страхотна, и ще deploy-нете регресия, защото средните и трудните случаи са се счупили.
Ден 4: Ground truth
За всеки въпрос ви трябва:
- Очакваният отговор — написан, 1–3 изречения, отговорът, който domain expert би дал.
- Подкрепящите пасажи — указатели (doc IDs, line ranges, chunk IDs) към частите от corpus, които би трябвало да бъдат retrieved, за да се отговори на въпроса.
Това е бавната част. Планирайте ~3 минути на въпрос = ~10 часа за 200 въпроса. Двама души паралелно, половин седмица. Използвайте domain expert.
Заслужава си. Това е частта, която превръща „LLM-ът каза нещо правдоподобно“ в „LLM-ът цитира правилния източник и даде правилния отговор“.
Ден 5: Baselines + метрики
Пуснете текущата си система (или stub, ако нямате такава) срещу 170-те видими въпроса. Запишете:
- Retrieval@k: дали top-k retrieved chunks включват очакваните подкрепящи пасажи?
- Answer correctness: оценено от LLM judge срещу очаквания отговор, с held-out reference. Калибрирайте judge-а срещу ~30 човешки оценки, за да сте сигурни, че не просто подпечатва.
- Citation precision: от върнатите цитати, каква част реално подкрепят твърдението?
Сега имате baselines. Всяка бъдеща промяна на prompt или retrieval се показва като делта от тези.
„Не оптимизирайте срещу това“ set
30-те held-out въпроса съществуват по една причина: да се хванете самите вие.
Всеки екип, който изгражда eval set, в крайна сметка започва да настройва системата срещу eval set-а. Нова prompt ревизия, пуснете evals, score-ът е нараснал, ship. Три месеца по-късно вашият in-suite score е 95%, а потребителското удовлетворение е непроменено, защото сте overfitting-вали.
Held-out 30-те въпроса се пускат само по време на тримесечни здравни проверки. Ако регресират, докато останалата част от suite-а се подобрява, това е димната аларма за overfitting. Те са проверка върху проверката.
Не ги гледайте. Не добавяйте към тях. Не подменяйте с еквиваленти. Заключете ги в трезор.
Какво ви дава това
- Възпроизводим сигнал, който блокира промени на prompt и retrieval.
- Baseline, с който можете да сравнявате при оценка на нови LLM версии.
- Защитим отговор на „откъде знаете, че вашият RAG е добър?“
Изградете v1 за седмица. Итерирайте върху въпросите месечно. Подменете held-out set веднъж годишно.
Никога няма да имате време да изградите перфектния eval set. Абсолютно ще имате време да изградите полезния.