Въпроси за интервю от 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 (Вярност, Релевантност на отговора, Припомняне на контекст) или TruLens.	Три основни показателя: вярност, релевантност на отговора, припомняне на контекст.
Ръчна оценка	Всяка седмица тествайте 20 лоши случая, анализирайте видовете грешки (неуспешно извличане / грешка при генериране / липса в базата знания).	Приоритизиране на подобрения.
A/B тестване	В производствена среда разделете на групи за тестване на различни стратегии за извличане (напр. BM25 срещу хибридно търсене).	Онлайн показатели: удовлетвореност на потребителите, процент без отговор.

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

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

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

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

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