Слабости эмбеддингов и четыре условия точного поиска по смыслу

Зачем это знать

• Понять заранее, на каких запросах поиск по документам промахнётся, и заложить это в приёмку
• Спросить подрядчика про разграничение доступа до того, как база собрана, а не после
• Получить простой замер точности, который считается силами одного сотрудника за день

Что такое слабости эмбеддингов простыми словами

Представьте склад, где коробки расставлены по смыслу содержимого. Похожее стоит рядом: крепёж у крепежа, смазки у смазок. Кладовщик ищет не по номеру, а по описанию — и обычно находит быстрее любого каталога.

Так работает эмбеддинг: текст превращается в набор чисел, близкие по смыслу тексты оказываются рядом. Поиск сводится к вопросу «что лежит ближе всего к запросу».

Отсюда и слабые места. На складе по смыслу тяжело найти конкретную коробку по инвентарному номеру: номер смысла не несёт. Две редакции одного договора лежат вплотную, различить их по описанию нельзя. И полка общая: если её не разгородить, каждый видит всё.

Как это работает и где промахивается

1. Документы режут на куски. Кусок в полстраницы — обычный размер. Таблица, разорванная пополам, теряет заголовки колонок, и найденный фрагмент перестаёт быть понятным сам по себе.
2. Каждый кусок превращают в числа. Смысл сохраняется, точные обозначения размываются: артикул АТ-4471-02 и АТ-4471-12 для модели почти одно и то же.
3. Куски складывают в векторную базу. Права на исходные папки при этом не переносятся. Разграничение задаётся отдельным полем у каждого куска и фильтром по нему.
4. Запрос ищут по близости. Возвращается пять-десять ближайших кусков. Свежесть, версия и статус документа на близость не влияют — старая редакция обгоняет новую так же часто, как наоборот.
5. Найденное отдают модели. Дальше работает RAG: ответ собирается по этим кускам. Промах поиска превращается в уверенный неверный ответ, потому что модель верит тому, что ей передали.

Отдельная история — изменение тона. Когда базу пополняют сухими регламентами, ответы поддержки становятся суше и формальнее, хотя фактическая точность растёт. OWASP описывает это как побочный эффект дополнения ответов поиском, и на линии поддержки он заметен раньше, чем в отчётах.

Пример из практики

Сервисная компания, база знаний на 4 000 страниц: регламенты, паспорта оборудования, переписка с заводом. Инженеры спрашивают голосом и текстом, поиск по смыслу подключили за две недели.

Цифры ниже — расчётный ориентир для компании такого профиля, а не отчёт по конкретному внедрению. Методика замера указана, чтобы её можно было повторить на своих данных.

Замер простой: 100 реальных вопросов инженеров за месяц, к каждому вручную помечен правильный документ. Считается доля запросов, где нужный документ попал в первую пятёрку выдачи. На чистом поиске по смыслу такой ориентир — около 68 из 100. Промахи собираются в три кучки: точные артикулы, устаревшие редакции, узкие термины завода.

Дальше добавляют три вещи. Точное совпадение по номеру и артикулу параллельно смысловому поиску. Фильтр по дате и статусу документа до поиска. Переранжирование первой двадцатки отдельной моделью. Тот же замер на тех же 100 вопросах даёт около 84 из 100.

Оставшиеся 16 промахов честнее оставить людям. Половина из них — вопросы, на которые в базе ответа нет вовсе.

Что это даёт бизнесу

• Приёмка получает цифру. Доля попаданий в первую пятёрку измеряется до оплаты и после каждой доработки. Подрядчику задаётся порог, ниже которого работа не принимается.
• Риск утечки закрывается на старте. Поля доступа проектируются вместе с базой. Переделка разграничения на собранной базе означает повторную загрузку всех документов.
• Бюджет тратится точечно. Три кучки промахов лечатся разными средствами разной цены: фильтр по дате — правка запроса, словарь терминов — день работы, переранжирование — отдельная модель и отдельный счёт.
• Ответы остаются в тонусе. Изменение тона после пополнения базы отслеживается той же выборкой диалогов, что и точность.

Когда без этого можно обойтись

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

Не нужен разбор слабостей и там, где вопросы строго типовые: десять форм заявок, фиксированные поля, готовые ответы. Такой процесс дешевле закрыть справочником и правилами. Прикинуть, готов ли конкретный процесс к автоматизации, помогает чек-лист.

Что важно проверить

Первое: попросите показать замер на ваших документах и ваших вопросах, а не демонстрацию на подготовленной выборке. Достаточно 100 запросов и одного дня разметки силами предметного специалиста.

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

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