Генеративный ИИ для руководителя Часть 5 из 7. Как из модели проектируют цифрового ассистента

Генеративный ИИ для руководителя Часть 5 из 7. Как из модели проектируют цифрового ассистента

В предыдущих статьях

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

Теперь вопрос: как из языковой модели сделать цифрового ассистента для работы ведомства?

Ошибка многих ИИ-проектов считать, что достаточно подключить модель и дать сотрудникам чат. Так появляется не ассистент, а неконтролируемый канал работы с информацией.

Модель умеет писать текст. Но ассистент должен решать задачу: искать документы, учитывать права доступа, ссылаться на источники, соблюдать инструкции и передавать результат человеку на проверку.

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

Первый этап проектирование.

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

Для каждого сценария нужно описать: кто пользователь, какие данные нужны, какой результат должен получить, где нужна проверка человеком и какие действия ИИ выполнять не должен. Ассистент для обращений может группировать темы, предлагать проект ответа и указывать, каких данных не хватает. Но он не должен сам отправлять официальный ответ.

Второй этап архитектура решения.

На этом этапе создается не чат, а цифровая система: интерфейс, база знаний, поисковый слой, языковая модель, системные инструкции, права доступа и журнал запросов.

Схема: запрос сотрудника поиск в базе знаний проверка прав доступа ответ модели ссылка на источник проверка человеком

Часто используется подход RAG Retrieval-Augmented Generation. Система сначала ищет нужные фрагменты в проверенной базе знаний, а потом модель формирует ответ. Это нужно, чтобы модель работала с документами организации, а не вспоминала ответ из общих знаний.

Третий элемент инструкции для модели.

Это правила поведения ассистента: отвечать только на основе источников, не придумывать нормативные ссылки, отделять факты от предположений, предупреждать, если данных недостаточно, не раскрывать информацию без прав доступа и передавать спорные случаи человеку. Такая настройка называется prompt engineering (оперативное проектирование) проектирование инструкций и шаблонов запросов.

Четвертый элемент интеграции.

Ассистент должен работать рядом с системами организации: СЭД, базами знаний, реестрами, внутренними сервисами. Для этого используются API-интеграции каналы обмена данными между системами.

Пятый элемент разграничение прав.

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

Шестой элемент контроль качества.

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

Проверяется не только грамотность текста, но и поведение системы: дает ли она источники, не придумывает ли факты, соблюдает ли права доступа и передает ли спорные случаи человеку.

Главный вывод: цифровой ассистент это не языковая модель с интерфейсом, а спроектированная система, встроенная в рабочий процесс.

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

В следующей статье разберем внедрение и сопровождение: самообновляемая база знаний, ИИ-агент и почему систему нельзя запустить и забыть.