ИИ-поиск по регламентам: пункты, редакции, ссылки

ИИ-поиск по регламентам — это система, которая отвечает на вопросы сотрудников по корпоративным документам и возвращает ссылку на конкретный пункт действующей редакции. Если ответа в документах нет, агент прямо об этом говорит, а не сочиняет.

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

Когда нужен ИИ-поиск по регламентам, а не «спросить у ChatGPT»

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

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

Разница становится критичной в трёх ситуациях:

• Документы меняются. Публичная модель не знает, что редакция от 2023 года отменена. База знаний хранит историю редакций: действующая версия используется для ответа, отменённая помечена и сохранена в архиве.
• Нужна точность до пункта. «Примерно так» не подходит, когда речь о стандартах качества, технике безопасности или финансовых процедурах. Ссылка на пункт — единственный способ быстро проверить ответ.
• Данные не должны покидать контур. Индекс базы знаний строится локальной моделью эмбеддингов на вашем сервере. Тексты документов для поиска наружу не уходят.

Как устроен поиск: пункты, редакции, отказ от ответа

Система работает в три шага.

Разбор документов. Каждый загруженный документ разбивается на пункты. Для каждого пункта фиксируются: номер, статус (действующий или отменённый), дата ввода, отменяющий документ. Это позволяет отличать актуальную редакцию от архивной.

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

Формирование ответа. Модель собирает ответ только из найденных фрагментов. Если релевантных пунктов нет, агент отвечает: «В загруженных документах ответа не нашлось». Это не баг, а принцип работы — система не додумывает.

В ответе всегда присутствуют:

• ссылка на документ;
• номер пункта действующей редакции;
• пометка, если пункт относится к отменённой редакции (такой пункт не используется для ответа).

Откуда берутся документы

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

• 1С:Документооборот — чтение через OData/API: карточки, файлы, статусы, связи «отменяет / отменён».
• Файловые хранилища — сетевые папки и диски с docx, pdf, xlsx. Система разбирает структуру, находит версии и дубли, размечает документы по разделам.
• Почта — приказы и письма по IMAP из согласованных ящиков. Только домен компании, только разрешённые папки.
• Внутренние системы — CRM, внутренние API, базы данных. Если безопасного интерфейса нет, договариваемся о файловом обмене или промежуточном модуле.

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

Пример: бот по регламентам для отдела качества

Это пример-сценарий, а не опубликованный кейс.

Производственная компания. Отдел качества работает по внутренним стандартам и регламентам. Документы хранятся в 1С:Документооборот, у каждого — история редакций. Сотрудники тратят время на поиск нужного пункта в нужной редакции.

Что строится:

1. Система подключается к 1С:Документооборот через OData и читает карточки, файлы и статусы программно.
2. Документы разбираются по пунктам. Стандарты с архивными редакциями разносятся по статусам: действующий, отменённый, с указанием отменяющего документа.
3. Бот отдела запускается в Telegram-группе. Сотрудник спрашивает: «Какой допустимый уровень брака для линии №3?» — и получает ответ со ссылкой на пункт действующей редакции стандарта.
4. Если ответа в документах нет, бот говорит об этом, а не выдумывает.

Публикацию ответа в группу отдела подтверждает человек — пока сотрудники привыкают к системе.

Кто контролирует ответы и снижает риски

ИИ-поиск по корпоративным документам не работает в режиме «запустили и забыли». Контроль выстроен на нескольких уровнях.

Стендовая группа. Перед выпуском в отдел агент отвечает в закрытой группе руководителю и ИТ-специалистам. Ответы проверяются вручную: совпадает ли ссылка, верный ли пункт, не всплыла ли отменённая редакция.

Контрольные вопросы. Руководитель отдела составляет список реальных вопросов с известными ответами. Каждый ответ агента сверяется с документом и пунктом. Это позволяет отловить ошибки до того, как они дойдут до сотрудников.

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

Журнал вопросов без ответа. Система фиксирует, на какие вопросы не нашлось ответа в документах. Сводка приходит руководителю — это сигнал, какие инструкции стоит дополнить.

Риски, которые закрывает такой подход:

• Сотрудник получит устаревшую редакцию → история редакций и статусы документов исключают это.
• Модель выдумает ответ → система отвечает только по найденным фрагментам, при их отсутствии отказывает.
• Данные утекут наружу → индекс строится локально, тексты документов наружу не уходят.

Этапы внедрения

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

1. Описание задачи. Вы рассказываете, какие документы используются, кто ищет, какой результат нужен. Техническое задание не требуется.
2. Оценка. Проверяем, подходит ли задача для ИИ, доступны ли интерфейсы источников. Называем состав работ и диапазон часов. Если ИИ здесь не нужен — говорим прямо.
3. Договор и доступы. Фиксируем предмет, ставки, порядок приёмки. Площадку и классы данных согласуем с вашей ИТ-службой. Актуальные ставки — в открытом прайсе.
4. Сборка. Архитектура, индексация документов, настройка поиска, подключение к источникам. Промежуточные версии показываем на ограниченных данных.
5. Проверка. Прогоняем типовые, ошибочные и рискованные сценарии. Настраиваем журналы, права и передачу спорных случаев человеку.
6. Запуск и сопровождение. Инструкции, обучение сотрудников, регламент сопровождения. Дальше — доработки, мониторинг, новые отделы.

До начала работ заказчик создаёт рабочую группу в Telegram и назначает кураторов. Подробнее о каждом шаге — на странице как мы работаем.

Как проверить результат

Качество поиска по регламентам проверяется не презентацией, а конкретными материалами.

Журнал работ. Каждая запись: дата, вид работы, часы, формулировка результата, артефакт. Журнал открыт заказчику в течение месяца. Из него собираются отчёт и акт.

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

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

Стендовая группа. Ответы в закрытой группе до и после выпуска в отдел. Руководитель видит, как система отвечает, до того как это увидят сотрудники.

С чего начать

Начните с одного процесса. Опишите, какие документы используются, где они хранятся, кто ищет и какой результат нужен. Техническое задание не требуется — достаточно описания на языке работы отдела.

Мы проверим, подходит ли задача для ИИ-поиска, какие источники доступны и сколько часов займёт первый шаг. Если задача не подходит — скажем об этом и объясним почему.

Описать задачу · Открыть прайс · Примеры реализованных проектов