Изградете evaluation набора преди да изберете модел

Доставчик показва document assistant с 94% accuracy. Единайсет седмици след пускането системата пак мери 94%, а клиентът иска да я изключи. И двете числа са честни. Само едното е мерено върху документите на клиента.

Evaluation наборът надживява модела, промпта, chunker-а и обикновено доставчика. Изградете го преди всички тях — от корпуса, който наистина ще пристига, заедно с човек, който знае коя грешка колко струва.

Страниците, които публичният бенчмарк изключва, са тези, на които ще се провалите

Публичните бенчмаркове са подбрани в определена посока: по една канонична версия на документ, цифров текст вместо сканове, по една азбука на страница и въпроси, написани срещу пасажи, за които се знае, че съществуват. Всяко от тези удобства изчезва при първия контакт с реален файлов сървър.

Вместо това пристигат ревизия 4 и ревизия 5 на една и съща инструкция в съседни папки; приложения, сканирани на 200 dpi през 2011 г.; стокови разписки, снимани с телефон под ъгъл и с палец в кадъра; и формуляр за поддръжка, в който имената на полетата са на кирилица, а каталожните номера — на латиница, с кирилско С на мястото на латинско C. Никакво сравнение на низове няма да ги помири.

Извадката се прави от реалната поща, а не от това, което е лесно за етикетиране. Стратифицирайте по нещата, които наистина варират — семейство оформление, качество на скана, език, възраст на документа — и запишете броя случаи на страта, за да може резултатът да се чете по страти, а не смесен. За production gate 150–400 етикетирани случая е работният минимум, а съставът тежи повече от броя: ако 40% от месечния обем е чистият цифров PDF на един доставчик, това оформление не бива да заема 40% от набора, иначе заглавното число се определя от случая, който никога не е бил рисков.

Обратната грешка е също толкова реална: набор, съставен само от грозната опашка, показва ниско число, остава ниско и не казва нищо за пропускливостта. Пазете и двете и никога не ги осреднявайте, без да го кажете.

Accuracy е едно число върху две грешки с различна цена

Фалшиво приемане и фалшиво отхвърляне не са едно и също събитие. При екстракция сгрешен ДДС номер, записан в ERP-а, излиза като разлика при равнение седмици по-късно, вече след плащането, и струва на някого едно утро. Документ, изпратен в опашката за преглед, струва под 60 секунди, когато мястото в източника е маркирано за прегледащия.

Когато съотношението е 50:1 или по-лошо, система с два пункта по-ниска accuracy, но склонна към въздържане, е по-добрата система — а accuracy ги подрежда точно наопаки. Докладвайте confusion matrix и задайте целта като дял фалшиви приемания при фиксирано натоварване на прегледа: „под 0,5% фалшиви приемания при не повече от 20% документи в опашката“ е спецификация. „96% точност“ е настроение.

Abstention заслужава собствено поле на таблото. Върху реален корпус 5–15% е здравословно; под 2% означава, че системата гадае и някой я е настроил да изглежда решителна; над 25% означава, че retrieval-ът е счупен, а вината отнася генераторът.

Таксономията на отказите идва от четене на traces, не от framework

Ragas и DeepEval ще ви изчислят faithfulness, context precision и tool-call accuracy. Нито едното не може да ви каже какво се обърква във вашата област, защото това е факт за вашите документи. Затова първата седмица е open coding: четете реални неуспешни взаимодействия, наименувайте всеки отказ със свои думи и групирайте след това, а не преди.

Сходимостта идва по-бързо, отколкото хората очакват — след около 30 traces нови режими спират да се появяват. Почти винаги първата находка е, че 60–80% от видимите за потребителя откази са пропуски на retrieval-а, а не откази на генерацията: FP1–FP3 при Barnett (отговорът така и не е стигнал до контекста) срещу FP4–FP7 (моделът го е имал и се е справил зле). Поправките нямат нищо общо — chunking и reranking от едната страна, промпт и сглобяване на контекста от другата — и смесването им е най-сигурният начин да изгубите тримесечие.

Етикетите идват от един поименно определен експерт: бинарно пас/фал плюс писана критика при всеки фал. Не скала 1–5 — тройката е неинтерпретируема и двама души няма да разбират едно и също под нея.

Това е фазата, за която клиентите най-малко искат да плащат: няколко дни, в които старши човек чете разпечатки и не произвежда демо. Тя е и най-ценната работа в проекта.

Near-duplicates са тестът, а не шумът

Две ревизии на една и съща инструкция се различават с 2% от текста си и стоят практически една върху друга в embedding пространството. Ranking-ът не може да ги раздели и не бива да бъде каран да опитва. Тестовият случай не е „намира ли инструкцията“, а „намира ли ревизия 5 по въпрос, чийто отговор се е променил в ревизия 5“ — а поправката е metadata филтър по дата на влизане в сила и обект, който прави отменените ревизии недостижими, а не просто по-ниско класирани. Заложете и страничния ефект: рестриктивните филтри фрагментират HNSW графа, заради което съществуват filterable HNSW и ACORN.

Същото сходство удря и самия набор. Документ, който присъства едновременно във few-shot примерите на промпта и в evaluation набора, надува резултата и той няма да се възпроизведе. Дедуплицирайте през тази граница по идентификатор на документ, а не по hash — скановете няма да дадат еднакъв hash.

Judge-ът се оценява, преди да получи право да оценява

LLM-as-judge е единственият начин да пуснете няколкостотин случая при всеки commit и му се вярва далеч над доказателствата. MT-Bench и Chatbot Arena установиха, че силните judge-ове достигат над 80% съгласие с човешките предпочитания — приблизително нивото, на което хората се съгласяват помежду си. Това е таванът, а не отправната точка, и идва с position bias, verbosity bias, self-enhancement bias и слабо разсъждение по всичко аритметично.

Затова мерете judge-а както мерите системата: true-positive и true-negative rate спрямо човешките етикети, по режим на отказ, с цел 0,85 или повече за всеки от двата. Суровото съгласие е безполезно при небалансирани класове — ако 8% от изходите са фал, judge, който пуска всичко, отчита 92% и не открива нищо.

Две следствия, които се прескачат. Фиксирайте model ID на judge-а толкова строго, колкото на продукционния модел: тиха смяна на версията при доставчика мести резултатите ви, без вие да сте пипали нищо. И избягвайте едно семейство модели да оценява собствения си изход — self-enhancement bias е измерен, не хипотетичен. Judge прогоните не са чувствителни към латентност, така че минават през Batch API на 50%.

Наборът е gate само ако нещо блокира на него

Детерминистичните проверки — валидност на схемата, наличие на цитат, забранени термини, латентност — вървят при всеки commit и не струват нищо. Съдената подмножина трябва да приключва под десет минути, за да ѝ бъде позволено да блокира merge, а пълният набор върви нощем. Прагът е regression delta: не повече от 1–2 пункта спад, при всяка промяна на промпт, модел, индекс и chunking, не само при тези, които изглеждат рискови.

За каквото и да е agentic оценяването с едно минаване е грешният инструмент. τ-bench показа челни модели над 50% при едно минаване и под 25% при pass^8 в retail домейна, тоест успех и в осемте независими опита на една и съща задача. Продукцията излага непоследователност, не неспособност. Пускайте всеки случай пет до десет пъти и докладвайте pass^k.

Ако системата обслужва български, той се нуждае от собствен набор и собствено докладвано число. Модели, бенчмаркнати основно на английски, обикновено падат с 5–15 пункта на български, а смесеният многоезичен резултат скрива това напълно.

Докъде не важи

Замразеният evaluation набор гние. Всяка корекция от продукция е кандидат за нов случай, но набор, хранен само с провали, се изкривява към противниковото и резултатът от миналото тримесечие спира да е сравним. Версионирайте набора, пазете замразено ядро за тренда и датирайте всяко добавяне.

И evaluation наборът отговаря дали системата работи, никога дали е струвало да бъде изградена. Този въпрос е цена на решена задача срещу процеса, който тя заменя, и никой golden set не го съдържа.

Накрая границата за нас. Palamed има четири доставени ангажимента: европейски маркетплейс за автомобили с над 300 000 обяви, дигиталният речник на Министерството на образованието и науката на beron.mon.bg, email автоматизация за козметичен бранд, където клиентът е измерил около 60% съкращение на времето за комуникация по своя собствена методика, и NLP модул, който класифицира входящите търговски запитвания от имейл и Instagram и подготвя отговора от продуктовите и ценовите данни, които екипът и без това поддържа — клиентът е отчел около 85% по-малко ръчно писане по повтарящите се запитвания, а всеки отговор се одобрява от човек, преди да тръгне. Не сме пускали етикетиран evaluation набор през CI на клиент. Горното е публикуваният модел на работа — прагът 0,85 за judge alignment, сходимостта около 30 traces, находката за pass^k — и стандартите под него. Който ви цитира 99% точност, ви казва, че тестовият набор е писан от същия човек, който е писал промпта.