Не каждой системе поиска по документам нужна нейросеть. Если сотрудник ищет договор по номеру или товар по артикулу, обычный полнотекстовый поиск в Elasticsearch или PostgreSQL справится быстрее и дешевле любого RAG. RAG нужен там, где вопрос сформулирован свободно, а не точным термином из документа. Разберем, где проходит эта граница и почему гибридный поиск по документам для многих компаний в итоге оказывается оптимальным решением.
Классический полнотекстовый поиск (Elasticsearch, PostgreSQL Full-Text Search) справляется, если пользователь ищет по точным терминам, номерам и названиям. RAG нужен, когда вопрос задан свободным языком и требуется единый сгенерированный ответ из нескольких документов. В статье: критерии выбора, сравнение затрат и гибридный подход как компромисс.
Когда компании достаточно классического поиска по документам?
Классического поиска достаточно, если люди ищут по точным словам: номер договора, артикул, фамилия сотрудника. Такие запросы не требуют понимания смысла.
PostgreSQL Full-Text Search через связку tsvector и GIN-индекс комфортно работает на базах до 5-10 миллионов записей при задержке запроса менее 100 миллисекунд, и не требует отдельного поискового сервера. Для точного поиска по номерам и кодам этого хватает, а векторная база с моделью эмбеддингов добавит только сложность без выигрыша в качестве.
Логика простая. Пользователь и так знает, что искать. Бухгалтер вводит номер счета, юрист - номер договора, кладовщик - артикул. Инвертированный индекс находит точное совпадение за миллисекунды, смысл запроса тут не нужен.
Если база небольшая, а запросы предсказуемые, PostgreSQL Full-Text Search или Elasticsearch решают задачу без лишней инфраструктуры. Не нужна векторная база, не нужна модель эмбеддингов, не нужен сервис генерации ответа. Меньше движущихся частей - меньше что может сломаться в проде.
Как работает полнотекстовый поиск в Elasticsearch и PostgreSQL?
Оба инструмента используют инвертированный индекс и алгоритм BM25 для ранжирования по частоте термина. PostgreSQL встроен прямо в базу данных, Elasticsearch - отдельный поисковый движок с более широкими возможностями.
Elasticsearch построен на Apache Lucene и распределяет индекс по шардам, за счет этого масштабируется горизонтально на десятки миллионов документов. PostgreSQL Full-Text Search хранит текст как tsvector и ищет через GIN-индекс прямо внутри транзакционной базы, без отдельного кластера и синхронизации данных.
Разница по факту не в том, кто "умнее" ищет, а в том, где живет сложность поиска. Ниже - сжатое сравнение по практическим критериям.
| Критерий | PostgreSQL Full-Text Search | Elasticsearch |
|---|---|---|
| Инфраструктура | Не нужна, встроен в БД | Отдельный кластер, нужен DevOps |
| Комфортный масштаб | До 5-10 млн записей | Десятки-сотни миллионов документов |
| Внедрение | Часы, если БД уже PostgreSQL | Дни-недели на настройку |
| Доп. возможности | Базовое ранжирование, tsvector | Facets, geo-поиск, автокомплит, мультиязык |
| Эксплуатация | Дешевле | Дороже, нужен мониторинг кластера |
По опыту компаний, которые выбирали между этими решениями, PostgreSQL FTS чаще всего закрывает задачу, если данные и так уже лежат в PostgreSQL, а требования к поиску не выходят за рамки "найти документ по словам из него".
Когда компании действительно нужен RAG для поиска по документам?
RAG нужен, когда сотрудники формулируют вопросы своими словами, без знания точных терминов документа, и когда нужен не список файлов, а готовый ответ.
RAG собирает ответ из нескольких документов через языковую модель, а не просто возвращает список ссылок на файлы. Он незаменим, когда база большая и неструктурированная, а пользователь физически не может угадать точное ключевое слово нужного документа заранее.
Разница видна на конкретном примере. Клиент службы поддержки пишет "как отменить платеж", а в регламенте это называется "процедура сторнирования транзакции". Классический поиск по ключевым словам такую связь не найдет - слова разные. RAG понимает смысл вопроса и достанет нужный раздел регламента, даже если формулировки не совпадают ни на одно слово.
Разбирали эту логику подробнее в статье про RAG для корпоративной базы знаний и в кейсе про бота поддержки с RAG - там показано, как это выглядит на реальном проекте, а не только в теории.
Чем гибридный поиск лучше чистого RAG или обычного поиска?
Гибридный поиск объединяет точное совпадение по терминам и понимание смысла запроса. Он находит и точные коды, и вопросы, заданные свободным языком, в одном запросе.
Гибридный поиск через BM25 плюс векторы дает прирост качества около 10% по сравнению с чистым векторным поиском, а контекстуализация чанков перед индексацией добавляет еще примерно столько же. Проверено на связке Qdrant и N8N с локальными моделями для расчета sparse-векторов.
Технически это выглядит так: документ разбивается на чанки, для каждого считается два типа векторов - плотный (embedding, про смысл) и разреженный (BM25, про точные слова). Оба типа хранятся в одной коллекции Qdrant, а результаты объединяются через Fusion RRF. На практике локальная модель BM25 рядом с N8N отрабатывает мгновенно и почти не грузит сервер - отдельный GPU-кластер под это не нужен.
Подробный разбор архитектуры - в статье Qdrant Hybrid Search. Если стоит более широкий вопрос выбора инструмента для AI-агента, а не только поиска, смотрите сравнение в статье MCP vs RAG vs Function Calling.
Сколько стоит RAG по сравнению с классическим поиском?
Классический поиск обходится в разы дешевле: не нужна векторная база, эмбеддинги и токены LLM на каждый запрос. RAG окупается только там, где реально экономит время на поиск смысла.
У классического поиска затраты предсказуемые и разовые: настроить индекс, один раз выделить ресурсы под сервер поиска. У RAG затраты растут вместе с использованием - каждый запрос это токены на генерацию эмбеддинга и токены на ответ языковой модели, плюс отдельная векторная база, которую нужно поддерживать и апдейтить при изменении документов.
| Статья затрат | Классический поиск | RAG |
|---|---|---|
| Инфраструктура | Индекс внутри существующей БД или Elasticsearch | Векторная БД (Qdrant и подобные) отдельно |
| Стоимость запроса | Фиксированная, от ресурсов сервера | Токены эмбеддинга + токены LLM на каждый запрос |
| Обновление данных | Реиндексация стандартными средствами | Пересчет эмбеддингов при любом значимом изменении текста |
| Порог внедрения | Низкий, есть в большинстве СУБД из коробки | Выше: нужна архитектура retrieval + generation |
По оценке порогов внедрения Elasticsearch, заметная деградация производительности классического поиска обычно начинается за пределами 5-10 миллионов записей - это ориентир, после которого стоит пересмотреть архитектуру, но не обязательно сразу в сторону RAG.
Итог: как выбрать систему поиска для своих документов
Начинайте с вопроса "как реально формулируют запрос ваши пользователи", а не с того, какая технология звучит перспективнее. Если это точные термины - берите GIN-индекс в PostgreSQL или Elasticsearch. Если это свободные вопросы без знания терминологии документа - нужен RAG. Если и то, и другое - гибридный поиск закрывает оба сценария одним решением.
Максим: «У Нейроскрайба ждали от разработчика неделю-две-три. У Нейроштата целая команда работала - ждали целую фичу месяцами. Получили - и разочаровались, потому что время реализации критично.»
Та же логика применима к поиску по документам. Не стройте RAG-инфраструктуру с векторной базой и пайплайном эмбеддингов, если задачу закрывает GIN-индекс, настроенный за час. Сложная архитектура, которую ждут месяцами, а по итогу используют на 10% возможностей - это дорогая ошибка, которую проще не совершать.
Глоссарий
- RAG (Retrieval-Augmented Generation) - подход, при котором языковая модель сначала находит релевантные фрагменты документов, а затем генерирует ответ на их основе.
- Полнотекстовый поиск - поиск документов по вхождению слов и фраз, без понимания смысла запроса.
- Инвертированный индекс - структура данных, которая для каждого слова хранит список документов, где оно встречается, - это и делает полнотекстовый поиск быстрым.
- BM25 - алгоритм ранжирования результатов поиска по частоте термина в документе и его редкости во всей базе.
- Эмбеддинг - числовое представление текста, по которому можно сравнивать смысловую близость фраз.
- Векторная база данных - хранилище, оптимизированное для поиска по эмбеддингам (например, Qdrant).
- Гибридный поиск - объединение полнотекстового и векторного поиска в одном запросе, обычно через Fusion RRF.
- Чанкинг - разбиение документа на небольшие фрагменты перед индексацией для RAG.
Частые вопросы про поиск по документам
Нужен ли RAG маленькой компании с небольшой базой документов?
Чаще всего нет. Если документов немного и сотрудники ищут по знакомым терминам, PostgreSQL Full-Text Search закроет задачу за один вечер настройки, без отдельной инфраструктуры под RAG.
Может ли PostgreSQL полностью заменить Elasticsearch?
Для базового поиска - да, особенно если данные и так лежат в PostgreSQL. Но если нужны facets, geo-поиск, автокомплит или работа с сотнями миллионов документов, Elasticsearch подходит лучше.
Что такое BM25 простыми словами?
Формула, которая считает, насколько слово из запроса важно для конкретного документа: чем чаще слово встречается в этом документе и чем реже - во всех остальных, тем выше документ в выдаче.
Почему RAG иногда дает неточный или выдуманный ответ?
Часто дело не в самой модели, а в качестве retrieval-части: плохая нарезка чанков, отсутствие контекстуализации перед индексацией. Гибридный поиск с BM25 заметно снижает такие ошибки.
Что такое гибридный поиск и когда он оправдан?
Это сочетание точного поиска по словам и смыслового поиска по эмбеддингам в одном запросе. Оправдан, когда часть пользователей ищет по точным терминам, а часть - свободными формулировками.
Как понять, что пора переходить с классического поиска на RAG?
Если сотрудники регулярно не находят нужный документ из-за разных формулировок одного и того же вопроса, а не из-за размера базы - это сигнал, что нужен семантический слой поверх обычного поиска.
Сколько времени занимает внедрение гибридного поиска поверх готовой базы?
На связке вроде Qdrant и N8N базовый пайплайн - разбиение на чанки, расчет двух типов векторов, запись в коллекцию - собирается за несколько дней, без разработки с нуля.
Внутренние ссылки по теме: RAG для корпоративной базы знаний, Бот поддержки с RAG, Qdrant Hybrid Search, MCP vs RAG vs Function Calling.
Если разбираетесь, какая архитектура нужна именно вашей компании - посмотрите каталог AI-инструментов на VibeCoderz или запишитесь на консультацию к Максиму.
Обновлено: сентябрь 2026.