Розробка RAG-системи (Retrieval-Augmented Generation)

Розробка RAG-системи (Retrieval-Augmented Generation)

RAG (Retrieval-Augmented Generation) — архітектура, в якій мовна модель при генерації відповіді звертається до зовнішнього сховища знань. Замість того, щоб спиратися лише на знання, «вбудовані» у ваги під час передnavegуванння, модель отримує релевантний контекст на момент інференса. Це дозволяє працювати з актуальними даними, корпоративними документами та спеціалізованими базами знань без дорогих fine-tuning.

Базова архітектура RAG

Користувач → Запит
              ↓
        Embedding-модель
              ↓
       Векторний пошук (Top-K)
              ↓
   Вилучені чанки + запит
              ↓
             LLM
              ↓
           Відповідь

Компоненти:

• Indexing pipeline: завантаження документів, розділення на чанки, embedding, збереження у векторну БД
• Retrieval: переведення запиту у вектор, пошук найближчих сусідів
• Generation: передача контексту + запиту в LLM

Стек для RAG-системи

Пайплайн індексації

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Qdrant
from langchain_community.document_loaders import PyPDFDirectoryLoader

# Завантаження документів
loader = PyPDFDirectoryLoader("./docs/")
documents = loader.load()

# Розділення на чанки
splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=64,
    separators=["\n\n", "\n", ".", " "],
)
chunks = splitter.split_documents(documents)

# Embedding та збереження
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = Qdrant.from_documents(
    chunks,
    embeddings,
    url="http://localhost:6333",
    collection_name="corporate-docs",
    force_recreate=True,
)

Пайплайн відповіді на запит

from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA
from langchain.prompts import ChatPromptTemplate

template = """Ви — помічник, що відповідає строго на основі наданого контексту.
Якщо відповідь не містяться в контексті, скажіть "Інформація не знайдена в базі знань".
Завжди вказуйте джерело (назву документа та розділ).

Контекст:
{context}

Запитання: {question}

Відповідь:"""

prompt = ChatPromptTemplate.from_template(template)
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# Retrieval + Generation
retriever = vectorstore.as_retriever(
    search_type="mmr",   # Maximum Marginal Relevance — зменшує дублювання
    search_kwargs={"k": 5, "fetch_k": 20}
)

qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=retriever,
    chain_type_kwargs={"prompt": prompt},
    return_source_documents=True,
)

result = qa_chain.invoke({"query": "Який строк гарантійного обслуговування?"})

Практичний кейс: RAG для страхової компанії

Завдання: помічник для обробки звернень клієнтів — пошук у договорах страхування, правилах виплат, прецедентних рішеннях (12 000 документів, ~2M сторінок).

Ключові рішення:

Embedding: BGE-M3 (багатомовна, добре працює з українською, безкоштовна self-hosted). Розмірність 1024.

Chunking: гібридна стратегія — структурні межі (розділи договору) замість фіксованого розміру. Розмір чанку 200–600 токенів.

Reranking: CrossEncoder після векторного пошуку. Top-50 кандидатів → Top-5 після rerank. +18% до faithfulness.

Метрики (RAGAS):

Розмір чанку: як вибирати

• Малі чанки (128–256 токенів): висока точність retrieval, але можуть не містити повний контекст для відповіді. Добро для FAQ та коротких фактів.
• Середні чанки (512–1024 токенів): збалансований підхід. Оптимум для більшості завдань.
• Великі чанки (1024–2048 токенів): охоплюють більше контексту, але погіршують точність retrieval. Для документів з довгими взаємопов'язаними розділами.

Parent Document Retriever — рішення дилеми: індексуємо малі чанки для пошуку, повертаємо великі чанки в LLM.

Строки розробки RAG-системи

• Прототип (базовий RAG): 1–2 тижні
• Production-ready система з оцінкою якості: 4–8 тижнів
• Розширена RAG (hybrid search, reranking, evaluation): 8–14 тижнів