Как научить 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 мес
Решение: → эскалация на руководителя
Причина: «Новый контрагент, большая сумма, нужна проверка СБ»
 [1]

После 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-компании: СБ дополнительно проверяет санкционные списки"
  - "Строительные компании: нужна проверка лицензий"
 [1]

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

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

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

---

Метод 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: Аудит (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% — в головах. На одних регламентах агент будет формально правильным, но практически бесполезным.

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

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

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

---

Выводы

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

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

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

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

---

---

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

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

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

3. Кто отвеча��т за ошибки AI-агента ^[6]

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

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

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

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