AI-ի հարցազրույցի հարցեր 11. Ինչպե՞ս օպտիմալացնել RAG-ը:

RAG-ի օպտիմալացումը մեկ մասի ճշգրտում չէ, այլ ամբողջական շղթայի օպտիմալացման գործընթաց: Ստորև ես կներկայացնեմ համակարգային օպտիմալացման ռազմավարություններ տվյալների ինդեքսավորման, որոնման, գեներացիայի և գնահատման չորս հարթություններում, ինչպես նաև կկցեմ գործնական փորձ, որի մասին կարելի է հիշատակել հարցազրույցի ժամանակ:

1. Տվյալների ինդեքսավորման կողմի օպտիմալացում («Գիտելիքների բազայի» որակի բարձրացում)

Սա ամենահաճախ անտեսվող, բայց ամենաարագ արդյունք տվող կետն է:

Օպտիմալացման կետ	Խնդիր	Կոնկրետ մոտեցում	Արդյունավետության ցուցանիշ
Փաստաթղթերի վերլուծություն	PDF-ի աղյուսակները, դիագրամները անտեսվում են, կամ տեքստը խառն է, հերթականությունը խախտված:	Օգտագործել ավելի լավ վերլուծական գրադարան (օրինակ՝ `unstructured`, `pypdf`-ի layout պահպանման ռեժիմ); աղյուսակները հանել `pandas`-ով և վերածել Markdown-ի:	Recall +5~15%
Տեքստի հատվածի չափ	Chunk-ը չափազանց փոքր է, կորցնում է կոնտեքստը (օրինակ՝ «Նրա եկամուտն այս տարի աճել է»-ում «նրա»-ի հղումը կորչում է); chunk-ը չափազանց մեծ է, որոնման աղմուկը մեծանում է:	Փորձարկել տարբեր chunk size (256/512/768 token), overlap դնել 10~20%; երկար փաստաթղթերի համար կտրել իմաստային սահմաններով (պարբերություն/վերնագիր)՝ ոչ թե ֆիքսված երկարությամբ:	Hit rate / Fidelity
Մետատվյալների ավելացում	Գտնվել է համապատասխան հատված, բայց հնարավոր չէ հետևել աղբյուրին կամ ժամանակին, կամ անհրաժեշտ է զտել ըստ ոլորտի:	Յուրաքանչյուր chunk-ին ավելացնել մետատվյալներ՝ `source` (ֆայլի անուն/URL), `timestamp`, `page_num`, `doc_type`: Որոնման ժամանակ օգտագործել ֆիլտրեր (օրինակ՝ `doc_type == 'legal'`):	Զտման ճշգրտություն
Ներդրման մոդելի ընտրություն	Ընդհանուր embedding-ը վատ է աշխատում ուղղահայաց ոլորտներում (բժիշկ, կոդ, իրավունք):	Օգտագործել ոլորտում միկրո-ճշգրտված մոդելներ (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); կամ միկրո-ճշգրտել սեփական embedding մոդելը (triplet loss-ով):	Retrieval MRR@10 +10~20%

2. Որոնման կողմի օպտիմալացում («Գրքերի թերթումը» ավելի ճշգրիտ դարձնել)

Որոնումը որոշում է LLM-ին մատակարարվող «հղումների» որակը:

Օպտիմալացման կետ	Խնդիր	Կոնկրետ մոտեցում	Արդյունք
Հիբրիդային որոնում	Վեկտորային որոնումը չի կարողանում ճշգրիտ համապատասխանեցնել տերմինները (օրինակ՝ ապրանքի մոդել `ABC-123`), հիմնաբառային որոնումը չի հասկանում հոմանիշները:	Միաժամանակ օգտագործել վեկտորային (իմաստային) և BM25 (հիմնաբառային) որոնումը, միավորել կշռված ձևով (օրինակ՝ 0.7վեկտոր + 0.3BM25) կամ rerank-ի միջոցով:	Recall +10~25%
Վերադասակարգում (Rerank)	Վեկտորային որոնման առաջին արդյունքները ոչ միշտ են ամենահամապատասխանը, 10-րդն ավելի լավն է:	Օգտագործել cross‑encoder մոդել (օրինակ՝ `BGE‑reranker-v2`, Cohere Rerank)՝ թեկնածուների բազմությունը (օրինակ՝ առաջին 20) վերագնահատելու համար, վերցնել top‑K:	Hit rate-ի զգալի բարելավում (հատկապես top‑1)
Հարցման վերագրում	Օգտատիրոջ հարցը անորոշ է կամ բազմակի խոսակցություններում հղումները պարզ չեն («Դրա գինը՞»):	Օգտագործել LLM՝ սկզբնական հարցը վերափոխելու որոնման համար ավելի հարմար ձևի (օրինակ՝ «Որքա՞ն է iPhone 15-ի գինը»); կամ լրացնել խոսակցության պատմության միջոցով:	Recall +5~15%
HyDE	Օգտատիրոջ հարցը շատ կարճ է կամ վերացական (օրինակ՝ «Պատմիր ֆոտոսինթեզի մասին»), ուղիղ որոնումը վատ է:	Նախ թույլ տալ LLM-ին գեներացնել հիպոթետիկ պատասխան, ապա օգտագործել այդ պատասխանը փաստաթղթեր որոնելու համար:	Հարմար է բաց տիրույթի համար, բայց ոչ ճշգրիտ փաստական հարցերի
Որոնման Top‑K ճշգրտում	K-ն շատ փոքր է, կարող է բաց թողնել կարևոր ինֆորմացիա; K-ն շատ մեծ է, ավելացնում է tokens-ի ծախսն ու աղմուկը:	Փորձարկել K=3/5/10, դիտարկել recall-ի և պատասխանի հավատարմության հավասարակշռությունը:	Արդյունավետության և էֆեկտի trade‑off

3. Գեներացիայի կողմի օպտիմալացում (LLM-ին ստիպել լավ օգտագործել հղումները)

Որոնումը որքան էլ ճշգրիտ լինի, եթե prompt-ը վատ է կամ մոդելը թույլ է, արդյունքը չի լինի:

Օպտիմալացման կետ	Խնդիր	Կոնկրետ մոտեցում	Արդյունք
Prompt ինժեներիա	LLM-ն անտեսում է որոնված բովանդակությունը կամ հորինում է:	Հստակ հրահանգ՝ «Պատասխանել միայն տրված հղումների հիման վրա: Եթե ինֆորմացիան անբավարար է կամ առնչություն չունի, ասել «Բավարար ինֆորմացիա չկա»:» Ավելացնել few‑shot examples, որոնք ցույց են տալիս, թե ինչպես մեջբերել աղբյուրը:	Fidelity +20~40%
Համատեքստի սեղմում	Որոնված բովանդակությունը շատ երկար է (գերազանցում է մոդելի կոնտեքստային պատուհանը) կամ մեծ մասը աղմուկ է:	Օգտագործել `LLMLingua` կամ «ընտրովի համատեքստ» սեղմում, պահել ամենահամապատասխան նախադասությունները, այնուհետև ուղարկել LLM-ին:	Ինֆորմացիայի կորստի ռիսկի նվազեցում
LLM մոդելի թարմացում	Փոքր մոդելը (7B) չի կարող բարդ տրամաբանություն կատարել կամ հիշել երկար կոնտեքստը:	Փոխել ավելի ուժեղ մոդելի (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B):	Տրամաբանության ճշգրտության զգալի բարելավում
Հոսքային ցուցադրում և մեջբերումներ	Օգտատերը չի կարող ստուգել պատասխանի հավաստիությունը:	Գեներացիայի ժամանակ LLM-ին թույլ տալ արտածել `[citation:1]`, որը համապատասխանում է որոնված փաստաթղթի համարին: Հետին մասում կցել հղումը:	Օգտատիրոջ վստահություն + վրիպազերծման հնարավորություն
Պատասխանելու մերժման կալիբրացիա	Մոդելը հորինում է, երբ չպետք է, կամ ասում է «չգիտեմ», երբ պետք է պատասխանի:	Սահմանել նմանության շեմ. եթե որոնված top‑1 chunk-ի կոսինուսային նմանությունը հարցի հետ 0.7-ից ցածր է, հրահանգել LLM-ին «տվյալները չեն համապատասխանում»:	Հալուցինացիայի մակարդակի նվազեցում

4. Գնահատում և կրկնություն (իմանալ, թե ուր կարգավորել)

Առանց չափման հնարավոր չէ օպտիմալացնել:

Օպտիմալացման կետ	Մոտեցում	Ցուցանիշ
Գնահատման հավաքածուի ստեղծում	Պատրաստել 100~300 իրական օգտատիրոջ հարց + ստանդարտ պատասխան + ճիշտ որոնված փաստաթղթի ID:	Ընդգրկել տարբեր բարդության և մտադրության հարցեր:
Ավտոմատ գնահատում	Օգտագործել RAGAS (Faithfulness, Answer Relevance, Context Recall) կամ TruLens:	Երեք հիմնական ցուցանիշ՝ հավատարմություն, պատասխանի համապատասխանություն, համատեքստի recall:
Ձեռքով գնահատում	Շաբաթը մեկ ընտրել 20 bad case, վերլուծել սխալի տեսակը (որոնման ձախողում / գեներացիայի սխալ / գիտելիքների բազայի բացակայություն):	Բարելավման առաջնահերթությունների որոշում:
A/B թեստավորում	Արտադրական միջավայրում բաժանել խմբերի և փորձարկել տարբեր որոնման ռազմավարություններ (օրինակ՝ BM25 vs հիբրիդային որոնում):	Առցանց ցուցանիշներ՝ օգտատիրոջ գոհունակություն, պատասխանի բացակայության մակարդակ:

5. Հարցազրույցում ասելիք «գործնական փորձ» (լրացուցիչ միավոր)

«Իմ պատասխանատվությամբ RAG նախագծում սկզբնական baseline hit rate-ը 67% էր: Ես երեք բան արեցի.
1. Հատվածի չափը ֆիքսված 1024-ից փոխեցի դինամիկ իմաստային կտրման (ըստ վերնագրի+պարբերության), hit rate-ը դարձավ 74%;
2. Ավելացրի հիբրիդային որոնում (վեկտոր + BM25) և փոքր rerank մոդել, hit rate-ը բարձրացավ 83%;
3. Օպտիմալացրի prompt-ը և պարտադրեցի «[Չգտնվեց համապատասխան ինֆորմացիա]», հալուցինացիայի մակարդակը 22%-ից իջավ 5%-ից ցածր:

Բացի այդ, մենք ստեղծեցինք շարունակական գնահատման pipeline, յուրաքանչյուր փոփոխությունից առաջ 200 հարցով RAGAS միավորներ հավաքելով՝ համոզվելու, որ դեգրադացիա չկա:»

Վերջնական ամփոփում. RAG-ի օպտիմալացման ամբողջական ուղեգիծ

Տվյալների շերտ ─→ Փաստաթղթերի մաքրում, հատվածի օպտիմալացում, մետատվյալների ուժեղացում, ոլորտային embedding
Որոնման շերտ ─→ Հիբրիդային որոնում, rerank, հարցման վերագրում, HyDE, Top‑K ճշգրտում
Գեներացիայի շերտ ─→ Prompt-ի ուժեղացում, հրահանգների պահանջ, սեղմում, մեջբերում, մերժման շեմ
Գնահատման շերտ ─→ Գնահատման հավաքածու, RAGAS, ձեռքով վերլուծություն, A/B փորձ