AI ინტერვიუს სერია 11: როგორ გავაუმჯობესოთ RAG?
RAG-ის გაუმჯობესება არ არის ერთი ეტაპის კორექტირება, არამედ სრული ჯაჭვის ოპტიმიზაციის პროცესი. ქვემოთ მოცემულია სისტემატური ოპტიმიზაციის სტრატეგიები მონაცემთა ინდექსირების, ძიების, გენერაციისა და შეფასების ოთხი განზომილებიდან, ასევე პრაქტიკული გამოცდილება, რომელიც შეგიძლიათ ახსენოთ ინტერვიუში.
1. მონაცემთა ინდექსირების მხარის ოპტიმიზაცია („ცოდნის ბაზის“ ხარისხის გაუმჯობესება)
ეს ყველაზე ხშირად იგნორირებული, მაგრამ ყველაზე სწრაფი შედეგის მომტანი ადგილია.
| ოპტიმიზაციის წერტილი | პრობლემის ფენომენი | კონკრეტული ქმედება | ეფექტურობის ინდიკატორი |
|---|---|---|---|
| დოკუმენტის ანალიზი | PDF-ში ცხრილები, ნაკადის დიაგრამები იგნორირებულია, ან ტექსტი არეულია, თანმიმდევრობა დარღვეულია. | გამოიყენეთ უკეთესი ანალიზის ბიბლიოთეკა (მაგ. unstructured, pypdf-ის განლაგების შესანახი რეჟიმი); ცხრილებისთვის გამოიყენეთ pandas ამოსაღებად და Markdown-ში გადასაყვანად. |
მოძიების სიხშირე +5~15% |
| ტექსტის ბლოკის ზომა | ძალიან პატარა chunk კარგავს კონტექსტს (მაგ. „მისი წლევანდელი შემოსავალი გაიზარდა“-ში „მისი“ მინიშნება იკარგება); ძალიან დიდი chunk იწვევს ძიების ხმაურს. | ექსპერიმენტი chunk size-ით (256/512/768 token), overlap 10~20%; გრძელი დოკუმენტებისთვის დაყავით სემანტიკური საზღვრების მიხედვით (პარაგრაფი/სათაური) და არა ფიქსირებული სიგრძით. | მოხვედრის სიხშირე / ერთგულება |
| მეტამონაცემების დამატება | ნაპოვნია შესაბამისი პასაჟი, მაგრამ შეუძლებელია წყაროს ან დროის მიკვლევა, ან საჭიროა ფილტრაცია სფეროს მიხედვით. | თითოეულ chunk-ს დაუმატეთ მეტამონაცემები: source (ფაილის სახელი/URL), timestamp, page_num, doc_type. ძიებისას გამოიყენეთ ფილტრები (მაგ. doc_type == 'legal'). |
ფილტრაციის სიზუსტე |
| Embedding მოდელის არჩევა | ზოგადი embedding ცუდად მუშაობს ვერტიკალურ სფეროებში (სამედიცინო, კოდი, იურიდიული). | გამოიყენეთ სფეროს მიხედვით fine-tuned მოდელი (BGE-large-zh, GTE-Qwen2-7B-instruct); ან დააფინეთულიეთ საკუთარი embedding მოდელი (triplet loss-ით). | ძიების MRR@10 +10~20% |
2. ძიების მხარის ოპტიმიზაცია („წიგნის გადაფურცვლის“ გაუმჯობესება)
ძიება განსაზღვრავს LLM-ისთვის მიწოდებული „სამაგალითო მასალის“ ხარისხს.
| ოპტიმიზაციის წერტილი | პრობლემის ფენომენი | კონკრეტული ქმედება | ეფექტი |
|---|---|---|---|
| ჰიბრიდული ძიება | ვექტორული ძიება ვერ ემთხვევა ზუსტ ტერმინებს (მაგ. პროდუქტის მოდელი ABC-123), საკვანძო სიტყვებზე დაფუძნებული ძიება ვერ ხვდება სინონიმებს. |
ერთდროულად გამოიყენეთ ვექტორული ძიება (სემანტიკური) და BM25 (საკვანძო სიტყვები), შეწონით (მაგ. 0.7ვექტორი + 0.3BM25) ან rerank-ის შერწყმით. | მოძიების სიხშირე +10~25% |
| ხელახალი რანჟირება (Rerank) | ვექტორული ძიების პირველი რამდენიმე შედეგი შეიძლება არ იყოს ყველაზე შესაბამისი, მე-10 კი საუკეთესო. | გამოიყენეთ cross‑encoder მოდელი (მაგ. BGE‑reranker-v2, Cohere Rerank) კანდიდატთა სიმრავლის (პირველი 20) ხელახალი შესაფასებლად, აიღეთ top‑K. |
მოხვედრის სიხშირე მნიშვნელოვნად იზრდება (განსაკუთრებით top‑1) |
| მოთხოვნის გადაწერა | მომხმარებლის შეკითხვა ბუნდოვანია ან მრავალრაუნდიან საუბარში მინიშნება გაურკვეველი („რა ფასი აქვს მას?“). | გამოიყენეთ LLM ორიგინალური შეკითხვის ძიებისთვის უფრო შესაფერის ფორმაში გადასაწერად (მაგ. „რა ღირს iPhone 15?“); ან გამოიყენეთ დიალოგის ისტორია შესავსებად. | მოძიების სიხშირე +5~15% |
| HyDE | მომხმარებლის შეკითხვა ძალიან მოკლეა ან ზედმეტად აბსტრაქტული (მაგ. „მომიყევი ფოტოსინთეზზე“), პირდაპირი ძიება ცუდია. | ჯერ LLM-ს დააგენერირებინეთ ჰიპოთეტური პასუხი, შემდეგ გამოიყენეთ ეს პასუხი დოკუმენტების მოსაძებნად. | გამოდგება ღია სფეროსთვის, მაგრამ არა ფაქტობრივი ზუსტი კითხვა-პასუხისთვის |
| Top‑K რეგულირება | ძალიან მცირე K-მ შეიძლება გამოტოვოს მნიშვნელოვანი ინფორმაცია; ძალიან დიდი K ზრდის token-ის მოხმარებას და ხმაურს. | ექსპერიმენტი K=3/5/10, დააკვირდით მოძიების სიხშირისა და პასუხის ერთგულების ბალანსს. | ეფექტურობასა და შედეგს შორის trade‑off |
3. გენერაციის მხარის ოპტიმიზაცია (LLM-ისთვის საცნობარო მასალის კარგად გამოყენება)
რაც არ უნდა კარგი იყოს ძიება, თუ პრომპტი ცუდია ან მოდელი სუსტი, შედეგი ვერ იქნება.
| ოპტიმიზაციის წერტილი | პრობლემის ფენომენი | კონკრეტული ქმედება | ეფექტი |
|---|---|---|---|
| პრომპტ ინჟინერია | LLM იგნორირებას უკეთებს მოძიებულ შინაარსს, ან ქმნის ფაქტებს. | მკაფიო ინსტრუქცია: „უპასუხეთ მხოლოდ მოწოდებულ საცნობარო მასალაზე დაყრდნობით. თუ ინფორმაცია არასაკმარისია ან არარელევანტური, უპასუხეთ ‘არ არის საკმარისი ინფორმაცია’.“ დაამატეთ few‑shot examples, რომელიც აჩვენებს, როგორ მივუთითოთ წყარო. | ერთგულება +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. | სამი ძირითადი ინდიკატორი: ერთგულება, პასუხის რელევანტურობა, კონტექსტის მოძიების სიხშირე. |
| ადამიანის შეფასება | ყოველ კვირას აირჩიეთ 20 bad case, გააანალიზეთ შეცდომის ტიპი (მოძიების წარუმატებლობა / გენერაციის შეცდომა / ცოდნის ბაზის ნაკლი). | გაუმჯობესების პრიორიტეტების დალაგება. |
| A/B ტესტირება | საწარმოო გარემოში ბალთა ტესტირება სხვადასხვა მოძიების სტრატეგიებისთვის (მაგ. BM25 vs ჰიბრიდული ძიება). | ონლაინ ინდიკატორები: მომხმარებლის კმაყოფილება, უპასუხობის სიხშირე. |
5. ინტერვიუში წარმოსაჩენი „პრაქტიკული გამოცდილება“ (დამატებითი ქულა)
„ჩემს RAG პროექტში, თავდაპირველად ბაზისური მოხვედრის სიხშირე იყო მხოლოდ 67%. მე გავაკეთე სამი რამ:
1. დაყოფა ფიქსირებული 1024-დან შეიცვალა დინამიკური სემანტიკური ჭრით (სათაურის+პარაგრაფის მიხედვით), მოხვედრის სიხშირე გაიზარდა 74%-მდე;
2. დაემატა ჰიბრიდული ძიება (ვექტორი + BM25) და მცირე rerank მოდელი, მოხვედრის სიხშირე გაიზარდა 83%-მდე;
3. გაუმჯობესდა პრომპტი და იძულებითი მოთხოვნა[შესაბამისი ინფორმაცია ვერ მოიძებნა], ჰალუცინაციის სიხშირე 22%-დან 5%-მდე შემცირდა.გარდა ამისა, ჩვენ შევქმენით უწყვეტი შეფასების pipeline, ყოველი ცვლილების წინ ვატარებდით 200 კითხვის RAGAS ქულის გაზომვას, რათა დავრწმუნებულიყავით, რომ არ იყო დეგრადაცია.“
ბოლო შეჯამება: RAG-ის ოპტიმიზაციის სრული საგზაო რუკა
მონაცემთა ფენა ─→ დოკუმენტების გაწმენდა, ბლოკების ოპტიმიზაცია, მეტამონაცემების გაძლიერება, სფეროს embedding
ძიების ფენა ─→ ჰიბრიდული ძიება, rerank, მოთხოვნის გადაწერა, HyDE, Top-K ოპტიმიზაცია
გენერაციის ფენა ─→ პრომპტის გაძლიერება, ინსტრუქციის მოთხოვნები, შეკუმშვა, ციტირება, უარყოფის ზღვარი
შეფასების ფენა ─→ შეფასების ნაკრები, RAGAS, ადამიანის ანალიზი, A/B ექსპერიმენტები
评论
暂无已展示的评论。
发表评论（匿名）