Семантический поиск находит нужный абзац, даже если в нём нет слов из вопроса: каждый фрагмент текста заранее превращён в набор чисел, и система сравнивает не слова, а близость этих чисел. Векторная база данных — хранилище для таких чисел, устроенное так, чтобы за доли секунды выбирать из сотен тысяч фрагментов ближайшие к вопросу.
Звучит сложно, работает просто. Сотрудник спрашивает «можно ли взять отпуск за свой счёт», а в регламенте написано «отпуск без сохранения заработной платы» — и это находится.
Суть: почему обычный поиск этот абзац не находит #
Обычный поиск ищет совпадение слов: сравнивает набранное в строке с тем, что написано в документе, и выдаёт места, где слова совпали.
На запросе про отпуск за свой счёт выходит так. Слово «отпуск» в регламенте есть — поиск выдаст всю главу об отпусках: тридцать абзацев про ежегодный, дополнительный, учебный и по уходу за ребёнком. Нужный абзац среди них есть, но ничем не выделен: фразы «за свой счёт» в документе нет вообще, и подтянуть его наверх поиску нечем.
Так получается почти с каждым живым вопросом. Люди спрашивают своими словами, а документы написаны языком юристов и кадровиков:
| Как спрашивает сотрудник | Как написано в документе |
|---|---|
| Отпуск за свой счёт | Отпуск без сохранения заработной платы |
| Задержали зарплату | Нарушение сроков выплаты вознаграждения |
| Заболел, что делать | Период временной нетрудоспособности |
| Как вернуть товар | Отказ от товара надлежащего качества |
| Кто подписывает счёт на 300 тысяч | Лимиты согласования расходных документов |
Левую колонку набирают в поиск, правая лежит в регламенте. Общих слов между ними почти нет — поэтому поиском по документам пользуются один раз, не находят и больше не открывают. Спрашивают у коллеги: это быстрее.
Отсюда и задача: нужен поиск, которому неважно, какими словами задан вопрос.
Разбор: как текст превращается в числа #
Представьте карту, на которой у каждого абзаца есть адрес. Не адрес в документе, а адрес по смыслу: тексты про одно и то же оказываются по соседству, тексты про разное — в разных районах.
Такой адрес и есть вектор — список чисел, обычно от нескольких сотен до нескольких тысяч. Считает его отдельная небольшая модель, её называют эмбеддером: на входе кусок текста, на выходе числа. По отдельности ни одно из них ничего не значит, смысл имеет только близость одного набора к другому.
Дальше всё механично:
- Документы режут на фрагменты. Вектор считают не для файла целиком, а для куска в несколько абзацев. Иначе инструкция на сорок страниц получит один адрес «про работу склада», и найти в ней конкретное правило будет нельзя.
- Для каждого фрагмента считают вектор и кладут его рядом с текстом фрагмента.
- Вопрос прогоняют через тот же эмбеддер. «Отпуск за свой счёт» получает свой набор чисел.
- Ищут ближайшие. Считается расстояние от вопроса до фрагментов, наверх идёт десяток самых близких.
«Отпуск за свой счёт» и «отпуск без сохранения заработной платы» оказываются на карте рядом, потому что в текстах, на которых училась модель, эти выражения стоят в похожем окружении. Это не понимание, а статистика по огромному объёму текстов, превращённая в координаты.
Эмбеддер не отвечает, он только находит #
Частая путаница: кажется, что семантический поиск — это уже ИИ, который понял вопрос. Нет. Эмбеддер не умеет отвечать, он только расставляет тексты по близости. Ответ формулирует языковая модель — по найденным фрагментам, а не по памяти. Этот механизм целиком — поиск, затем ответ по найденному — называется RAG, про него есть отдельная статья: что такое RAG. Как собирается вся цепочка, от загрузки документов до ответа со ссылкой, разобрано в статье про устройство системы.
Важное следствие: качество ответа упирается в качество поиска. Если нужный абзац не попал в десятку найденного, модель про него не узнает и ответит по тому, что нашлось. Поэтому за поиск в таких системах бьются сильнее, чем за выбор модели.
Второе следствие — нарезка. Слишком крупные фрагменты получают смазанный адрес: в один вектор попало пять тем, и ни к одному вопросу он не близок. Слишком мелкие рвут ответ на части, модель видит половину условия и не видит оговорки. Рабочий размер — пункт регламента, раздел инструкции, один вопрос с ответом; по смысловым границам, а не по счётчику символов. Про подготовку самих материалов — в статье про базу знаний, там же про противоречия и актуальность, которые никакой поиск не лечит.
Что такое векторная база данных и зачем она отдельно #
Обычная база данных отвечает на вопросы с точным ответом: найди договор номер 112, покажи счета за март. Она построена вокруг точных значений и делает это быстро. Вопрос «найди десять фрагментов, ближайших к этому набору из тысячи чисел» для неё чужой: перебрать все и сравнить каждый можно, пока их три тысячи, а документы компании дают сотни тысяч фрагментов.
Векторная база данных решает одну задачу: держать векторы и быстро находить ближайшие. Делает она это хитростью — заранее строит структуру, по которой можно спуститься к нужному району карты, не обходя остальное. Такой поиск называют приближённым: он может пропустить один фрагмент из сотни, зато отвечает за миллисекунды.
Выглядеть это может по-разному:
- Расширение к обычной базе. К PostgreSQL ставится pgvector, и векторы живут рядом с остальными данными. На десятках тысяч фрагментов этого хватает с запасом, а администрировать нужно одну систему, а не две.
- Отдельная векторная база. Qdrant, Milvus, Weaviate и подобные — нужны, когда фрагментов миллионы.
- Поисковый движок. Elasticsearch и OpenSearch умеют и слова, и векторы; их выбирают там, где поиск по словам уже работал раньше.
Для компании на 30–300 сотрудников разница между вариантами почти нулевая, спорить о ней не стоит.
Больше векторная база не делает почти ничего: не хранит права доступа, не знает, какая версия документа действующая, не умеет сказать «этот приказ отменён». Это остаётся за обычной базой и за порядком в документах.
Эмбеддер нельзя поменять на ходу #
Грабля, о которой стоит знать до покупки: векторы, посчитанные разными моделями, несравнимы между собой — это как сложить адреса с двух разных карт. Меняете эмбеддер на более качественный — пересчитывать придётся всю базу до последнего фрагмента. На трёхстах документах это полчаса, на сотне тысяч — отдельная работа с простоем.
Почему хороший результат даёт сочетание двух поисков #
Семантический поиск силён там, где слабы слова. Словесный — наоборот: он берёт то, что написано буквально. Надёжный результат даёт не выбор между ними, а оба сразу — это называют гибридным поиском.
Работает так: вопрос уходит в два поиска сразу. Словесный ищет точные совпадения и редкие слова, смысловой — близкие формулировки. Две выдачи складываются в одну, фрагмент, попавший в обе, поднимается наверх, и в модель уходит общая десятка. Разделение труда между ними честное:
| Вопрос | Кто находит |
|---|---|
| Можно ли отпуск за свой счёт | Смысловой: нужных слов в документе нет |
| Приказ 112-ОД от 3 марта | Словесный: смысловой выдаст похожие приказы, но не этот |
| Артикул АБ-45120-Ч | Словесный: для смыслового это просто набор знаков |
| Что делать, если клиент отказался от доставки | Смысловой: в инструкции это «аннулирование заказа» |
| Условия по модели XR-2200 | Словесный: название модели — точная строка |
| Кто согласует крупные траты | Смысловой: в регламенте это «лимиты согласования» |
Половина строк в этой таблице — случаи, где чистый семантический поиск промахивается. Он работает с похожестью, а номер приказа похожестью не ищется: все номера похожи друг на друга и ни один не ближе остальных. Поэтому системы на одних векторах выглядят умными на общих вопросах и беспомощными на конкретике, которой в работе с документами как раз больше.
Как это устроено у нас #
Поиск гибридный. По смыслу и по словам одновременно, две выдачи объединяются перед ответом. Отдельного «режима точного поиска» для сотрудника нет — он просто задаёт вопрос.
Ответ строится только по найденным фрагментам. Чего нет в документах, ассистент не придумывает, а передаёт человеку.
У каждого ответа есть ссылка на документ-источник. Это и есть способ проверить поиск: видно, откуда взят ответ, и видно, если взято не оттуда.
Перед выдачей ответ проверяется. Если модель сослалась на документ, которого нет, ссылка правится, а не выбрасывается весь ответ вместе с верной частью. Почему это вообще нужно — в статье про галлюцинации нейросети.
Модель выбирается цепочкой. GigaChat, YandexGPT, зарубежная через ProxyAPI, модель внутри сети компании: если одна не ответила, запрос идёт дальше. На поиск это не влияет — фрагменты к этому моменту уже найдены.
Серверы в России, персональные данные обезличиваются до отправки в модель.
Та же база подключается потом к боту для клиентов — сайт, Telegram, MAX, ВКонтакте, Авито, — и поиск там тот же самый.
Сколько стоит и от чего зависит #
Векторная база — не отдельная строка в счёте. Платят за работу: разбор документов, нарезку, настройку поиска, проверку на реальных вопросах. Цены на 23 октября 2026 года, подробный состав работ — на странице корпоративной базы знаний:
| Что | Стоимость | Срок |
|---|---|---|
| Аудит: карта документов, с какого отдела начать | Бесплатно | 30 минут |
| Пилот: один отдел, до 300 документов, проверка на 40 вопросах | от 150 000 ₽ | 3–4 недели |
| Внедрение: несколько отделов, права доступа, автообновление, 1С, Битрикс24, Диадок | от 500 000 ₽ | 6–10 недель |
| Сопровождение: обновление базы, контроль ответов, отчёт по вопросам | от 40 000 ₽ в месяц | — |
Если проект такого размера сейчас велик, есть платформа по подписке: от 7 000 ₽ в месяц плюс настройка от 15 000 ₽, базу собираем мы, запуск 3–10 дней. Разница не в качестве поиска, а в объёме работ: права доступа по отделам, автообновление из источников и интеграции — это внедрение.
На цену влияет объём документов, число источников и нужны ли права доступа. Качество поиска на цену не влияет — гибридный поиск есть в любом варианте.
Где это не работает #
Отрицания. «Командировку можно продлить» и «командировку нельзя продлить» для эмбеддера почти одинаковы: слова те же, смысл противоположный. Спасает не поиск, а то, что модель читает найденный фрагмент целиком и видит частицу «не».
Подсчёты и сравнения. «Сколько договоров истекает в декабре» — это не поиск абзаца, а запрос к данным. Поиск по смыслу найдёт абзацы про договоры, но не сложит их; такие вопросы закрывают отчётом в учётной системе.
Сканы и таблицы. Если договор лежит фотографией, текста в нём для машины нет и вектор считать не из чего — сначала нужно распознавание. Многоуровневая таблица при нарезке рассыпается: фрагмент «Москва / 3 дня / 450 ₽» без шапки не значит ничего. Такие документы готовят руками.
Противоречия в документах. Два абзаца с разными условиями возврата оба будут близки к вопросу, и ассистент возьмёт один. Поиск здесь ни при чём: нужно убрать устаревший документ.
Точность в процентах. Цифру вроде «находит в 95% случаев» мы не называем. Проверяемый способ один: взять сорок реальных вопросов отдела и посмотреть ответы — это и есть содержание пилота.
Голос в корпоративном ассистенте. Расшифровки голосовых сообщений для сотрудников у нас нет, только текст.
И главное, чем всё это не является: семантический поиск не делает модель знающей ваши документы — она читает их заново, из найденного. Разница между этим и дообучением модели на своих данных разобрана в статье RAG или дообучение: это разные по цене вещи, и путать их дорого.
Частые вопросы #
Чем векторный поиск отличается от поиска на нашем сайте? #
Поиск на сайте сравнивает слова: нашлось совпадение — выдал страницу. Векторный сравнивает смысл и находит нужное, когда вопрос и документ написаны разными словами. На артикулах и номерах старый поиск часто лучше, поэтому в рабочих системах их держат вместе.
Нужна ли отдельная векторная база или хватит обычной? #
Для компании на 30–300 сотрудников почти всегда хватает обычной базы с векторным расширением: одна система вместо двух и меньше поводов для сбоя. Отдельная нужна при миллионах фрагментов. Если исполнитель начинает разговор с выбора векторной базы, а не с ваших документов — это повод насторожиться.
Наши документы уходят куда-то наружу, чтобы посчитать векторы? #
Зависит от того, какой эмбеддер используется, и вопрос стоит задавать прямо. У нас серверы в России, персональные данные обезличиваются до отправки в модель, по умолчанию работаем на GigaChat и YandexGPT. Если документы не должны покидать вашу сеть совсем, модель разворачивается внутри неё.
Что происходит, когда документ изменился? #
Пересчитывается вектор изменённых фрагментов, остальная база не трогается — быстро и незаметно. Вопрос в другом: узнает ли система, что документ изменился. При внедрении настраивается автообновление из источников, иначе новую версию кто-то должен загружать руками.
Можно ли понять, почему ассистент нашёл именно этот абзац? #
Расстояние между числами полностью не объяснить, но это и не нужно. Проверяют иначе: у ответа есть ссылка на документ и место, откуда он взят. Если найдено не то, видно сразу — и разбираться идут в нарезку и формулировки, а не в математику.
Сколько документов нужно, чтобы это имело смысл? #
Хватит пятидесяти документов одного отдела. Объём влияет на срок и цену, а не на результат: поиск по смыслу выигрывает уже там, где люди спрашивают своими словами, а документы написаны казённым языком.
Поиск по смыслу — не магия и не интеллект. Это способ сравнивать тексты, которым неважны слова: он силён на формулировках и слаб на номерах, поэтому в рабочей системе всегда стоит рядом со словесным. Если документы в компании есть, но ими не пользуются, потому что в них нельзя ничего найти — задача ровно эта.
