База знаний для поиска по документам — это не папка с файлами и не диск с регламентами. Это набор фрагментов по 300–800 слов, у каждого из которых есть источник, дата вступления в силу и статус. Пока документы лежат в исходном виде, система будет находить отменённые редакции наравне с действующими и отвечать по ним ровно так же уверенно.
Это же и та часть проекта, которую нельзя целиком отдать подрядчику. Он умеет распознавать сканы, настраивать правила разбиения и строить индекс. Но решить, какая из трёх версий приказа действует, что означает сокращение в номенклатуре и кому из сотрудников этот документ вообще предназначен, может только человек изнутри компании. Как устроен сам механизм ответа по документам, разобрано в опорной статье про поиск по вашим документам; здесь — то, что делается до него.
Дальше — почему фрагмент именно такого размера; как резать документы, чтобы не разрывать смысл; шесть обязательных полей и как они используются в фильтрации; что нельзя загружать в базу вовсе; правило актуальности и цена его отсутствия в рублях; процедура замены регламента за один день; и честный счёт часов на базах в 300 и 3 000 документов.
Почему кусок в 300–800 слов, а не файл и не абзац
Поиск не ищет по документам — он ищет по фрагментам и подставляет в запрос модели только найденные. Отсюда два ограничения с разных сторон. Слишком крупный фрагмент топит нужное предложение в лишнем тексте и дорого стоит: регламент на 40 страниц — это около 14 000 слов, при пяти таких фрагментах запрос перестанет помещаться в разумный бюджет. Слишком мелкий теряет контекст: фраза «в этом случае срок составляет 14 дней» без названия раздела не отвечает ни на один вопрос, потому что неизвестно, о каком случае речь.
Три вертикальные колонки одинаковой ширины: «Файл целиком», «Отдельный абзац», «Раздел, 300–800 слов». В каждой сверху схематичный лист: в первой — весь лист залит серым, во второй — закрашена одна тонкая полоска в середине, в третьей — закрашен блок с заголовком сверху. Ниже в каждой колонке три строки: «Объём» (14 000 слов / 60 слов / 300–800 слов), «Сколько таких кусков влезет в один запрос» («меньше одного, 8–12 ₽ за вопрос» / «сотни, и каждый бесполезен» / «пять-семь без ущерба для бюджета»), «Что ломается» («лишний текст топит нужное» / «нет контекста: непонятно, о каком случае речь» / «—»). Третья колонка выделена тоном.
Практический ориентир — один фрагмент равен одному смысловому разделу: пункт регламента, раздел инструкции, описание одной услуги, ответ на один типовой вопрос. Если раздел получается длиннее 800 слов, он режется по подзаголовкам; если короче 150 — склеивается с соседним внутри того же раздела. Разброс 300–800 не догма, а следствие того, как написаны деловые документы: именно такой длины в них обычно оказывается законченная мысль.
Единица хранения и поиска: кусок документа с сохранённым заголовком раздела, ссылкой на исходный файл и набором полей-метаданных. Модель никогда не видит ваш документ целиком — она видит несколько фрагментов, отобранных поиском. Всё, чего нет во фрагменте, для неё не существует, поэтому заголовок раздела внутри фрагмента — не украшение, а часть данных.
Резать по заголовкам, а не по счётчику символов
Самый дешёвый способ нарезки — механический: отсчитать 2 000 символов и поставить границу. Он же самый вредный, потому что граница регулярно проходит посередине пункта. В модельном замере на 100 контрольных вопросах механическая нарезка дала 12 ответов, склеенных из двух разных разделов, — формально текст был найден верно, а по смыслу ответ относился к другому случаю. Правильный порядок — сначала разметка по заголовкам исходного документа, и только внутри слишком длинных разделов — по объёму.
- Заголовок раздела копируется внутрь каждого фрагмента. Это одно техническое решение, которое даёт больше всего качества: в замере, описанном в опорной статье про поиск по документам, фрагменты без сохранённого заголовка дали 22 неверных ответа на 100 вопросов.
- Перекрытие соседних фрагментов 10–15 %. Последний абзац предыдущего фрагмента повторяется в начале следующего, чтобы мысль, разорванная границей, целиком попадала хотя бы в один из них. Платится это небольшим ростом объёма базы, и оно того стоит.
- Таблицы не индексируются как текст. Строка «Москва — 2 дня — от 5 000 ₽ бесплатно» сама по себе не отвечает ни на один человеческий вопрос. Таблицы либо переписываются в текстовые формулировки при нарезке, либо выносятся в отдельный источник, к которому система обращается запросом, а не поиском.
- Приложения разделяются на бланки и правила. Пустой бланк заявления индексировать бессмысленно, а правила его заполнения — обязательно. Это две разные сущности, которые в исходном файле обычно живут вместе.
- Списки и нумерация сохраняются. Пункты 3.1–3.7, превращённые в сплошной абзац, теряют структуру, а вместе с ней — возможность сослаться в ответе на конкретный пункт.
Что за это отвечает технически — способ, которым система измеряет близость вопроса к фрагменту. Он же объясняет, почему артикулы и номера договоров ищутся хуже формулировок: механизм разобран в статье про смысловой поиск и эмбеддинги. При подготовке базы из этого следует одно практическое правило: если в документе есть точные идентификаторы — коды, артикулы, номера, — их нужно оставить во фрагменте текстом, а не выносить в отдельную таблицу.
Шесть полей, без которых поиск не фильтруется
Метаданные — это то, что превращает свалку фрагментов в базу. Они не участвуют в поиске по смыслу, они отсекают лишнее до него: система сначала оставляет только те фрагменты, которые действуют и относятся к спрашивающему, и уже среди них ищет подходящие. Без этого шага действующая и отменённая редакции конкурируют на равных, и выбор между ними — лотерея.
| Поле | Пример значения | Как используется |
|---|---|---|
| Источник | Регламент отгрузки.docx, раздел 4.2, стр. 11 | Подставляется в ответ как ссылка; без неё сотрудник не может проверить, а спор не разбирается |
| Дата вступления в силу | 01.03.2026 | При конфликте двух фрагментов побеждает более поздний; в ответе указывается редакция |
| Статус | действует / отменён / проект | Жёсткий фильтр до поиска: отменённое и проекты в выдачу не попадают вовсе |
| Владелец | Иванова, руководитель склада | Имя, а не отдел. К кому идти с вопросом и кто отвечает за ревизию |
| Аудитория | склад; все магазины; юрлицо «Альфа» | Продавец не видит документы для руководителей, филиал — чужие региональные условия |
| Дата следующей ревизии | 01.09.2026 | Основание для планового пересмотра; просроченные документы попадают в отчёт |
Схема слева направо. Слева — карточка фрагмента: сверху заголовок раздела, ниже блок текста, справа столбцом шесть подписанных полей: «Источник», «Дата вступления в силу», «Статус», «Владелец», «Аудитория», «Дата ревизии». От карточки стрелка к вертикальному прямоугольнику-фильтру с подписью «Фильтр: статус = действует, аудитория = роль спрашивающего». За фильтром — блок «Поиск по смыслу», за ним «Пять фрагментов в запрос модели». Сбоку от фильтра отбрасываемая стопка с подписью «отменённые редакции и чужие разделы». Под схемой подпись: «в замере 9 ответов из 100 опирались на отменённые редакции, после фильтра — ни одного».
Проставляются эти поля на уровне документа и наследуются всеми его фрагментами — вручную размечать каждый кусок не нужно. Исключение одно: аудитория, если внутри документа есть разделы для разных ролей. Эффект измеряется на тех же контрольных вопросах, что и всё остальное: в модельном замере до включения фильтра по статусу 9 ответов из 100 опирались на отменённую редакцию, после — ни одного. Как строится сам замер и почему тридцати вопросов не хватает, разобрано в материале про измерение качества на своих данных.
Что нельзя загружать в базу как есть
Соблазн «залейте всё, система разберётся» понятен: он экономит недели работы. Разбирается система плохо, а последствия видны не сразу — первые две недели база выглядит богатой, а потом начинают приходить жалобы на ответы, которые никто не может объяснить. Шесть категорий, которые нужно остановить на входе.
- Сканы без текстового слоя. Для поиска это пустые файлы. Распознавание делают Content AI (российский преемник ABBYY: ContentReader вместо FineReader, ContentCapture вместо FlexiCapture), Smart Engines или 1С:Распознавание первичных документов; после распознавания обязательна выборочная вычитка — на таблицах и печатях ошибки распознавания идут гуще всего.
- Презентации. Текст в картинках, тезисы без контекста, слайд «Наши преимущества» из четырёх слов. Если презентация — единственный носитель знания, его надо записать текстом; индексировать слайды бессмысленно.
- Переписка и чаты. Нет статуса, нет владельца, есть прямые противоречия между сообщениями разных лет. Из переписки вынимают правила и записывают отдельным документом — это одна из самых полезных работ подготовки, и она же самая трудоёмкая.
- Черновики и файлы вида «версия_финал_2_правки». Пока не понятно, какая редакция действует, документ в базу не идёт. Это не педантизм: система не различает черновик и утверждённый текст никак, кроме поля статуса.
- Отменённые редакции без пометки. Их не удаляют — они нужны для разбора старых споров, — но переводят в статус «отменён», после чего они перестают попадать в поиск и остаются доступны по прямому запросу.
- Выгрузки цен, остатков и графиков. Это данные, а не знания: они меняются ежедневно, и правильный способ их получить — запрос в учётную систему во время ответа, а не поиск по проиндексированной копии вчерашнего дня.
В приложениях к регламентам регулярно живут списки сотрудников с телефонами, а в примерах заполнения документов — реальные ФИО и адреса клиентов. Попав во фрагменты, они уезжают провайдеру модели в каждом запросе, где такой фрагмент найден. Перед загрузкой приложения проверяются отдельно, а примеры заменяются обезличенными. Это не только требование 152-ФЗ — это ещё и защита от ситуации, когда агент называет клиенту чужой телефон из примера в инструкции.
Правило актуальности и цена его отсутствия
У каждого документа в базе есть имя владельца и дата следующей ревизии. Это правило звучит бюрократически ровно до первого случая, когда агент три месяца отвечает по отменённому прайсу, и никто в компании не может назвать человека, который должен был это заметить.
Считаем деградацию на нашем модельном потоке: 6 000 обращений в месяц, из них 4 % касаются цен и условий — это 240 вопросов. Прайс сменился, старый файл остался в индексе со статусом «действует»; поиск находит обе редакции, и в трёх случаях из десяти наверх выходит старая. Получается 72 обращения в месяц с неверной ценой. Разбор каждого — 40 минут работы менеджера по ставке 700 ₽/час.
И это только прямые часы. Сюда не входит то, что часть названных старых цен придётся дать клиенту, и не входит потеря доверия сотрудников к системе: после трёх случаев подряд люди перестают спрашивать агента и возвращаются к переписке с коллегами — а платить за систему компания при этом продолжает. Кто конкретно ведёт базу в компаниях разного размера и сколько это часов в месяц, мы разбирали в отдельном материале про ведение базы знаний поддержки.
Процедура замены: как убить старую версию в тот же день
Главное свойство поиска по документам — обновление вступает в силу за минуты, без переобучения модели. Но только при условии, что процедура написана и ей следуют. Шесть шагов ниже занимают около получаса на один документ и закрывают весь сценарий из предыдущего раздела.
- 1Правка идёт в источнике, не в базе
Документ редактируется там, где он живёт официально: в папке регламентов, в системе документооборота, в 1С:Документооборот. База знаний — производная, и править её напрямую нельзя, иначе через месяц источник и база разойдутся.
- 2Старая редакция получает статус «отменён» и дату
Не удаляется, а помечается. После этого она мгновенно выпадает из фильтра поиска и перестаёт конкурировать с новой, но остаётся доступна по прямому запросу для разбора старых обращений.
- 3Новая редакция загружается с датой вступления в силу
Дата ставится реальная — та, с которой правило действует, а не день загрузки файла. Эта разница важна при разборе спора: агент должен уметь ответить, что действовало в момент обращения клиента.
- 4Переиндексация затронутых фрагментов
Пересчитываются только изменённые документы, не вся база: это минуты и копейки. Полный пересчёт базы нужен только при смене модели эмбеддингов — отдельная и редкая операция.
- 5Три контрольных вопроса из списка
Из готового списка контрольных вопросов берутся три, относящихся к изменённому документу. Ответ должен ссылаться на новую редакцию и новую дату. Если ссылается на старую — где-то не проставлен статус, и это видно сразу, а не через месяц.
- 6Запись в журнале изменений базы
Что заменено, когда, кем, какая редакция отменена. Журнал нужен ровно для одного: когда через полгода придёт спор «нам ваш бот сказал другое», по нему за минуту восстанавливается, что система отвечала в тот день.
Горизонтальная лента из шести подписанных блоков со стрелками: «Правка в источнике» → «Старой редакции статус «отменён»» → «Новая редакция с датой вступления в силу» → «Переиндексация затронутых фрагментов» → «Три контрольных вопроса» → «Запись в журнале». Под второй блок выноска «выпадает из поиска мгновенно», под четвёртым — «минуты, не часы», под пятым — «ответ должен ссылаться на новую редакцию». Справа от ленты общая подпись «около 30 минут на документ».
Отдельно про календарь: не все документы требуют одинакового внимания. Прайсы и условия акций пересматриваются по событию, регламенты — раз в полгода, описания продукции — раз в год. Как разложить базу по срокам годности и не превратить ревизию в бесконечную работу, разобрано в материале про регламент обновления базы знаний.
Сколько это часов и кто это делает
Здесь самая частая неприятность проекта: в смете подрядчика подготовка базы стоит 55 000 ₽, и заказчик считает, что этим всё закрыто. На деле 55 000 ₽ — только инженерная половина: распознавание, настройка правил нарезки, индексация, замер. Вторая половина делается вашими предметными специалистами и не попадает ни в одну смету, потому что это внутренние часы.
| Работа | База 300 документов | База 3 000 документов | Кто делает |
|---|---|---|---|
| Инвентаризация и отбор: что вообще идёт в базу | 10 ч | 70 ч | предметный специалист |
| Сведение версий, снятие отменённых редакций | 14 ч | 120 ч | владельцы разделов |
| Вычитка после распознавания сканов | 15 ч | 150 ч | предметный специалист |
| Простановка шести полей метаданных | 20 ч | 170 ч | предметный специалист |
| Разбор таблиц и приложений | 12 ч | 90 ч | предметный специалист и инженер |
| Проверка границ фрагментов на выборке | 16 ч | 60 ч | предметный специалист |
| Список контрольных вопросов и эталонные ответы | 13 ч | 20 ч | предметный специалист |
| Итого часов заказчика | 100 ч | 680 ч | — |
Две вертикальные составные колонки на одной шкале, ось Y — часы от 0 до 700. Левая колонка «300 документов» высотой 100 ч, правая «3 000 документов» высотой 680 ч. Обе разбиты на семь подписанных сегментов с числами: инвентаризация 10/70, версии 14/120, вычитка 15/150, метаданные 20/170, таблицы 12/90, границы фрагментов 16/60, контрольные вопросы 13/20. Сегменты «вычитка» и «метаданные» выделены тоном, к ним выноска «растут линейно». К сегменту «контрольные вопросы» выноска «почти не растёт». Под колонками подписи «90 000 ₽ внутренних часов» и «612 000 ₽ внутренних часов».
Из правой колонки следует практический вывод, который экономит проекты. 680 часов — это четыре месяца работы одного человека, и такой проект почти всегда умирает на подготовке. Правильный ход на большой базе — не готовить всё, а взять первые 200–300 документов, закрывающих восемь вопросов из десяти, запуститься на них и добирать остальное по мере появления вопросов, на которые система честно ответила «в базе этого нет». Такой список ненайденного — лучший план дальнейшего наполнения, и он бесплатный.
Второе следствие — про смету целиком. Если проект внедрения помощника стоит 175 000 ₽, реальная стоимость первого запуска составляет 265 000 ₽ вместе с вашими часами. Это не повод торговаться с подрядчиком: приведённые в порядок регламенты остаются вашими при любом исходе проекта и одинаково полезны новым сотрудникам и проверяющим. Это повод спланировать людей заранее — общий порядок работы с данными до внедрения разобран в материале про подготовку данных перед внедрением.
Когда полная подготовка не нужна
Процедура выше рассчитана на базу от полутора-двух сотен документов. Ниже этого объёма она превращается в дорогой ритуал, и есть более дешёвые ответы.
- Свод правил помещается в 15–20 страниц и живёт в одной редакции. Тогда никакой базы не нужно — правила кладутся прямо в запрос к модели. Это дешевле в разы; порог и арифметика перехода разобраны в статье про четыре подхода к подключению модели к данным.
- Вопросы касаются данных, а не знаний: остатки, цены, статусы заказов, графики смен. Здесь нужен не поиск по документам, а прямой запрос в учётную систему — и никакой нарезки, потому что нечего резать.
- Документы меняются чаще, чем раз в неделю, и версионирования в компании нет. Сначала наводится порядок в источнике, потом строится база. В обратном порядке вы получите систему, которая аккуратно отвечает по хаосу.
- Меньше 300–400 обращений в месяц. При таком потоке 100 часов подготовки и 145 000 ₽ не вернутся ни экономией времени сотрудников, ни снятой очередью: дешевле оставить папку с регламентами и поиск по ней.
Зеркальный признак — когда браться стоит: документов больше двухсот, они регулярно противоречат друг другу, а на один и тот же вопрос разные сотрудники отвечают по-разному. В такой ситуации подготовка базы окупается ещё до запуска системы, просто потому что впервые появляется одна действующая редакция каждого правила.
