Контекст для агентов Понятно, что для эффективной работы моделям нужен контекст. Даже лучшие модели не могут ответить на простой вопрос, если им его не дать. Нашёл пример, где и Fable, и ChatGPT 5.5 довольно неуклюже отвечают на вопрос просто потому, что не знают нужного контекста и не могут его додумать. А вектор выдал такой ответ как самый частотное, но что не значит самый логичный. (Скриншот из Fable сделан вчера, пока басня ещё не перестала быть былью, простите 😅) Но где этот контекст хранить? Я выделял бы три подхода. 1. Текстовые файлы Самый простой вариант — хранить текстом в .md, json, jaml и т.п. Файлы могут лежать локально, в git-e или внутри инструментов вроде dbt и каталогов данных. Дальше агент либо ищет нужную информацию по ключевым словам с помощью grep, либо переходит по ссылкам между документами. Если используются внешние тулы, подтягиваться через API или MCP. На удивление, этот подход работает очень хорошо. Особенно если задача относительно небольшая. 2. RAG, векторные и графовые базы Когда документов становится много (условно 1000+), обычного поиска уже недостаточно. Тут появляются векторные базы и RAG. Вместо поиска по словам система ищет смысловое сходство, что может быть полезно в сложных задачах и мултиязычности. Графовые же базы решают задачу связей и смыслов. Они позволяют хранить линки между объектами: метриками, таблицами, дашбордами, бизнес-процессами, что даёт дополнительный буст в понимании для агента. Такие решения масштабируются намного лучше, но требуют больше инфраструктуры и поддержки. Мне пока сложно представить где это было бы нужно именно для аналитики. Если делать company brain для большой организации, то наверное может быть полезно. Но в рамках одного домена данных, мне кажется, что в такое не упереться. 3. MCP и сырые данные Третий подход — вообще не хранить контекст как-то специально, а получать его напрямую из сырой информации через MCP и конекторы. В этом случае агент может сам сходить в Jira, Confluence, CRM или BI-систему и получить информацию из того, что найдет. Подход максимально универсальный, но дает нестабильные результаты, так как нет курируемого слоя контекста, а значит можно наткнуться на ошибки и устаревшие данные. В общем быстро, но надёжно. Хотя даже так, часто лучше, чем без контекста совсем. Как управлять Дальше встаёт вопрос как его формировать и им управлять. Вокруг этого нужно и какой-то UI и процессы и это прям большой пласт работы, уверен, что там будет лежать много пользы и задач для аналитиков в будущем и пока прям хорошего решения я не видел. Приорал от того как задачу с контекстом решили ребята из DataLens. Они сделали это через скрытую вкладку дашборда. По сути аналитик создает отдельный таб, который содержит описание метрик, бизнес-правил, заранее отобранные графики и данные. А при каждом запросе бизнес-пользователя боту, это всё передается в контекстное окно модели. С одной стороны — это прям костыль-костыль. С другой — это красивое решение Аналитик может самостоятельно управлять знаниями бота без RAG и отдельного нового интерфейса, просто меняя содержимое вкладки. Для небольших задач будет работать отлично, хотя конечно плохо, что это привязанно только к одному дашборду. Послушать их первых уст про то как это работает можно будет на вебинаре 16-ого июня, Паша Дубинин как раз расскажет про это, должно быть интересно. Что использую сам Мы у себя в команде, именно для внутренних дашбордов, используем первый вариант — локальные .md-файлы. На них работают и внутренние дашборды, и агенты, которые отвечают на вопросы команды. И, если честно, пока не вижу причин усложнять решение. Если у вас система из 5–7 дашбордов и десятка таблиц, то десяток .md, немного структуры и локальные HTML-дашборды для наших задач сейчас работают отлично. Даже дефолтный Data Analytics plugin для Codex работает очень неплохо. Даня Шевцов тоже недавно рассказывал про похожий подход на воркшопе про агентскую аналитику, вот запись. В общем думаю, что следующий шаг для BI — это BI as .md files! __P.S. Ну и достаем поп-корн и ждём, что будет с Fable 🤪__