Эмбеддинг — это перевод куска текста в длинный набор чисел, устроенный так, что близкие по смыслу куски получают близкие наборы. Формально это координаты точки в пространстве с сотнями измерений; практически — способ разложить все ваши документы по столу так, чтобы похожее лежало рядом. Дальше поиск сводится к простой операции: вопрос тоже превращается в набор чисел, и система берёт те фрагменты документов, чьи наборы оказались ближе всего.
Отсюда главное свойство и главная слабость. Свойство: система находит нужный пункт регламента по фразе, в которой нет ни одного слова из этого пункта, — потому что сравниваются не слова, а смыслы. Слабость зеркальная: там, где важно точное совпадение — артикул, номер приказа, дата, сумма, — смысловая близость мешает, и поиск уверенно приносит похожий, но не тот документ.
Дальше — механизм на одном примере из розницы, разбор слабого места с цифрами замера, устройство гибридного поиска и его вклад в деньги, что происходит при смене модели эмбеддингов и почему англоязычные бенчмарки на ваших документах ничего не значат. В конце — два вопроса, которые стоит задать подрядчику про поиск на первой же встрече.
Механизм: три фразы клиента и один пункт регламента
Возьмём пункт внутреннего регламента розничной сети: «Товар надлежащего качества принимается к возврату в течение 14 календарных дней при сохранении товарного вида; отсутствие индивидуальной упаковки не является основанием для отказа». И три реальные формулировки, с которыми к системе приходят сотрудники: «клиент вернул кроссовки без коробки, брать?», «можно ли отказать, если коробку выбросили», «две недели прошло, упаковки нет — что делать».
Обычный поиск по словам находит из этих трёх только третью, и то по слову «упаковки». В первых двух совпадений нет вовсе: в регламенте нет ни «кроссовок», ни «коробки», ни «выбросили». Векторный поиск находит все три, потому что после перевода в числа они оказываются в одной области — рядом с фрагментом про возврат без индивидуальной упаковки и далеко от фрагмента про гарантийный ремонт, хотя в последнем слово «возврат» тоже встречается.
Схема-карта: прямоугольное поле с рассыпанными точками-фрагментами. В левой верхней части плотная группа из четырёх точек, обведённая тонким кругом: три подписаны репликами «клиент вернул кроссовки без коробки, брать?», «можно ли отказать, если коробку выбросили», «две недели прошло, упаковки нет», четвёртая выделена и подписана «Регламент возвратов: 14 календарных дней, упаковка не обязательна». В правой нижней части отдельно стоит точка «Положение о гарантийном ремонте» с подписью-выноской «слово «возврат» есть, смысл другой — далеко». Внизу подпись «расстояние = близость смысла, а не совпадение слов».
Числовое представление фрагмента текста, которое вычисляет отдельная небольшая модель — модель эмбеддингов. Для одного фрагмента это набор из нескольких сотен или тысяч чисел; сам по себе он ничего не значит, значение имеет только расстояние до других таких наборов. Хранится всё это в векторном хранилище — обычно расширение pgvector к обычной PostgreSQL.
Здесь же прячется вторая по частоте причина плохого поиска после самого механизма — размер фрагмента. Один набор чисел описывает весь кусок целиком, поэтому чем кусок длиннее, тем более усреднённым получается его смысл: у фрагмента на пять страниц координаты оказываются «где-то посередине» между всеми темами, которые в нём затронуты, и он перестаёт находиться по любой из них. Слишком мелкие куски дают обратную проблему: фраза «в этом случае возврат не принимается» без предыдущего абзаца теряет смысл, по которому её можно найти. Рабочий диапазон — 300–800 слов на фрагмент с небольшим перекрытием и с обязательным сохранением заголовка раздела в тексте самого фрагмента.
Важное следствие для приёмки: у векторного поиска нет понятия «нашёл или не нашёл». Он всегда возвращает ближайшие фрагменты, даже когда в базе нет ничего подходящего — просто ближайшие окажутся далеко. Поэтому в системе обязателен порог: если расстояние до лучшего фрагмента больше заданного, правильное поведение — сказать «в базе нет ответа» и передать вопрос человеку, а не пересказывать случайно подвернувшийся текст. Отсутствие такого порога — одна из причин, по которой ассистент уверенно отвечает неправду.
Слабое место: артикулы, номера договоров, даты и суммы
Тот же механизм, который спасает на перефразированных вопросах, ломается на точных идентификаторах. Для модели эмбеддингов «Приказ № 118» и «Приказ № 181» — почти одно и то же: тексты вокруг похожи, структура одинаковая, а сама цифра занимает в смысле фрагмента ничтожную долю. Артикул ТК-4471-02 и артикул ТК-4471-12 окажутся практически в одной точке. То же с датами, суммами и номерами договоров.
Для бизнеса это означает конкретный класс ошибок, который выглядит особенно неприятно: система отвечает уверенно, со ссылкой на документ, и документ не тот. Сотрудник спрашивает про условия по договору № 447, получает ответ по договору № 474 — и ответ выглядит правдоподобно, потому что договоры типовые. Заметить такое по тексту ответа почти невозможно; ловится оно только сверкой с источником.
Две колонки: «Векторный поиск» и «Поиск по словам». Пять строк сравнения. «Вопрос своими словами, других терминов» — находит / не находит. «Синонимы и внутренний сленг» — находит / только со словарём синонимов. «Номер приказа, договора, артикул» — путает похожие / находит точно. «Дата и сумма» — почти не различает / различает. «Опечатка в слове» — обычно переживает / промахивается. Внизу общая полоса с подписью «на контрольных 100 вопросах: 71 попадание против 60 — и промахи в разных местах».
Обходится это тремя приёмами, и все три должны быть в смете явно. Первый — та самая пара с обычным текстовым поиском, о которой ниже. Второй — метаданные: номер документа, дата, контрагент, тип вынимаются в отдельные поля при загрузке базы и работают как обычный фильтр, а не как часть смысла. Тогда вопрос «условия по договору № 447» сначала сужает выборку до одного договора и только потом ищет по смыслу внутри него. Третий — проверка на выходе: если в вопросе есть идентификатор, а в найденном фрагменте его нет буквально, фрагмент отбрасывается. Ни один из приёмов не появляется сам собой при выборе «хорошей платформы» — это работа на 30 000–60 000 ₽ в проекте.
Фраза в коммерческом предложении означает только выбранный механизм, а не то, что поиск работает. На базе, где половина обращений содержит номер документа или артикул, чистый векторный поиск даст заметно худший результат, чем обычный полнотекстовый, который стоит на порядок дешевле. Спрашивайте не про технологию, а про замер на ваших вопросах.
Гибридный поиск: 89 попаданий из 100 вместо 71
Рабочий стандарт на сентябрь 2026 — гибридный поиск: оба механизма запускаются параллельно, их результаты сводятся в один список, и модели передаются лучшие фрагменты из объединённого набора. Стоит такая настройка 30 000–60 000 ₽ разово в рамках проекта и не требует ни другого хранилища, ни другой модели.
Схема, в которой по одному вопросу параллельно работают два механизма — векторный и обычный текстовый, — а их выдачи объединяются в один ранжированный список. Настройки здесь две: вес каждого механизма при слиянии и глубина, сколько кандидатов берётся от каждого до объединения. Обе подбираются под вашу базу на контрольном наборе вопросов и не переносятся с чужого проекта.
Насколько это меняет картину, видно только на замере. Методика простая и повторяемая: берётся 100 реальных вопросов, для каждого вручную отмечается, в каком фрагменте лежит правильный ответ, и считается доля случаев, когда этот фрагмент попал в первую пятёрку выдачи. Ниже — модельный замер на типовой базе регламентов из 380 документов, где 60 вопросов заданы свободной формулировкой, а 40 содержат точный идентификатор: номер приказа, артикул, дату или сумму.
| Тип поиска | Вопросы своими словами (60) | Вопросы с идентификатором (40) | Всего из 100 |
|---|---|---|---|
| Только векторный | 51 | 20 | 71 |
| Только по словам | 23 | 37 | 60 |
| Гибридный | 53 | 36 | 89 |
Групповая столбчатая диаграмма. Три группы по два столбца: «Только векторный» — 51 из 60 и 20 из 40; «Только по словам» — 23 из 60 и 37 из 40; «Гибридный» — 53 из 60 и 36 из 40. Первый столбец в каждой группе подписан «вопросы своими словами», второй — «вопросы с номером или артикулом». Над каждой группой итог: 71, 60, 89 из 100. Столбцы группы «Гибридный» выделены. Ось Y — число попаданий фрагмента в первую пятёрку выдачи. Подпись внизу: «модельный замер, база 380 документов, 100 контрольных вопросов».
Обратите внимание на две вещи в таблице. Первая: гибрид не складывает результаты, а почти повторяет лучший механизм на каждой половине — 53 из 60 против 51 у векторного и 36 из 40 против 37 у текстового. Это нормально и это правильный ориентир: гибрид не творит чудес, он просто перестаёт проваливаться на чужой половине. Вторая: 89 из 100 — не потолок, а хорошая рабочая планка. Оставшиеся 11 случаев почти всегда лечатся не поиском, а самой базой: противоречащие редакции, оторванный от текста заголовок, таблица, превращённая распознаванием в кашу.
Во что обходится плохой поиск: 58 800 ₽ в месяц
Разница между 71 и 89 попаданиями из 100 звучит абстрактно, пока не переведена в рабочее время. Вводные модельного примера те же, что мы используем в разборах по этому разделу: компания на 140 человек, внутренний ассистент отвечает сотрудникам, поток 6 000 обращений в месяц. Вопрос, на который система не ответила, уходит методисту: около 7 минут с учётом поиска нужного документа, ставка с налогами примерно 700 ₽/час, то есть 81,67 ₽ за вопрос.
Оговорка, без которой расчёт нечестен: попадание фрагмента в выдачу и верный ответ — не одно и то же. Модель может найти нужный текст и всё равно ответить неточно, поэтому мы переводим в результат только две трети прироста. И вторая оговорка, общая для всех подобных расчётов: экономия здесь — возвращённое время, а не сокращение людей. Если методистам нечем занять освободившиеся часы, эта сумма останется на бумаге. Как считать такие эффекты, чтобы им можно было верить, разобрано в материале про измерение эффекта автоматизации.
Модель эмбеддингов: менять нельзя, не пересчитав всю базу
Числа для фрагментов считает отдельная модель — модель эмбеддингов, и она не та же самая, что отвечает на вопросы. Ключевое свойство: наборы чисел от разных моделей несопоставимы между собой. Это не «немного хуже совпадает», а просто разные системы координат. Поэтому смена модели эмбеддингов означает пересчёт всей базы целиком: старые записи после этого бесполезны.
Схема из трёх блоков со стрелками. Блок 1 «База: 380 документов, 3 400 фрагментов» со стрелкой в блок 2 «Модель эмбеддингов A» и далее в блок «Хранилище, координаты A». Ниже параллельная дорожка: тот же блок 1 → «Модель эмбеддингов B» → «Хранилище, координаты B». Между двумя хранилищами перечёркнутая двусторонняя стрелка с подписью «несопоставимы». Справа столбик из трёх строк с подписью «что стоит смена»: «пересчёт 2,4 млн токенов — около 48 ₽», «повторный замер на 100 вопросах и подстройка порогов — 25 000–40 000 ₽», «окно, пока поиск работает по старому индексу».
Хорошая новость: сам пересчёт почти ничего не стоит. Эмбеддинги тарифицируются порядка 0,02 ₽ за 1 000 токенов — на порядок дешевле генерации ответов. База из 380 документов даёт около 3 400 фрагментов, это примерно 2,4 млн токенов, то есть около 48 ₽ за полный пересчёт. Плохая новость: деньги уходят не туда. Пересчёт обесценивает предыдущую настройку — пороги отказа, веса гибридного поиска, границы фрагментов подбирались под старые расстояния и после смены модели должны подбираться заново, вместе с повторным замером на контрольных 100 вопросах. Это 25 000–40 000 ₽ и один-два дня работы.
Практический вывод для договора: зафиксируйте модель эмбеддингов по имени и версии, как и основную модель, и отдельно оговорите, за чей счёт делается пересчёт и повторный замер при её смене. Иначе через год провайдер объявит старую версию устаревшей, и разговор о том, кто платит за перенастройку, начнётся с нуля.
Русский язык: бенчмарки не переносятся на ваши документы
Место модели в публичном рейтинге почти всегда измерено на англоязычных наборах общего назначения. На русских документах картина другая, и отличается она в обе стороны: одна модель хорошо держит канцелярит и юридические формулировки, но путается в сокращениях, другая наоборот. Добавьте сюда отраслевой сленг, склонения, сокращения вроде «УПД» и «КС-2», внутренние названия — и рейтинг перестаёт что-либо предсказывать.
Проверка занимает один рабочий день и делается до выбора платформы, а не после. Порядок такой.
- 1Соберите 100 вопросов и разметьте ответы
Берите настоящие вопросы из переписки и обращений, а не придуманные. Для каждого укажите документ и абзац, где лежит правильный ответ. Обязательно держите пропорцию, близкую к реальной: у нас в примере 60 свободных формулировок и 40 с точным идентификатором. Этот набор потом переиспользуется на каждой приёмке и при каждой смене модели.
- 2Прогоните набор через две-три модели эмбеддингов
Достаточно взять кусок базы на 300–500 фрагментов — полная база для сравнения не нужна. Считается одна цифра: в скольких случаях из 100 нужный фрагмент попал в первую пятёрку. Разброс между моделями на русских документах обычно составляет 8–15 процентных пунктов, и лидер англоязычного рейтинга оказывается первым далеко не всегда.
- 3Посмотрите отдельно на промахи
Разложите неудачные случаи на две кучки: «вопрос своими словами» и «вопрос с номером или артикулом». Если во второй кучке промахов много у всех моделей — это не повод менять модель, это повод настраивать гибридный поиск. Такое разделение экономит недели споров с подрядчиком о том, что именно чинить.
Два вопроса подрядчику про поиск
На первой встрече о технологии поиска обычно не говорят вовсе — обсуждают каналы, интеграции и сроки. Между тем именно поиск определяет качество будущей системы: в восьми случаях из десяти неверный ответ возникает до того, как модель вообще включается в работу. Два вопроса ниже занимают три минуты и сразу показывают уровень собеседника.
- 1«Поиск гибридный или только векторный? Покажите на одном наборе, как система находит документ по номеру приказа и по фразе своими словами». Если в ответ звучит только «у нас векторный поиск, современная технология» — механизма поиска по точным идентификаторам в системе нет, и вопросы с артикулами и номерами договоров будут промахиваться. Это не смертельно, но должно попасть в смету как отдельная работа на 30 000–60 000 ₽, а не всплыть на третьем месяце.
- 2«Какая модель эмбеддингов используется, зафиксирована ли её версия и за чей счёт пересчёт базы и повторный замер при её смене?» Правильный ответ содержит имя и версию модели и упоминание о том, что при смене нужен повторный замер. Ответ «мы используем лучшую на рынке» означает, что версия не зафиксирована и через год вы будете оплачивать перенастройку как новую работу. Что ещё стоит закрепить в документах, разобрано в материале про договор на разработку.
Когда векторный поиск не нужен
Смысловой поиск стал обязательным пунктом любого предложения, и это делает его частой переплатой. Ниже — случаи, где обычный полнотекстовый поиск справляется не хуже и стоит на порядок дешевле.
- Почти все запросы содержат точный идентификатор. Поиск по номеру накладной, по артикулу, по номеру заказа — это работа для обычного индекса учётной системы. Векторное хранилище здесь только добавит ошибок и расходов.
- База маленькая и стабильная — до 20–30 страниц. Весь текст помещается прямо в запрос к модели, и поиск не нужен вовсе: система физически не может не найти нужное место.
- Пользователи спрашивают строго терминами из документа. Так бывает в узких профессиональных областях, где формулировка вопроса совпадает с формулировкой регламента почти дословно. Полнотекстовый поиск даст здесь сопоставимый результат.
- Документы противоречат друг другу и никто не знает, какая редакция действует. Любой поиск в этой ситуации будет уверенно приносить отменённый приказ. Сначала ревизия документов — порядок подготовки данных перед внедрением мы разбирали отдельно, — потом настройка поиска.
- Меньше 300–400 обращений в месяц. Постоянные расходы контура съедят экономию независимо от того, насколько хорошо настроен поиск.
Зеркальный признак применимости прост: векторный поиск нужен там, где люди спрашивают своими словами, документов больше сотни страниц и формулировки вопросов не совпадают с формулировками регламентов. Если это про вас — берите сразу гибридный вариант, а не чистый векторный: разница в цене составляет десятки тысяч рублей один раз, разница в результате — 18 процентных пунктов каждый месяц.
