Как получить от AI-аналитика ответ на задачу

Две команды из моих последних разговоров строят аналитику на агенте. Обе получают правдоподобные числа. Обе не уверены, что числа верные, и не знают, чем это проверить.

---

Дело не в модели. Задачу отдали раньше, чем описали.

У меня есть стенд — синтетический интернет-магазин, где я сам сгенерировал данные и поэтому заранее знаю правильный ответ на любой вопрос. На нём видно: если оставить в задаче одно решение необъявленным, ответ уезжает в среднем на 12.64%. Это восьмая часть. И по самому числу этого не заметить: оно выглядит нормально, ничего не падает, никакой ошибки в логах нет.

Дальше я проведу одну задачу через семь шагов и на каждом покажу, что пришлось объявить, чтобы задачу вообще можно было отдать. Там, где способа проверить не существует, я так и пишу: способа нет, и вот почему его не будет.

---

Сцена: шесть слов и пять решений

Посчитай долю возвратов за декабрь.

Задача на пятнадцать минут. Отдаём агенту, получаем число, число выглядит нормально.

Внутри неё сидят пять решений, и ни одно в задаче не названо.

Какой декабрь. Календарный месяц — или скользящее окно от сегодняшнего дня, если так принято в компании.

Куда относить возврат. Товар купили в декабре, вернули в январе. Этот возврат портит декабрь или январь? Оба ответа защитимы, и они дают разные числа.

Учитывать ли незрелые заказы. Возвраты приходят с задержкой: то, что купили три недели назад, ещё не успело вернуться. Если не отсечь свежие заказы, доля будет занижена — и через месяц тихо вырастет сама собой, без всяких изменений в бизнесе.

Считать ли гостевые заказы. Покупки без регистрации ведут себя иначе, чем покупки постоянных клиентов.

Что вы хотите увидеть. Одно число — или ещё и сравнение с ноябрём и с прошлым годом.

У каждого пункта два нормальных ответа. Если вы не выбрали, выберет модель. Молча и не обязательно одинаково в следующий раз.

Теперь главный вопрос: сколько из этих пяти решений записано в семантическом слое — в том файле, где команда фиксирует, как считаются метрики?

Одно из пяти. С натяжкой два.

Задача не передавалась агенту. Не потому что сложная — а потому что решения по ней жили в голове человека, который её ставил.

---

Семь шагов

Шаг 1. Понять, что вообще за задача

Прежде чем спрашивать «справится ли агент», стоит спросить проще: что появится, когда задача будет закрыта? Число в чате. Выгрузка в файле. Новый дашборд. Звено регулярного расчёта. Исследование на две недели. Или договорённость о том, как впредь считаем метрику.

У нашей задачи на выходе число. Я разметил живой бэклог аналитической команды за полтора года — 705 задач — и таких там двенадцать. Не двенадцать процентов. Двенадцать штук.

Это сильно меняет разговор. Публичные бенчмарки для агентов проверяют ровно этот тип задач — «задай вопрос, получи число». То есть меряют примерно одну пятидесятую того, чем команда занята на самом деле. У остальных типов и работа другая, и проверять их надо иначе.

Что делать: взять сотню своих задач и разметить не по теме, а по тому, что появляется на выходе. Час работы, и разговор про агентов сразу становится предметным.

Чего это не даёт: мои пропорции не переносятся на вашу команду. Я проверил на втором источнике — типы задач те же, а доли совсем другие, потому что в разных командах по-разному принято сохранять результат.

Шаг 2. Записать решения туда, где их видит агент

Окно, привязка возврата, отсечка незрелых заказов, гости — всё это должно лежать в слое явной строчкой со значением. Не абзацем пояснений рядом, а именно строчкой, которую агент прочитает.

Это единственный шаг, который я проверил в обе стороны.

Сначала убирал. Брал слой, вынимал одну строку с решением, задавал агенту те же вопросы. В четырёх случаях из шести ответ поехал — и поехал ровно по той оси, которую я убрал. Агент не переспросил ни разу.

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

Оставшиеся два случая из шести честнее показать, чем спрятать. В одном ответ поехал, но по другой оси, не по снятой. А в другом решение устояло: я убрал из слоя строку о том, считать ли выручку до возвратов или после, — и агент в двух прогонах из трёх всё равно посчитал после возвратов. То есть не всякое незаписанное решение отзывается. Иногда у модели крепкое умолчание, и оно случайно совпадает с вашим.

Потом добавлял. Записывал решение, противоречащее тому, что модель выбирает по умолчанию. Послушалась три раза из трёх.

И есть третий результат, неприятный для тех, кто слой уже поднял. Слой сильнее задачи. Я взял девять случаев, где в задаче написано одно, а в слое стоит другое. Разошлись пять из девяти, и в четырёх из пяти победил слой.

В обоих случаях агент честно применил скользящее окно из слоя вместо месяца из задачи и в ответе про это написал. Написать в задаче «мне нужен календарный апрель», когда в слое стоит окно, — не значит получить календарный апрель.

Что делать: объявлять решения строчками в слое. Это самый дорогой шаг, зато делается один раз.

Чего это не даёт: пояснительный текст вокруг решения не работает. Работает только само записанное значение.

Шаг 3. Поставить задачу

Здесь я был неправ, и это, пожалуй, самая полезная часть статьи.

Я пробовал придумать, как проверять качество постановки задачи, ничего не вышло, и я сделал вывод: проверяющий не нужен, нужен формат. Поля, которые заказчик заполняет словами из слоя. Формат у меня уже был написан.

Я решил его проверить. Взял семь настоящих задач, посмотрел, какие решения по ходу дела пришлось принять тому, кто их выполнял, — и выписал только те, которые он назвал сам, а не те, что я за него придумал. Получилось четырнадцать решений.

Формат закрыл три из четырнадцати. Вот куда делись остальные одиннадцать:

Проблема не в полях, и её нельзя починить, добавив ещё пару. Заказчик физически не может написать в задаче, что колонка is_cancelled в витрине давно превратилась в константу. Чтобы это узнать, надо открыть код витрины и прочитать. Эти одиннадцать решений не забыты и не спрятаны — в момент постановки задачи их ещё не существует.

Постановку невозможно принять не потому, что нет хорошего формата, а потому что четыре пятых решений рождаются, когда человек читает код, а не когда он пишет задачу.

Что формат всё-таки даёт. Полей в нём четыре, задач было семь, итого 28 заполнений. Из них 21 выводится из текста задачи автоматически, и только 7 требуют, чтобы человек подумал и выбрал. Четверть, а не половина. Причём поле «какой объект правим» не потребовало выбора ни разу из семи, а «какие колонки» и «какие строки» — по три раза каждое.

Формат экономит рутину. Он не превращает непередаваемую задачу в передаваемую.

Что делать: перестать требовать от заказчика полноты. Требовать её — значит требовать знания, которое появляется только у того, кто уже начал считать.

Чего это не даёт: проверить постановку по-прежнему нечем. Но у этих одиннадцати решений есть куда деться, и об этом шаг 6.

Шаг 4. Настроить, что агент видит

Агент считает по тому, что ему показали, и не жалуется.

В моём стенде 21 таблица. Агент видит шесть. Дал ему таблицу с нужным полем, но не дал ключей, по которым её соединять, — он развернул развилку сам, на своё усмотрение. Не дал вовсе — честно ответил «в схеме нет такого поля» и посчитал по тому, что было.

Что делать: выписать в столбик таблицы, которых касается задача, и рядом — таблицы, которые реально уходят агенту. Это два разных списка чаще, чем кажется.

Чего это не даёт: проверить видимость заранее нельзя. Она проверяется только запуском.

Шаг 5. Агент считает

Единственный шаг, который агент закрывает целиком и сам. Писать про него почти нечего, и это хорошая новость: весь спор про то, достаточно ли умная модель, занимает один шаг из семи. Остальные шесть — про то, как устроена работа вокруг неё.

Шаг 6. Разобрать ответ и вытащить из него остальное

Сначала скучное, но обязательное: договоритесь, в каком виде вы принимаете ответ. Какая колонка считается ответом, какая это величина, в каких единицах. Пока этого нет, вам попросту нечем сверять — вы каждый раз глазами угадываете, что перед вами.

А теперь главное. Помните одиннадцать решений, которые невозможно было объявить заранее? Человек, который считал, их всё-таки назвал. В блоке замечаний в конце своего ответа. Во всех семи задачах этот блок оказался содержательным: двенадцать вызовов из двенадцати, ни одного пустого «замечаний нет».

Отсюда самое дешёвое действие во всей статье. Попросите агента отдельным блоком перечислять, что он решил сам. Не «проверь себя» — это бесполезно. А буквально: какие развилки ты встретил и что выбрал на каждой. И разбирайте этот блок так же внимательно, как само число.

Так круг замыкается. Решений, которых не было в момент постановки, к моменту ответа уже существуют. Их надо забрать из ответа и вернуть в слой — то есть в шаг 2. В следующий раз эта развилка будет уже закрыта.

Что делать: добавить блок «что я решил сам» в шаблон ответа. День работы, а эффект больше, чем у половины остального списка.

Чего это не даёт: форма ответа не делает ответы правильнее. Она делает их проверяемыми — и там, где сверить раньше было нечем, теперь есть чем, и сверка не проходит.

Шаг 7. Принять работу

Универсального способа проверки не существует. Под каждый тип задачи — свой.

Если правильный ответ известен заранее, сверяйте с ним. Если неизвестен — разбирайте не итог, а из чего он сложился. Если агент правил существующий отчёт — проверяйте, не задел ли он лишнее. Если это звено регулярного расчёта — смотрите, сходятся ли суммы по разным разрезам.

И у каждого способа есть слепое пятно, которое надо знать заранее, а не выяснить потом. Проверка «не задел ли лишнее» однажды сказала «всё чисто» на запуске, где в соседней витрине переписалось 11 991 значение. Сверка сумм по разрезам молчит, когда агент пишет один запрос вместо трёх: сходиться просто нечему.

Что делать: завести один способ проверки под свой основной тип задач и сразу записать, чего он не ловит.

Чего это не даёт: любая проверка без внешнего источника правды проверяет только, что цифры согласуются между собой. Согласоваться они могут и будучи неверными.

---

До и после

До — шесть слов:

Посчитай долю возвратов за декабрь.

После — настоящая постановка с моего стенда. Предупреждаю: читается тяжело, и в этом весь смысл.

Посчитать return_rate (grain=line) по когорте заказов декабря: знаменатель — проданные строки завершённых заказов с ordered_at_utc в декабре последнего завершившегося года относительно курсора, числитель — те же строки, по которым есть возврат (независимо от даты возврата). Все данные отсекаются по received_at_utc <= world_cursor; из декабрьской когорты исключаются заказы, не дозревшие на 21 день к курсору.

Здесь закрыты все пять развилок, и рядом с текстом лежат восемь решений с обоснованием у каждого.

Оговорка, без которой этот пример был бы враньём: текст написал человек, который ставил задачу, и исполнителю он не уходил. У меня сохранились постановка, решения и список того, что осталось открытым. Ответа и SQL там нет.

И второе, чего в этом примере не видно. Ни в одном живом заказе, который я разбирал, полного набора решений не было. Обычные задачи называют период, статус и нужные колонки — и молчат про привязку возврата, про незрелые заказы, про гостей и про форму ответа. В одном разобранном заказе четыре решения из семи не объявлены нигде.

Отсюда вывод, который стоит всей статьи: сложность задачи и возможность её отдать — разные вещи. Шесть слов отдать нельзя. Три абзаца терминов можно отдавать хоть каждый месяц.

---

Почему неверный ответ выглядит нормально

Допустим, вы уже подняли агента на своих данных и получаете правдоподобные числа. Вот что видно на стенде, где правильный ответ известен.

Правдоподобность вы проверяете против ожидания, а не против правды. Это главное. В том случае, где слой перебил задачу, агент выдал выручку 12 744 925.74 при правильных 4 001 058.59. Разница не в процентах — в разы. И ответ всё равно прошёл: двенадцать миллионов выручки выглядят как совершенно нормальная выручка. Никто не смотрит на число и не думает «это втрое больше правды», потому что правды никто не видел.

То есть защищает вас не размер ошибки. Мелкие ошибки не видно, потому что они мелкие. Крупные не видно, потому что у вас нет с чем сравнить.

Ошибки при этом бывают очень разные. Я задал агенту пятнадцать вопросов и сверил с известными ответами. Три оказались неверными, и они не похожи друг на друга:

Первые две — те самые незаметные расхождения на проценты. А третья интереснее: чтобы получить 163%, агент сравнил абсолютное значение 79 412 272 с процентом 19.75. Сложил рубли с процентами и выдал результат без единой жалобы.

Вывод не в том, что ошибки маленькие. Вывод в том, что ни одна из трёх ничего не уронила. Ни исключения, ни пустого результата, ни предупреждения. Все три доехали до ответа в том же виде, что и двенадцать правильных.

Ломается при этом не модель. Между вопросом и числом стоит шесть этапов, и модель занимает из них не все. Я разобрал три механизма, которыми ответ уезжал. Два из трёх — это код вокруг модели: то слой отбора не показал нужную таблицу, то приоритет слоя перебил то, что было написано в задаче. Третий — наполовину модель. Проверка, которая следит за качеством модели, ловит примерно половину проблем.

Подпись не совпадает с делом. Вариант расчёта назывался «гости включены отдельным каналом». Запрос при этом гостей исключал и возвращал ноль. Ничего не упало, подпись осталась.

Задача может разрешить то, чего вы не имели в виду. Заказ говорил «считать выручку как цена × количество» и тем самым назвал цену источником данных. В результате правило подписало изменение 703 431 строки как заказанное.

---

В каком порядке это делать у себя

Порядок не по логике схемы, а по тому, что быстрее окупается.

1. Разметить сто задач по тому, что появляется на выходе. Час. После этого разговор про агентов становится предметным.
2. Договориться о форме ответа и попросить блок «что я решил сам». День. Без этого дальше не работает ничего.
3. Спросить агента, чего он не сможет, ещё до того, как дали данные. Дёшево, и дыры в слое видно сразу, а не постфактум в отчёте.
4. Записать решения строчками в слой. Дорого, один раз, надолго.
5. Разобраться, что агент видит. Инженерная работа, недели.
6. Завести один способ проверки под свой основной тип задач. От часа до нескольких недель.
7. Возвращать в слой то, что агент назвал в блоке замечаний. Постоянно, понемногу.

Формата постановки в списке нет намеренно. Он полезен, но задачу не переносит — почему, написано в шаге 3.

---

Чего всё это не даёт

На шагах 3 и 4 проверять по-прежнему нечем. Это ровно то место, где задача превращается в контекст. Я пробовал построить проверку, не получилось, и причина мне теперь понятна: четыре пятых нужных решений в этот момент ещё не родились.

Сроки в днях с меня брать не стоит. Это сроки одного человека без согласований на синтетическом стенде. Переносятся не сроки, а соотношения: слой дороже настройки контекста, контекст дороже формы ответа, а сама проверка при готовом фундаменте — самое дешёвое.

Все числа получены на одной сборке. Восемь из десяти проверенных чисел — с синтетического магазина, ещё два — из разметки выгруженных задач. Ни одно не подтверждено на втором стенде. Так что читайте «я измерил» как «я измерил вот на этом». Между стендами у меня переезжали способы проверки, а не значения.

Доли по типам задач считаются только по своему бэклогу. Мои — не ваши.

И один случай из моей собственной практики, раз уж статья про проверку. Готовя этот текст, я написал, что величина расхождения у трёх неверных ответов в моих записях не сохранилась. Она сохранилась — абзацем ниже того места, которое я прочитал. Я прочитал итог и не дочитал разбор. Таблица выше существует только потому, что я перепроверил собственную сверку.

---

Чек-лист перед тем, как отдавать задачу

1. Что появится, когда задача будет закрыта: число, выгрузка, дашборд, звено расчёта, исследование, договорённость?
2. Какие решения задача требует — и все ли записаны в слое строчкой, а не пояснением рядом?
3. Что стоит в слое там, где задача говорит своё? Слой сильнее, проверьте заранее.
4. Все ли таблицы, которых задача касается, реально видны агенту?
5. В каком виде вы принимаете ответ: какая колонка, какая величина, какие единицы?
6. Есть ли в ответе блок «что я решил сам» — и читаете ли вы его так же внимательно, как число?
7. Чем вы будете сверять и чего этот способ не ловит?

Семь «да» — задачу можно отдавать. Первое «нет» — это и есть то, чем стоит заняться.