Когда компания «загружает базу знаний в нейросеть», обычно происходит не обучение, а сборка поискового конвейера вокруг модели. Разница определяет всё остальное: что чинится за день, что требует переделки и почему ответ иногда уверенно ссылается на документ, в котором нужного нет.
Чем это отличается от обучения модели
Модель не запоминает ваши документы. Она получает их фрагменты прямо в тексте запроса — каждый раз заново, под конкретный вопрос, и после ответа не помнит о них ничего.
Дообучение меняет саму модель: её поведение, стиль, склонность отвечать определённым образом. Повторять его приходится при каждом заметном изменении данных, а проверить, что именно осело в весах, снаружи нельзя. Сборка по документам меняет только то, что модель видит в момент ответа, — и это даёт три практических следствия.
Документ, удалённый из хранилища, перестаёт влиять на ответы сразу. Обновление регламента — это переиндексация, а не переобучение. Разграничение доступа делается на слое поиска: разным людям отдаются разные фрагменты одной и той же моделью. Ни одно из трёх свойств не появляется при дообучении.
Что при этом не меняется — устройство самой модели. Она по-прежнему достраивает правдоподобное продолжение текста, просто теперь у неё под рукой ваш текст вместо усреднённого. Механика разобрана в материале про устройство языковых моделей.
Конвейер из пяти шагов
Между вопросом и ответом происходит пять операций, и полезно держать их раздельно — ломаются они по-разному.
- Подготовка. Документы приводятся к тексту: извлекается содержимое файлов, таблиц, подписей к рисункам. Сканы без распознавания на этом шаге исчезают молча — дальше их просто нет.
- Нарезка. Текст режется на фрагменты подходящего размера. Шаг выглядит техническим и определяет больше, чем кажется, — про него отдельный раздел ниже.
- Векторизация. Каждый фрагмент превращается в эмбеддинг — набор чисел, задающий положение текста в смысловом пространстве. Тем же способом обрабатывается и вопрос.
- Поиск. Векторный поиск достаёт фрагменты, ближайшие к вопросу. Здесь же применяются фильтры по метаданным: раздел, дата, права доступа.
- Сборка ответа. Найденное подставляется в запрос вместе с инструкцией — что делать с фрагментами, как ссылаться, что отвечать при отсутствии данных. Формулировка этой инструкции подчиняется общим правилам постановки задачи.
Ключевое свойство конвейера: ошибка предыдущего шага не видна следующему. Поиск не знает, что фрагмент нарезан неудачно. Модель не знает, что нужный документ в подборку не попал, — и добросовестно отвечает по тому, что дали. Поэтому вопрос «почему плохой ответ» почти никогда не решается заменой модели.
Похожесть — не подтверждение
Поиск отбирает фрагменты по смысловой близости. Близкий текст и подтверждающий текст — разные вещи, и на этой границе живёт основная часть ошибок.
Фрагмент про соседний случай, про прошлую версию правила, про другой продукт с похожим названием окажется близким к вопросу: он про то же самое, только не про то. Модель получает его как контекст и отвечает по нему, потому что ничего другого ей не дали. Формально ответ подкреплён документом, фактически подкрепление не работает — это та самая ошибка атрибуции, разобранная в материале про галлюцинации моделей.
То же устройство видно снаружи, в публичных системах. Замер 853 сгенерированных ответов показывает, что источников в одном ответе оказывается в среднем 11,2 — то есть подборка широкая, и попадание в неё определяется формой фрагмента, а не его правотой. Внутренняя база отличается только тем, что за её состав отвечаете вы.
Отсюда практическое требование к инструкции: система должна уметь отвечать «в документах этого нет». Без явного разрешения на такой ответ модель заполнит пустоту правдоподобным, потому что это её обычный режим. Если такая система отвечает клиентам, признание «в документах этого нет» должно вести не в тупик, а к человеку, и спор бот или оператор решается тем, во что обойдётся неверный ответ, а не гладкостью текста.
Нарезка решает больше, чем выбор модели
Шаг, который выглядит настройкой на полчаса, определяет качество сильнее остальных четырёх вместе взятых.
Мелкий фрагмент теряет условие применения. «Скидка составляет десять процентов» — верное утверждение, вырванное из абзаца, где сказано, для какого договора и до какой даты. Ответ получается точным по букве и ложным по смыслу, и заметить это по самому ответу невозможно.
Крупный фрагмент размывает нужное. Одно предложение внутри трёх страниц слабо влияет на смысловое положение всего куска, поэтому поиск такой фрагмент не поднимает — документ «есть в базе» и не находится.
Что помогает на практике:
- Резать по смысловым границам, а не по числу знаков: раздел, пункт регламента, вопрос-ответ. Границы документа обычно уже расставлены его автором.
- Добавлять к фрагменту заголовок родительского раздела и название документа. Иначе пункт 4.2 попадает в подборку без указания, к чему он относится.
- Хранить версию и дату в метаданных фрагмента и требовать их в ответе. Это единственный дешёвый способ поймать ответ по отменённому регламенту.
- Разводить таблицы и текст. Таблица, склеенная в строку, теряет связь ячеек со шапкой и превращается в набор чисел без подписей.
- Убирать дубли до загрузки. Три редакции одного документа дадут три близких фрагмента, которые займут всю подборку; механика та же, что у дублей на сайте, и решается тем же — выбором канонической версии.
Последний пункт связан с предварительной работой, которую пропускают чаще всего: разбором того, что вообще лежит в хранилище. Порядок такого разбора описан в материале про аудит контента, и он применим к внутренней документации не меньше, чем к сайту.
Где ломается конвейер
Отказы удобно разложить по слоям — так видно, что чинить, не переделывая всё.
| Слой | Что в нём настраивается | Как выглядит отказ |
|---|---|---|
| Подготовка | Извлечение текста, таблиц, подписей к рисункам | Система не знает того, что было в таблице или в скане |
| Нарезка | Размер фрагмента, перекрытие, привязка к заголовку | Ответ верен по букве и ложен по смыслу — условие осталось в соседнем фрагменте |
| Векторизация | Модель эмбеддингов, язык, единый формат для базы и вопроса | Не находится очевидное — вопрос и документ описаны разными словами |
| Поиск | Число фрагментов, порог близости, фильтры по метаданным | В подборке одна тема в шести вариантах, а нужный документ не попал |
| Сборка ответа | Инструкция, порядок фрагментов, требование ссылаться | Модель отвечает из общих знаний, игнорируя поданные фрагменты |
| Хранилище | Периодичность переиндексации, удаление устаревшего | Ответ по отменённой версии — старая редакция осталась в базе |
Читать таблицу лучше сверху вниз, а чинить — тоже сверху. Нижние слои настраиваются быстро и заметно, поэтому за них берутся первыми, хотя причина обычно в первых двух строках.
Проверять качество тоже стоит по слоям, а не по общему впечатлению. Отдельно — попал ли нужный фрагмент в подборку. Отдельно — правильно ли модель им воспользовалась. Смешивать эти два вопроса в одну оценку «нравится ответ или нет» бесполезно: они чинятся разными руками. Первый вопрос ближе к устройству поиска по сайту, второй — к работе с нейросетями для текста.
Ответ ссылается на документ, но нужной фразы в документе нет. Фрагмент подобран по близости, а не по подтверждению. Требовать в инструкции цитату из фрагмента, а не пересказ, и проверять совпадение цитаты с оригиналом — наличие ссылки проверкой не является.
Документ загружен, а система его не находит. Три частые причины по порядку проверки: текст не извлёкся из файла, фрагмент слишком крупный, вопрос сформулирован не теми словами, что документ. Первое проверяется за минуту — посмотреть, что вообще попало в хранилище.
Ответы ухудшились после добавления новых документов. Подборка ограничена по объёму, и близкие дубли вытесняют нужное. Убирать устаревшие редакции, а не увеличивать число подаваемых фрагментов.
Модель отвечает общими словами вместо содержания базы. Инструкция не запрещает отвечать из собственных знаний либо подборка пришла пустой. Разделить случаи просто — посмотреть, что подавалось в запрос; при пустой подборке правильный ответ звучит как «в документах этого нет».
Границы применимости
Конвейер решает задачу поиска ответа в тексте и не решает всё остальное, что от него ждут.
- Противоречия в документах он не разрешает. Если два регламента говорят разное, система выдаст один из них — тот, что оказался ближе к формулировке вопроса. Выбор между версиями остаётся человеческой работой.
- Арифметика и сводки — не его задача. «Сколько всего договоров с таким условием» требует обхода всей базы, а поиск по смыслу возвращает несколько ближайших фрагментов. Такие вопросы решаются запросом к данным, а не к тексту.
- Знание вне документов не появляется. Если практика нигде не записана, конвейер её не найдёт; он работает ровно с тем, что кто-то однажды написал.
- Проверка не отменяется. Ошибка меняет вид — вместо выдумки появляется неверно подобранный фрагмент, — но остаётся. Ответ по внутренней базе требует проверки не меньше, чем ответ машины со сносками.
- Смешение похожих названий сохраняется. Два продукта или два подразделения со схожими именами сливаются в один ответ ровно так же, как сливаются сущности в публичных ответах.
- Разграничение доступа надо строить отдельно. Если фильтры по правам не заданы на слое поиска, любой сотрудник получит содержание любого документа — и узнает об этом раньше вас.
Общее у пунктов: конвейер усиливает качество исходных документов и так же честно усиливает их беспорядок.
Спорное место
Слабое место этой конструкции — соблазн считать её заменой порядку в документах. Обещание звучит наоборот: загрузите что есть, система разберётся. На практике она не разбирается, а воспроизводит — противоречия, устаревшие версии, три редакции одного положения. Внедрение почти всегда упирается в то, что кто-то должен прочитать базу и решить, какая версия действующая, и эта работа не автоматизируется тем инструментом, ради которого затевалась.
Второе сомнение — про измеримость. Оценить такую систему честно трудно: нужен заранее составленный набор вопросов с известными правильными ответами, а составляет его тот же человек, который настраивал конвейер. Совпадение оценки с ожиданием здесь ничего не доказывает. Более надёжный, хотя и медленный признак — перестали ли люди искать документ вручную после того, как спросили систему; если продолжают проверять руками, конвейер работает как поисковая подсказка, а не как источник ответа, и планировать по нему экономию времени рано.
Третье касается места этой темы в маркетинге. Внутренняя база знаний и попадание в чужие ответы — разные задачи с общей механикой: и там и там текст сначала находят, а потом пересказывают. Различие в том, что состав внутренней выборки вы задаёте сами, а состав публичной — нет, и второе описывается четырьмя слоями видимости со своими правилами.
Частые вопросы
Чем это отличается от дообучения модели на наших данных?
Почему система не находит документ, который точно загружен?
Убирает ли такая сборка выдумку в ответах?
Какой размер фрагмента правильный?
Нужен ли для этого свой сервер и своя модель?