Добавление поставщиков контекстов

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

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

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

Когда это следует использовать

Добавьте поставщиков контекстов в агент, когда:

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

Почему не просто использовать инструменты?

Средства и поставщики контекста предоставляют агентам доступ к внешней информации, но они работают по-разному:

Аспект Инструменты Поставщики контекстов
Trigger Реактивная — модель решает, когда следует вызывать средство. Упреждающий — выполняется автоматически перед каждым вызовом
Элемент управления На основе модели: модель выбирает инструмент, когда и с какими аргументами Управляемый разработчиком: вы решаете, какой контекст всегда доступен
Видимость Модель должна знать, что инструмент существует, и судить о том, что это актуально Контекст внедряется прозрачно— модель видит ее как часть запроса.
Сценарий использования Действия и запросы по требованию: "поиск в Интернете," "запрос базы данных" Контекст, постоянно присутствующий: история разговоров, профили пользователей, предварительно загруженные знания
Стоимость токена Токены расходуются только при вызове средства Маркеры, потраченные на каждый вызов (контекст всегда находится в запросе)

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

Подсказка

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

Как работают поставщики контекстов

Поставщики контекстов участвуют в двухэтапном жизненном цикле для каждого вызова агента:

┌──────────────────────────────────────────────────────────────┐
│  Caller: agent.run("What's the return policy?")              │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  BEFORE RUN — each context provider injects context          │
│                                                              │
│  • History provider loads past conversation messages         │
│  • Memory provider retrieves relevant facts/preferences      │
│  • RAG provider searches knowledge base and adds results     │
│  • Custom provider injects user profile, time, location      │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  Agent core — model sees original input + all injected       │
│  context and generates a response                            │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  AFTER RUN — each context provider processes the response    │
│                                                              │
│  • History provider saves the new messages                   │
│  • Memory provider extracts facts to remember for later      │
│  • Custom provider updates session state                     │
└──────────────────────────────────────────────────────────────┘

Основные моменты:

  1. Поставщики контекста запускаются автоматически. Вы зарегистрируете их один раз при создании агента. После этого они участвуют в каждом вызове без необходимости дополнительного кода с вашей стороны.
  2. Несколько поставщиков объединяются. Вы можете зарегистрировать несколько поставщиков контекста — поставщика истории, поставщика RAG и пользовательского поставщика, — и все они вносят вклад в одно и то же окно контекста. Их вклады объединяются в порядке регистрации.
  3. У поставщиков есть два крючка. Хук до внедряет контекст (сообщения, инструкции, инструменты) в подсказку. После перехватчика обрабатывается ответ — хранение сообщений, извлечение воспоминаний или обновление состояния.
  4. Поставщики осведомлены о сеансах. Поставщики контекста получают текущий сеанс, чтобы они могли загружать и хранить данные, привязанные к определенной беседе. Сведения о работе управления сеансами см. в разделе "Сеансы ".

Подсказка

Подробное представление о том, где поставщики контекстов сидят в полном конвейере выполнения агента ( наряду с ПО промежуточного слоя и клиентом чата) см. в разделе "Архитектура конвейера агента".

Управление окном контекста

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

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

Подсказка

Практический опыт работы с поставщиками памяти и контекста см. в разделе "Шаг 4. Память " в руководстве по началу работы.

Это важно

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

Рекомендации

Рассмотрение Сведения
Бюджет токена Каждый вставленный контекст использует токены. Тщательно отслеживайте общий размер контекста, особенно при объединении нескольких поставщиков. Если контекст увеличивается без ограничения, важные сведения усекаются без уведомления.
Задержка извлечения Поставщики контекстов, запрашивающие внешние службы (базы данных, индексы поиска, API), добавляют задержку для каждого вызова. Используйте кэширование, пул подключений и асинхронные операции для быстрого извлечения.
Relevance Внедрение неуместного контекста не просто является тратой токенов — оно может активно ухудшать ответы модели, разбавляя сигнал. Убедитесь, что ваши поставщики предоставляют целенаправленную и соответствующую информацию.
Устаревание Кэшированный или предварительно загруженный контекст может стать устаревшим. Поставщики разработки могут обновлять данные с соответствующими интервалами и учитывать, подходит ли немного устаревший контекст для вашего варианта использования.
Композиционность Если несколько поставщиков участвуют в одном окне контекста, их вклады могут взаимодействовать непредвиденными способами. Тестируйте провайдеров вместе, а не только по отдельности, чтобы гарантировать, что общий контекст имеет смысл.

Дальнейшие действия

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

Агенты в качестве инструментов

Вернитесь глубже:

  • Last updated on