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'`).	Прецизност на филтрирање
Избор на модел за вградување	Генеричките вградувања се слаби во вертикални домени (медицина, код, право).	Користете дотеран модел за доменот (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); или дотерете свој модел за вградување (со 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]` што одговара на бројот на пронајдениот документ. На backend додајте линк до оригиналниот текст.	Доверба на корисникот + можност за дебагирање
Калибрација на одбивање одговор	Моделот измислува кога не треба, или вели „не знам“ кога треба да одговори.	Поставете праг на сличност: ако косинусната сличност помеѓу 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%.

Исто така, изградивме континуиран евалуациски pipeline, пред секоја промена пуштавме 200 прашања преку RAGAS за да се осигураме дека нема регресија.“

Последен заклучок: Комплетна патна карта за оптимизација на RAG

Податочен слој ─→ чистење на документи, оптимизација на поделба, зголемување на метаподатоци, domain вградување
Слој за пребарување ─→ хибридно пребарување, повторно рангирање, препишување прашања, HyDE, прилагодување на Top-K
Слој за генерирање ─→ зајакнување на промптови, барања за инструкции, компресија, цитати, праг на одбивање
Слој за евалуација ─→ евалуациски сет, RAGAS, рачна анализа, A/B експерименти