Пошаговое руководство по настройке Retrieval-Augmented Generation для поиска по корпоративным документам и личным архивам. Практические рекомендации по чанкованию, выбору embeddings, хранению векторов и интеграции с LLM (с конкретными цифрами и кодом).
Статья была полезной?
RAG (Retrieval-Augmented Generation) — это комбинация поиска по документам и генеративной модели, позволяющая LLM выдавать точные ответы на вопросы, опираясь на релевантные фрагменты корпуса. Ниже покажу рабочий процесс с цифрами, командами и кодом, чтобы за 1–3 дня получить рабочий прототип поиска по своим документам.
RAG — подход, где на запрос пользователя сначала выполняется поиск релевантных фрагментов векторами (retrieval), а затем LLM использует найденные фрагменты в подсказке (augmentation) для генерации ответа. Это снижает выдумки (hallucination) у модели и ограничивает её знания базой документов. Практический пример: у вас 50 000 служебных записок, 15 ГБ PDF и 1000 презентаций — RAG позволяет быстро найти и сформулировать ответ, опираясь на конкретные абзацы.
Конкретика: сформируйте корус в формате текстов — PDF, DOCX, HTML, TXT. Для начала целевой объём 0.5–10 ГБ: 10 000–100 000 документов. На этапе сбора учтите метаданные: дата, автор, источник. Для прототипа 1 000 документов (≈0.5–1 ГБ) хватает, на продакшн рекомендуют 50 000+ документов.
pdfminer.six или pypdf для PDF, python-docx для DOCX, встроенный парсер для HTML.# Пример: парсинг PDF -> текст (python, pypdf)
from pypdf import PdfReader
with open('document.pdf','rb') as f:
reader = PdfReader(f)
text = '
'.join(p.extract_text() or '' for p in reader.pages)Разбейте документы на фрагменты (chunks) понятного размера. Рекомендуемые параметры: 200–500 токенов на чанк с перекрытием 50–100 токенов. В символах это примерно 800–2500 символов на чанк в зависимости от языка и стиля.
doc_id, chunk_id, offset, source_url, date. Это позволит показывать пользователю источник ответа.# Чанкование на 400 токенов с overlap 100 (пример на простом разбиении по словам)
def chunk_text(text, tokens_per_chunk=400, overlap=100):
words = text.split()
chunks = []
i = 0
while i < len(words):
chunk = ' '.join(words[i:i+tokens_per_chunk])
chunks.append(chunk)
i += tokens_per_chunk - overlap
return chunksEmbeddings — векторы фиксированной размерности, представляющие смысл фрагмента. В 2025–2026 рекомендую ориентироваться на размерность 768–1536 для типичных задач поиска: 768 — быстрее и дешевле, 1536 — точнее при большом объёме данных.
sentence-transformers/all-MiniLM-L6-v2 (384 dim) — 10–20 мс на вектор на GPU A100; all-mpnet-base-v2 (768 dim) — 20–50 мс/вектор на GPU T4. Стоимость GPU в облаке (p3a/p4) ~0.50–3.00 USD/час в 2025 году.# Пример генерации embeddings через OpenAI (python, 2025)
from openai import OpenAI
client = OpenAI()
texts = ['Первый фрагмент', 'Второй фрагмент']
emb = client.embeddings.create(model='text-embedding-3-large', input=texts)
vectors = [e['embedding'] for e in emb['data']]Выбор хранилища зависит от объёма и SLA. Для прототипа подойдёт FAISS или Chroma на одной машине. Для продакшн 50k+ векторов используйте Qdrant, Milvus или Pinecone — они поддерживают репликацию и масштабирование.
# Сохранение в FAISS и метаданные в numpy
import faiss
import numpy as np
vectors = np.array(vectors).astype('float32') # shape (N, D)
index = faiss.IndexFlatIP(vectors.shape[1]) # cosine через нормализацию
faiss.normalize_L2(vectors)
index.add(vectors)
faiss.write_index(index, 'index.faiss')
np.save('metadata.npy', np.array(metadata, dtype=object))Схема простая: на запрос пользователя — генерация embedding запроса, ближайший поиск в векторной БД (к примеру топ-5), сбор фрагментов и передача их LLM в подсказке. Важно: ограничьте токены контекста (часто 2–5 фрагментов по 400 токенов) и используйте шаблон подсказки с явными инструкциями о цитировании источников.
# Псевдокод процесса RAG (python)
query = 'Как настроить бэкап базы данных в PostgreSQL?'
q_emb = client.embeddings.create(model='text-embedding-3-large', input=query)['data'][0]['embedding']
# поиск top_k
D, I = index.search(np.array([q_emb], dtype='float32'), k=5)
context = '
'.join(metadata[i]['text'] for i in I[0])
prompt = f"Ответь кратко, опираясь на источники:
{context}
Вопрос: {query}"
resp = client.chat.completions.create(model='gpt-4o-mini', messages=[{'role':'user','content':prompt}])
print(resp.choices[0].message.content)Рекомендации по качеству ответов:
Выбор зависит от бюджета, объёма и требования к латентности. Привожу проверенные рекомендации на 2025–2026 год с конкретикой.
sentence-transformers/all-MiniLM-L6-v2 — 384 dim, быстрое локальное исполнение на CPU, точность хорошая для коротких текстов. На CPU 8‑ядрах обработка 10k фрагментов займёт 1–3 часа.all-mpnet-base-v2 — 768 dim; локально на GPU T4 ~50–100 ms/вектор, облачная обработка 100k фрагментов займёт 1–3 часа при batch=512.hkunlp/instructor-xl) — лучше сохраняют юридические/медицинские нюансы.Практический подбор: если у вас 10k документов, начните с local MPNet (768) и сравните точность на контрольном наборе из 100 запросов. Если точность <75% — переходите на 1536-d коммерческий embedding.
Опции: файловая система (FAISS index + npy), self-hosted DB (Qdrant, Milvus), managed (Pinecone). Выбор зависит от SLA, бюджета и команды поддержки. Ниже — конкретные схемы хранения и резервирования.
Измеряйте точность retrieval и RAG-ответа. Набор метрик и конкретика:
Планируйте CI/CD для индексации: инкрементальная генерация эмбеддингов при появлении новых документов, ежедневные/почасовые задания. Рекомендуемая архитектура при 24/7: разделение ingestion (ETL), embeddings сервис, векторная БД, сервис RAG (API) и frontend.
Показывайте источник и контекст. UX влияет на доверие пользователей сильнее, чем качество модели: показывайте snippet с подсветкой найденного фрагмента, дату и автора. Если RAG не уверен (низкие скоры), выводите фразу «Не найдено релевантных подтверждений» и предложите уточнить запрос.
RAG работает в две стадии: retrieval — поиск семантически похожих фрагментов векторного пространства с помощью embedding моделей и векторной БД; generation — LLM получает найденные фрагменты в подсказке и формирует ответ, опираясь на них. Retrieval сокращает пространство знаний для LLM и снижает риск выдумывания фактов. На практике pipeline: запрос → embedding запроса → top-K search → формирование prompt с контекстом → вызов LLM → постобработка и выдача пользователю.
Локальный вариант дешевле при больших объёмах (низкие переменные расходы) и даёт контроль над данными. Облачный сервис проще в эксплуатации, лучше масштабируется и зачастую даёт более качественные embeddings out-of-the-box. Если у вас 10k–100k фрагментов и строгие требования к конфиденциальности — локальная модель (MPNet/miniLM) на GPU будет разумным выбором. Если важнее точность и вы готовы платить — коммерческие embedding API часто дают лучший результат при тех же усилиях интеграции.
Галлюцинации возникают, когда LLM генерирует информацию, не подтверждённую контекстом. Причины: релевантные фрагменты не найдены, контекст слабо связан с вопросом или prompt не содержит строгих инструкций. Снижение: 1) увеличить Recall@K, 2) использовать порог сходства и не подставлять нерелевантные фрагменты, 3) требовать от LLM ссылаться на источник в ответе, 4) добавлять реранк или verification шаг (например, secondary call к model, которая проверяет факты).
Реранк повышает точность финальной выдачи: первичный ANN search даёт «кандидатов», реранк с помощью cross-encoder или более точной модели пересчитывает релевантность. Включайте реранк если точность retrieval ниже желаемой (Recall@5 < 0.85) или когда важно ранжирование по релевантности, а не просто наличие фрагмента. Стоимость: реранк добавляет вычисления — 20–200 ms на запрос при легкой модели, 0.5–2 USD/1k запросов для облачных cross-encoders в 2025.
Метаданные удобно хранить в документной БД (Postgres + jsonb, MongoDB) или как parquet/numpy-файлы в S3. Индексы FAISS — бэкап как файлы (.faiss) на S3; для Qdrant/Milvus используйте встроенные механизмы snapshot и репликацию: снимок каждые 6–24 часов и реплика на отдельный регион. Тест восстановления: восстанавливайте из бэкапа раз в неделю, чтобы убедиться, что процесс работает и реконструкция индекса занимает приемлемое время (обычно 10–60 минут для 10–50 GB).
Архитектура RAG: поиск и генерация
Интерфейс Qdrant с примером поиска
Комментарии (0)
Войдите или зарегистрируйтесь, чтобы оставить комментарий
Загрузка комментариев…