RAG нужен бизнесу не для красивого демо с чатиком, а для одной очень приземлённой задачи: быстро найти точный ответ в большом массиве документов и показать, на какие источники он опирается. Если у компании сотни PDF, техпаспортов, инструкций, договоров или FAQ, обычный поиск по словам быстро превращается в ручной квест. RAG добавляет слой поиска по смыслу и отдаёт модели только релевантный контекст.

Где это даёт деньги, а не вау-эффект

Представьте компанию, которая продаёт промышленное оборудование. Клиент спрашивает: «Нужен компрессор на 12 бар, линия 200 единиц в час, помещение 3 на 4 метра. Что подойдёт?»

Без RAG менеджер открывает каталог на сотни страниц, таблицы совместимости и техпаспорта. Ответ появляется через десятки минут — если менеджер вообще нашёл нужные параметры. С RAG система заранее индексирует документацию, находит релевантные фрагменты и формирует ответ с ссылками на конкретные страницы или разделы.

Для бизнеса ценность не в том, что «AI ответил». Ценность в том, что новичок быстрее работает как опытный сотрудник, инженер не тратит день на типовые вопросы, а клиент получает ответ пока ещё не ушёл к конкуренту.

“A search for ‘climate change’ can retrieve documents about ‘global warming,’ even if the exact words differ.” — Qdrant Documentation

Это хорошее объяснение сути векторного поиска: система ищет не только совпадение слов, а близость смысла. Для каталогов это критично. Клиент может сказать «поместится в маленькую комнату», а в документации будет «габаритные размеры 1180 × 760 × 940 мм». Ключевые слова разные, смысл связан.

Как работает RAG без мистики

RAG — retrieval-augmented generation, генерация с предварительным поиском. Система не просит LLM «вспомнить всё из головы». Она сначала достаёт релевантные документы, а уже потом просит модель ответить на основе найденных фрагментов.

Минимальная архитектура выглядит так:

  1. Документы режутся на фрагменты: страницы, разделы, абзацы, таблицы.
  2. Модель эмбеддингов превращает каждый фрагмент в вектор — числовое представление смысла.
  3. Векторная база хранит эти векторы вместе с метаданными: файл, страница, версия, продукт, дата.
  4. Запрос пользователя тоже превращается в вектор.
  5. База возвращает top-k ближайших фрагментов.
  6. LLM формирует ответ, но только в рамках найденного контекста.

“RAG models combine parametric memory with non-parametric memory.” — Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

В переводе на бизнес-язык: у модели есть общие знания в параметрах, но факты компании лучше держать снаружи — в базе, которую можно обновлять без переобучения модели. Каталог поменялся, цена обновилась, новая инструкция вышла — вы переиндексировали документы, а не обучали новую LLM.

Что выбрать: Qdrant, Weaviate, Pinecone или Postgres

Я в Digital Shadow использую Qdrant для задач смыслового поиска. Но инструмент выбирается не по моде, а по ограничениям проекта.

  • Qdrant хорош, когда нужен self-hosted контроль, гибридный поиск и понятная эксплуатация.
  • Weaviate удобен как open-source vector database с готовой экосистемой для semantic search и RAG.
  • Pinecone часто выбирают, когда нужен managed-вариант без обслуживания инфраструктуры.
  • PostgreSQL с pgvector может быть достаточен, если у команды уже есть Postgres и объём данных умеренный.

Главный вопрос не «какая база лучшая», а «какой SLA, объём, безопасность, цена ошибки и кто будет это поддерживать».

Где RAG ломается

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

Типовые ошибки внедрения:

  • грузить PDF как попало, без очистки таблиц и заголовков;
  • резать документы слишком крупно или слишком мелко;
  • не добавлять метаданные: версия, дата, продукт, язык, владелец;
  • не проверять качество retrieval отдельно от качества ответа;
  • не делать fallback «не знаю», когда источников недостаточно.

“Weaviate can serve as a robust backend for RAG workflows, where vector search is used to retrieve context that enhances the output of generative models.” — Weaviate Documentation

Ключевое слово здесь — context. RAG не делает модель всезнающей. Он подсовывает ей правильный рабочий контекст. Поэтому проектировать надо не чат, а цепочку: ingestion → retrieval → reranking → answer → citations → feedback.

Когда RAG не нужен

Если у вас 10 коротких документов и они целиком помещаются в контекст модели, отдельная векторная база может быть лишней. Иногда проще загрузить документы напрямую в сессию или использовать обычный поиск.

RAG становится полезен, когда есть масштаб и повторяемость: сотни документов, регулярные вопросы, риск ошибки, несколько ролей пользователей и необходимость ссылаться на источник. В этом случае система окупается не тем, что «заменяет людей», а тем, что убирает часы ручного поиска и снижает вероятность уверенной ошибки.