Старший продакт-менеджер Андрей Безруков из команды Авито Рекламы опубликовал на Хабре кейс: Авито отзывы и комментарии пользователей рекламного кабинета размечает не продуктовая команда вручную, а конвейер из ИИ-агентов и Python-помощника. Материал помечен как «простой», время чтения — около одиннадцати минут.
В кейсе разобрано шесть вещей: зачем комментарий разбивать на отдельные смыслы, почему одна модель с большим списком правил не справилась, из каких роляей собрана система, какие ошибки авторы отловили на тестовых запусках, как измеряли качество и что система не гарантирует даже в текущем виде. В конце слово берут продуктовый аналитик и UX-исследователь команды.
Ниже — содержание материала. Своя оценка собрана в последнем разделе и за пределы источника выходит только там.
Почему Авито отзывы перестали разбирать вручную
Кабинет Авито Рекламы запустили в июне 2025 года. По словам автора, тогда команда читала комментарии пользователей от и до: это помогало расставлять приоритеты в бэклоге и быстрее править сервис.
Через год пользователей стало «на порядки больше», а сама продуктовая команда выросла и разделила зоны ответственности. Читать и распределять весь поток руками стало невозможно — отсюда и задача автоматизации.
Требования к системе авторы перечисляют конкретно: находить дубли (сообщения одного пользователя по одной теме), сохранять несколько смыслов внутри одного комментария, оценивать веса тем, распределять фидбэк между командами и готовить сводки. Под весами понимается сравнение вида «одна и та же проблема у нескольких пользователей, которые запускают сотни кампаний, или у сотни пользователей с одной-двумя кампаниями».
Два ограничения заданы отдельно. Разметка обязана строго следовать правилам, которые формулируют UX-исследователи, а исходный текст пользователя должен сохраняться рядом с метками — чтобы от агрегированной картины можно было вернуться к конкретным словам.
Почему одного агента оказалось недостаточно
Первая попытка была самой простой: одному агенту передали комментарии, большой список правил и попросили вернуть готовые метки. На коротких примерах это работало, на длинной очереди качество падало. Причина, по версии авторов, в том, что модели приходилось одновременно понимать текст, помнить сотни близких правил, проверять собственный выбор, соблюдать формат ответа и работать с данными.
Из экспериментов команда вывела три утверждения, на которых держится вся дальнейшая архитектура:
- Самопроверка не бывает независимой. После выбора категории модель помнит, как приняла решение, и при повторной проверке склонна его подтверждать. Отдельный проверяющий получает результат в чистом контексте и может заметить несоответствие тексту или правилу.
- Большой контекст размывает внимание. Сотни комментариев, близкие категории и длинные инструкции конкурируют между собой; растёт риск склеить разные темы, пропустить редкое правило или принять завершение одного этапа за конец всей задачи.
- Агенты упрощают решения после долгой работы. Авторы связывают это с перегруженным контекстом, конкурирующими задачами и отсутствием явного критерия завершения.
Отдельное решение, на которое стоит обратить внимание: единицей анализа в системе стал не комментарий, а смысловая тема внутри него. Пример из материала — фраза «Объявление отклонили без понятного объяснения, поддержка не отвечает, а по креативам не хватает статистики». В ней три темы: неясная причина отклонения, медленный ответ поддержки, нехватка статистики по креативам. Сначала система находит все самостоятельные темы, потом классифицирует каждую и только затем собирает результаты обратно в разметку комментария.
Терминология, которую вводят авторы и без которой дальше не разобраться: консёрн — название конкретной боли, вопроса или продуктового запроса; тег — более широкая продуктовая область (модерация, финансы, таргетинг, поддержка); таксономия — справочник консёрнов, тегов и условий их применения; субагент — отдельный исполнитель с одной ролью и чистым контекстом; бакет — группа до 50 комментариев, проходящая конвейер как независимая часть запуска; манифест — служебный список бакетов с их статусами.
Конвейер: кто за что отвечает
Смысловые решения авторы оставили агентам, а повторяемые и проверяемые операции отдали Python. Сравнение, которое они используют, — микросервисная архитектура, перенесённая на ИИ-агентов: каждая роль получает только те данные, которые нужны именно ей.
Последовательность ролей в материале описана так:
- Python-помощник формирует очередь: забирает неразмеченные комментарии из единого источника, фиксирует состав выборки и текущую версию правил, делит очередь на бакеты, создаёт манифест. Уже размеченные строки в процесс не подмешиваются.
- Сегментатор читает полный комментарий, выделяет все самостоятельные мысли и сохраняет короткий фрагмент текста как подтверждение каждой темы. Таксономию ему на этом этапе не показывают, чтобы существующие категории не ограничивали поиск смыслов.
- Критик полноты сравнивает полученные темы с исходным комментарием: добавляет пропущенные, разделяет склеенные, убирает дубли и неподтверждённые выводы.
- Классификатор применяет таксономию: для каждой подтверждённой темы выбирает категорию и тип сигнала. Решение принимается по расширенным условиям применения и ограничениям для близких правил, а не по схожести названий.
- Критик правил сверяет разметку с текстом и сравнивает выбранный консёрн с правдоподобными альтернативами. Допустимое, но слишком широкое решение получает предупреждение; отклоняется только явное противоречие.
- Корректор исправляет отклонённые решения — ровно один раз. Второго круга критики нет специально, чтобы процесс не стал бесконечным.
- Python-помощник проверяет структуру ответа, выводит теги из выбранных консёрнов и записывает итог. Ошибка на одной строке не задерживает остальные.
- Контроллер запуска берёт следующий бакет и продолжает цикл, пока каждый бакет в манифесте не получит итоговый статус. Если контроллер завершился раньше времени, управляющий агент запускает новый и продолжает тот же зафиксированный прогон.
Правила живут в таксономии, а не в коде
Продуктовая логика вынесена в отдельный справочник, который поддерживают UX-исследователи и продуктовая команда. Для каждого консёрна заданы точное название, продуктовая область, условия применения, ограничения и короткий однозначный пример. Изменение таксономии не требует переписывать Python-код — продуктовые знания в код не переносятся вовсе.
Пример разведения близких правил из материала: фраза «Объявление отклонили, но непонятно, что исправить» попадает в категорию «Непонятна причина отклонения», а вопрос о том, сколько обычно длится проверка, — это уже другое правило. Похожих слов для выбора недостаточно, классификатор обязан проверить смысл и границы применения.
Главный вывод этого блока авторы формулируют прямо: качество таксономии важнее количества промптов и дополнительных проверок. Если два консёрна описывают почти одно и то же, модель будет колебаться даже при хорошей инструкции, и полезнее объединить правила или точнее развести их границы, чем усложнять код.
Восемь ошибок, которые заложены в архитектуру
Текущая версия системы сложилась после нескольких тестовых запусков. Авторы перечисляют восемь проблем, которые наблюдали, и решение по каждой:
- Длинный комментарий получал одну метку. Классификатор находил знакомый консёрн и переставал замечать остальные мысли. Выделение тем вынесли в отдельный этап и добавили независимую проверку полноты.
- Правило выбиралось по похожему названию, хотя существенное условие применения не выполнялось. Условия применения и контрпримеры явно разделили, а критику стали передавать сильные альтернативы.
- Критик отклонял допустимые решения, искал идеальный ответ и добавлял хаоса. Его сделали мягче: допустимый ответ сохраняется, отклоняется только доказуемое противоречие.
- Исправления ходили по кругу — каждая новая проверка запускала ещё одну переразметку. Оставили одну точечную повторную попытку без второго круга критики.
- Корректный смысл ломался из-за формата ответа. Python получил фиксированные шаблоны, нормализацию безобидных отклонений и локализацию ошибки на одной строке.
- Агент останавливался в середине очереди, принимая завершение этапа или бакета за конец задачи. Добавили манифест, отдельного контроллера и техническую проверку завершения всех бакетов.
- Маленькие бакеты расходовали слишком много ресурсов: для каждой группы повторялись инструкции, запуск ролей и проверки. Размер бакета увеличили до 50 комментариев, сохранив свежих субагентов для каждой группы.
- Консёрн и тег расходились, пока модель заполняла два связанных поля независимо. Тег перестали выделять отдельно — Python однозначно выводит его из консёрна.
Качество: метрики, эталон и границы
Для оценки собрали контрольную выборку из 196 комментариев, размеченных вручную вместе с UX-исследователями. Отбирали случайно, с учётом разных источников обратной связи; ручная разметка хранится отдельно и субагентам во время теста не передаётся.
Главная метрика — Micro F1 по консёрнам. Полное совпадение комментария с эталоном авторы считают слишком грубой проверкой: в длинном отзыве агент может правильно найти три темы и пропустить четвёртую. Поэтому отдельно считаются правильные назначения, лишние назначения и пропуски, а Micro F1 объединяет точность и полноту по всем темам выборки.
Результаты на контрольной выборке: Micro F1 по консёрнам — 83,87%, по тегам — 90,27%. Второе число авторы называют диагностическим: теги не отдельная смысловая задача модели, их выводит Python из выбранных консёрнов.
Отдельный блок посвящён тому, что эталон тоже приходится проверять. Короткий комментарий часто не позволяет определить единственно верный консёрн: «Не могу пополнить кошелёк» может означать и непонимание сценария, и технический сбой — финансовая тема или техническая ошибка. Для очевидных случаев в эталоне остаётся один ответ, для объективно неоднозначных заранее фиксируется несколько допустимых вариантов. На текущей выборке 190 комментариев имеют высокую уверенность, а для шести зафиксировано семь дополнительных допустимых вариантов. Варианты определяются до оценки нового запуска — чтобы ответ не объявляли правильным задним числом ради роста метрики.
Границы системы авторы перечисляют парами «гарантируем — не гарантируем»: фиксированный состав очереди и версию правил на время запуска, но не единственно верную трактовку неоднозначного текста; чистый контекст для каждой роли и бакета, но не точность при пересекающихся правилах; использование только актуальных консёрнов и автоматическое соответствие тегам, но не полноту таксономии; защиту от перезаписи и остановки после локальной ошибки, но не от ошибок в ручном эталоне; завершение только после обработки всех бакетов, но не появление правил для новых пользовательских смыслов без участия команды. Их формулировка: архитектура помогает стабильно применять знания команды, но не заменяет развитие самих знаний.
На выходе для каждого комментария сохраняются тип сигнала (жалоба, предложение, вопрос, позитив или отсутствие полезного сигнала), консёрны всех найденных тем и связанные теги, а рядом — исходный текст.
Как это используют, в материале рассказывают три человека. Андрей Безруков планирует бэклог по кварталам: в середине квартала смотрит общий рейтинг проблем, выделяет топ по своей зоне и уже потом читает прямую речь и логи; раньше на такую сборку уходило несколько недель и участие многих коллег. Продуктовый аналитик Роман Булгаков отмечает, что несколько лет назад для разметки такого объёма понадобилась бы отдельная команда по данным с обучающей выборкой и настройкой модели, а теперь аналитик вместе с UX-исследователями собирает процесс быстрее и проверяет его на эталоне. Ведущий UX-исследователь Анна Кузьменко называет зоной роста регулярное обновление таксономии: одни проблемы решаются, другие появляются, а интервью показывают, что под одним тегом иногда скрываются разные причины.
Коротко
- Единица анализа — не комментарий, а смысловая тема внутри него: сначала система находит все самостоятельные мысли, потом классифицирует каждую.
- Один агент с большим списком правил не выдержал длинную очередь, поэтому задачу разбили на роли: сегментатор, критик полноты, классификатор, критик правил, корректор, плюс Python на очередь, формат и запись.
- Проверяет разметку отдельный агент с чистым контекстом — самопроверка той же модели склонна подтверждать своё же решение.
- Продуктовые правила вынесены в таксономию с условиями применения и контрпримерами; её качество авторы считают важнее числа промптов и проверок.
- Micro F1 по консёрнам — 83,87%, по тегам — 90,27% на контрольной выборке из 196 ручно размеченных комментариев, где для шести неоднозначных случаев заранее зафиксированы допустимые варианты.
Что из этого следует
Кейс про разбор фидбэка, но переносится он на любую поточную разметку текста — заявки, письма, расшифровки звонков, входящие идеи для контента. Главное переносимое решение здесь не «агентов должно быть много», а разделение труда: смысл отдаётся модели, повторяемые операции и запись результата — коду, и роли не смешиваются в одном промпте.
Второе, что стоит забрать, — порядок этапов. Сегментация до таксономии (чтобы существующие категории не ограничивали поиск смыслов), критика в чистом контексте и ровно одна попытка исправления. Последнее особенно практично: бесконечные круги самокритики съедают деньги и время, не улучшая результат.
Что проверить у себя, если такая задача есть. Во-первых, измеряете ли вы качество вообще: без ручного эталона и метрики, учитывающей пропуски, рассуждать об улучшении промптов бессмысленно. Во-вторых, нет ли в вашем справочнике категорий, различие между которыми вы сами не можете объяснить одной фразой, — на таких парах модель будет колебаться всегда. В-третьих, фиксируете ли вы версию правил на момент запуска: иначе два прогона несравнимы.
И честная рамка, которую авторы задали сами: 83,87% по точным категориям — хороший рабочий результат для приоритизации бэклога, но не основание выключить человека. Система здесь готовит картину для решения, а решение принимает продакт.
Источник: Как мы собрали ИИ-конвейер для разметки продуктового фидбэка