Создание агента памяти об инцидентах SRE с отслеживанием состояния с помощью Hindsight и Groq

Создание агента памяти об инцидентах SRE с отслеживанием состояния с помощью Hindsight и Groq Когда критически важная производственная служба выходит из строя в 3:00 ночи, среднее время устранения проблемы (MTTR) редко ограничивается скоростью вычислений. Это является узким местом при извлечении человеческой памяти. В современных распределенных архитектурах команды часто устраняют идентичные или слегка измененные варианты прошлых сбоев: утечки пула соединений, каскадные тайм-ауты или невытесненные сегменты памяти. Институциональные знания, необходимые для разрешения этих чрезвычайных ситуаций, обычно заперты в статических вики-документах, старых посмертных исследованиях Jira или памяти опытных инженеров. Когда команды пытаются подключить стандартные LLM к сортировке инцидентов в реальном времени, стандартные подсказки контекстного окна не работают: Раздувание контекста: внесение сотен исторических инцидентов в подсказку LLM сжигает бюджеты токенов и снижает точность рассуждений. Галлюцинированные Runbook: в общих моделях отсутствует топологический контекст внутренней архитектуры организации, поэтому рекомендуются деструктивные действия по умолчанию (например, перезагрузка главного узла базы данных во время активного всплеска записи). Операции без сохранения состояния: агенты Vanilla LLM не могут различить модели прошлых инцидентов, оперативные предупреждения,