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 тік салаларда (медицина, код, құқық) нашар жұмыс істейді. | Салаға бейімделген модельдерді қолдану (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 сынау, еске түсіру мен жауап адалдығының тепе-теңдігін бақылау. | Тиімділік пен нәтиже арасындағы ымыра |
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 нашар жағдайды сынау, қате түрлерін талдау (іздеу сәтсіздігі / генерация қатесі / білім қорының жетіспеушілігі). | Жақсарту басымдықтарын реттеу. |
| A/B тестілеу | Өндірістік ортада әртүрлі іздеу стратегияларын (мысалы, BM25 қарсы аралас іздеу) бақылау. | Онлайн көрсеткіштер: пайдаланушы қанағаттануы, жауапсыздық деңгейі. |
5. Сұхбатта айтуға болатын «практикалық тәжірибелер» (бонустық пункт)
«Мен жауапты RAG жобасында бастапқы хит жылдамдығы 67% болды. Мен үш нәрсе жасадым:
1. Бөлшектеуді тұрақты 1024-тен динамикалық семантикалық бөлуге ауыстырдым (тақырып+абзац бойынша), хит жылдамдығы 74%-ке жетті;
2. Аралас іздеуді (вектор + BM25) және шағын rerank моделін қостым, хит жылдамдығы 83%-ке көтерілді;
3. Нұсқаулықты оңтайландырып, «[Тиісті ақпарат табылмады]» дегенді міндеттедім, галлюцинация деңгейі 22%-тен 5%-ке дейін төмендеді.Сонымен қатар, біз үздіксіз бағалау конвейерін құрдық, әр өзгеріс алдында 200 сұрақтан тұратын RAGAS ұпайын есептеп, ешқандай регрессия болмауын қамтамасыз еттік.»
Қорытынды: Толық RAG оңтайландыру жол картасы
Деректер қабаты ─→ Құжаттарды тазалау, бөлшектеуді оңтайландыру, метадеректерді күшейту, салалық embedding
Іздеу қабаты ─→ Аралас іздеу, rerank, сұрауды қайта жазу, HyDE, Top-K оңтайландыру
Генерация қабаты ─→ Нұсқаулықты күшейту, нұсқау талаптары, сығымдау, сілтеме, бас тарту шегі
Бағалау қабаты ─→ Бағалау жиынтығы, RAGAS, қолмен талдау, A/B эксперименті
评论
暂无已展示的评论。
发表评论(匿名)