Data: модельге жады қалай беруге болады

Модель өте ақылды бола тұра, компания туралы ештеңе білмеуі мүмкін. Ол оқыту деректеріндегі жалпы заңдылықтарды біледі, бірақ бүгін қандай тариф қолданыста екенін немесе нақты клиенттің шартында не жазылғанын білмейді.

Бұл мәселені шешудің екі жолы бар: модельдің өзін өзгерту немесе оған сұрау кезінде қажетті ақпаратқа қолжетімділік беру. Екінші тәсіл үшін RAG — Retrieval-Augmented Generation қолданылады.

Мәтіннен жауапқа дейінгі жолды қарастырамыз: Embeddings → Vector DB → Retrieval → Reranking → RAG.

Embeddings: мағынаны сандарға қалай айналдыруға болады

📌 Бұл не: мәтіннің сандық көрінісі, фрагменттерді мағыналық жақындығы бойынша салыстыруға мүмкіндік береді.

✅ Мақсаты: іздеу тек бірдей сөздерді ғана емес, мағынаны да табу үшін. «Тауарды қалай қайтаруға болады?» сұрауы «Қайтару тәртібі» құжатын табады.

⚠️ Шектеу: семантикалық жақындық әрқашан релеванттылықты білдірмейді. Артикулдар, шарт нөмірлері мен кодтар көбіне keyword немесе hybrid search талап етеді.

Vector DB: embeddings қайда сақталады

📌 Бұл не: векторларды метадеректермен бірге сақтау және іздеу жүйесі (құжат, дереккөз, күні, қолжетімділік құқықтары).

⚠️ Немен шатастырады: әдеттегі дерекқормен. Vector DB PostgreSQL немесе MongoDB-ды алмастырмайды. Олар әртүрлі міндеттерді шешеді және нақты жүйеде бірге жұмыс істейді.

✅ Танымал шешімдер: Pinecone (бұлттық, оңай бастау), Weaviate (open-source, икемлі), Qdrant (жылдам), pgvector (PostgreSQL үшін кеңейту).

RAG: модельге қайта оқытпай-ақ білім қалай беруге болады

💻 Схема: Сұрау → іздеу → релевантті фрагменттер → контекст → модель → жауап.

✅ Басты артықшылығы: білімді модель салмақтарын өзгертпей-ақ жаңартуға болады. Базаға жаңа құжат қосылды — индекстеуден кейін жүйе оны жауаптарда бірден қолдана алады.

⚠️ RAG жеткіліксіз болатын жағдайлар: ол ақпаратқа қолжетімділік мәселесін жақсы шешеді, бірақ модельдің арнайы мінез-құлықты немесе форматты тұрақты сақтауын кепілдендірмейді. Бұл үшін адаптация қажет.

Chunking: құжаттарды қалай бөлуге болады

Модель шексіз құжатпен тиімді жұмыс істей алмайды. Мәтіндер индекстеу үшін chunks (фрагменттерге) бөлінеді.

📌 Fixed-size: бірдей өлшемдегі фрагменттерге бөлу. Қарапайым, бірақ шекара маңызды ойдың дәл ортасынан өтуі мүмкін.

📌 Structure-aware: жүйе тақырыптарды, бөлімдерді және абзацтарды ескеріп, мағыналық байланыстарды сақтайды.

⚠️ Басты мәселе: тым кіші chunk контекстен айырылады, тым үлкені шуыл қосып, өңдеу құнын арттырады. Өлшем нақты міндетке қарай таңдалады.

Retrieval + Reranking: шынымен қажеттіні қалай табуға болады

Алғашқы іздеу ұқсас, бірақ ең пайдалы емес құжаттарды көп қайтаруы мүмкін. Сондықтан екі кезеңді архитектура қолданылады:

1️⃣ Retrieval: жүйе үміткерлер жиынын жылдам табады (мысалы, білім базасынан 100 фрагмент).

2️⃣ Reranking: дәлірек, бірақ баяу модель осы 100 фрагментті қайта бағалап, LLM-ге беру үшін ең релеванты топ-10-ын таңдайды.

Бұл жылдамдық (жедел алғашқы іздеу) пен дәлдік (сапалы reranking) арасындағы тамаша баланс.

---

Дереккөздер:

• [Hugging Face Blog](https://huggingface.co/blog)

• [The Batch — Andrew Ng](https://www.deeplearning.ai/the-batch/)

• [Artificial Analysis](https://artificialanalysis.ai/)

• [REAL DIGITAL](https://t.me/digitalreal)