При обработке больших потоков неструктурированного текста разработчики обычно выбирают один из двух путей:
Первый — использовать детерминированные методы. Регулярки, сигнатуры, и подобные инструменты работают быстро. Вот только никак не поймают новые, ранее не описанные паттерны.
Путь второй — скармливать сырые данные в ЛЛМ напрямую. В реальности этот подход быстро умирает. Отправлять огромные объемы нефильтрованного текста в языковые модели слишком дорого и медленно.
Русский и английский оригиналы статьи в моём блоге.
Это подробный разбор одного эксперимента. Я взял god node из реального LangGraph агента и попросил 5 американских и 6 китайских моделей сначала предложить, как её распутать, а потом оценить предложения друг друга. Дальше тремя разными способами пытался понять, кому из них в этом деле верить.
Оглавление
Исходная задача. Что за god node и чем она опасна.
Пару месяцев назад я смотрел демку: AI-агент получал пулл-реквест, пробегал по diff-у, находил потенциальный race condition и писал развёрнутый комментарий с предложением фикса. Всё это занимало около 40 секунд.
В нашей команде ревью давно стало бутылочным горлышком. Двое сеньоров, около двенадцати PR в день, каждый висит в очереди по полдня. Идея автоматизировать первый проход — типовые замечания, проверки стайлгайда, очевидные ошибки — выглядела очень соблазнительно.
У нас есть корпоративные MCP-серверы, AI-агент и пользователи в Telegram. Каждый пользователь должен авторизоваться через Keycloak, а агент — работать от его имени. Здесь собраны грабли, на которые мы наступили, и архитектурные решения, к которым пришли.
Если вы:
Прикручиваете OAuth/OIDC к чему-то, что на это не рассчитано
Строите мультитенантного AI-агента, где у каждого пользователя свои права
Пытаетесь подружить MCP-серверы с корпоративным IdP
Пишете кастомные ноды для n8n
Я пришел в разработку агентов из дата инженерии, и в очередной раз занимаясь сборкой типовой структуры на LangGraph я заскучал по декларативному подходу, хорошо многим знакомому по dbt - там ты описываешь что ты хочешь сделать с данными, а не как. И тогда у меня появилась мысль - а почему бы не собрать свой фреймворк для агентов, который даст тот же подход.
Привет! На фоне ажиотажа вокруг нейросетей все чаще встает вполне приземленный вопрос — сколько стоит содержать собственную LLM.
Это продолжение статьиЧитать полностью »
В типовом BI-проекте данные проходят некоторый путь от источника данных до аналитического отчёта:
Источник данных → ETL-процессы → DWH (витрины) → OLAP-cube → Меры
На выходе получаем множество мер — ключевых показателей бизнеса
вроде: "Выручка", "Средний чек", "Конверсия"; каждая из которых это результат
цепочки трансформаций данных через SQL-процедуры, представления
и DAX-формулы.
Когда в проекте более 200 мер, удержать все детали в голове сложно, и при вопросе пользователя: - "Откуда берётся значение в мере [Долг поставщика]?", разработчик вынужден:
