RAG върху фирмени документи: какво се обърква на практика

На хартия RAG е прост: разбиваш документите на парчета, правиш ембединги, търсиш, подаваш намереното на модела. На практика 80% от работата е преди първото търсене.

Ето къде се къса най-често.

Документите не са това, което мислиш

Първата седмица на всеки такъв проект минава в четене на реални файлове. Почти винаги излиза едно и също:

• Сканирани PDF-и без текстов слой. Изглеждат нормално, но за машината са картинки. Трябва OCR — и той греши точно в таблиците, които са най-важни.
• Таблици, разпънати на три страници. Ако ги нарежеш наивно, редовете се откъсват от заглавията на колоните и отговорът става грешен, без да изглежда грешен.
• Пет версии на един договор. „Финал“, „Финал_2“, „Финал_подписан“. Ако не решиш коя е меродавната, системата ще цитира отменени клаузи.
• Смесени езици. Български текст с английски термини в едно изречение. Част от готовите модели за ембединги се справят зле с това.

Решението не е по-умен модел, а инвентаризация: кой документ е актуален, кой е архив, кой изобщо няма място в индекса.

Нарязването е продуктово решение, не техническо

Стандартният съвет е „по 500 токена с 50 застъпване“. Работи за блог статии. За фирмени документи почти винаги е по-добре да следваш структурата:

• договор → по член и алинея;
• наръчник → по подзаглавие;
• тикети → по тикет, с данни за статус и продукт;
• таблици → ред по ред, с повторени заглавия на колоните във всяко парче.

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

Търсенето само по вектори не стига

Векторното търсене е добро за „за какво става дума“, но слабо за точни неща — номер на договор, код на продукт, име на клиент. Комбинацията, която ползвам почти винаги:

1. Класическо търсене по ключови думи (BM25) — хваща точните съвпадения.
2. Векторно търсене — хваща перифразите.
3. Обединяване на двата резултата и пренареждане (reranking) с малък модел.

Тази комбинация обикновено вдига попаденията повече от смяната на голям модел с още по-голям — и е драстично по-евтина.

Метаданните решават достъпа

Ако различни хора имат право на различни документи, филтърът трябва да е преди търсенето, не след генерирането. Всяко парче носи със себе си отдел, ниво на достъп и дата. Иначе рано или късно моделът ще цитира на един служител нещо, което не му е работа да чете — а това е инцидент със сигурността, не бъг.

Проверката, преди да пуснеш системата на хората

Никакво внедряване без набор от въпроси с известни отговори. Минимумът:

• 30–50 реални въпроса, събрани от хората, които ще ползват системата;
• за всеки — кой документ съдържа отговора;
• измерване: в колко процента от случаите правилният документ изобщо е намерен и в колко отговорът е верен.

Без тези числа „подобрихме промпта“ е усещане, не факт.

Отговор без източник не се брои

Всеки отговор в системите, които правя, показва откъде идва — документ, страница, параграф. Две причини:

• Човекът може да провери за секунди, вместо да вярва.
• Когато моделът няма източник, това е ясен сигнал да каже „не намирам“, вместо да съчини.

Голяма част от доверието към системата се гради точно тук, а не от красотата на текста.

Какво бих направил различно

Ако започвам отначало, отделям първите две седмици само за данните: инвентаризация, чистене, правила за версиите. Скучно е, никой не иска да го плаща и е единственото, което определя дали проектът ще работи.