Удержание ИИ-агентов на поверхности: Стратегии контекстной инженерии, предотвращающие гниение контекста с помощью Milvus

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

Это не модель "устает" - это гниение контекста. По мере развития беседы модель вынуждена жонглировать большим количеством информации, и ее способность расставлять приоритеты постепенно снижается. Исследования Antropic показывают, что при расширении контекстных окон с 8 до 128 тысяч лексем точность поиска может упасть на 15-30 %. У модели все еще есть место, но она теряет представление о том, что важно. Большие контекстные окна помогают отсрочить проблему, но не устранить ее.

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

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

В этом блоге мы рассмотрим, как происходит ротация контекста, какие стратегии используют команды для борьбы с ней, а также архитектурные паттерны - от поиска до разработки подсказок - которые позволяют агентам ИИ сохранять четкость в длительных многоэтапных рабочих процессах.

Почему происходит гниение контекста

Люди часто полагают, что если дать модели ИИ больше контекста, то это естественным образом приведет к лучшим ответам. Но на самом деле это не так. Люди тоже с трудом справляются с длинными данными: по данным когнитивной науки, наша рабочая память вмещает примерно 7±2 фрагментов информации. Если превысить этот показатель, мы начинаем забывать, размывать или неверно интерпретировать детали.

LLM демонстрируют схожее поведение - только в гораздо больших масштабах и с более драматичными режимами отказа.

Корень проблемы кроется в самой архитектуре трансформера. Каждый маркер должен сравнивать себя с каждым другим маркером, формируя парное внимание по всей последовательности. Это означает, что вычисления растут O(n²) с длиной контекста. Расширение подсказки с 1 тыс. токенов до 100 тыс. не заставляет модель "работать усерднее" - оно умножает количество взаимодействий с токенами на 10 000×.

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

Несмотря на эти ограничения, длинный контекст теперь неизбежен. Ранние приложения LLM были в основном однооборотными задачами - классификацией, обобщением или простой генерацией. Сегодня более 70 % корпоративных систем ИИ используют агентов, которые остаются активными в течение многих раундов взаимодействия, часто часами, управляя разветвленными, многоступенчатыми рабочими процессами. Долгоживущие сессии перешли из разряда исключений в разряд стандартных.

Тогда возникает следующий вопрос: как удержать внимание модели, не перегружая ее?

Контекстно-поисковые подходы к решению проблемы контекстной гнили

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

1. Поиск "точно в срок": Сокращение ненужного контекста

Одной из основных причин гниения контекста является перегрузка модели информацией, которая ей пока не нужна. Claude Code-Anthropic - помощник по кодированию - решает эту проблему с помощью Just-in-Time (JIT) retrieval- стратегии, при которой модель получает информацию только тогда, когда она становится актуальной.

Вместо того чтобы запихивать в свой контекст целые кодовые базы или наборы данных (что значительно увеличивает вероятность дрейфа и забывания), Claude Code ведет крошечный индекс: пути к файлам, команды и ссылки на документацию. Когда модели нужен какой-то фрагмент информации, она извлекает его и вставляет в контекст в тот момент, когда это важно - нераньше.

Например, если вы попросите Claude Code проанализировать базу данных объемом 10 ГБ, он никогда не попытается загрузить ее целиком. Он работает скорее как инженер:

1. Выполняет SQL-запрос, чтобы получить высокоуровневые сводки набора данных.

2. Использует такие команды, как head и tail, чтобы просмотреть примеры данных и понять их структуру.

3. Сохраняет в контексте только самую важную информацию - например, ключевые статистические данные или строки выборки.

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

2. Предварительный поиск (векторный поиск): Предотвращение дрейфа контекста до того, как он начался

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

Контекстная гниль часто происходит потому, что модели передают большую кучу необработанного текста и ожидают, что она сама отберет то, что важно. Предварительный поиск меняет ситуацию: векторная база данных (например, Milvus и Zilliz Cloud) определяет наиболее релевантные фрагменты перед выводом, гарантируя, что только ценный контекст попадет в модель.

В типичной системе RAG:

• Документы встраиваются и хранятся в векторной базе данных, такой как Milvus.

• Во время запроса система извлекает небольшой набор высоко релевантных фрагментов путем поиска по сходству.

• Только эти фрагменты попадают в контекст модели.

Это предотвращает гниение двумя способами:

• Уменьшение шума: нерелевантный или слабо связанный текст никогда не попадает в контекст.

• Эффективность: модели обрабатывают гораздо меньше лексем, что снижает вероятность упустить важные детали.

Milvus может искать миллионы документов за миллисекунды, что делает этот подход идеальным для живых систем, где задержка имеет значение.

3. Гибридный JIT и векторный поиск

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

• Своевременность: Если база знаний обновляется быстрее, чем перестраивается векторный индекс, модель может опираться на устаревшую информацию.

• Точность: до начала выполнения задачи трудно точно предсказать, что понадобится модели, особенно в многоэтапных или исследовательских рабочих процессах.

Поэтому в реальных рабочих нагрузках оптимальным решением является гибридная система.

• Векторный поиск стабильных, высокодостоверных знаний

• JIT-исследование на основе агентов для информации, которая меняется или становится актуальной только в середине задачи.

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

Давайте посмотрим, как это работает в реальной системе. Возьмем, к примеру, помощника по работе с производственной документацией. Большинство команд в конечном итоге останавливаются на двухступенчатом конвейере: векторный поиск на базе Milvus + JIT-поиск на базе агентов.

1. Векторный поиск с использованием Milvus (предварительное извлечение)

• Преобразуйте документацию, ссылки на API, журналы изменений и известные проблемы во вкрапления.

• Храните их в базе данных Milvus Vector Database с такими метаданными, как область продукта, версия и время обновления.

• Когда пользователь задает вопрос, запустите семантический поиск, чтобы получить топ-K релевантных сегментов.

Это позволяет решить около 80 % рутинных запросов менее чем за 500 мс, обеспечивая модель сильной, устойчивой к контексту отправной точкой.

2. Исследование на основе агентов

Когда первоначального поиска недостаточно - например, когда пользователь запрашивает что-то очень специфическое или чувствительное ко времени - агент может обратиться к инструментам для получения новой информации:

• Используйте search_code для поиска определенных функций или файлов в кодовой базе.

• Используйте run_query для получения данных из базы данных в режиме реального времени

• Используйте fetch_api для получения последней информации о состоянии системы.

Эти вызовы обычно занимают 3-5 секунд, но они гарантируют, что модель всегда работает со свежими, точными и актуальными данными - даже для вопросов, которые система не могла предугадать заранее.

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

Milvus особенно эффективен в этих гибридных сценариях, поскольку поддерживает:

• Векторный поиск + скалярная фильтрация, сочетающая семантическую релевантность со структурированными ограничениями

• Инкрементные обновления, позволяющие обновлять вкрапления без простоев.

Это делает Milvus идеальной основой для систем, которым требуется как семантическое понимание, так и точный контроль над получаемыми данными.

Например, вы можете выполнить такой запрос:

# You can combine queries like this in Milvus
collection.search(
    data=[query_embedding],  # Semantic similarity
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    expr="doc_type == 'API' and update_time > '2025-01-01'",  # Structured filtering
    limit=5
)

Как выбрать правильный подход для работы с контекстным ротором

Поскольку существуют векторно-поисковый предварительный поиск, поиск "точно в срок" и гибридный поиск, возникает естественный вопрос: какой из них следует использовать?

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

1. Векторный поиск → Лучше всего подходит для стабильных областей.

Если домен меняется медленно, но требует точности - финансы, юридическая работа, соответствие нормативным требованиям, медицинская документация, - то база знаний на базе Milvus с предварительным поиском обычно подходит.

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

Предсказуемые задачи + стабильные знания → предварительный поиск.

2. Поиск "точно в срок" → Лучше всего подходит для динамичных, исследовательских рабочих процессов.

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

Непредсказуемые задачи + быстро меняющиеся знания → поиск "точно в срок".

3. Гибридный подход → Когда оба условия верны

Многие реальные системы не являются ни чисто стабильными, ни чисто динамичными. Например, документация разработчика меняется медленно, в то время как состояние производственной среды меняется минута за минутой. Гибридный подход позволяет вам:

• Загружать известные, стабильные знания с помощью векторного поиска (быстро, с малым временем ожидания).

• Получать динамическую информацию с помощью агентских инструментов по запросу (точная, актуальная).

Смешанные знания + смешанная структура задач → гибридный подход к поиску.

Что делать, если контекстного окна все еще недостаточно

Контекстная инженерия помогает снизить перегрузку, но иногда проблема более фундаментальна: задача просто не помещается, даже при тщательной обрезке.

Некоторые рабочие процессы, такие как миграция большой кодовой базы, обзор архитектур с несколькими хранилищами или создание отчетов о глубоких исследованиях, могут превысить 200K+ контекстных окон, прежде чем модель достигнет конца задачи. Даже если векторный поиск выполняет большую работу, некоторые задачи требуют более постоянной, структурированной памяти.

Недавно Anthropic предложил три практические стратегии.

1. Сжатие: Сохранить сигнал, отбросить шум

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

• Ключевые решения

• Ограничения и требования

• Остающиеся вопросы

• Соответствующие образцы или примеры

И удаляет:

• Многословные выходные данные инструмента

• Нерелевантные журналы

• лишние шаги

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

2. Структурированное ведение заметок: Перемещение стабильной информации за пределы контекста

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

Например, прототип покемона-агента Клода хранит такие долговременные факты, как:

• Pikachu leveled up to 8

• Trained 1234 steps on Route 1

• Goal: reach level 10

Между тем, преходящие детали - журналы сражений, длинные результаты работы инструментов - остаются вне активного контекста. Это отражает то, как люди используют блокноты: мы не храним каждую деталь в рабочей памяти; мы храним опорные точки снаружи и просматриваем их, когда это необходимо.

Структурированное ведение заметок предотвращает размывание контекста, вызванное повторением ненужных деталей, и в то же время дает модели надежный источник истины.

3. Субагентная архитектура: Разделяй и властвуй над большими задачами

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

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

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

Лучшие практики разработки контекста, который действительно работает

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

Anthropic предлагает полезный способ подумать об этом - не как об одном упражнении по написанию подсказки, а как о построении контекста на трех уровнях.

Системные подсказки: Найдите зону Златовласки

Большинство системных подсказок терпят неудачу в крайностях. Слишком много деталей - списки правил, вложенные условия, жестко закодированные исключения - делают подсказку хрупкой и сложной в обслуживании. Слишком слабая структура заставляет модель гадать, что делать.

Лучшие подсказки находятся посередине: достаточно структурированные, чтобы направлять поведение, и достаточно гибкие, чтобы модель могла рассуждать. На практике это означает предоставление модели четкой роли, общего рабочего процесса и легкого инструментального руководства - не больше и не меньше.

Например:

You are a technical documentation assistant serving developers.
1. Start by retrieving relevant documents from the Milvus knowledge base.  
2. If the retrieval results are insufficient, use the `search_code` tool to perform a deeper search in the codebase.  
3. When answering, cite specific documentation sections or code line numbers.
## Tool guidance

search_docs: Used for semantic retrieval, best for conceptual questions.
search_code: Used for precise lookup in the codebase, best for implementation-detail questions.

…

Эта подсказка задает направление, не перегружая модель и не заставляя ее жонглировать динамической информацией, которой здесь не место.

Дизайн инструментов: Меньше - значит больше

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

Хорошее эмпирическое правило:

• Один инструмент, одна цель

• Явные, недвусмысленные параметры

• Никаких пересекающихся обязанностей

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

Динамическая информация должна быть получена, а не закодирована

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

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

Заключение

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

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

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

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

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

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

У вас есть вопросы или вы хотите получить подробную информацию о какой-либо функции? Присоединяйтесь к нашему каналу Discord или создавайте проблемы на GitHub. Вы также можете записаться на 20-минутную индивидуальную сессию, чтобы получить понимание, рекомендации и ответы на свои вопросы через Milvus Office Hours.