Как проверить, что ИИ-аналитик не врёт
Ранее писал, что семантический слой это мастхев для внедрения ИИ-аналитиков, которые будут снимать рутину и сами отвечать на вопросы по метрикам. Но когда такого аналитика выкатываешь в прод, встаёт вопрос посерьёзнее: не обманывает ли он нас, с умным лицом выдавая метрики?
Авито в своём докладе показали зрелый набор методов, и разобрать его для уважаемых подписчиков будет полезно
🔢Валидация через семантический слой 👍 Логика расчёта 10 000+ метрик зафиксирована в репозитории (YAML-файлы), модель не генерирует SQL с нуля, а выбирает из уже определённых объектов. По сути аналог verified queries: система не может посчитать метрику как-нибудь, только по зафиксированной формуле. Это самый сильный элемент, потому что ошибки отсекаются ещё до выполнения запроса
🔢Golden Set + Continuous Eval Эталонные пары вопрос-ответ, подготовленные экспертами. Используется не разово, а как continuous eval, т.е. при обновлении модели или базы знаний прогоняют golden set и смотрят, не деградировало ли качество
🔢Confidence Score + классификатор недовольства Модель оценивает собственный выбор метрики и разреза по шкале от 1 до 10. При 10k+ метрик и 120+ разрезах это критично, а на случай, когда confidence высокий, а результат всё равно мимо, есть отдельный классификатор, который ловит недовольство пользователя и запускает перегенерацию
🔢Бенчмарк по бизнес-задачам + доменная экспертиза Оценка через успешность сессий для конкретных jobs to be done, плюс 20+ аналитиков размечают сложные случаи
Набор сильный...но по моему опыту есть ещё несколько вещей, которые стоит добавить, с оговорками где и когда они реально нужны:
🔴Eval map, т.е. разбивка точности по типам вопросов У Авито бенчмарк по бизнес-задачам, но нет (по крайней мере в докладе) матрицы точности по типам SQL-операций: простые агрегации, джойны, бизнес-логика, сложные вычисления. Общая цифра 85% может скрывать провал на бизнес-метриках при 100% на простых вопросах. Без eval map вы не знаете, где именно система ломается. Google Cloud так устроил eval для своих text-to-SQL продуктов, академические бенчмарки Spider и BIRD работают аналогично
🔵LLM-as-judge на этапе eval, не в рантайме Авито используют confidence score, но это про рантайм. LLM-as-judge слегка о другом: отдельная модель офлайн оценивает качество сгенерированного SQL при прогоне eval pipeline. Бывает, результат совпал случайно, а SQL кривой, или наоборот SQL правильный, но результат разошёлся из-за округления значений. Это дополнительный вызов LLM на каждый вопрос в golden set, не на каждый пользовательский запрос, так что дёшево и для здоровья полезно
🩷Shadow mode на этапе внедрени ИИ-аналитик работает параллельно с настоящим, только ответы пользователю не уходят — их сравнивает живой аналитик со своими, и из расхождений органически растёт golden set. Но надо учитывать, что это оправдано первые месяцы обкатки системы, т.к. на постоянной основе дорого, потому что требует времени аналитика на каждое сравнение
🟤Полное логирование с периодическим аудитом Сохранять все вопросы, сгенерированный SQL и результаты, периодически сэмплировать и проверять вручную. У Авито элементы этого есть, но системный аудит случайной выборки ловит деградацию, которую фиксированный golden set пропустит, потому что пользователи всегда задают вопросы, которых в golden set нет
tl;dr: подход Авито ориентирован на предотвращение ошибок через семантический слой и экспертную разметку. На практике частенько к этому стоит добавить технический аудит, eval map и логирование. Еще бы LLM-as-judge полезен на этапе eval, shadow mode на этапе внедрения. Одно не заменяет другое: семантический слой предотвращает ошибки, eval pipeline их ловит. Но как всегда надо оценивать финансовую целеесобразность таких проектов
