Google уничтожил контекстное окно

Миллионные контекстные окна должны были стать чит-кодом для крупных языковых моделей. Продавцы боролись за внимание, рекламируя 128K, 200K, даже 1M-токеновые подсказки, как будто просто увеличенная емкость открыла бы доступ к надежным кодирующим помощникам, автономным агентам и полностью индексируемым базам знаний. На практике все оказалось менее кинематографично: больше токенов зачастую означает просто более медленные, дорогие и по-прежнему запутанные модели.

Последние исследования Google по инженерии контекста опровергают мифы. Компания утверждает, что «применение большего количества токенов к проблеме лишь дает временное решение, но не изменяет форму кривой» в отношении стоимости, задержки и надежности. Вы можете кратковременно опередить сложность, используя окно в 1 миллион токенов, но реальные рабочие нагрузки — результаты RAG, журналы многоагентных систем, выходные данные инструментов и история пользователей — быстро догонят.

Три жестких ограничения постоянно ставят под сомнение стратегию «просто загружайте запрос». Первое — это спираль затрат и задержек: каждые дополнительные 100K токенов увеличивают время вывода и расходы на облачные услуги, часто в 2–3 раза в приложениях с крупномасштабным производством. Второе — «потеря в середине», зафиксированный эффект, когда модели игнорируют важные инструкции, закамуфлированные в перегруженных запросах. Третье — физика: даже окна в миллион токенов переполняются, как только вы начинаете связывать инструменты и агентов на протяжении часов или дней.

Ответ Google заключается не в "2M токенах", а в архитектурном повороте. Вместо того чтобы рассматривать контекст как гигантский изменяемый чат-журнал, компания воспринимает его как собранный обзор над более богатой, со状态ной системой. Сырые данные — сессии, воспоминания, артефакты — выступают в роли исходного кода; пайплайн процессоров компилирует минимальный, специфичный для задачи рабочий контекст для каждого вызова модели.

Этот сдвиг превращает контекст из проблемы буферизации с грубой силой в задачу системного проектирования. Набор инструментов для разработки агентов (ADK) от Google включает это в четырехуровневую структуру: рабочий контекст, сессия, память и артефакты, каждая из которых имеет четкие обязанности и циклы жизни. Контекст перестает быть «тем, что помещается в окно» и становится явным продуктом кода, политик и объемов.

Эта статья подробно описывает, как эта структура на самом деле работает в производственной среде. Используя Набор инструментов для разработки агентов Google (ADK), мы разберем архитектуру контекста, различные объекты контекста и разрешения, а также реального агента для исследования документов, который демонстрирует, почему эра миллиона токенов уже закончилась.

Более крупные окна контекста обещают всеведение, но в основном обеспечивают шок от цен. Каждые дополнительные 100 000 токенов добавляют реальные деньги и секунды, и команды по производству чувствуют это на себе. Блог Google по контекстной инженерии описывает спирали затрат/задержки: больше токенов за вызов, умноженное на тысячи одновременно работающих пользователей, быстро превращает «классную демонстрацию» в «раздутый бюджет».

Задержка возрастает столь же жестоко. Этот миллион токенов в запросе приводит к более медленному декодированию, более длинным цепочкам инструментов и пользовательскому опыту, который теряет черты “ассистента” и превращается в “систему управления задачами”. В многопользовательских настройках каждый вызов агента расширяется до нескольких вызовов модели, так что один раздувшийся контекст заражает всю цепочку.

Затем следует Потерянные в центре. LLMs не обращают равномерного внимания на длинные подсказки; они часто переоценивают начало и конец и тихо игнорируют середину. Блог Google и последующие исследования показывают, что точность снижается, когда ключевые факты находятся в середине длинной последовательности, даже если модель технически «видит» всё.

Представьте себе подсказку агента по производству спустя несколько минут использования. Вверху: свежий вопрос пользователя. Внизу: недавняя ошибка инструмента и инструкция по повторной попытке. Посередине: фактическое ограничение политики или критическая система инструкции. Модель с удовольствием оптимизирует края и уходит от того, что на самом деле имеет значение.

Реальные нагрузки усугубляют ситуацию. Один запрос может включать: - 20–50 фрагментов RAG - 5–10 логов вызовов инструментов - Десятки предыдущих сообщений в чате

Запихните всё это в модель, готовую на 1 миллион токенов, и контекстный окно всё равно задохнется после нескольких насыщенных взаимодействий. Даже демонстрации Google Agent Development Kit (ADK) показывают, как быстро артефакты, память и состояние сессии будут разрастаться, если вы наивно заливать всё в запрос.

Жесткие физические ограничения завершают работу. Длина контекста растёт саблинейно в зависимости от вычислительных мощностей и объёма памяти; переход от 128K к 1M токенов уже требует экзотической инфраструктуры. Если идти ещё выше, вы столкнётесь с ограничениями GPU RAM, пропускной способностью и стабильностью обучения, а не только с умным дизайном подсказок.

Это не лабораторные курьезы. Это причины, по которым производственные команды молча ограничивают историю, сокращают результаты RAG и агрессивно обобщают. Пока контекст не прекратит быть сырым потоком и не станет собранным представлением, крупные агенты продолжат тонуть в своих собственных данных.

Новая идея компилятора контекста от Google разрушает устаревшую ментальную модель контекстного окна как бесконечного чата. Вместо изменяемого потока данных контекст становится собранным представлением гораздо более богатого состояния: сессий, воспоминаний и артефактов, которые существуют за пределами любого отдельного запроса. Каждый вызов модели видит только тщательно сформированный срез, а не всю соломинку.

Думайте как инженер-компилятор, а не как настройщик промтов. Исходные данные взаимодействия становятся исходным кодом; цепочка процессоров выступает в роли компилятора; финальный промт, отправляемый в Gemini, является оптимизированным исполняемым файлом. В блоге Google, Проектирование эффективной контекстуально-осведомленной многоагентной системы для производства, это четко обозначается как жесткое требование для агентов масштаба производства, а не как нечто необязательное.

В рамках этой модели работа разработчика переходит от вопроса «как сформулировать этот запрос?» к вопросу «как построить конвейер, который создает контекст?». Вы проектируете, как сеансы хранят структурированные события, как воспоминания кодируют долгосрочные знания и как артефакты, такие как PDF или CSV, ссылаются по ID, а не загружаются в окно. Вы прекращаете ручное создание мегазапросов и начинаете определять потоки, процессоры и области применения.

Google Agent Development Kit (ADK) включает это в свои API. Он предоставляет различные контекстные слои — рабочий контекст, сессия, память, артефакты — и заставляет вас связывать их вместе через явные процессоры и префиксы состояния, такие как `app`, `user` и `temp`. Эта сепарация хранения от представления означает, что вы можете регистрировать тысячи событий, одновременно создавая лаконичный, целенаправленный запрос менее 5 000 токенов.

Власть исходит от по умолчанию ограниченного объема. Каждое обращение к модели получает только необходимый минимум контекста для выполнения своей задачи, собранный в нужный момент компилятором. Если агенту нужна дополнительная информация, он вызывает инструменты для получения артефактов или запросов в памяти, вместо того чтобы загружать все заранее "на всякий случай".

Этот подход, основанный на собранном контексте, решает все три проблемы сразу. Количество токенов сокращается, поэтому затраты и задержка также уменьшаются. "Потерянное в середине" сокращается, потому что середина в основном исчезает — нерелевантная история никогда не попадает в рабочий контекст. Ограничения физического контекста перестают быть жестким потолком и становятся бюджетом оптимизации, который вы контролируете с помощью кода.

Контекстная инженерия начинается с четкого разделения между тем, где хранятся данные, и тем, как модель их воспринимает. Набор инструментов для разработки агентов (ADK) Google закладывает это в свой первый принцип: разделять хранение и представление. Это может звучать абстрактно, но это разница между системой, которую можно развивать, и той, которая обрушивается под собственным весом.

ADK проводит четкую границу между Сессией и Рабочим Контекстом. Сессия выступает в роли постоянного, авторитетного реестра: каждое сообщение пользователя, вызов инструмента, результат инструмента и событие системы попадают сюда в виде структурированного состояния. Рабочий Контекст — это временный снимок, созданный для одного вызова LLM, который затем удаляется.

Думайте о Сессии как о вашей базе данных, а о Рабочем Контексте как о результатах SQL-запроса. Вы никогда не изменяете базу данных, чтобы соответствовать каждому запросу; вы изменяете запрос. Тот же принцип здесь: вы сохраняете полную, только добавляемую Сессию и создаете различные Рабочие Контексты на основе нее в зависимости от задачи, модели или бюджета задержки.

Это разделение становится критически важным в момент, когда ваш продукт изменяется. Хотите заменить Gemini 3 Pro на более компактную модель или перейти с многословного чата на лаконичную команду для выполнения задач? Вы обновляете процессоры, которые формируют Рабочий Контекст, а не схему Сессии или исторические данные. Прошлые взаимодействия остаются неизменными, даже когда вы кардинально меняете способ их представления модели.

Документация Google Agent Development Kit (ADK) формализует это с помощью отдельных объектов контекста и префиксов состояния. Состояние, поддерживаемое сессией, находится под устойчивыми префиксами, такими как `app` и `user`, в то время как эпhemerные данные, относящиеся только к вызову, находятся под `temp`. Только Рабочий Контекст читает между этими пространствами имен и компилирует минимальный обзор для текущего вызова.

Практическое воздействие быстро проявляется в многогентных системах. Один агент может видеть Рабочий Контекст только с последними 3 репликами пользователя и кратким описанием инструмента; другой может получить сводку из 200 сообщений Сессии с отметками RAG. Оба выводятся из одной и той же основной записи, но каждый запрос оплачивает только те токены, которые ему действительно нужны.

Окна контекста раньше увеличивались за счет конкатенации строк: сообщение пользователя, ответ агента, вывод инструмента, повторяйте до тех пор, пока стоимость не взлетит. Google Agent Development Kit (ADK) устраняет это и заменяет на Явные Трансформации: названный, упорядоченный конвейер, который компилирует сырое состояние в рабочий запрос. Контекст перестает быть комком текста и становится артефактом сборки.

Вместо `prompt = history + docs + tools` вы определяете процессоры, такие как `summarize_session`, `select_relevant_artifacts`, `inject_instructions` и `budget_tokens`. Каждый этап имеет свое название, контракт и место в пайплайне. Вы можете фиксировать каждую стадию, сравнивать результаты между запусками и менять процессоры, не трогая остальную часть системы.

Блог Google по контексту и документы ADK описывают это как поток процессоров, которые преобразуют четыре уровня состояния: сессия, память, артефакты и рабочий контекст. Исследовательский агент документа, например, может: - Извлечь предыдущие решения из памяти - Оценить кандидатные PDF-документы из артефактов - Сжать цитаты в краткое резюме на 2000 токенов - Выдать минимальный запрос для Gemini 3 Pro

Поскольку процессоры явные, команды могут проводить юнит-тесты. Вы можете утверждать, что `select_relevant_artifacts` никогда не выбирает больше 5 документов, или что `summarize_session` остается ниже 1,000 токенов. Отладка перестает быть вопросом «почему модель выдала ошибочные данные?» и становится вопросом «какой процессор внедрил неправильные данные?».

По умолчанию ограниченный решает другую половину проблемы: кто что видит. Вместо того чтобы сбрасывать весь многопользовательский транскрипт в каждый вызов инструмента, ADK передает минимальный, специфичный для роли контекст через типизированные контекстные объекты. Инструменты, обработчики обратных вызовов и поставщики инструкций получают ограниченный обзор.

Функции инструмента получают ToolContext, который может читать и записывать состояние сессии, сохранять или загружать артефакты и осуществлять поиск в памяти. Обработчики обратных вызовов получают CallbackContext с состоянием и артефактами, но без поиска в памяти, что предотвращает хаос от побочных каналов. Поставщики инструкций видят только контекст только для чтения, поэтому они не могут тайно изменять состояние при генерации системных подсказок.

Контекст с ограниченной областью преобразует многопользовательские системы в AI-конвейер. На одном этапе анализируются артефакты и создается структурированный обзор; на следующем, с более узким фокусом, этот обзор превращается в текст, ориентированный на пользователя; на третьем этапе результаты записываются в память. Ни один отдельный агент не хранит всю историю в 50 000 токенов.

Совместно Эксплицитные Трансформации и Scoped by Default создают предсказуемые контекстные потоки под нагрузкой. Вы точно знаете, какие процессоры запускаются, к какому состоянию они могут обращаться и сколько токенов они генерируют. Эта дисциплина делает модель на миллион токенов необязательной вместо обязательной.

Агенты с учетом контекста в Google Agent Development Kit (ADK) работают на четырехуровневом стеке, который рассматривает контекст как продукт, а не как побочный эффект. Каждый уровень отвечает на разные вопросы: что модель видит сейчас, что на самом деле произошло, что должно сохраняться и где находятся тяжелые ресурсы.

На вершине находится рабочий контекст. Это временная нагрузка, которую ADK компилирует и отправляет в Gemini для одного вызова модели: выбранные сообщения, выводы инструментов, фрагменты из памяти и несколько ссылок на артефакты. ADK немедленно отбрасывает его после вызова, поэтому ничего в рабочем контексте не является авторитетным само по себе.

Под этим находится сессия, длительный, канонический лог взаимодействия. Каждое сообщение пользователя, ответ модели, вызов инструмента и результат инструмента попадают сюда в виде структурированного объекта события, а не плоского транскрипта. Когда ADK восстанавливает рабочий контекст, он запрашивает эту временную шкалу сессии и применяет процессоры, которые фильтруют, обобщают или повторно организуют события для текущей задачи.

Долговечные знания переходят в память. Память хранит предпочтения пользователей (тон общения, языки, привычки по уведомлениям), долговечные факты (политики компании, характеристики продуктов) и итоговые решения, которые должны пережить любой отдельный чат. ADK предоставляет это через API поиска по памяти, так что агент может извлечь только 3–10 значимых элементов вместо того, чтобы воспроизводить 10,000 токенов истории.

Артефакты решают проблему «огромного файла в запросе». Артефакты — это большие бинарные или текстовые объекты — PDF, CSV, изображения, аудиофайлы — которые хранятся один раз и идентифицируются стабильными именами или идентификаторами, а не вставляются в запрос. Инструменты считывают и записывают артефакты, а рабочий контекст содержит только легковесные ссылки и извлеченные фрагменты при необходимости.

Вместе эти четыре слоя формируют контекстный конвейер, а не монолит. Агент документальных исследований, например, может: прочитать сессию, чтобы найти последний вопрос пользователя, исследовать память на наличие предыдущих решений, загрузить артефакт PDF по ID, а затем составить рабочий контекст только с несколькими релевантными абзацами и цитатами. Стоимость и задержка зависят от этого собранного фрагмента, а не от сыроого корпуса.

Собственные рекомендации Google призывают команды рассматривать эти уровни как первоклассные дизайнерские поверхности. Документация по контексту ADK разъясняет, как рабочий контекст, сессии, память и артефакты сопоставляются с конкретными типами, разрешениями и процессорами, чтобы многоагентные системы оставались быстрыми, дешевыми и стабильными по мере роста нагрузки.

Система состояния создает у ИИ ощущение стойкости, а не кратковременной памяти, и пакет разработки агентов Google (ADK) напрямую встраивает это в свой контекстный API с обманчиво простым префиксным системой. Вместо того чтобы передавать агентам одну нечеткую массу «памяти», ADK распределяет состояние на пространства имен temp:, user: и app:, которые четко соответствуют тому, как на самом деле работает реальное программное обеспечение.

temp: Начните с temp:, черновика. Всё, что вы напишете под `temp:`, существует только для одной сессии, а затем исчезает. Один инструмент может сохранить разобранный CSV под `temp:parsed_doc`, другой инструмент может прочитать его через 200 мс, и как только агент ответит, ADK стирает его — нет риска загрязнения долгосрочной истории промежуточным мусором.

Повышая уровень, пользователь: становится настоящей памятью агента о человеке. Ключи, такие как `user:reading_level`, `user:last_projects` или `user:blocked_sources`, сохраняются между сессиями, при условии, что вы подключаете ADK к хранилищу данных. Исследовательский ассистент, встроенный в демо-версию, может запомнить, какие статьи пользователь уже резюмировал на прошлой неделе, и избегать повторного запроса или повторного объяснения.

На вершине находится app:, глобальное состояние для всей развертки. Здесь хранятся флажки функций (`app:enable_vision`), системные ограничения по количеству запросов и ссылки на общий индекс эмбеддингов. Каждое экземпляр агента и каждый пользователь могут читать эти значения, так что вы можете изменить конфигурацию один раз и наблюдать, как поведение меняется в сотнях параллельных сессий.

Вместе эти три префикса предоставляют вам конкретную иерархию состояний без необходимости изобретать собственную структуру. Вы получаете: - temp: для проводки между инструментами на каждом этапе - user: для памяти по каждому идентификатору - app: для настройки между пользователями

Эта иерархия напрямую отражает принципы дизайна ADK. Отделение хранения от представления: состояние находится под `temp:`, `user:` или `app:`, в то время как рабочий контекст представляет собой скомпилированный срез этих ключей. Явные преобразования: инструменты и процессоры читают и записывают определённые префиксы вместо того, чтобы изменять огромный запрос. По умолчанию с ограниченной областью действия: `temp:` никогда не уходит за пределы одного хода, `user:` никогда случайно не становится глобальным, а `app:` никогда незаметно не превращается в поведение, специфичное для пользователя.

Google Agent Development Kit (ADK) превращает всю эту теорию контекста в работающий исследовательский бот. Демонстрация Yeyu Lab создает документального ассистента, который может искать, открывать и анализировать файлы, не загружая целые PDF в запрос. Вместо этого он компилирует достаточно контекста для каждого вызова Gemini 1.5 или Gemini 2.0.

Суть дизайна заключается в парадигме загрузки по запросу. Инструмент `list_documents` возвращает только легковесные метаданные: идентификаторы документов, заголовки, возможно, размеры в байтах и временные метки. Модель видит компактную таблицу опций, а не 200 страниц необработанного текста.

Когда пользователь выбирает что-то вроде «проанализировать квартальный отчет», агент вызывает `analyze_document`. Этот инструмент извлекает полный файл из хранилища артефактов, выполняет разбиение на части или суммирование, и только затем предоставляет полученные результаты модели. Большая языковая модель никогда не получает оригинальный документ в исходном виде; она получает только обработанные фрагменты, которые запросила.

Инструменты координируют работу через `temp:` состояние вместо передачи данных по сети. `list_documents` записывает `temp.current_doc_id = "report_q2_2024"`; `analyze_document` считывает тот же ключ и точно знает, какой артефакт загрузить. Никаких base64 блобов, никаких JSON размером в 50,000 токенов, скачущих между инструментами.

Этот `temp:` контекст существует только для одного вызова, что позволяет сохранить рабочий контекст минимальным. Типичный этап может включать в себя запрос от пользователя, короткий системный запрос, компактный список документов и одну строку `current_doc_id`, при этом оставаясь насыщенным многоэтапным процессом. Набор инструментов для разработки агентов Google (ADK) занимается внутренними процессами, позволяя модели сосредоточиться на рассуждениях.

Долгосрочное поведение зависит от состояния `user:`. Когда кто-то говорит: «Я предпочитаю краткие резюме», инструмент или обратный вызов записывает `user.summary_style = "brief"`. Будущие вызовы — завтра, на следующей неделе, на другом устройстве — могут прочитать этот ключ и автоматически выдавать краткие аннотации из 3 предложений вместо подробных разбора на 3 страницы.

Предпочтения могут накапливаться без увеличения объёма подсказок. Вы можете отслеживать: - `user.domain_focus = "финансы"` - `user.citation_format = "APA"` - `user.summary_style = "краткий"`

Каждое вызов компилирует только соответствующий подмножество в рабочий контекст. Никто не просматривает 200-туровую запись чата просто чтобы вспомнить, что пользователю не нравятся маркированные списки.

Интеллект этого агента основан на эффективном использовании инструментов, а не на огромном контексте. Модель делает точные вызовы инструментов, перемещается через состояние `temp:` и `user:`, и взаимодействует с артефактами только при необходимости. Набор инструментов для разработки агентов Google (ADK) эффективно убивает идею о том, что вам нужно пересчитывать всю свою историю каждый раз, просто чтобы выглядеть умным.

Проектирование подсказок когда-то означало умелые заклинания и хрупкие хаки. Инженерия контекста, как это описано в блоге Google о контексте и в комплексе инструментов для разработки агентов Google (ADK), преобразует эту роль во что-то более близкое к архитектуре распределенных систем для языковых моделей.

Вместо того чтобы одержимо сосредотачиваться на одном мега-промте, разработчики теперь создают конвейеры: как сессии, состояние, память и артефакты проходят через процессоры в скомпилированный рабочий контекст. Четырехуровневая структура ADK — рабочий контекст, журнал сессий, долгосрочная память и внешние артефакты — превращает вопрос «что в промте?» в «какая система создала этот вывод и почему?»

Этот сдвиг свидетельствует о явной зрелости развития ИИ. Вы определяете: - Где находятся данные - Какие преобразования выполняются и когда - Какой агент или инструмент видит какой охват

Результат: поведение перестает казаться волшебным и начинает восприниматься как подлежащее отладке.

Надежность возрастает, потому что каждый контекстный срез имеет явный рецепт. Если агент начинает фантазировать, вы проверяете процессоры и префиксы, которые сформировали его восприятие, а не 40,000-токенную массу. Префиксы состояния ADK (`app`, `user`, `temp`) и ограниченные контексты (инструмент, коллбек, вызов) предоставляют вам рычаги для воспроизведения ошибок, написания тестов и анализа режимов отказа.

Предсказуемость улучшается, потому что агенты больше не загружают целые истории. Они запрашивают артефакты по ID, ищут информацию в памяти с помощью контролируемых запросов и записывают в ограниченные сегменты состояния. Затраты также сокращаются: вы передаете только минимальный скомпилированный контекст за вызов вместо того, чтобы воспроизводить недели журналов в окно на миллион токенов.

Для команд, нацеленных на производство, это выглядит как черновик для многоагентных бэкендов. Один агент занимается оркестрацией, специализированные агенты владеют инструментами и памятью, а контекстная структура ADK гарантирует, что каждый вызов получает ровно столько информации, сколько нужно. Документация Google, включая Введение в разговорный контекст: сессия, состояние и память, читается меньше как советы по запросам и больше как руководство по проектированию API.

Контекстная инженерия, реализованная в наборе инструментов разработки агентов Google (ADK), превращает приложения на основе LLM в системы, которые вы проектируете, а не в заклинания, которые вы настраиваете. Это предварительное условие для серьезных, регулируемых развертываний с множеством агентов.

Готовы попробовать это на практике? Начните с установки Google Agent Development Kit (ADK), получите ключ API Gemini и прочитайте объяснение по контекстному инжинирингу в блоге Google Developers: Архитектура эффективной контекстно-зависимой многопользовательской системы для производства. В этом посте определены четыре уровня — рабочий контекст, сессия, память, артефакты — и три принципа, которые должен отражать ваш код.

Далее перейдите прямо к официальной документации по контексту ADK на google.github.io/adk-docs/context. Сосредоточьтесь на том, как `InvocationContext`, `ToolContext` и `CallbackContext` контролируют доступ к сессии, памяти и артефактам, а также на том, как префиксы `app:`, `user:` и `temp:` реализуют ограниченное состояние. Рассматривайте эти API как границу вашей системы, а не просто как вспомогательные классы.

Затем загрузите демо Yeyu Lab с GitHub: context_demo. Запустите помощника по документам, наблюдайте, как артефакты сохраняются и ссылаются на них по идентификатору, а не встраиваются в подсказки, и проследите, как инструменты читают/записывают состояние через префиксы, а не прячут данные в свободно формированном тексте. Это ваша эталонная реализация для Контекстно-осведомленного многопользовательского рабочего процесса.

Для первого проекта рефакторьте существующее приложение RAG, чтобы оно соответствовало этому шаблону. Замените вашу логику «всё засовывать в подсказку» на:

• 1Журнал сеансов структурированных событий
• 2Хранение артефактов для PDF, CSV и длинных документов
• 3Поиск по памяти вместо повторной отправки одних и тех же фактов
• 4состояние `temp:` для передачи промежуточных результатов между инструментами

Вы уже не просто настраиваете запросы; вы проектируете распределенные системы, которые общаются на естественном языке. Разработчики, которые воспринимают контекст как скомпилированный взгляд — и которые строят архитектуру вокруг состояния, артефактов и явных преобразований — будут теми, кто будет поставлять готовый к продакшну ИИ, пока все остальные продолжают гоняться за более широким окном контекста.

Что такое контекстная инженерия?

Контекстная инженерия — это новая архитектурная концепция от Google для ИИ-агентов. Она рассматривает контекст не как один поток текста, а как "собранный вид", созданный из различных источников данных, таких как история сессий, память и внешние файлы, оптимизированный для каждого конкретного вызова модели.

Почему большие контекстные окна представляют собой проблему для ИИ-агентов?

Хотя большие окна контекста кажутся мощными, они приводят к спирали высоких затрат и медленной задержки. Кроме того, они страдают от проблемы «потерянных в середине», когда модели испытывают трудности с нахождением релевантной информации в море шума, что в конечном итоге ограничивает масштабируемость и надежность.

Как Google реализует эти идеи в своем Наборе инструментов для разработки агентов (ADK)?

ADK предоставляет структуру с встроенными примитивами для Инженерии Контекста. Она отделяет постоянное хранилище (Сессия, Память, Артефакты) от временного 'Рабочего Контекста', отправляемого в LLM, используя инструменты и управление состоянием для загрузки только необходимого, когда это необходимо.

Заменяет ли Контекстная Инженерия Генерацию, Упрощённую ВRetrieval (RAG)?

Это дополняет и уточняет его. RAG касается извлечения данных; Инженерия контекста касается того, как эти извлеченные данные (и весь другой контекст) структурированы, управляются и представлены модели. Это обеспечивает более надежную и масштабируемую систему для рабочих процессов в стиле RAG.