Генеративный ИИ для руководителя Часть 5 из 7. Как из модели проектируют цифрового ассистента
В предыдущих статьях
мы разобрали: ИИ начинается с данных, модель работает с токенами, обучение строится на прогнозе следующего фрагмента текста, а качество результата зависит от подготовки данных.
Теперь вопрос: как из языковой модели сделать цифрового ассистента для работы ведомства?
Ошибка многих ИИ-проектов — считать, что достаточно подключить модель и дать сотрудникам чат. Так появляется не ассистент, а неконтролируемый канал работы с информацией.
Модель умеет писать текст. Но ассистент должен решать задачу: искать документы, учитывать права доступа, ссылаться на источники, соблюдать инструкции и передавать результат человеку на проверку.
Сама по себе модель — еще не продукт. Ассистент появляется, когда она встроена в систему: с ролями пользователей, сценариями, ограничениями, источниками данных, журналированием и ответственностью человека.
Первый этап — проектирование.
Начинать нужно не с вопроса “какую нейросеть подключить?”, а с вопроса “какую задачу мы решаем?”. Например: сократить время подготовки справок, ускорить обработку обращений, помочь сотрудникам ориентироваться в регламентах.
Для каждого сценария нужно описать: кто пользователь, какие данные нужны, какой результат должен получить, где нужна проверка человеком и какие действия ИИ выполнять не должен. Ассистент для обращений может группировать темы, предлагать проект ответа и указывать, каких данных не хватает. Но он не должен сам отправлять официальный ответ.
Второй этап — архитектура решения.
На этом этапе создается не “чат”, а цифровая система: интерфейс, база знаний, поисковый слой, языковая модель, системные инструкции, права доступа и журнал запросов.
Схема: запрос сотрудника поиск в базе знаний проверка прав доступа ответ модели ссылка на источник проверка человеком
Часто используется подход RAG — Retrieval-Augmented Generation. Система сначала ищет нужные фрагменты в проверенной базе знаний, а потом модель формирует ответ. Это нужно, чтобы модель работала с документами организации, а не “вспоминала” ответ из общих знаний.
Третий элемент — инструкции для модели.
Это правила поведения ассистента: отвечать только на основе источников, не придумывать нормативные ссылки, отделять факты от предположений, предупреждать, если данных недостаточно, не раскрывать информацию без прав доступа и передавать спорные случаи человеку. Такая настройка называется prompt engineering (оперативное проектирование) — проектирование инструкций и шаблонов запросов.
Четвертый элемент — интеграции.
Ассистент должен работать рядом с системами организации: СЭД, базами знаний, реестрами, внутренними сервисами. Для этого используются API-интеграции — каналы обмена данными между системами.
Пятый элемент — разграничение прав.
Один сотрудник может видеть справочные материалы, другой — служебные документы, третий — данные по обращениям. Поэтому нужны RBAC или ACL — механизмы доступа по ролям. Без этого ассистент может показать лишнее.
Шестой элемент — контроль качества.
Для оценки ассистента используют evals — наборы контрольных вопросов и ожидаемых ответов. Для пилота можно подготовить 100–200 запросов: найти регламент, подготовить проект ответа, ответить при недостатке данных, проверить ситуацию без доступа, обработать конфликтующие источники.
Проверяется не только грамотность текста, но и поведение системы: дает ли она источники, не придумывает ли факты, соблюдает ли права доступа и передает ли спорные случаи человеку.
Главный вывод: цифровой ассистент — это не языковая модель с интерфейсом, а спроектированная система, встроенная в рабочий процесс.
Эффект дает не сама нейросеть, а контур вокруг нее: задача, данные, роли, инструкции, интеграции, права доступа и контроль качества.
В следующей статье разберем внедрение и сопровождение: самообновляемая база знаний, ИИ-агент и почему систему нельзя “запустить и забыть”.
