🤖
Self-service аналитика в Anthropic Аналитическая команда из Anthropic рассказала в
статье как они делают аналитику на базе Claude. Получилась крепкая статья, где расписаны все основные концепты, которые нужны чтобы агенты меньше тупили при работе с данными.
Забавно, что начинают они с того, что вот при работе с кодом всё хорошо — там ведут документацию, есть история изменений и часто есть только один верный результат. А вот в аналитике данные не описаны, нет точной проверки результата и просто бардак. Сложно с ними не согласиться, но думаю, что с кодом всё примерно так же на самом деле 😅
Поэтому основные действия направлены именно на улучшение контекста и качества описания данных. Так как именно это даёт наибольший буст (как и для вообще любых агентских задач, а не только для данных).
Они разделяют эту работу на 4 уровня:
— Data foundations
— Sources of truth
— Skills
— Validation
С первыми двумя всё довольно скучно и стандартно: внедряйте процессы data governance, стройте семантический слой и linage, сделайте набор "золотых" курируемых таблиц (вообще были бы такие источники и агенты бы были не нужны 🤣), с которыми будет в первую очередь работать агент
И делать это желательно руками, а не агентами:
One idea we tried that didn’t work: bootstrapping the semantic layer by having an LLM auto-generate metric definitions from raw tables and query logs. It produced plausible-looking definitions that encoded the very ambiguities we were trying to eliminate, and was net-negative on our evals versus a smaller, human-curated layer.
Из интересных идей: можно подсунуть в контекст SQL запросы из дашбордов и предыдущих исследований. И ещё важно скармливать не только исторический курируемый бизнес контекст (аля вики с процессами), но и текущий операционный (чаты, роадмапы и таски).
В общем никуда от скучной работы по причесыванию документации и данных не деться. А вот со скилами и валидацией в статье для меня были новые идеи.
Скиллы становятся такой же важной сущностью как и код для ETL / дашборды / документация. Это ещё одна сущность, которая должна обновляться и при обновлении схемы данных, и при изменении бизнес-процессов. Если этим не заниматься, то быстро происходит падение качества:
We watched our offline accuracy drift from ~95% at launch to ~65% over a month before we treated this as an engineering problem.
То есть за скиллами тоже надо будет следить и настраивать все инженерные практики, как и для кода. А улучшать их можно через «A/Б-тесты» и эксперименты. Microsoft даже уже сделали
open-source проект заточенный на это.
Для правильной же валидации приходиться делать слепки данных, которые использовались при создании скилла. Чтобы можно было сравнивать яблоки с яблоками при его изменении, иначе будет невозможно иттеративно их улучшать. И это прям ещё один большой слой по работе с базой — как это делать если база большая, куда всё это складывать и т.п.
И ещё одна нерешенная задача это silent failure — как искать случаи когда модель дала ответ, но пользователь не понял, что он плохой или просто не сообщил про это. Получается, что очень сложно отслеживать реальное качество и непонятно насколько 95% evals траслируется в реальное качество.
Жалко, что совсем ничего не рассказали про конечный опыт пользователя и UI: как делают дашборды и чаты, как они разделяют доступ по доменам и т.п. Просто голый Claude чат тут не подойдет и это тоже важная часть, которую нужно научиться строить для полноценной системы.
В общем общий вывод — чтобы аналитика на базе LLM работала надо делать много процессов и внедрять инженерные практики. Чооооорт 😈
