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