ИИ-ассистент не превращает разрозненные документы в единую правду. Он быстрее находит и убедительнее пересказывает то, что ему дали. Если в папке лежат три разных условия возврата, в чате закреплено исключение, а правильный срок знает только руководитель, ассистент воспроизведёт этот беспорядок в форме уверенного ответа.
Поэтому база знаний — самостоятельный редакционный продукт. Её качество определяется не числом загруженных файлов, а долей рабочих вопросов, на которые существует один действующий, доступный и проверяемый ответ. Ниже — порядок сборки от инвентаризации до приёмочного набора.
Шаг 1. Ограничьте тему и аудиторию#
Не начинайте со всей компании. Выберите одну аудиторию и один класс вопросов: операторы поддержки по условиям обслуживания, продавцы по продуктам, новые сотрудники по внутренним процедурам. Запишите, какие решения база не поддерживает. Например, она объясняет порядок возврата, но не решает, одобрять ли спорный возврат конкретному клиенту.
Карточка проекта занимает одну страницу:
- кто задаёт вопросы;
- по каким темам;
- из каких утверждённых источников берётся ответ;
- какие сведения доступны этой аудитории;
- кто подтверждает содержание;
- как выглядит полезный ответ;
- когда ассистент обязан сказать, что сведений нет;
- куда передаётся спорный вопрос.
Такой контур защищает от бесконечной загрузки документов «на будущее». Если файл не помогает выбранной аудитории решить вопрос, он не нужен в первой версии. Позже тему можно расширить отдельным пакетом и отдельными тестами.
Шаг 2. Соберите вопросы до документов#
Источником структуры должны стать реальные вопросы, а не папки на диске. Возьмите обращения поддержки, поисковые запросы внутри портала, письма новичков, заметки руководителей. Удалите персональные данные и сгруппируйте формулировки по намерению.
Для каждой группы запишите эталонное действие: дать краткий ответ, показать инструкцию, уточнить условие или передать специалисту. Частота помогает определить порядок, а цена ошибки — глубину проверки. Редкий вопрос о доступе к системе может быть важнее сотни вопросов о графике.
| Поле вопроса | Пример содержания |
|---|---|
| Формулировки | как спрашивают люди, включая сокращения и опечатки |
| Намерение | что человек хочет сделать после ответа |
| Цена ошибки | неудобство, лишняя работа, деньги, доступ или обязательство |
| Владелец ответа | должность, подтверждающая правило |
| Канонический источник | документ или страница, где правило закреплено |
| Исключения | когда общий ответ не действует |
| Эскалация | кому направить вопрос при нехватке данных |
Если на частый вопрос нет утверждённого источника, не поручайте ассистенту составить его. Это пробел процесса. Владелец должен сначала сформулировать и утвердить правило, а уже затем материал попадает в базу.
Шаг 3. Проведите инвентаризацию материалов#
Составьте реестр всех кандидатов: инструкции, регламенты, справки, страницы сайта, шаблоны писем, таблицы, презентации. Для каждого укажите адрес, формат, владельца, дату изменения, статус, аудиторию и связанные вопросы. Не копируйте файлы в новую папку, пока не разобрались, какой из них действующий.
Присвойте один из статусов:
- действующий — подтверждён владельцем и используется сейчас;
- требует проверки — возможно полезен, но нет подтверждения;
- черновик — не является основанием для ответа;
- архив — сохраняется для истории, но не участвует в выдаче;
- дубль — повторяет канонический источник;
- к удалению — не нужен и не имеет обязательного срока хранения.
Слово «новый» в названии и поздняя дата изменения ничего не доказывают. Владелец процесса письменно подтверждает, какая версия действует. Если владельца нет, назначьте его до публикации в базе: документ без ответственного со временем неизбежно устареет.
Не удаляйте материалы автоматически. Архивируйте их по внутренним правилам хранения и исключайте из поиска ассистента. Задача проекта — управлять выдачей, а не самовольно менять корпоративный архив.
Шаг 4. Выберите канонический источник#
Одно правило должно жить в одном месте. Если условия доставки повторяются в инструкции, скрипте, шаблоне письма и презентации, любое обновление придётся делать четыре раза. Практически его сделают в одном, и база начнёт противоречить сама себе.
Выберите каноническую страницу или документ. В остальных материалах оставьте краткую формулировку и ссылку либо полностью замените повтор ссылкой. Для каждого факта запишите, кто может его менять и какое событие запускает обновление: новый прайс, изменение продукта, утверждение регламента.
Конфликт разрешают до загрузки. Таблица разногласий выглядит так:
| Вопрос | Источник А | Источник Б | Решение владельца | Дата действия |
|---|---|---|---|---|
| одно и то же правило | формулировка и версия | другая формулировка | какая версия каноническая | с какого дня |
Нельзя просить модель «выбрать более свежий» текст без формального признака. Дата файла может отражать исправление опечатки, а не вступление правила в силу. Нужны отдельные поля версии, статуса и периода действия.
Шаг 5. Перепишите документы для поиска и чтения#
Хорошая статья базы отвечает на один связный вопрос и читается без устного контекста. Заголовок описывает действие пользователя, начало даёт короткий ответ, затем идут условия, шаги, исключения и эскалация. Внутренние сокращения расшифровываются при первом упоминании.
Шаблон статьи:
- название вопроса языком пользователя;
- короткий ответ в двух-трёх предложениях;
- для кого и когда правило действует;
- пошаговые действия;
- исключения и стоп-условия;
- ссылки на формы или связанные инструкции;
- владелец содержания;
- версия, дата действия и следующая проверка.
Таблицы снабжайте заголовками столбцов и пояснением. Сканированные PDF распознавайте и сверяйте, особенно числа, фамилии и маркировки. Текст в изображении дублируйте обычным текстом. Не прячьте важное исключение в сноску: система может получить общий фрагмент без неё.
Если ответ зависит от нескольких условий, сделайте таблицу решений. Явная конструкция «если — то — исключение» полезнее длинного абзаца и человеку, и поиску. Но не превращайте оценочное решение в механическое правило, если полномочие остаётся у руководителя.
Шаг 6. Разметьте версии, область и доступы#
Минимальный набор метаданных на каждый материал:
| Поле | Обязательное содержание |
|---|---|
| ID | постоянный идентификатор, не зависящий от названия |
| статус | действует, черновик или архив |
| версия | номер или дата утверждённой редакции |
| действует с/по | период применения |
| владелец | должность или команда |
| аудитория | кому можно показывать материал |
| тема и продукт | область, где правило применимо |
| дата проверки | когда содержание сверяли |
| следующая проверка | срок или событие-триггер |
Доступ наследуйте из исходного хранилища или задайте явными группами. Закрытый документ не должен попадать в поиск пользователя без прав даже в виде короткой цитаты. Инструкция модели не заменяет технический фильтр: если текст уже передан модели, граница доступа пройдена.
Особенно внимательно проверяйте документы, где рядом находятся общая справка и данные конкретных клиентов или сотрудников. Разделите их: общие знания — в базе, персональные записи — в системе с отдельными правами и журналированием.
Шаг 7. Подготовьте систему обновления#
У каждой статьи есть жизненный цикл. Изменение начинается не с сообщения редактору «когда будет время», а с события. Новый тариф запускает проверку страниц о цене. Изменение процесса — инструкций и шаблонов. Закрытие продукта — отзыв всех связанных материалов.
Регламент обновления должен отвечать на вопросы:
- кто создаёт заявку на изменение;
- кто подтверждает новую формулировку;
- как отзывается старая версия;
- когда обновление появляется в поиске;
- какие контрольные вопросы прогоняются после изменения;
- кто получает сообщение об ошибке;
- за какой срок критическая неточность исключается из выдачи.
Добавьте на каждую страницу кнопку или адрес для сообщения об ошибке. Пользователь должен приложить вопрос, неверный ответ и ссылку на источник. Владелец базы разбирает не только формулировку ответа, но и причину: документ неверен, поиск выбрал не то или ассистент добавил лишнее.
Шаг 8. Проведите приёмочный тест#
Контрольный набор собирают одновременно с вопросами. Для каждого примера есть ожидаемый ответ, допустимый источник и условие отказа. Не ограничивайтесь прямыми формулировками. Добавьте разговорные варианты, опечатки, сокращения, вопросы с неверной предпосылкой и запросы, на которые база не должна отвечать.
Проверка проходит в два слоя. Сначала убедитесь, что поиск поднял правильный действующий материал и не показал закрытый. Затем оцените итоговый ответ: не потеряны ли условия, не добавлены ли новые обещания, работает ли ссылка. Архитектура такого поиска разобрана отдельно в гайде RAG для бизнеса.
Матрица приёмки:
| Проверка | Успех |
|---|---|
| частый вопрос | найден канонический источник, ответ достаточен для действия |
| исключение | общее правило не выдано без оговорки |
| старый документ | архив не участвует в ответе |
| нет ответа | ассистент честно сообщает пробел и даёт маршрут |
| нет доступа | содержание не раскрывается прямо или косвенно |
| изменённая версия | после обновления контрольный ответ меняется предсказуемо |
Запускать базу стоит на ограниченной аудитории. Первые недели сохраняйте вопросы, выбранные источники, ответы и правки сотрудников. Частые неудачи превращайте либо в улучшение статьи, либо в новый контрольный пример. Не закрывайте проблему добавлением случайных инструкций в запрос модели: решение должно оставаться воспроизводимым.
Чек-лист готовности базы#
- определена одна аудитория и границы темы;
- собраны реальные вопросы и цена ошибки;
- каждый ответ опирается на утверждённый источник;
- у каждого материала есть владелец и статус;
- дубли сведены к каноническим страницам;
- архив исключён из рабочих ответов;
- статьи содержат условия и исключения;
- таблицы и сканы доступны как проверенный текст;
- права доступа применяются технически;
- обновления запускаются событиями;
- есть набор вопросов без ответа и без доступа;
- пользователь может сообщить об ошибке.
Готовая база знаний — не разовый архив для модели. Это набор решений, за каждое из которых отвечает человек, а история изменений видна и проверяема. ИИ-ассистент лишь сокращает путь к этим решениям. Если содержание нельзя поддерживать без ассистента, после его подключения проблема станет заметнее, но не исчезнет.
Как поддерживать редакционный ритм#
Разделите обслуживание по частоте. Критическая ошибка исключается из выдачи сразу и разбирается владельцем. Изменение продукта обновляет связанные статьи до или одновременно с запуском изменения. Плановый обзор проходит по дате следующей проверки. Отчёт по поисковым пробелам разбирается регулярно, но не требует срочно писать ответ на каждый единичный запрос.
На встрече владельцев смотрят четыре списка: просроченные проверки, вопросы без источника, частые неудачные запросы и документы с конфликтующими версиями. У каждой строки должно появиться решение и срок. Само число загруженных материалов не является показателем здоровья базы.
Следите за признаками деградации: сотрудники снова спрашивают в чатах вместо поиска, часто открывают архивные файлы, исправляют ответы вручную одинаковым способом, не знают владельца статьи. Эти сигналы важнее общей оценки ассистента, потому что показывают разрыв между официальным знанием и рабочей практикой.
При смене платформы экспортируйте канонические тексты, метаданные, версии и контрольные вопросы. Не делайте интерфейс ассистента единственным местом, где хранится знание. База должна оставаться читаемой, управляемой и проверяемой даже при отключённой модели — тогда технология помогает процессу, а не удерживает его заложником.