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

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

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

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

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: Плейбуки

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

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

# playbook: new_contractor_large_amount.yaml situation: "Договор с новым контрагентом на сумму > 500к" triggers: - contractor_not_in_database: true - amount_rub: ">500000" actions: 1_security_check: action: "Запросить проверку СБ (форма СБ-01)" sla: "2 рабочих дня" 2_on_approved: action: "Стандартный маршрут согласования" 3_on_rejected: action: "Эскалация на руководителя отдела" responsible: "Руководитель отдела" notes: - "IT-компании: СБ дополнительно проверяет санкционные списки" - "Строительные компании: нужна проверка лицензий"

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

Плюсы. Чёткая логика. Легко тестировать и отлаживать. Прозрачно для аудита.

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

---

Метод 3: RAG

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

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

1. Регламенты и инструкции

2. Плейбуки

3. Примеры решений из shadowing

4. FAQ и ответы на частые вопросы

5. История инцидентов и их разборы

Как работает на практике:

→ Запрос: Согласовать договор аренды с ООО «Новая компания» на 800к → Поиск по базе знаний: — Плейбук «Новый контрагент > 500к» (релевантность: 0.94) — Пример: аренда, 750к, новый контрагент (релевантность: 0.91) — Правило: аренда → юрист Иван Петрович (релевантность: 0.88) → Решение агента: 1. Запросить проверку СБ (по плейбуку) 2. После одобрения → отправить Ивану Петровичу (по правилу маршрутизации) → Источники решения: [плейбук #12, пример #47, правило #3]

Последний пункт — важный. Агент «объясняет» свои решения ссылками на конкретные документы. Это критично для аудита и доверия.

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

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

---

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

Этап 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к/месяц на актуализацию.

Да, это дорого. Но без этого агент будет «делать ерунду». Выбор простой: вложиться в знания или получить бесполезного бота.

---

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

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

«Эксперты сами напишут». Не напишут. Нет времени, навыков и мотивации. Нужен выделенный аналитик, который вытаскивает знания из экспертов.

«Один раз настроим и забудем». Знания устаревают. Люди меняются. Процессы эволюционируют. База требует обновления — как минимум ежемесячно.

«Чем больше данных, тем лучше». Не лучше. Много мусора в базе → агент путается. Качество важнее количества.

---

Выводы

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

Три метода: shadowing, плейбуки, RAG. На практике — комбинация всех трёх.

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

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

---

---

Серия «Почему AI-проекты проваливаются»:

1. 6 проблем, о которых молчат интеграторы

2. Инструкция для человека vs инструкция для AI

3. Кто отвечает за ошибки AI-агента

4. Что делать, когда AI-агент «упал»

5. Как передать агенту неявные знания ← вы здесь

6. Пошаговый план внедрения

Анатолий Лапков. Telegram: @futex_ai

Источник