Был предложен переход к RAG-подходу, очистка базы знаний и ограничение сценариев первого пилота.
Карта разбора
Ситуация, риски и решение
AI-чатбот был запущен для сотрудников, но в реальной работе давал общие ответы, не ссылался на документы и не вызывал доверия.
- ошибочные ответы без источников
- доступ к знаниям без учёта ролей
- расширение AI-сценария до проверки базы знаний
- источники знаний и их актуальность
- типовые вопросы сотрудников и границы сценария
- права доступа, качество ответов и правила отказа
- сузить первый пилот до одной зоны знаний
- перейти к RAG-подходу со ссылками на источники
- ввести тестовые вопросы и разбор ошибок
- стало понятно, что проблема не в модели, а в данных и сценарии
- появился безопасный план повторного AI-пилота
- снизился риск запуска инструмента, которому пользователи не доверяют
Почему сценарий обезличен
Разбор не описывает публичный проект конкретной компании. Это типовой сценарий AI-внедрения, где проблема была не в “плохой модели”, а в неподготовленных данных, неясном сценарии и отсутствии контроля качества.
Контекст
Компания хотела ускорить ответы сотрудников на типовые вопросы. Быстро появился чатбот, который должен был помогать искать инструкции, регламенты и ответы по внутренним процессам.
На демонстрации решение выглядело убедительно, но в ежедневной работе сотрудники перестали им пользоваться. Ответы были поверхностными, источники не показывались, а спорные ситуации приходилось перепроверять вручную.
Симптомы
- чатбот отвечал общими формулировками и не ссылался на документы;
- сотрудники не понимали, можно ли доверять ответу;
- часть документов была устаревшей или хранилась в разных местах;
- права доступа не учитывали роли сотрудников;
- вопросы пользователей были шире, чем подготовленная база знаний;
- не было критериев качества ответа и процесса разбора ошибок.
Что проверяли
| Зона проверки | Что было важно понять |
|---|---|
| Источники знаний | Какие документы актуальны и кто отвечает за обновление |
| Структура базы | Можно ли быстро найти нужный фрагмент и связанный контекст |
| Типовые вопросы | Какие реальные вопросы задают сотрудники |
| Права доступа | Кому можно показывать разные категории информации |
| Качество ответов | Как проверять точность, полноту и полезность ответа |
| Сценарии отказа | Когда ассистент должен не отвечать, а передавать вопрос человеку |
Ошибка, причина и исправление
| Ошибка чатбота | Возможная причина | Что предложено |
|---|---|---|
| Ответы звучат общо | Нет привязки к базе знаний | Перейти к RAG-подходу с источниками |
| Нет ссылок на документы | Не описан механизм цитирования | Добавить ссылки на фрагменты и документы |
| Пользователи не доверяют ответам | Нет критериев качества | Ввести тестовые вопросы и разбор ошибок |
| Ответы видят не те сотрудники | Не настроены права доступа | Описать роли и ограничения |
| Чатбот пытается отвечать на всё | Сценарий слишком широкий | Сузить первый пилот до одной зоны знаний |
Что стало понятно
Проблема была не в том, что “AI не работает”. Система не имела управляемой базы знаний, понятных источников, ролей доступа и ограниченного сценария. В такой ситуации даже хорошая модель будет давать ответы, которым пользователи не доверяют.
План действий
- Выбрать один ограниченный сценарий для первого пилота.
- Собрать и очистить источники знаний по этому сценарию.
- Назначить владельцев документов и правила обновления.
- Настроить RAG-подход с поиском по релевантным фрагментам.
- Добавить ссылки на источники и правила отказа от ответа.
- Проверять качество на реальных вопросах сотрудников.
- Масштабировать ассистента только после проверки доверия пользователей.
Вывод для похожих проектов
AI не компенсирует хаос в знаниях. Перед внедрением ассистента важно проверить данные, права доступа, сценарии и критерии качества.
Для похожих задач полезны страница AI-чатбот отвечает неправильно, статья что проверить до смены модели, AI-аудит, RAG-ассистент, AI-ready архитектура и статья почему AI не спасёт плохо спроектированный web-проект.
