Чем AI-first аналитика отличается от привычной и как к ней подготовиться

Последние месяцы я активно гоняю AI-аналитика на тестовом стенде и смотрю, что в привычном пайплайне аналитики остаётся, что поправить, а что надо строить (схема и чек-лист - в карусели).

1. Данные: остаются, но меняется то, что доходит до агента

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

• код сборки и тесты - агент не видит вовсе

• описания витрин - только через манифест и после пересборки

• файл определений метрик (он же семантический слой) - видит целиком

2. Решения: переезжают из голов аналитиков и SQL в три места

Решение - это всё, как можно сделать и можно ли сделать иначе: какой период, кто гость, считать ли отмены и тд. Агенту их надо положить принудительно туда, откуда он эти решения точно прочитает:

• файл определений метрик (metrics.yml) - окна, статусы, исключения, сравнение периодов, область действия

• описания витрин (schema.yml) - решение словами. Поле уже есть, а рядом текст, как его понимать. Агент это прочитает, но дальше должен сам правильно применить (написать нужное условие, не перепутать с другим полем)

• поле витрины - решение в данных, которые не надо толковать. Агент принимает однозначное решение по полю витрины.

3. Постановка: доходит до агента по четырём каналам

Аналитик уточняет детали задачи в разговоре, а агент просто берет инструкции и контекст прямо из промпта:

• текст задачи: что считать, за какой период, в каком виде ответ

• контекст: схема, описания, определения, примеры значений, прошлая версия результата

• обвязка: код, который решает, что именно из контекста попадёт к модели

• инструкция: постоянный текст от команды, который обвязка добавляет к каждой задаче (не выбирать "молча", можно ответить «уточните» или «не готов»)

4. Проверка: переходит из ресурсов сеньора в процесс

Ошибка агента правдоподобна: дублей нет, числа разумные - но не те. Глазами такое легко пропустить, поэтому нужен процесс проверки итогов:

• автопроверка до выдачи: сравнение с прошлой версией, сверка с внешним итогом, контрольные суммы

• эталонные запросы для частых вопросов

• разбор расхождений до конкретного решения (а не просто «модель ошиблась»)

• замечания агента: он сам называет решения, которые принял сам.

5. Роль: у каждой записи появляется владелец

Владелец записи отвечает за то, чтобы запись оставалась правдой:

• добавляет решение, когда агент ошибся или переспросил

• обновляет запись, когда меняется метрика

• проверяет, что запись доходит до агента после пересборки.

Что же все-таки понадобится AI first компании? Как минимум, пачка новых артефактов:

1. файл определений метрик с областью действия

2. описания витрин с решениями

3. шаблон задачи с полем «форма ответа»

4. инструкция с правом обоснованно уточнять и отказываться

5. автопроверка с эталонными запросами

6. лог того, что видела модель