Управление контекстом диалога для сохранения критичной информации

Суть

Прогрессивная суммаризация теряет количественные факты (суммы, даты, order ID), схлопывая их в расплывчатую прозу. Извлекайте такие данные в постоянный блок «факты дела» (case facts), который всегда включается в промпт отдельно от суммированной истории.

«Потеря в середине» и раздувание результатов

Эффект «lost in the middle»: модель надёжно обрабатывает начало и конец, но роняет находки из середины. Ключевые находки ставьте в начало и используйте явные заголовки разделов. Результаты инструментов обрезайте до релевантных полей перед добавлением в историю — иначе объект на 40+ полей непропорционально раздувает контекст.

Обрезка результата инструмента до релевантных полей

func trimOrderResult(order map[string]any) map[string]any {
	// Из объекта на 40+ полей оставляем лишь нужное диалогу.
	return map[string]any{
		"order_id":   order["order_id"],
		"status":     order["status"],
		"total":      order["total"],
		"currency":   order["currency"],
		"created_at": order["created_at"],
	}
}

Anti-patterns

Ловушка	Почему не работает	Верный паттерн
Суммаризировать диалог ради экономии токенов	Суммаризация схлопывает количественные факты в расплывчатую прозу	Транзакционные факты — в постоянном блоке case facts вне суммированной истории
Класть ключевые находки в середину агрегированного входа	Середина обрабатывается менее надёжно — находки теряются	Ключевые находки — в начало; явные заголовки разделов
Добавлять полные объекты результатов инструментов	Объект на 40+ полей непропорционально раздувает контекст	Обрезать до релевантных полей перед добавлением

Exam traps

Ловушка	Почему не работает	Верный паттерн
Увеличить интервал суммаризации (каждые 15 ходов вместо 5)	Откладывает, но не решает потерю фактов	Блок case facts вне суммаризации
Большое окно контекста против схлопывания фактов	Потеря от суммаризации не зависит от размера окна	Сохранять факты структурно
Включать полную несуммированную историю в каждый промпт	Сводит на нет смысл управления контекстом	Постоянный блок фактов + сжатая история

Практическое задание (T1)

Построить блок case facts, извлекающий транзакционные данные после каждого вызова инструмента.
Смоделировать диалог на 10 ходов с 5 поисками заказов; измерить разницу токенов (обрезанные vs полные).
Намеренно поставить ключевые находки на позицию 5 из 10 — увидеть потерю; перенести на 1 — увидеть сохранение.
Внедрить заголовки разделов (## Web Results, ## Document Analysis) и измерить качество синтеза.
Изменить поиск заказа на возврат 5 релевантных полей; задокументировать экономию токенов за 20 ходов.

Проверка знаний

Агент разрешения обращений поддержки

Агент после 8 ходов называет неверную сумму возврата. Расследование: история была суммирована на 5-м ходу, схлопнув конкретные суммы в расплывчатый текст. Что сделать?

A Увеличить интервал суммаризации до каждых 15 ходов
B Извлекать транзакционные факты в постоянный блок case facts, всегда включаемый в промпт, отдельно от суммированной истории
C Перейти на модель с большим окном контекста
D Включать полный несуммированный диалог в каждый промпт

Многоагентная исследовательская система

Синтезатор стабильно роняет находки из отчётов 3–6 (середина), но надёжно включает 1–2 и 7–8. Что сделать?

A Улучшить качество отчётов 3–6
B Эффект «lost in the middle» — поставить сводку ключевых находок в начало и использовать явные заголовки разделов
C Направить синтез на модель более высокого уровня
D Стандартизировать форматы всех отчётов

Поддержка со скользящим окном

Агент трижды просит номер счёта в разных сессиях, хотя клиент каждый раз его называет. Корень проблемы?

A Увеличить скользящее окно до 20 ходов
B Агент не записал номер счёта во внутреннее состояние
C Номер счёта — критичный постоянный контекст, требующий отдельного блока 'active commitments' вне скользящего окна
D Суммировать каждую сессию и добавлять в начало следующей