← Назад к блогу
Серия: Почему AI-проекты проваливаются · Статья 5

Как научить AI-агента работать «как у нас принято»: передача неявных знаний

Новый сотрудник приходит в компанию. Первый месяц он смотрит, как работают другие. Задаёт вопросы. Впитывает неписаные правила.

«К Петрову лучше не ходить в пятницу после обеда». «Если клиент из Газпрома — сначала согласуй с Мариной». «Этот шаблон договора устарел, используй новый из папки».

Через месяц-два новичок начинает работать «как принято». Без инструкций. Просто потому что видел, как это делают другие.

AI-агент так не умеет.

Всё, что сотрудники «знают на автомате», для агента не существует. Пока не будет явно описано и загружено в систему.

Проблема tacit knowledge

В теории менеджмента есть понятие tacit knowledge — неявное знание. Это то, что люди знают, но не могут легко объяснить или формализовать.

Как ездить на велосипеде. Как определить, что клиент готов к сделке. Как понять, что этот договор «странный».

В компаниях tacit knowledge — это 70-80% реального know-how. Регламенты и инструкции — только верхушка айсберга.

И это главная причина, почему AI-агенты «делают ерунду». Они работают по верхушке айсберга, не зная, что под водой.

Три метода передачи знаний

Метод 1: Shadowing (наблюдение)

Агент «наблюдает» за работой человека. Собирает данные о реальных решениях. Учится на примерах.

Как это работает:

  1. Человек работает как обычно
  2. Система логирует все действия: что пришло на вход, какое решение принято, почему
  3. Накапливается база примеров
  4. Агент обучается на этих примерах (few-shot learning, fine-tuning или RAG)

Пример для согласования договоров:

Вход: Договор аренды, ООО «Ромашка», сумма 450к, срок 1 год
Решение: Отправить юристу Ивану Петровичу
Причина (из комментария): «Аренда — это к Петровичу, он специализируется»

Вход: Договор поставки, ИП Сидоров, сумма 80к, срок 3 мес
Решение: Согласовать без юриста
Причина: «Типовой шаблон, сумма маленькая, контрагент из белого списка»

Вход: Договор услуг, ООО «СтройМонтаж», сумма 2 млн, срок 6 мес
Решение: Эскалация на руководителя
Причина: «Новый контрагент, большая сумма, нужна проверка СБ»

После 100-200 таких примеров агент начинает понимать паттерны.

Плюсы: Не нужно формализовывать знания заранее. Учимся на реальных данных.

Минусы: Нужно время на сбор примеров (1-2 месяца). Качество зависит от качества логирования.

Метод 2: Плейбуки (пошаговые сценарии)

Эксперты описывают типичные ситуации и правильные действия в каждой.

Структура плейбука:

Ситуация: Договор с новым контрагентом на сумму > 500к

Признаки:
— Контрагента нет в базе
— Сумма превышает 500 000 ₽

Действия:
1. Запросить проверку СБ (форма СБ-01)
2. Дождаться результата (SLA: 2 рабочих дня)
3. Если СБ одобрил → стандартный маршрут
4. Если СБ не одобрил → эскалация на руководителя

Ответственный за решение: Руководитель отдела

Примечания:
— Для IT-компаний СБ проверяет дополнительно санкционные списки
— Для строительных компаний нужна проверка лицензий

Сколько плейбуков нужно:

Для типичного процесса согласования договоров: 15-30 плейбуков. Для сложного процесса (закупки, HR): 50-100 плейбуков.

Плюсы: Чёткая логика. Легко тестировать и отлаживать.

Минусы: Трудоёмко. Эксперты не любят писать документацию. Плейбуки устаревают.

Метод 3: RAG (Retrieval-Augmented Generation)

Агент ищет релевантную информацию в базе знаний и использует её для принятия решений.

Что входит в базу знаний:

  1. Регламенты и инструкции
  2. Плейбуки (см. выше)
  3. Примеры решений (из shadowing)
  4. FAQ и ответы на частые вопросы
  5. История инцидентов и их разборы

Как работает:

Запрос: Нужно согласовать договор аренды с ООО «Новая компания» на 800к

Поиск в базе знаний:
— Найден плейбук «Договор с новым контрагентом > 500к»
— Найден пример похожего договора (аренда, 750к, новый контрагент)
— Найдено правило «Аренда → юрист Иван Петрович»

Решение агента:
1. Запросить проверку СБ
2. После одобрения СБ → отправить юристу Ивану Петровичу

Плюсы: Гибкость. Легко обновлять базу знаний. Агент «объясняет» свои решения ссылками на источники.

Минусы: Качество зависит от качества базы знаний. Нужна регулярная актуализация.

Процесс создания базы знаний

Вот как мы это делаем на проектах:

Этап 1: Аудит (1-2 недели)

Интервью с ключевыми сотрудниками. Записываем на диктофон, транскрибируем.

Вопросы:

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

Обычно 5-7 интервью по 1-1.5 часа.

Этап 2: Анализ истории (1 неделя)

Смотрим логи CRM, переписку, историю решений.

Ищем паттерны: почему одни договоры согласовывались быстро, а другие — неделями?

Этап 3: Формализация (2-4 недели)

Превращаем собранное в плейбуки и правила.

Каждый плейбук валидируем с экспертом: «Правильно ли я понял?»

Этап 4: Загрузка и тестирование (1-2 недели)

Загружаем в систему. Тестируем на исторических данных.

Сравниваем решения агента с реальными решениями людей. Расхождения — повод доработать базу знаний.

Этап 5: Shadow mode (2-4 недели)

Агент работает параллельно с человеком. Предлагает решения, но не исполняет.

Человек видит предложение агента и своё решение. Расхождения логируются.

Этап 6: Продакшен + итерации

Запуск в прод с мониторингом. Регулярный разбор ошибок. Обновление базы знаний.

Сколько это стоит

Честный ответ: дорого.

Аудит и интервью: 100-150к (время экспертов + аналитик)

Формализация: 150-300к (в зависимости от сложности процесса)

Техническая реализация RAG: 100-200к

Shadow mode и доработки: 100-150к

Итого: 450-800к на один процесс.

Плюс поддержка: 30-50к/месяц на актуализацию базы знаний.

Это не считая самого агента и интеграций.

Да, это дорого. Но без этого агент будет «делать ерунду».

Типичные ошибки

1. «Скормим агенту регламенты»

Регламенты — это 20% знаний. Остальные 80% — в головах. Агент на одних регламентах будет работать формально правильно, но практически бесполезно.

2. «Эксперты сами напишут»

Не напишут. У них нет времени, навыков и мотивации писать документацию. Нужен выделенный аналитик, который будет вытаскивать знания из экспертов.

3. «Один раз настроим и забудем»

Знания устаревают. Люди меняются. Процессы эволюционируют. База знаний требует регулярного обновления.

4. «Чем больше данных, тем лучше»

Не лучше. Много мусора в базе знаний → агент путается. Качество важнее количества.

Выводы

Передача неявных знаний — это самая трудоёмкая часть внедрения AI-агента. И самая важная.

Три метода: shadowing, плейбуки, RAG. Обычно используем комбинацию.

Бюджет: 450-800к на один процесс. Сроки: 2-3 месяца.

Если интегратор обещает «настроить за неделю по вашим регламентам» — он не понимает задачу.

Подписывайтесь на канал:

Telegram @futex_ai