В мире искусственного интеллекта, где каждый день появляются новые модели и фреймворки, часто возникает соблазн полагаться исключительно на мощность больших языковых моделей (LLM). Кажется, что если модель достаточно велика, она справится с любой задачей, от простого ответа на вопрос до сложного анализа разрозненных данных. Однако реальный опыт, особенно в таких строгих условиях, как соревнования KDD Cup 2026, показывает обратное. Надежность системы часто зависит не от «умности» самой модели, а от качества «контейнера» — той архитектуры и ограничений, которые вы вокруг нее строите. Именно этот инсайт лег в основу работы команды NVIDIA KGMON, занявшей второе место в соревновании Data Agents.
Задача, стоявшая перед участниками, была нетривиальной: агенты должны были отвечать на вопросы на естественном языке, используя гетерогенные источники данных. Это включали SQL-базы, CSV и JSON-файлы, текстовые документы, PDF-файлы и даже видео. Каждое задание требовало не просто поиска информации, а полноценного аналитического рассуждения: агент должен был оценить доступные данные, выбрать правильные инструменты, объединить информацию из разных источников, сформировать итоговый ответ и, что самое важное, избежать ловушек, типичных для аналитических рабочих процессов. При этом всем командам было предписано использовать одну и ту же небольшую, фиксированную LLM, что делало оптимизацию самой «обвязки» агента ключевым фактором успеха.
В этой статье мы подробно разберем подход команды KGMON. Мы не просто перескажем их решение, а углубимся в каждую техническую деталь, объясняя, почему те или иные архитектурные решения были приняты, как они помогают избежать типичных ошибок и как этот опыт можно применить в ваших собственных проектах по созданию AI-агентов для бизнес-аналитики. Это руководство о том, как превратить хрупкий эксперимент с LLM в стабильный, предсказуемый и проверяемый инструмент.
01Две фундаментальные принципы надежного агента
Прежде чем переходить к техническим деталям, важно понять философскую основу системы KGMON. Вся архитектура была построена вокруг двух простых, но мощных принципов. Первый принцип — ограничение пространства действий. Чем больше способов у агента взаимодействовать с данными, вызывать инструменты или восстанавливаться после ошибок, тем выше вероятность сбоя. Хаос в интерфейсе ведет к хаосу в логике. KGMON унифицировали доступ к данным, предоставили минимально необходимый набор инструментов и заставили агента использовать единственный путь для вывода финального ответа.
Второй принцип — полная наблюдаемость каждого шага. В сложных системах ошибки неизбежны. Они могут возникнуть из-за неверного вызова инструмента, ошибки в SQL-запросе, пропущенного правила из документа или неправильного формата ответа. Чтобы исправлять эти ошибки, нужно видеть, где именно произошел сбой. Поэтому система KGMON была спроектирована так, чтобы каждый шаг агента можно было отследить, проанализировать и использовать для улучшения системы. На рисунке ниже показан общий рабочий процесс, где предобработка данных, ограничение инструментов и сохранение состояния работают в связке с трассировкой выполнения.
021. Унификация структурированных данных в единую поверхность запросов
Одной из самых больших проблем при работе с разрозненными данными является необходимость писать разный код для разных форматов. Если агенту нужно читать CSV, парсить JSON и выполнять SQL-запросы к базе данных, это создает огромную нагрузку на контекстное окно модели и увеличивает вероятность ошибок маршрутизации. Команда KGMON решила эту проблему радикально: они преобразовали все CSV и JSON файлы в таблицы внутри единой базы данных SQLite.
Это решение позволило агенту использовать только один интерфейс для работы со всеми структурированными данными. В среде Python, которая была закреплена за агентом, были реализованы две встроенные функции:
schema()— для просмотра структуры таблиц и колонок;sql(query)— для выполнения запросов к единой базе данных.
Эти функции не были стандартными библиотеками Python или SQLite. Они были кастомными, специально разработанными для нужд агента. Это дало агенту единственный, понятный и предсказуемый способ обнаружения и запроса данных. Единый SQL-интерфейс значительно снизил количество ошибок маршрутизации (routing errors) и «потраченных зря» ходов, оставив ограниченную вычислительную мощность фиксированной модели свободной для самого важного — логического рассуждения над данными.
032. Предварительная подготовка контекста схемы (Schema Scouting)
Даже имея единый интерфейс, агент может потеряться в деталях. Какие таблицы можно объединить? Где ключи соединения? Есть ли дубликаты имен колонок? Какое значение имеют единицы измерения? Ответы на эти вопросы часто кроются в структуре данных, а не в самих данных. Команда KGMON добавила шаг «разведки схемы» (schema scouting) перед началом основного цикла рассуждений.
Система автоматически анализировала таблицы, выявляла возможные ключи соединения, дубликаты имен, похожие поля, единицы измерения, паттерны пропущенных значений (null patterns) и проблемы с гранулярностью строк. Этот контекст передавался агенту в начале каждого задания. Это экономит один или несколько ранних ходов, которые агент мог бы потратить на случайные попытки понять структуру данных, и значительно снижает ошибки, связанные с выбором неверных колонок или пропуском необходимых объединений (joins).
На рисунке выше показано, как конвертация CSV и JSON в таблицы SQLite дает агенту единый SQL-интерфейс, а разведка схемы предоставляет необходимый контекст еще до начала анализа. Это похоже на то, как опытный аналитик сначала изучает метаданные набора данных, прежде чем писать первый запрос.
043. Создание небольшого, «мнения»-ориентированного набора инструментов
Чем меньше инструментов, тем проще агенту ими пользоваться. Команда KGMON ограничила набор доступных агенту функций до минимума, необходимого для выполнения задачи. В среду были включены:
schema()— для инспекции таблиц;sql(query)— для запросов к базе данных;write_answer(df)— для атомарной записи финального ответа;prose_helper()— для работы с текстовыми документами.
Ключевым элементом здесь стала middleware-прослойка, которая исправляла некорректные вызовы инструментов. Если агент делал ошибку в синтаксисе вызова функции, система не прерывала выполнение, а пыталась исправить запрос. Это предотвращало преждевременное завершение попытки из-за мелкой синтаксической ошибки. Кроме того, использование постоянного состояния Python (stateful Python environment) позволяло агенту сохранять переменные между вызовами инструментов. Это означало, что промежуточные результаты можно было переиспользовать, что экономит ходы и держит модель сфокусированной на анализе, а не на рутинных операциях.
На рисунке изображена архитектура постоянного окружения, которое сохраняет переменные между вызовами инструментов, исправляет некорректные вызовы и записывает ответы через единую вспомогательную функцию. Короткие и валидные попытки оставляют больше ходов для дополнительных запусков, оценки и ансамблирования результатов.
054. Работа с текстовыми документами: изоляция от структурированных данных
Аналитические задачи часто включают PDF-файлы, markdown-документы, политики и отчеты. В этих источниках могут содержаться критически важные пороги, правила, определения и даже табличные данные. Однако большие документы могут быстро заполнить контекстное окно LLM, вытеснив важную информацию о структуре данных. Команда KGMON заблокировала прямой доступ к чтению целых файлов через стандартные методы Python (например, open() или .read()).
Вместо этого они предоставили инструменты, которые ограничивали предварительный просмотр и поиск по регулярным выражениям (regex). Найдя релевантный раздел, агент мог вызвать prose_helper(). Это был кастомный инструмент, который передавал фрагменты документа отдельному вызову LLM с температурой 0 (без креативности) и отключенным рассуждением. Этот вспомогательный LLM возвращал готовые ответы или извлекал таблицы, не загружая сырой текст документа в основной контекст агента.
На рисунке показан рабочий процесс инспекции документов. prose_helper() используется в двух режимах: mode="answer" для извлечения правил или пороговых значений и mode="table" для извлечения повторяющихся записей в SQL-таблицы. Это позволяет агенту применять правила, извлеченные из текста, в SQL-анализе, сохраняя рабочее контекстное окно чистым и сфокусированным.
065. Предобработка видео: вынос вычислений за пределы цикла агента
Некоторые задания KDD Cup включали брифинг-видео. Обработка видео в реальном времени внутри цикла агента потребовала бы огромных вычислительных ресурсов и замедлила бы работу. Команда KGMON вынесла эту задачу за пределы основного цикла. Они извлекали ключевые кадры, транскрибировали аудио, синхронизировали сегменты транскрипта с кадрами и предоставляли эти данные агенту как готовое доказательство.
Каждое задание включало не более одного видео, которое часто содержало ограничения на основе слайдов или отвлекающие значения. Синхронизация транскрипта с ключевыми кадрами позволяла агенту связать устный контекст с правильным визуальным доказательством. Это решение показывает, что для мультимодальных данных предобработка часто эффективнее, чем попытка научить LLM «смотреть» видео в реальном времени.
На рисунке показаны шаги предобработки видео, где ключевые кадры сопоставляются с сегментами транскрипта, чтобы агент мог интерпретировать визуальные доказательства в контексте. Для систем с большим количеством видео лучше использовать инструмент поиска по требованию, аналогичный prose_helper().
076. Трассировка выполнения: ключ к отладке и улучшению
Без детальной логи невозможно создать надежный агент. Каждая попытка в системе KGMON логировала промпты, вызовы инструментов, SQL-запросы, промежуточные результаты, ошибки, исправления, поиск по документам и финальные ответы. Это позволяло использовать специализированного агента-инспектора (или человека) для обзора неудачных траекторий, категоризации ошибок и выявления повторяющихся проблем.
Трассировка показывала, привела ли ошибка к неверному ответу из-за путаницы в схеме, неверного объединения, пропущенного доказательства из текста, проблемы с форматированием вывода или хрупкого правила в промпте. На рисунке ниже показано, как трассировка выполнения выявляет место, где попытка впервые идет не по плану, помогая команде категоризировать повторяющиеся сбои.
087. Оценка и ансамблирование: баланс между надежностью и стоимостью
Команда KGMON улучшила покрытие и надежность за счет многократных попыток и выбора лучшего ответа. Они группировали попытки по значениям ответов, а не по именам колонок, и могли давать дополнительные запуски для спорных задач. Многократные попытки помогали отличить стабильные ответы от случайных ошибок, особенно при оценке по точному значению.
Однако важно помнить, что многократные попытки увеличивают использование токенов, задержку и вычислительные затраты. В производственных системах ансамблирование следует использовать выборочно, только для задач, чья ценность, неопределенность или риск оправдывают эти затраты. Начните с однократной оценки и трассировки, и используйте уверенность, несогласие или сбои валидации как триггеры для дополнительных запусков.
098. Циклы улучшения и роль человека
Автоматические циклы улучшения, где агент использует обратную связь для настройки промптов и инструментов, могут привести к переобучению на бенчмарке. Команда KGMON столкнулась с рисками: жесткое кодирование примеров, накопление противоречивых инструкций и добавление хрупких правил постобработки. Чтобы избежать этого, они требовали наличия выделенных задач, аудита промптов, обзора трассировки и человеческого одобрения перед внедрением изменений.
Человек оставался в центре процесса, определяя требования, проверяя трассировку, направляя поведение агента и отбирая улучшения. Целевое человеческое вмешательство улучшало будущие запуски, не требуя контроля над каждым вызовом инструмента. На рисунке показано, где человеческий обзор вписывается в цикл: люди определяют критерии успеха и проверяют предлагаемые улучшения, в то время как агенты выполняют задачи, проверяют трассировки и генерируют изменения.
10Что это значит на практике
Опыт команды KGMON из KDD Cup 2026 предоставляет четкий рецепт создания надежных AI-агентов для аналитики данных, который можно адаптировать для производственных сред. Вот ключевые выводы:
- Нормализуйте доступ к данным заранее. Не заставляйте агента разбираться с разными форматами файлов. Преобразуйте их в единую базу данных или виртуальный слой запросов.
- Предоставьте агенту узкий набор инструментов. Избегайте избыточности. Один надежный способ выполнить SQL-запрос лучше, чем десять потенциально ошибочных.
- Делайте каждый шаг наблюдаемым. Логируйте все вызовы и промежуточные результаты. Без трассировки вы не сможете отлаживать агентов.
- Оценивайте не только ответы, но и траектории. Понимание того, как агент пришел к ответу, важнее самого ответа для долгосрочного улучшения.
- Используйте многократные попытки выборочно. Не тратьте ресурсы на все задачи. Используйте их для самых сложных или критичных.
- Сохраняйте знания. Извлекайте правила из текста и применяйте их в SQL, чтобы не перегружать контекст.
- Внедряйте улучшения только после валидации. Избегайте переобучения на тестовых данных. Требуйте человеческого одобрения для изменений в логике агента.
Начните с одного повторяющегося аналитического рабочего процесса и постройте наименьшую возможную обвязку, способную его завершить. Определите вопрос и формат ответа. Дайте агенту узкий набор инструментов. Запишите каждый вызов инструмента. Создайте небольшой набор для оценки, включающий как успешные случаи, так и типичные ошибки. Проверьте траектории агента, затем улучшите его инструменты, промпты и проверки. Как только основа станет надежной, добавляйте инспекцию документов, общие знания, проверенные улучшения и выборочную оценку нескольких попыток.
Надежность агента зависит от модели и ее обвязки. Вместе они должны поддерживать анализ, который можно проверить, повторить и использовать. Архитектура KGMON доказывает, что даже с ограниченной моделью можно достичь выдающихся результатов, если правильно спроектировать среду, в которой эта модель работает.
Источник: NVIDIA Developer ↗