"🤖 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 работала надо делать много процессов и внедрять инженерные практики. Чооооорт 😈"