Datadog은 생산 문제를 조사하도록 훈련된 모델인 Scout를 출시했습니다. 이는 회사의 AI SRE 제품인 Bits Investigation 내에서 실행되어 경고를 포착하고 원격 측정을 통해 문제의 원인을 제안할 수 있습니다. Datadog 엔지니어와 소수의 고객이 비공개 미리보기로 사용하고 있습니다.
발표에 설명된 대부분의 작업은 비용과 관련이 있습니다. Bits가 쿼리를 시도하고 결과를 연구하고 다음에 확인할 사항을 결정함에 따라 조사에는 많은 모델 호출이 필요할 수 있습니다. 범용 모델은 이를 수행할 수 있지만 Datadog은 법안으로 인해 모든 경고에 대해 실행하기가 어렵다고 말합니다. 발표 작성자는 엔지니어가 페이지에 응답하는 동안 Bits가 작업을 시작하기를 원합니다.
“우리의 목표는 Bits가 엔지니어가 개입하기 전에 증거를 수집하고 가능한 원인을 식별하는 상시 응급 대응자 역할을 하는 것입니다.”
오스마네 아부아말, 벤 코헨, 아프신 로스타미자데, 아미트 탈워카르, 옴리 사스, 다니엘 샨
Datadog의 AlertEval 벤치마크에서 Scout Medium은 GPT-6.1 Sol 높음 및 Claude Opus 5.5 높음과 유사한 점수를 받았습니다. 예상 추론 비용은 3~8배 낮았습니다. xhigh 설정에서 Datadog은 Scout가 비용의 1/4로 Claude Fable 5.1 xhigh와 일치했다고 말합니다. 가격은 공개되지 않으므로 이 수치는 Scout 매체 조사 비용과 관련이 있습니다.
AlertEval은 실제 경고, 보관된 원격 측정 및 Datadog 엔지니어가 작성한 설명을 사용합니다. LLM 판사는 Scout의 계정을 전문가 계정과 비교하여 즉각적인 원인 수준과 근본적인 원인 수준 모두에서 일치하는 결과를 보상합니다. 증거가 없는 모순과 주장은 점수를 잃습니다. 결과 점수는 0에서 100까지이지만 Datadog은 이것이 해결된 사건의 백분율이 아니라고 경고합니다.
Scout는 GLM-5.3 플래시를 기반으로 합니다. Datadog은 역사적 사례에서 발견된 패턴으로 만든 사건 시뮬레이션을 사용하여 강화 학습으로 모델을 사후 훈련했습니다. 시뮬레이션에는 경고, 쿼리할 수 있는 원격 측정 및 알려진 원인이 포함되어 있습니다. 회사에 따르면 여기에는 고객 데이터가 포함되어 있지 않습니다. Scout는 로그, 메트릭, 추적에 대한 검색은 물론 코드, 배포 및 기능 플래그 검사를 포함하여 Bits의 도구를 모델로 한 도구를 사용합니다.
“훈련을 통해 원인을 찾고 증거로 결론을 뒷받침할 수 있습니다.”
오스마네 아부아말, 벤 코헨, 아프신 로스타미자데, 아미트 탈워카르, 옴리 사스, 다니엘 샨
기술 보고서는 훈련 중 무엇이 잘못되었는지에 대한 유용한 설명을 제공합니다. 최종 답변에 따른 보상으로 인해 Scout는 주장을 줄이고 조기에 조사를 중단했습니다. 이로 인해 더 나은 조사자가 되지 않고도 처벌을 받을 가능성이 낮아졌습니다. 팀은 정확성, 탐구 및 뒷받침하는 증거를 고려하여 보상을 변경했습니다. 또한 일부 훈련 실행에서 도구를 제거하거나 사용 가능한 시간을 단축하여 모델이 사고를 통해 하나의 고정 경로를 학습하는 것을 중지했습니다.
Datadog은 90개의 결함으로 구성된 공개 세트인 SREGym에 대한 두 번째 평가를 실행했습니다. Scout는 중간 노력으로 71건, 높음에서 79건, xhigh에서 80건을 해결했습니다. GPT-6.1 Sol xhigh는 82를 완료했습니다. Datadog은 최신 비교 모델에 대한 실행을 포함하여 이러한 테스트를 자체적으로 수행했으므로 독립적인 결과가 유용할 것입니다.
관찰 가능성 공급업체가 에이전트가 처리해야 하는 사고의 양을 파악하는 동안 Scout가 도착합니다. AWS DevOps Agent는 여러 모니터링 제품의 원격 측정을 소스 코드, 배포 기록 및 Runbook과 결합합니다. AWS는 도구 전반에 걸쳐 정보를 결합하는 반면 Datadog은 자체 제품 내에서 반복적으로 사용할 수 있도록 더 저렴한 모델을 교육합니다.
Honeycomb의 Canvas Agent는 많은 엔지니어가 직접 조사하는 방식에 더 가깝습니다. 경고가 발생하거나 SLO가 소진될 때 공유 캔버스를 열고, 쿼리를 실행하고, 아이디어를 테스트하고, 엔지니어가 조사할 수 있도록 증거를 표시합니다. 팀은 익숙한 디버깅 절차를 캔버스 스킬로 캡처할 수 있습니다. Honeycomb은 외부 에이전트가 원격 측정을 쿼리할 수 있도록 하는 MCP 서버도 제공합니다. Honeycomb은 전용 SRE 모델을 발표하지 않았습니다. 쿼리 엔진과 조사 진행 방식에 대한 기록에 중점을 두고 있습니다.
Splunk와 New Relic은 수리 단계를 더욱 발전시켰습니다. Splunk AI SRE는 경고를 그룹화하고 증거 체인을 통해 가능한 원인을 생성합니다. 연결된 Claude 에이전트는 샌드박스에서 코드 변경을 준비하고 풀 요청을 열 수 있습니다. New Relic의 SRE 에이전트는 런북, 사고 검토 및 이전 해결 방법을 분석에 포함하고 Autopilot은 수정 조치를 제안할 수 있습니다. 둘 다 생산 변경 전 승인 단계를 유지합니다.
InfoQ에서 보고한 ClickHouse 연구에 따르면 범용 모델은 요약을 생성할 수 있지만 근본 원인을 일관되게 찾으려면 인간의 지도가 필요하다는 사실이 밝혀졌습니다. Instacart는 Blueberry와 유사한 접근 방식을 취합니다. 에이전트는 엔지니어가 Slack에서 제안된 원인을 평가하기 전에 컨텍스트를 수집합니다.
Scout의 벤치마크 증거는 대부분 Datadog의 자체입니다. 출시에 대한 대응으로 독립 AI 뉴스 계정 AGTP는 AlertEval이 독립적으로 테스트되지 않았다고 지적했습니다. 또한 Scout가 어떤 증거를 고려하고 폐기했는지 보여주는 감사 추적을 요청했습니다. Honeycomb의 눈에 보이는 Canvas와 Splunk의 증거 체인은 다른 공급업체도 동일한 요구 사항을 보고 있음을 나타냅니다. 사고 발생 시 짧은 답변이 도움이 될 수 있지만 엔지니어는 모델이 해당 상황에 어떻게 도달했는지도 확인해야 합니다.
Datadog은 일반 출시 날짜를 제공하지 않았습니다. 회사는 시뮬레이션에 더 많은 유형의 고장을 추가하고 궁극적으로 Bits가 수리를 수행하도록 허용할 계획입니다. 미리보기는 해당 지점 이전에 중지됩니다. Scout는 조사하고 진단하고 복구 조치를 제안하며 엔지니어는 변경에 대한 책임을 집니다.
