Журнал — единственный способ доказать, что именно агент сказал клиенту и на каком основании. Всё остальное в проекте можно восстановить: инструкцию посмотреть в репозитории, базу знаний открыть, права проверить в настройках. Ответ, который ушёл клиенту три недели назад, не восстанавливается ничем: модель недетерминирована и на тот же вопрос завтра ответит иначе.
Отсюда практический вывод, который стоит проверить до подписания договора: журнал — это не «логи для отладки», которые подрядчик держит у себя и чистит раз в месяц. Это ваш артефакт, он живёт в вашем контуре, и его состав фиксируется в техническом задании наравне с функциями агента.
Ниже — состав записи из девяти полей, поле, без которого разбор невозможен, цена журнала и цена его отсутствия, сроки хранения с оглядкой на 152-ФЗ и три отчёта, которые превращают архив в инструмент. Расчёты — на модельном потоке 3 000 обращений в месяц, по состоянию на сентябрь 2026 года.
Девять полей одной записи
Запись создаётся на каждое обращение, а не на каждый инцидент: выбирать, что писать, в момент события невозможно — вы не знаете, какое обращение через месяц станет предметом разбора.
| Поле | Что в нём | Без него нельзя |
|---|---|---|
| 1. Время и длительность | Метка начала и сколько заняла обработка | Заметить, что ответы стали медленнее после обновления |
| 2. Идентификатор обращения и диалога | Сквозной номер, общий с CRM | Связать пять реплик в одну цепочку и найти её по карточке клиента |
| 3. Канал и идентификатор клиента | Чат на сайте, мессенджер, почта, телефон | Понять, что ломается только в одном канале |
| 4. Вопрос дословно | Исходный текст без нормализации и исправлений | Воспроизвести случай на стенде |
| 5. Найденные фрагменты базы | Идентификаторы документов, сами куски текста, оценка близости | Отличить поломку поиска от поломки генерации |
| 6. Версия модели и версия инструкции | Что именно действовало в этот момент | Понять, что сломало обновление, и откатить его |
| 7. Сгенерированный ответ | Текст, который реально ушёл клиенту | Ответить на претензию по существу |
| 8. Вызванные методы систем | Какой метод, с какими параметрами, что вернул | Увидеть, чьи данные агент читал и не вышел ли он за фильтр |
| 9. Итог и подтверждение | Отправлено, переведено оператору, отклонено; кто нажал кнопку | Разобраться, кто отвечает за конкретное действие |
Восьмое поле стоит отдельного внимания, если у агента есть доступ к данным. Запись «вызван метод «заказы клиента» с параметром «идентификатор 4812», вернул 3 записи» — это то, чем проверяется, что агент читал данные конкретного клиента, а не соседнего. Механика такой защиты разобрана в материале про безопасность агента с доступом к базе; журнал здесь — не дополнение к ней, а способ доказать, что она работает.
Поле, без которого разбор инцидента невозможен
Снаружи любая ошибка агента выглядит одинаково: клиент получил неверный ответ. Внутри это две совершенно разные поломки, и чинятся они в разных местах.
- 1Поиск нашёл не тот документ
В базе есть правильный ответ, но выдача принесла соседний регламент, устаревшую редакцию прайса или похожий по словам, но другой по смыслу кусок. Чинится это базой знаний: разбиением документов на фрагменты, заголовками, удалением дублей и устаревших версий. Работа редактора, недели, а не часы. Методика оценки — в материале про качество поиска по базе знаний.
- 2Поиск нашёл правильный документ, а генерация исказила
Нужный фрагмент был перед моделью, но в ответе появилось условие, которого в нём нет, или пропала важная оговорка. Чинится инструкцией, форматом ответа и требованием цитировать основание. Работа инженера, часы, а не недели.
- 3Ответа в базе нет вовсе
Ближайший найденный фрагмент имеет низкую оценку близости — в базе просто нет документа на эту тему. Правильное поведение здесь не ответ, а отказ с передачей человеку; как это устроено, разобрано в материале про то, что делает агент, когда не знает ответа. Чинится это не техникой, а написанием недостающего документа.
Различить три случая можно только одним способом: посмотреть, что именно нашёл поиск и с какой оценкой. Без пятого поля разбор превращается в спор между заказчиком и подрядчиком, где обе стороны правы и обе не могут ничего показать. Цена этой неопределённости не в часах разбора, а в том, что чинят не то: месяц работы редактора над базой, когда сломана была инструкция, — обычный исход такого спора.
Сколько стоит журнал и во что обходится его отсутствие
На потоке 3 000 обращений в месяц разборов набирается около двенадцати — примерно 0,4 % обращений. Это не инциденты в тяжёлом смысле: чаще всего это вопрос «почему агент так ответил вот этому клиенту», заданный руководителем поддержки. С журналом на такой вопрос отвечает редактор базы за пятнадцать минут. Без журнала он уходит подрядчику, тот пытается воспроизвести случай на стенде, и примерно в трети случаев ответа не находится вовсе.
Разовые 96 000 ₽ раскладываются на четыре строки: запись девяти полей и хранилище — 15 часов инженера, поиск по журналу и выгрузка выборки за период — 8 часов, три регулярных отчёта — 6 часов, обезличивание и удаление по сроку — 3 часа. Итого 32 часа по 3 000 ₽. Ежемесячные 4 500 ₽ — это 1 500 ₽ хранения с резервными копиями, два часа редактора на разбор отчётов и 1 200 ₽ на плановое обезличивание.
Объём хранения обычно переоценивают. Одна запись вместе с найденными фрагментами занимает около 25 КБ, три тысячи записей — 75 МБ в месяц и порядка 900 МБ в год. Дорого стоит не место, а записи телефонных разговоров, если агент работает на линии: там объём на два порядка больше и режим хранения отдельный.
Схема слева направо. Слева вертикальный список из девяти пронумерованных полей записи: время, идентификатор обращения, канал и клиент, вопрос дословно, найденные фрагменты, версия модели и инструкции, ответ, вызванные методы, итог и подтверждение. Пятое поле выделено рамкой и жирной линией. От него вправо расходятся три стрелки к трём блокам-исходам: «поиск нашёл не тот документ — чинит редактор базы, недели», «фрагмент верный, ответ искажён — чинит инженер инструкцией, часы», «оценка близости низкая, ответа в базе нет — писать документ». Ниже серым перечёркнутый вариант «без пятого поля» с подписью «три случая неразличимы, разбор упирается в спор». Чертёжная штриховка, подписи по-русски.
Где хранить, сколько и что делать с персональными данными
Диалог с клиентом почти всегда содержит персональные данные: имя, телефон, адрес доставки, номер заказа. Значит, журнал — это база с персональными данными со всеми обычными следствиями: обработка на серверах в России, основание, срок хранения, ограниченный доступ. Подробный разбор того, что именно считается персональными данными внутри диалога, — в материале про персональные данные в диалогах с ИИ.
- 1Полная запись — 12 месяцев. Этого хватает и на претензионные сроки, и на сезонный цикл: летний вопрос сравнивается с прошлогодним летним, а не с зимним.
- 2Дальше — обезличивание, а не удаление. Из записи убираются имя, телефон, адрес и номер заказа, остаются тема, найденные фрагменты, версия модели, ответ и исход. Обезличенный журнал живёт дальше и служит материалом для регрессионных прогонов при смене версии модели.
- 3Записи телефонных разговоров — отдельный режим. Предупреждение о записи в начале разговора, свой срок хранения, свой круг доступа. Порядок разобран в материале про запись разговоров и хранение по закону.
- 4Доступ разделён на два уровня. Чтение обезличенного журнала — у редактора базы и контролёра качества; полный доступ к записям с персональными данными — у двух человек, и каждая выгрузка сама попадает в журнал.
Тридцать дней — стандартное значение почти во всех системах хранения логов, и его почти никогда не меняют. Проблема в том, что претензия клиента, запрос от контрагента и спор с подрядчиком приходят позже: типичный срок — от полутора до четырёх месяцев. К моменту, когда запись понадобилась, её уже нет, и разговор снова превращается в слово против слова. Проверить это в своём контуре можно за минуту: попросите поднять диалог трёхмесячной давности по номеру обращения.
Горизонтальная лента времени от нулевой точки вправо. Первый отрезок «0–12 месяцев» подписан «полная запись: девять полей, персональные данные, хранение в России», под ним пометка «доступ у двух человек, каждая выгрузка в журнале». Вертикальная линия на отметке 12 месяцев подписана «обезличивание». Второй отрезок, светлее, уходит вправо без конца и подписан «обезличенная запись: тема, найденные фрагменты, версия модели, ответ, исход», под ним пометка «материал для регрессионных прогонов». Слева от ленты отдельной короткой полоской показан вариант «ротация 30 дней» с подписью «настройка по умолчанию: запись стирается раньше, чем приходит претензия». Чертёжная штриховка, подписи по-русски.
Три отчёта и приёмка: как журнал становится инструментом
Журнал, в который никто не смотрит, — это архив, а не инструмент. Он превращается в инструмент тремя отчётами, каждый из которых собирается автоматически и читается за двадцать минут.
- Доля отказов по темам. Где агент чаще всего говорит «не знаю» и переводит на человека. Это карта пустых мест в базе знаний, отсортированная по частоте — то есть готовая очередь на написание документов.
- Темы с наибольшей долей ошибок. Строится по результатам выборочного контроля: какие темы чаще всего помечались контролёром как неверный ответ. Обычно это места, где в базе лежат два противоречащих документа; механика самого контроля — в материале про выборочный контроль диалогов.
- Вопросы без ответа в базе. Обращения, где у лучшего найденного фрагмента низкая оценка близости. Отличается от первого отчёта тем, что сюда попадают и случаи, когда агент всё же ответил — а значит, ответил из головы.
Тот же журнал закрывает два вопроса в отношениях с подрядчиком. Первый — приёмка: доля обращений, закрытых без человека, замеряется из журнала за календарный месяц, а не берётся со слов исполнителя; порядок приёмки разобран в материале про то, как принять ИИ-систему у подрядчика. Второй — обновления: при смене версии модели 200–300 сохранённых вопросов прогоняются заново и ответы сравниваются с прежними, а шестое поле показывает, какая версия инструкции действовала в момент каждого ответа. Что именно ломается при обновлении, разобрано отдельно — обновление версии модели.
Сравнение в две колонки. Левая «Журнал из девяти полей»: пять строк — «случай найден по номеру обращения», «видно, какие фрагменты нашёл поиск и с какой оценкой», «видно версию модели и инструкции», «разбор 15 минут, 225 ₽», «вывод: чинить базу или инструкцию». Правая «Логи для отладки у подрядчика»: пять строк — «случай ищут по времени и тексту», «фрагменты не сохранены», «версия инструкции неизвестна», «разбор 2 часа, 6 000 ₽», «в трети случаев вывода нет». Внизу общая полоса «12 разборов в месяц: 2 700 ₽ против 72 000 ₽». Чертёжная штриховка, подписи по-русски.
Когда девять полей избыточны
Полный состав записи нужен там, где ответ уходит наружу и где у ошибки есть цена. В трёх случаях он избыточен, и заводить его — значит платить за управление несуществующим риском.
- Внутренний помощник без выхода наружу. Бот, который ищет документ в архиве и подсказывает сотруднику, не порождает обещаний клиенту. Ему хватает пяти полей: время, пользователь, вопрос, найденные фрагменты, ответ. Это 6–8 часов работы вместо 32.
- Пилот на четыре недели. Все записи пишутся в один файл без интерфейса и отчётов, разбор идёт глазами. Отдельный контур журнала на этом этапе — преждевременное вложение: половина пилотов заканчивается решением не продолжать.
- Поток меньше 300 обращений в месяц. Три отчёта на таком объёме строятся просмотром списка за полчаса, автоматизировать их незачем. Писать девять полей при этом всё равно стоит — дорого не хранение, а дописывание полей задним числом, когда запись уже понадобилась.
И обратное правило, которое важнее всех трёх исключений. Единственное, что нельзя решить потом, — это состав записи. Отчёты, интерфейс поиска и обезличивание добавляются в любой момент; поля, которые не писались полгода, не появятся задним числом ни за какие деньги. Поэтому в техническом задании состав записи фиксируется до старта разработки, а не обсуждается на приёмке.
Модель не помнит, что ответила вчера. Если этого не помнит и журнал — не помнит никто.
