AI серия интервю въпрос 11: Как да оптимизираме RAG?

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

1. Оптимизация от страна на индексиране на данни (подобряване качеството на „базата знания“)

Това е най-лесно пренебрегваното място, което дава най-бързи резултати.

Оптимизационна точка	Проблем	Конкретни действия	Показател за ефективност
Разбор на документи	Таблици, диаграми в PDF се игнорират, или текстът е с грешни символи, разбъркан ред.	Използвайте по-добра библиотека за разбор (напр. `unstructured`, `pypdf` с режим на запазване на оформлението); за таблици извлечете с `pandas` и преобразувайте в Markdown.	Реколта +5~15%
Размер на текстовите части	Твърде малки части губят контекст (напр. "той увеличи приходите тази година" — загуба на препратка "той"); твърде големи части водят до много шум при извличане.	Експериментирайте с различни размери на части (256/512/768 токена), припокриване 10~20%; за дълги документи разделяйте по семантични граници (параграфи/заглавия), а не по фиксирана дължина.	Процент на попадения / точност
Добавяне на метаданни	Извлечени са съответстващи части, но не може да се проследи източникът или времето, или трябва да се филтрира по област.	Добавете метаданни за всяка част: `source` (име на файл/URL), `timestamp`, `page_num`, `doc_type`. При извличане използвайте филтри (напр. `doc_type == 'legal'`).	Прецизност на филтриране
Избор на модел за вграждане	Общите embedding модели се представят зле в специализирани области (медицина, код, право).	Използвайте фино настроени модели за областта (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); или настройте свой собствен embedding модел (с triplet loss).	MRR@10 при извличане +10~20%

2. Оптимизация от страна на извличане (по-точно „прелистване“)

Извличането определя качеството на „справочния материал“, подаван на LLM.

Оптимизационна точка	Проблем	Конкретни действия	Ефект
Хибридно извличане	Векторното извличане не може да съвпадне с точни термини (напр. модел продукт `ABC-123`), а ключовото извличане не разбира синоними.	Едновременно използвайте векторно извличане (семантично) и BM25 (ключови думи), като ги комбинирате с тежести (напр. 0.7вектор + 0.3BM25) или чрез пренареждане.	Реколта +10~25%
Пренареждане (Rerank)	Първите няколко резултата от векторното извличане не са непременно най-релевантни; десетият може да е най-добър.	Използвайте cross‑encoder модел (напр. `BGE‑reranker-v2`, Cohere Rerank), за да оцените отново кандидат-множество (напр. първите 20) и вземете top‑K.	Значително подобрение на процента на попадения (особено top‑1)
Пренаписване на заявка	Въпросът на потребителя е неясен или в многократен разговор препратките са неясни („каква е цената му?“).	Използвайте LLM, за да преформулирате оригиналния въпрос във форма, по-подходяща за извличане (напр. „Каква е цената на iPhone 15?“); или попълнете с помощта на историята на разговора.	Реколта +5~15%
HyDE	Въпросът на потребителя е твърде кратък или абстрактен (напр. „обясни фотосинтезата“), директното извличане е неефективно.	Първо накарайте LLM да генерира хипотетичен отговор, след което използвайте този отговор за извличане на документи.	Подходящ за отворени области, но не за точно фактическо отговаряне
Настройка на брой извлечени Top‑K	Твърде малко K може да пропусне ключова информация; твърде голямо K увеличава разхода на токени и шум.	Експериментирайте с K=3/5/10, наблюдавайте баланса между реколта и точност на отговора.	Компромис между ефективност и резултат

3. Оптимизация от страна на генериране (да накараме LLM да използва добре справочните материали)

Колкото и точно да е извличането, ако подканата е лоша или моделът не е добър, няма да работи.

Оптимизационна точка	Проблем	Конкретни действия	Ефект
Инженеринг на подкани	LLM игнорира извлеченото съдържание или измисля.	Ясна инструкция: „Отговаряйте само въз основа на предоставените справочни материали по-долу. Ако материалите са недостатъчни или нерелевантни, отговорете „Няма достатъчно информация“.“ Добавете few‑shot примери, показващи как да се цитират източници.	Точност +20~40%
Компресиране на контекст	Извлеченото съдържание е твърде дълго (надвишава прозореца на модела) или съдържа много шум.	Използвайте `LLMLingua` или `селективен контекст`, за да компресирате, запазвайки най-релевантните изречения, преди да ги подадете на LLM.	Намаляване на риска от загуба на информация
Обновяване на LLM модела	Малък модел (7B) не може да извърши сложни разсъждения или не помни дълъг контекст.	Преминете към по-силен модел (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Значително подобрение на точността на разсъжденията
Поточна обработка и цитиране	Потребителят не може да провери достоверността на отговора.	По време на генериране накарайте LLM да изведе `[citation:1]`, съответстващ на номера на извлечения документ. От страна на сървъра приложете връзка към оригиналния текст.	Доверие на потребителя + възможност за отстраняване на грешки
Калибриране на отказ за отговор	Моделът измисля, когато не трябва да отговаря, или казва, че не знае, когато трябва да отговори.	Задайте праг на сходство: ако косинусовото сходство между top‑1 част и въпроса е под 0.7, инструктирайте LLM „Материалът не е релевантен“.	Намаляване на процента на халюцинации

4. Страна на оценка и итерация (знам къде да настройвам)

Без измерване не може да се оптимизира.

Оптимизационна точка	Действие	Показател
Създаване на оценителен набор	Подгответе 100~300 реални потребителски въпроса + стандартни отговори + правилни ID на извлечени документи.	Покритие на различни трудности и намерения.
Автоматизирана оценка	Използвайте RAGAS (Faithfulness, Answer Relevance, Context Recall) или TruLens.	Три основни показателя: точност, релевантност на отговора, реколта на контекста.
Ръчна оценка	Всяка седмица тествайте 20 лоши случая, анализирайте типовете грешки (неуспех при извличане / грешка при генериране / липсваща база знания).	Приоритизиране на подобренията.
A/B тестване	В производствена среда разделете трафика за тестване на различни стратегии за извличане (напр. BM25 спрямо хибридно извличане).	Онлайн показатели: удовлетвореност на потребителите, процент на безотговорност.

5. „Практически опит“, който можете да споменете на интервю (бонус точки)

„В проекта за RAG, за който отговарях, първоначалният процент на попадение беше само 67%. Направих три неща:
1. Промених разделянето от фиксирани 1024 на динамично семантично разделяне (по заглавия и параграфи), което увеличи процента на попадение на 74%;
2. Добавих хибридно извличане (вектор + BM25) и малък rerank модел, което увеличи процента на попадение на 83%;
3. Оптимизирах подканата и задължително изисквах [Не е намерена съответстваща информация], като по този начин намалих процента на халюцинации от 22% до под 5%.

Освен това създадохме непрекъснат тръбопровод за оценка, като преди всяка промяна пускахме RAGAS резултати за 200 въпроса, за да гарантираме, че няма влошаване.“

Обобщение: Пълна пътна карта за оптимизация на RAG

Слой данни ─→ Почистване на документи, оптимизация на разделяне, обогатяване на метаданни, embedding за областта
Слой извличане ─→ Хибридно извличане, пренареждане, пренаписване на заявка, HyDE, настройка на Top-K
Слой генериране ─→ Усилване на подкани, изисквания в инструкциите, компресия, цитиране, праг за отказ
Слой оценка ─→ Оценителен набор, RAGAS, ръчен анализ, A/B експерименти