RAG-архитектура: когда использовать поиск по данным вместо обучения модели

Знания LLM заканчиваются на дате обучения и не включают ваши документы, прайс, историю поддержки и внутренние процессы. Спрашивать модель напрямую — значит получать риск галлюцинаций ровно на тех вопросах, где точность критична.

Типичная реакция — fine-tuning. Но fine-tuning не добавляет знания, он меняет поведение. Модель, обученная на ваших документах, все равно может уверенно выдумать несуществующую политику. Доступ к фактам дает retrieval, а не запоминание.

Fine-tuning учит стилю, а не фактам. Если ответ должен быть правдой, факты нужно извлекать.

• Зависит ли ответ от приватных или меняющихся данных? — да, значит RAG.
• Проблема в формате, тоне или поведении? — это территория fine-tuning.
• Нужны ли пользователю источники и цитаты? — RAG дает естественный трейс.
• Данные меняются ежемесячно или еженедельно? — RAG обновится за час, переобучение — нет.

Большинство production-систем комбинируют оба подхода: базовая модель под рассуждения, RAG для обоснования и легкий fine-tuning или работа с промптом для тона — в таком порядке инвестиций.

RAG — это три системы, а не один скрипт:

• Ingestion — документы разбиваются на чанки, эмбедятся и хранятся. Стратегия чанкинга — продуктовое решение: юридический договор чанкуется иначе, чем статья базы знаний.
• Retrieval — вопрос пользователя эмбедится и ищется. Мы комбинируем семантический поиск с ключевыми словами и метаданными: семантика сама по себе пропускает точные термины и ID.
• Synthesis — найденные чанки уходят в LLM со строгими инструкциями: отвечать только из контекста, цитировать источник, говорить «не найдено» вместо догадок.

Качество выигрывается или теряется на шаге retrieval. Если нужный чанк не извлечен, ни одна модель не даст правильный ответ.

Чанкинг — это продуктовое решение, а не деталь обработки текста. Один и тот же тип документов чанкуется по-разному в зависимости от того, как пользователи будут искать:

• Юридический договор — разбивка по иерархии пунктов: секции и пункты сохраняют границы, поэтому запрос на уровне пункта возвращает точный абзац, а не смешанный фрагмент.
• Статья базы знаний — разбивка по заголовкам и абзацам со смысловыми границами: каждый чанк отвечает на одну тему и самодостаточен.
• История поддержки — разбивка по репликам диалога с таймстампами: retrieval может предпочитать свежие ответы устаревшим.

Каждый чанк несет метаданные. Метаданные превращают retrieval из совпадения по ключевым словам в точный запрос:

{
  "document_id": "contract-2026-041",
  "document_type": "contract",
  "source_system": "legal_repository",
  "language": "en",
  "clause": "termination",
  "clause_number": "12.3",
  "chunk_index": 4,
  "updated_at": "2026-07-30"
}

Фильтры по этим полям — часть retrieval-запроса: только документы тенанта, только нужный язык, только документы после даты. Метаданные — это и то, как контроль доступа исполняется на этапе поиска.

• Чанкинг по структуре — разбивка по смысловым границам (заголовки, абзацы, секции), а не по фиксированному числу символов.
• Гибридный поиск — векторная близость плюс ключевые слова и фильтры по метаданным; реранкинг топ-кандидатов по релевантности.
• Эмбеддинги — хорошей общей модели достаточно для большинства бизнес-данных; ре-эмбеддинг при обновлении контента держит свежесть.
• PostgreSQL с pgvector — одна база для состояния, логов и векторов упрощает операции и держит данные в одном месте.
• Набор оценки — фиксированный набор вопросов с ожидаемыми чанками и ответами. Любое изменение чанкинга или промптов прогоняется на нем.
• Fallback-поведение — система обучена отказывать без контекста: «в базе знаний ответа нет» — валидный честный ответ.

• Чанкинг по фиксированному размеру — нарезка по числу символов разрушает структуру: пункты, заголовки и вопросы попадают в разные чанки, и retrieval теряет связь.
• Только семантический поиск — одной векторной близости мало для точных терминов, кодов и ID. Без ключевых слов и фильтров по метаданным точные запросы молча проваливаются.
• Без реранкинга — top-k по близости возвращает похожее, а не релевантное. Реранкинг кандидатов закрывает эту разницу.
• Без фильтров по метаданным — смешение языков, типов документов и дат в одном индексе засоряет результаты. Фильтры дешевы и влияют на качество поиска сильнее любого выбора модели.
• Без набора оценки — чанкинг, эмбеддинги и промпты меняются без регрессионного теста. Качество retrieval незаметно дрейфует с каждым изменением.
• Ответ без контекста — модель отвечает, когда ничего не извлечено. Путь отказа — часть архитектуры, а не состояние ошибки.
• Устаревший индекс — документы меняются, а индекс нет. Ingestion как пайплайн, а не разовая задача, — то, что держит ответы актуальными.

Мы используем один и тот же дизайн пайплайна в собственных продуктах:

• AI Business Copilot — RAG-база знаний хранит контекст компании, и мультиагентный анализ извлекает из нее данные при поиске возможностей автоматизации.
• LegalFlow AI — обработка документов для юридических команд: контракты и дела чанкуются по структуре, извлекаются по запросам на уровне пунктов и отвечают со ссылками на источники.
• LeadForge AI — retrieval-слой питает агента-контент данными о компаниях и контекстом CRM, чтобы аутрич опирался на факты, а не на шаблоны.

Паттерн повторяется в очень разных доменах: обоснованные ответы, прослеживаемость источников и честный отказ, когда в базе знаний пусто.