Поиск по базе знаний — первая задача, где компании сталкиваются с выбором: классический полнотекстовый поиск (BM25, морфология — как в поисковых системах нулевых) или векторная база данных с эмбеддингами, которая ищет «по смыслу». Вокруг второго много маркетинга; вокруг первого — снобизм. На деле это инструменты под разные запросы.
Ниже — прямое сравнение по бизнес-критериям: когда какой поиск выигрывает, во что обходится эксплуатация и что делать с персональными данными, которые неизбежно попадают в индекс. Отдельно про выбор между двумя векторными СУБД — «Milvus или Qdrant».
Кратко: когда что выбирать
Прямой ответ — в таблице: слева ситуация, справа разумное решение по состоянию на сентябрь 2026 года. Если узнали свою компанию в одной из строк — дальше достаточно проверить решение по чек-листу в конце страницы, а не перечитывать весь интернет.
| Ситуация | Что выбирать | Почему |
|---|---|---|
| Точный поиск по артикулам, реквизитам, кодам | полнотекстовый | детерминированность и скорость на точной лексике |
| Вопросы «своими словами» к базе знаний | векторный + реранкинг | совпадение по смыслу, а не по вхождению слов |
| RAG-ассистент на документах | гибрид: оба слоя | полнота выдачи важнее идеологии одного метода |
| Юридический поиск по точным формулировкам | полнотекстовый с фильтрами | норму ищут по канонической лексике |
| Мультиязычная база документов | векторный | эмбеддинги сопоставляют языки семантически |
| Старт с минимальным бюджетом | полнотекстовый из СУБД | ноль новых лицензий и минимальная эксплуатация |
Критерии сравнения
Развёрнутая матрица по критериям, которые заказчики проверяют перед решением: стоимость, сроки, риски, поддержка, комплаенс и режим данных. Каждая строка матрицы ниже раскрыта отдельным разбором — с пояснениями, откуда берутся цифры и на что смотреть в вашей ситуации.
| Критерий | Полнотекстовый поиск | Векторная БД |
|---|---|---|
| Стоимость | встроен в СУБД, которую вы уже используете | новый компонент: СУБД + расчёт эмбеддингов + эксплуатация |
| Сроки | дни: индексаторы и морфология из коробки | недели: пайплайн нарезки, эмбеддинги, векторная СУБД |
| Риски | пропуск документов без общих слов | ложные совпадения «по смыслу», деградация при смене модели |
| Поддержка | обычная СУБД-команда | нужен инженер по RAG-пайплайну и контролю индекса |
| 243-ФЗ и комплаенс | стандартные требования к системе | ИИ-компонент в системе — попадает в реестр ИИ-активов |
| Данные | в индексе — текст документов | в индексе — эмбеддинги: их тоже нельзя отдавать наружу |
| Качество на перефразированиях | низкое: «увольнение» ≠ «расторжение договора» | высокое: смысловое сопоставление формулировок |
Как читать матрицу: главный ориентир — строка «Качество на перефразированиях», потому что именно она отличает два мира поиска. Строки «Стоимость» и «Поддержка» напоминают, что векторный слой — это не библиотека, а эксплуатируемая система. Строки «243-ФЗ» и «Данные» важнее, чем кажется: индекс наследует чувствительность документов, и эмбеддинги — тоже данные, которые нельзя отдавать наружу без основания. Если сомневаетесь в классе данных — начните с аудита процессов и данных: он покажет и долю чувствительных документов, и реальную частоту запросов-перефразирований.
Разбор критериев
Стоимость и эксплуатация
Полнотекстовый поиск почти бесплатен инфраструктурно: он есть в СУБД, которую компания уже эксплуатирует. Векторный слой — это ещё одна СУБД, расчёт эмбеддингов по каждому документу при обновлении, мониторинг качества индекса. Отсюда честная последовательность: сначала полнотекстовый поиск и метрики, затем векторный слой на тех документах и запросах, где первый реально не находит. Аудит процессов и данных перед решением — от 90 000 ₽.
Сроки внедрения
Полнотекстовый индекс поднимается за дни; основное время уходит на нормализацию документов. Векторный контур — недели: нарезка, эмбеддинги, выбор СУБД, реранкинг, оценка качества. Если за проектом стоит дедлайн «поиск к концу квартала», старт с полнотекстового слоя почти всегда выполняет срок, а векторный слой наращивается вторым этапом без остановки системы.
Риски
Риск полнотекстового поиска — ложные пропуски: документ существует, но не содержит слов запроса. Риск векторного — ложные попадания: «похоже по смыслу», но не то; плюс зависимость от модели эмбеддингов (смена модели = пересборка индекса). Оба риска закрываются измеримо: выборка реальных запросов, разметка релевантности, метрики полноты и точности до и после каждого слоя.
Поддержка
Полнотекстовым поиском живая СУБД-команда справляется штатно. Векторный контур требует понимания RAG-пайплайна: почему индекс «поплыл», что делать при смене модели эмбеддингов, как перезаливать индекс. Это не аргумент «не делать», это аргумент «планировать сопровождение» — от 50 000 ₽/мес при аутсорсе, либо обучение своей команды.
Комплаенс: 243-ФЗ и документирование
Векторный слой делает систему ИИ-системой: в Москве в рамках эксперимента по 243-ФЗ такие системы попадают в реестр ИИ-активов с описанием модели и назначения. Полнотекстовый поиск под это определение не подпадает. Практический вывод: добавление векторов — не только техническое, но и комплаенс-решение, и дешевле учесть его сразу — методика в гайде «как вести реестр ИИ-активов по 243-ФЗ».
Данные в индексе
Забытая тема: в индекс попадают персональные данные из документов, а эмбеддинги — это тоже данные, из которых частично восстанавливается исходный текст при доступе к индексу. Значит: обезличивание до индексации, разграничение прав доступа в самом индексе (не только в источниках), размещение индекса в том же контуре, что и документы. Подробнее — «можно ли доверить ИИ персональные данные».
Вердикты по трём сценариям
Сценарий 1. Внутренняя база знаний до ~10 тысяч документов
Начать с полнотекстового поиска: быстро, дёшево, предсказуемо. Векторный слой добавлять по факту: собираете запросы, которые поиск не нашёл, и если их устойчиво много — обоснование для векторов готово. Пилот с метриками — от 480 000 ₽.
Сценарий 2. Клиентский ассистент, отвечающий по документам
Сразу гибрид: полнотекстовый слой гарантирует точные совпадения, векторный ловит перефразирования, реранкинг сводит выдачу. Это стандартный контур RAG-ассистента; его безопасность отдельно закрывается по чек-листу «как обезопасить чат-бот перед запуском».
Сценарий 3. Госорганизация, медицина, персональные данные
Индекс строится в собственном контуре с обезличиванием до индексации и журналированием доступа. Модель эмбеддингов фиксируется документально, система попадает в реестр ИИ-активов. Импортозамещение СУБД не препятствует: есть российские и open-source варианты.
Типичные ошибки выбора
Ошибки при выборе поискового стека для базы знаний:
- строить векторный поиск до сбора реальных запросов — вы не узнаете, нужен ли он вообще;
- мерить качество на синтетических примерах вместо живых вопросов сотрудников и клиентов;
- класть в индекс всё подряд: дубли, устаревшие версии и черновики снижают точность любого поиска;
- забывать про права доступа и обезличивание в самом индексе, а не только в источниках;
- менять модель эмбеддингов без пересборки индекса и регрессионных тестов — качество падает молча.
Итог
Полнотекстовый поиск и векторная база — не соперники, а эшелоны одной системы: точная лексика закрывается словами, перефразирования — смыслами. Стартуйте с простого, измеряйте на живых запросах и добавляйте векторный слой по доказательствам, а не по моде. Так вы получаете качество без лишней инфраструктуры. Решение стоит перепроверить на своих цифрах: разбор задачи бесплатный, ответ — за 1 рабочий день.
Чек-лист решения
Семь пунктов, которые стоит закрыть до выбора: они одинаково полезны обоим вариантам и закрывают большинство ошибок из списка выше. Пройдите список с командой — обычно это один рабочий час, который экономит недели переделок.
- Соберите выборку реальных запросов и разметьте релевантные документы — без этого выбор метода слеп.
- Проверьте, сколько запросов реально являются перефразированиями — это и есть ценность векторов.
- Определите класс данных в индексе и режим обезличивания до индексации.
- Спроектируйте права доступа в индексе, а не только в источниках документов.
- Зафиксируйте модель эмбеддингов и процедуру пересборки индекса при её смене.
- Определите метрики полноты и точности и дату первой переоценки.
- Если система ИИ — внесите её в реестр ИИ-активов (243-ФЗ, Москва).
Смежные материалы
Смежные сравнения: «Milvus или Qdrant» и «RAG или fine-tuning». Практика: услуги LLM-интеграций и RAG и OCR-извлечения данных; технология векторных БД на практике. Вопросы: «как обучить LLM на документах компании». Пошагово: «как подготовить данные для RAG».
Полный каталог разборов «или — или» — в разделе Сравнения; форматы работ, сроки и цены «от» — в каталоге услуг.