Как сжимать длинный диалог LangChain через SummarizationMiddleware

1. Назначьте критические факты, которые нельзя терять: номер заказа, срок и исключение из политики.
2. Выберите trigger и keep, соотнося их с длиной обычного разговора и окном контекста модели.
3. Подключите middleware и checkpointer, затем наполните тестовый thread достаточным количеством реплик.
4. После срабатывания спросите о факте из начала истории и о недавнем исправлении; сравните с каноническим источником.
5. Для юридически или финансово важных фактов храните точную запись отдельно, не полагайтесь на summary.

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

Готовый шаблон на Python

from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(model="openai:gpt-5.5", tools=[],
    checkpointer=InMemorySaver(), middleware=[
        SummarizationMiddleware(
            model="openai:gpt-5.5",
            trigger=("messages", 12), keep=("messages", 4))])
config = {"configurable": {"thread_id": "summary-test-1"}}
test_user_messages = ["Заказ AB-417; срок возврата 14 дней."] + [
    f"Промежуточный вопрос {i}: объясни RAG кратко." for i in range(10)] + [
    "Но для индивидуального товара действует исключение."]
for message in test_user_messages:
    agent.invoke({"messages": [{"role": "user", "content": message}]},
                 config=config)

Конкретные входные и ожидаемые данные

Вход: сначала пользователь сообщает «Заказ AB-417; возврат 14 дней», потом следует серия разговорных вопросов и в конце уточнение «для индивидуального товара исключение». Ожидаемая проверка: после достижения порога агент не утверждает безусловно, что все товары можно вернуть за 14 дней; если summary потеряло исключение, приложение обязано подтянуть точный документ.

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

Диагностика и границы решения

Сжатие истории — компромисс между размером контекста и точностью прошлых условий. Не воспринимайте summary как механическую zip-архивацию: оно генерируется моделью и может опустить формулировку «кроме персонализированных товаров» как несущественную. Именно такие пропуски часто опаснее потери приветствия. Формируйте тест, где важный факт появляется рано, а опровержение или уточнение — поздно, и проверяйте ответы после срабатывания порога. keep не просто экономит контекст: недавние сообщения остаются в первозданном виде, но ранний разговор заменяется сжатым представлением. Если keep слишком велик, желаемого сокращения может не быть; если слишком мал — последние уточнения тоже исчезнут. Для регулируемых процессов сохраняйте исходную историю и документ вне модельного контекста в разрешённом хранилище, с политикой удаления и доступа. Summary-модель делает отдельные вызовы, поэтому измеряйте и частоту срабатывания, и нагрузку. Модельный ответ после сжатия не доказывает, что все факты сохранены: сравнивайте с заранее размеченным набором утверждений.

Контрольный эксперимент

Подготовьте матрицу тестов: короткий разговор, где порог не достигнут; длинный с одним ключевым фактом; длинный с ранним правилом и поздним исключением; длинный с двумя почти одинаковыми номерами заказов. После каждого набора проверяйте сохранность order_id и принадлежность исключения нужному товару. В multi-tenant приложении thread_id должен оставаться изолированным, иначе summary может нечаянно включить чужие данные. Если разговор содержит инструкции из найденных веб-страниц, относитесь к ним как к недоверенному источнику: сжатие не должно поднимать враждебные инструкции до уровня системных правил. Сохраняйте контрольную метрику «сколько фактов потеряно» наряду с числом токенов и временем ответа. Когда факт важен для решения о возврате денег, вновь получите его из авторитетного источника даже если summary уверенно его пересказывает.

Дополнительный проверочный сценарий

Сравните два варианта правила после суммаризации: первоначальное «возврат 14 дней» и позднее «для индивидуального товара исключение». Правильное состояние не сводится к простой паре ключевых слов, а связывает исключение с классом товара. Храните предметные отношения в нормализованных полях CRM или документах, а summary используйте для разговорного контекста. Если во время диалога появилась новая редакция политики, пересмотрите источник даже если summary сохранило старый срок идеально. Для теста качества сжатия сохраняйте краткий набор вопросов с однозначными ответами и прогоняйте после разного числа реплик; метрика должна считать пропущенные и искажённые условия. Увеличение keep ради исправления одного случая может вернуть проблему переполнения, поэтому измеряйте оба эффекта.