AI-агент может успешно выполнить каждый шаг и при этом действовать на основе устаревшей информации. Узнайте, что такое память и контекст, почему они важны для AI-агентов и как трассировки помогают определить, на каком этапе информация оказалась неверной. Посмотрите, как инструменты управления памятью помогают обновлять или удалять устаревшие записи до того, как они повлияют на следующий запуск.
Когда AI-агент дает клиенту неверный ответ, где вы ищете причину в первую очередь? Скорее всего, там, где все выглядит как работающее. Допустим, клиент просит вашего агента поддержки оформить заказ на замену товара. Агент находит адрес доставки, создает замену и закрывает тикет. Каждая операция сообщает об успехе, но замена отправляется по адресу, с которого клиент съехал два года назад.
Насколько можно судить по вашим дашбордам, сбоев не было. База данных ответила, модель отработала, тикет закрыт. Проблема заключалась в том, что агент «помнил» о клиенте и что именно он передал AI-модели. Где-то в процессе устаревшая информация стала основой для принятия решения.
Чтобы понять почему, нужно увидеть, какие записи извлек агент, какая информация попала в модель и какой адрес был передан в инструмент доставки. Это расследование начинается с понимания взаимосвязи между памятью и контекстом.
Что такое память и контекст в AI-агенте?
Память и контекст — это два способа, с помощью которых AI-агент предоставляет информацию модели для принятия решений, и ваше приложение управляет обоими. AI-агент — это приложение, которое использует AI-модель для выбора следующего шага и вызова инструментов (внешних функций, таких как поиск в базе данных или API-запрос). Модель ничего не знает об истории вашего клиента или состоянии заказа, поэтому ваше приложение должно предоставить все эти данные.
Контекст — это то, что ваше приложение предоставляет для одного вызова модели: системные инструкции, текущий запрос, недавние сообщения, записи, найденные для этого запроса, и описания инструментов, которые модель может вызвать. Описания этих инструментов быстро накапливаются. Дайте агенту несколько десятков инструментов, и их описания могут занять больше места, чем вопрос клиента.
Контекстное окно ограничивает объем информации, которую модель может обработать за один вызов. Больше — не всегда лучше, потому что модели становится сложнее использовать релевантную информацию, когда ее окружает длинный контекст. Когда диалог выходит за рамки контекстного окна, многие фреймворки незаметно отбрасывают самые старые сообщения, суммируют их или отклоняют запрос, не сообщая об ошибке. Это может привести к «тихому» сбою.
Память — это информация, которую агент хранит для последующего использования, например, языковые предпочтения пользователя. Она сохраняется дольше текущего вызова модели и часто дольше текущей сессии. Значительная часть памяти записывается самой моделью в виде кратких изложений диалогов. Если одно из таких резюме неточно, ошибка может влиять на будущие вызовы до тех пор, пока сохраненная информация не будет исправлена или удалена.
Сохраненная память не влияет на модель, пока ваше приложение не извлечет запись и не поместит ее в контекст.
Совет: используйте термин «память» для сохраненной информации, а «контекст» — для входных данных, отправляемых при вызове модели. Единая терминология делает трассировки гораздо более читабельными, а расследование сбоев — проще.
Почему память и контекст меняют наблюдаемость AI-агентов?
Память и контекст меняют наблюдаемость AI-агентов, добавляя цепочку решений перед ответом, которую обычный мониторинг не видит. Чтобы расследовать сбой, вам нужна прозрачность этих решений. Наблюдаемость — это способность понять, что система делала внутри, на основе сигналов, которые она генерирует.
В обычном приложении задержки, частота ошибок и логи помогают быстро локализовать проблему. Агент, который возвращает «200 OK» вовремя после принятия неверного решения, не генерирует таких сигналов, и ваш дашборд радостно пометит это как успех.
Перед тем как агент ответит, он может сформировать запрос к памяти, извлечь сохраненные записи и выбрать информацию для включения в контекст модели. Каждая из этих операций может завершиться успешно, при этом передавая информацию, которая ведет к неверному результату.
Запрос выполнен успешно. Решение — ошибочно.
В примере с заказом на замену, когда агент отправляет товар по старому адресу клиента, событие в базе данных с пометкой «извлечение завершено» оставляет несколько вопросов без ответа.
Полезными доказательствами для расследования того, вел ли себя агент должным образом, являются идентификатор клиента, который фильтровал запрос, полученные записи из памяти и адрес, который попал в контекст модели. Имея такие данные, вы можете легче отделить сбой при извлечении от ошибки выбора контекста, а оба этих случая — от ситуации, когда модель приняла неверное решение при корректном контексте.
Связанная трассировка помогает проследить информацию через необходимые границы, исследовать, где мог начаться сбой, и определить потенциальные изменения.
Что должна фиксировать трассировка AI-агента?
Полезная трассировка AI-агента должна фиксировать релевантные шаги между запросом к памяти и ответом, который видит клиент, в рамках одной записи. Это включает извлечение, сборку контекста, вызовы модели и выполнение инструментов в рамках одного запуска агента.
Стройте трассировку из спанов (spans). Спан — это запись операции с временными метками, содержащая время начала, окончания, статус и любые атрибуты, которые вы к ней прикрепите. Появляющиеся - конвенции OpenTelemetry для спанов генеративных AI-агентов - дают разработчикам общий словарь для операций агентов, поэтому спан извлечения выглядит одинаково независимо от того, какой фреймворк его создал.
Вам не нужно создавать всю эту инструментацию с нуля. Платформа - Progress Agent Engineering - для наблюдения и оценки производственных агентов построена на базе OpenTelemetry. Ее комплекты разработки программного обеспечения (SDK) могут захватывать данные трассировки OpenTelemetry для поддерживаемых провайдеров больших языковых моделей (LLM) и фреймворков, а ее - представление трассировок - может отображать доступную телеметрию, такую как промпты, спаны, вызовы моделей, инструменты и извлечение данных для конкретного запуска.
Для расследования проблем с памятью и контекстом фиксируйте:
- Входные данные для извлечения: запишите запрос к памяти, идентификатор, который его фильтровал, и хранилище, которое его получило.
- Извлеченные записи: запишите ID, временные метки и источники возвращенных записей.
- Сборка контекста: запишите, какая извлеченная информация попала в контекст, а также версию инструкций и доступные инструменты.
- Активность модели или инструментов: запишите вывод модели, аргументы вызова инструментов и результат работы инструмента.
ID записей и версии важны, потому что сохраненная информация может измениться после запуска.
Фиксируйте только тот контент, который необходим для диагностики, маскируйте конфиденциальные поля перед экспортом и ограничивайте доступ к трассировкам, содержащим информацию о клиентах.
Предупреждение: трассировка, которая фиксирует полные промпты, также фиксирует все детали клиента, содержащиеся в них. Маскируйте персональные данные до того, как они попадут в вашу систему трассировки, иначе ваш инструмент наблюдаемости может стать источником утечки конфиденциальной информации.
Какие сбои памяти и контекста может выявить наблюдаемость?
Сбои памяти и контекста могут приводить к разным результатам, оставлять разные следы в трассировке и требовать разных исправлений:
Устаревшая память. Поиск может вернуть факт, который когда-то был верным, но с тех пор изменился. Допустим, пользователь меняет адрес, но поиск возвращает старую запись. Это коварнее, чем кажется, поскольку семантический поиск ранжирует записи по их схожести с запросом, а не по новизне. Старый и новый адреса выглядят практически одинаково для модели эмбеддингов, поэтому ничто не мешает устаревшей записи оказаться в приоритете. Трассировка должна отображать временную метку и источник записи, чтобы устаревшую запись было легко заметить.
Неверная область видимости. Отсутствие фильтра может создать дополнительные риски. Если в запросе опущен фильтр user_id, агент поддержки может получить адрес другого клиента и передать его в контекст. Диапазон поиска при этом останется отмечен зеленым цветом, так как база данных ответила. Ответила ли база данных для нужного пользователя — это отдельная проверка.
Неточная или скомпрометированная память. Постоянное хранение данных также повышает риск отравления памяти, когда вредоносная инструкция, сохраненная в долговременной памяти агента, извлекается позже и начинает управлять его поведением. Плохой контекст влияет только на один запуск. Скомпрометированная память продолжает поставлять плохой контекст до тех пор, пока кто-нибудь не найдет и не удалит запись.
Удаление записи требует специальных инструментов. Функции памяти и контекста Agent Engineering позволяют пометить память как активную, устаревшую или удаленную, а семантический вызов может возвращать извлеченные воспоминания с указанием источника и оценки релевантности.
Сбои при сборке контекста. У контекста есть свои сбои. Ваше приложение может извлечь правильную запись, а затем не включить ее в контекст. В других случаях приложение добавляет устаревшую сводку или скрывает решающую инструкцию под таким объемом истории, что модель использует ее недостаточно.
Без диапазонов поиска и контекста пропущенные записи, устаревшие сводки и скрытые инструкции сводятся к одному бесполезному диагнозу: модель выдала плохой ответ.
Полезный совет: подумайте о том, чтобы сохранять временную метку и источник вместе с записями памяти, а также учитывать новизну при поиске для чувствительных ко времени фактов, таких как адреса.
Как наблюдать за памятью и контекстом и улучшать их?
Наблюдайте за памятью и контекстом и улучшайте их, превращая один типичный неудачный запуск в повторяемый тест. Начните с сбора достаточного объема актуальной телеметрии, чтобы восстановить ход работы для расследования. В отчете Национального института стандартов и технологий (NIST) о мониторинге развернутых систем ИИ оперативный мониторинг отделяется от более сложной задачи — определения того, продолжает ли система ИИ работать должным образом.
Выберите неудачный запуск и ответьте на четыре вопроса по данным трассировки.
- Какой запрос к памяти был выполнен?
- Какие записи были возвращены?
- Какая информация поступила в модель?
- Какое действие последовало за этим?
Если трассировка не позволяет ответить ни на один из этих вопросов без угадывания на основе финального ответа, добавьте диапазон на эту границу. Сохраните объяснимый запуск в качестве базового уровня и сравнивайте трассировки в разных версиях. И сохраняйте телеметрию неудачных запусков, потому что выборка трассировок, сохраняющая один запуск из 100, с удручающей надежностью отбросит именно тот, который вам нужен.
Затем превратите инцидент в регрессионный тест. Сохраните запрос, соответствующее состояние памяти и ожидаемое действие. Для примера с заказом на замену проверьте, выбирает ли поиск ожидаемый текущий адрес для нужного клиента и получает ли инструмент доставки ожидаемое значение.
Используйте оценки для проверки результата по явным критериям. Точный адрес или идентификатор клиента подходят для детерминированной проверки. Полезность ответа может потребовать проверки человеком или моделью-оценщиком.
Создайте небольшой тестовый набор с успешными кейсами и известными сбоями. Наборы данных и эксперименты делают сравнение моделей и промптов повторяемым. Когда вы тестируете поиск или поведение инструментов, воспроизводите соответствующую память и состояние приложения в тестовом рабочем процессе.
После развертывания изменений проверьте новые трассировки, чтобы оценить, поступает ли исправленная информация в модель и следует ли за этим запланированное действие.
В случае с заменой, отправленной по старому адресу, расследование должно привести к конкретному исправление и регрессионному тесту, предназначенному для обнаружения подобных сбоев до того, как они затронут другую отправку.
Замена, отправленная по адресу, который устарел два года назад, все равно сводится к одному вопросу, и его стоит задавать при каждом неудачном запуске: сбой начался в памяти, в контексте или в решении модели?
Если у вас еще не настроена трассировка, платформа Progress Agent Engineering предлагает бесплатный план и SDK для .NET, Python и TypeScript.
Начать работу
