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