Ваши AI-агенты работают лишь с 15% нужной им информации
Сейчас почти каждый разговор о бюджете на корпоративный ИИ идет по одному сценарию. Согласуют крупную сумму — $10 млн, $20 млн и больше, строят агентную инфраструктуру, а затем руководство ждет обещанного роста производительности. Вместо этого компании получают нечто более неприятное: реальные возможности и реальный потенциал, но результаты, которые кажутся неровными, хрупкими и хуже поддающимися доверию, чем ожидалось.
Первый инстинкт — обвинить модель. Но модель редко является проблемой.
Проблема в том, что архитектура под моделью изначально не была рассчитана на задачи, которые предприятия действительно хотят решать, и большинство организаций понимают это только тогда, когда уже глубоко ушли в развертывание. Есть и вторая проблема, скрытая под первой: большая часть этой агентной инфраструктуры работает на данных, которыми предприятие не полностью управляет.
Математика context window, которую никто не делает
Когда AI-агент обрабатывает запрос, он работает в ограниченном пространстве, которое называется context window. Все, что модели нужно для рассуждения, поиска и ответа, должно поместиться в это пространство. То, как распределяется это пространство, оказывается самым важным архитектурным решением в корпоративном ИИ, и большинство организаций оставили его на настройках по умолчанию.
«Если посмотреть на структуру того, что агенты фактически используют при всей этой емкости: 25% уходят на правила и ограничения, 30% — на накладные расходы оркестрации и еще 30% — на фрагменты RAG, которые являются вероятностными предположениями, — и это оставляет 15% на вашу предметную область».
Перечитайте это еще раз: в типичном корпоративном агентном развертывании примерно 85% рабочей емкости агента расходуется еще до того, как в кадр попадают реальные знания бизнеса.
Именно в этих 15% происходит рассуждение. Именно за них вы платите.
Почему retrieval недостаточно
Доминирующий способ дать агентам доступ к корпоративным знаниям — retrieval-augmented generation, или RAG. Модель не хранит всю информацию у себя; вместо этого она извлекает релевантные фрагменты в момент inference на основе семантического сходства с запросом.
RAG — это действительно важный шаг вперед, и он хорошо работает для вопросов, основанных на шаблонах, где ответ «достаточно близко» приемлем. Но корпоративные решения — в клинической разработке, цепочках поставок, финансовом моделировании, соблюдении нормативных требований — редко касаются вопросов, где достаточно просто приблизиться к правильному ответу.
Глубинная проблема структурная. От RAG требуют поддерживать детерминированное рассуждение, хотя сам он является вероятностной системой. Как говорит Yarmoluk, «можно сказать, что еще больше сопоставления шаблонов на системах сопоставления шаблонов не решит проблему галлюцинаций или дрейфа».
Когда команда сначала считает агентов впечатляющими, а потом начинает им не доверять, причина обычно именно в этом. Модель способна. Но информация, на основе которой она рассуждает, — лишь вероятностное приближение того, что ей действительно следовало бы знать.
Архитектурный сдвиг: интеллект на уровне данных
Решение — не в большем context window, хотя это и помогает на краях. Не в лучшем prompting, хотя это тоже важно. Решение — в том, чтобы приблизить предметные знания к месту, где реально происходит inference, — подавать их из operational data layer, а не реконструировать на этапе запроса. Этот слой данных должен быть таким, которым предприятие владеет, управляет и который может аудировать. Sovereignty — это не галочка для compliance, а архитектурное требование.
Yarmoluk разрабатывает подход, в котором корпоративные знания рассматриваются как структурированный артефакт, который нужно сжать и оптимизировать для машинного рассуждения, а не как корпус для поиска. Представьте, что книга на 63 000 слов была сжата в структурированный файл знаний размером 20 килобайт: настолько маленький, что почти не занимает место в context window, и настолько точный, что модель рассуждает на его основе, а не извлекает обходными путями.
«Теперь ей не нужно говорить обо всех слоях, о которых вы уже говорили, — объясняет Yarmoluk. — Это тот путь, по которому пойдет агент или запрос… Мы хотим использовать “мышцы” для правильных задач».
Именно на этом архитектурном принципе построен EDB Postgres®AI (EDB PG AI). Агентам, которые работают из operational data layer, где фактически живет system of record, не нужно угадывать предметный контекст. Они рассуждают на его основе напрямую. Слой данных становится слоем интеллекта. А поскольку этот слой sovereign — работает под управлением организации, на контролируемой ею инфраструктуре, — рассуждение можно аудировать, выводы становятся защищаемыми, а риск — управляемым.
Надежность агентов — это проблема архитектуры данных, которую можно решать уже сейчас, опираясь на инфраструктурные решения, которые организации принимают сегодня.
Три вопроса, которые CIO стоит задать командам в этом квартале
Если вы отвечаете за развертывание корпоративного ИИ, эффективность использования context window и data sovereignty заслуживают обсуждения на уровне совета директоров.
1. Какой процент нашего context window доходит до предметных знаний? Если ваша архитектурная команда не может ответить на этот вопрос конкретной цифрой, вы не управляете самым важным AI-ресурсом. Зафиксируйте базовый уровень до того, как расширять context window или добавлять новых агентов.
2. Доступен ли наш operational data layer агенту напрямую, или мы подаем копии? Есть существенная разница между агентом, который рассуждает на основе живого system of record, и тем, который извлекает данные из vector index, построенного на этом system of record. Первый вариант архитектурно корректен. Второй находится на два шага дальше от ground truth.
3. Измеряем ли мы стоимость inference на одно решение или только расход токенов? Расход токенов — неправильная цель оптимизации. Правильный показатель — то, что Yarmoluk называет «cost before tokens». Сколько стоило получить inference, которое действительно было полезным? Агент, который тратит больше токенов, чтобы прийти к уверенно точному ответу, может быть экономичнее, чем тот, кто тратит меньше токенов, но выдает результат, требующий ручной проверки.
Обещание enterprise AI реально. Реальна и разница между тем, что организации построили, и тем, что им нужно. Преимущество получат те, кто будет считать управляемой переменной не capability модели, а context efficiency. А первыми придут те организации, которые рассматривали data sovereignty не как юридическое требование, а как архитектурное преимущество, на котором можно строить систему.
Материал — перевод статьи с английского.
Оригинал: Your AI agents are operating on 15% of the information they need