인시던트 조사 에이전트의 품질을 개선한 것은 툴과 프롬프트였다

이 글에서 다룰 내용

지난 편에서는 옵저버빌리티(Observability) AI 에이전트를 어떻게 평가할지에 대해, 시나리오를 별도의 사양으로 두고 그레이더가 실제로 무슨 일이 일어났는지 판정하는 방식을 추적했습니다. 마지막에 환경의 충실도가 과제로 남았습니다. 시뮬레이션이 너무 많으면 실제 실패를 놓치게 되고, 실환경의 변동성이 너무 크면 벤치마크가 노이즈로 가득 차기 때문입니다.

이번 글에서는 Grafana Assistant Investigations 개발팀이 실제 인시던트를 사용한 평가에서 무엇을 개선했는지 살펴보겠습니다. 그곳에서는 모델 교체보다도, 툴과 그 사용을 유도하는 프롬프트 변경이 품질 개선에 더 크게 기여했다고 보고되었습니다. 다루는 것은 인시던트 조사용 평가 사례이며, 생각하는 방식은 공통적이지만, 동일한 평가 기반이나 데이터셋인지는 공개 자료만으로는 확인할 수 없습니다.

아래 본문에서는 Grafana Labs의 공식 엔지니어링 블로그 Unprompted에서 가져온 4개의 기사를 참조했습니다. 인시던트 조사 평가, 하네스 설계, 툴 정의 압축, CLI 설계를 다룬 내용이며, 저자와 공개일은 말미의 출처에 정리했습니다. 게다가 필자가 수집한 공개된 벤치마크 리더보드 결과를 하나 포함합니다.

합성 환경과 실 인시던트의 차이

William Dumont[1]의 Enter the arena 기사에서 살펴보겠습니다. Grafana Assistant Investigations는 인시던트의 근본 원인 후보를 제시하는 에이전트입니다. 발생한 알람을 읽고, 텔레메트리를 조회하며, 발견된 것들을 상관관계 분석하고, 원인을 제안합니다. 온콜(on-call) 엔지니어가 하는 것과 같은 절차입니다.

이 툴을 만들기 시작한 팀은 처음에 답을 내는 것 자체가 어려운 부분은 아니라는 것을 배웠습니다. 어려운 것은 그 답이 좋은지 아는 것, 그리고 제안에 따라 행동할 만큼 일관되게 그 품질을 유지하는지를 아는 것입니다.

처음에는 **합성 텔레메트리(synthetic telemetry)**를 사용해 평가했습니다. 여기서 합성 텔레메트리란 실제 시스템에서 가져온 것이 아니라, 평가를 위해 인위적으로 생성한 메트릭, 로그, 트레이스입니다.

이 방식으로 반복 평가한 결과, 사내의 어려운 인시던트 집합에 대한 점수가 1주 만에 52%에서 69%로 움직였습니다. 채점은 여러 기준을 LLM이 판정하는 것입니다. 기사에서는 '점수 개선 자체보다 그것을 만들어낸 방법이 더 중요하다'고 언급하며, 실제로 기사의 대부분은 방법 설명에 할애되어 있습니다.

アリーナのループ

그림 1: 실선은 루프의 진행을 나타냅니다. 해결된 인시던트에서 케이스를 만들고, 여러 빌드를 같은 케이스에 돌려 채점하고, 발견한 개선 사항을 에이전트에 넣어 다시 실행합니다. 점선은 그 과정에서 새로운 케이스를 스위트에 추가하는 흐름을 나타냅니다.

벤치마크 구성을 살펴보겠습니다. 소재는 운영 인프라에서 이미 해결된 실제 인시던트이며, 엔지니어가 문의하는 것과 같은 옵저버빌리티(Observability) 백엔드를 사용합니다. 에이전트에게는 GitHub의 MCP 서버와 GitHub CLI를 통해 코드에 접근할 수 있는 권한도 주어지며, 텔레메트리 변화를 그 배경에 있는 커밋이나 풀 리퀘스트에 연결할 수 있습니다.

각 테스트 케이스는 실제 인시던트 보고서에서 만들어집니다. 처음에 제공되는 프롬프트는 발화된 알림(alert)으로부터 구성하고, 채점 기준은 사람이 작성한 분석에서 추출합니다. 기준이 다루는 것은 포스트모템(Postmortem)에서 중요해지는 관점들입니다. 영향 범위, 근본 원인, 기여 요인이 언급됩니다. 인시던트 보고서 자체가 정답이 됩니다.

에이전트에게 답을 미리 읽게 하지 않는 장치도 포함되어 있습니다. 모든 케이스는 인시던트가 시작된 시점에 컷오프(Cutoff)를 가지며, 그 시점 이후의 텔레메트리, 커밋 및 기타 시간 기록 증거는 참조할 수 없습니다. 해결 내용을 포함하는 인시던트 관리 레코드는 통째로 제외됩니다. 이것이 없으면 에이전트는 답을 도출하지 못하고 읽어버릴 수 있습니다.

채점의 세밀함에도 판단이 있습니다. 조사 전체를 합격/불합격으로 판정하는 것이 아니라, 보고서에 쓰인 주장을 하나씩 채점합니다. 어려운 조사는 대부분 적어도 하나의 기준을 놓치기 때문에, 전체를 이진(binary)으로 판정하면 어떤 빌드도 불합격이 되어 차이가 보이지 않습니다. 기준별로 완전히 충족함, 부분적으로 충족함, 놓침의 3단계가 있으며, 가중치를 부여한 충족률을 빌드 간에 비교합니다.

그리고 최적화하는 양은 품질뿐입니다. 벤치마크는 소요 시간, 도구 호출 수, 모델 호출 수, 토큰 수, 비용도 기록하지만, 점수에는 포함하지 않습니다. 같은 품질에 도달한 두 개의 빌드 중 어느 것을 선택할지 결정할 때 사용하는 보조 데이터이며, 더 나쁜 답을 선택하는 이유가 되어서는 안 된다고 합니다.

アリーナの構成

그림 2: 실선은 평가 흐름, 점선은 참조를 나타냅니다. 같은 인시던트를 여러 빌드가 조사하고, 사람이 작성한 보고서를 정답으로 LLM이 채점합니다. 컷오프 이후의 증거는 차단됩니다.

한 번에 하나의 요인만 변경하기

아레나에서는 한 번에 오직 하나의 요인만 변경하여 케이스를 판정하게 합니다. 모든 것을 일정하게 유지하고 같은 인시던트 집합에 대해 단일 요인만 움직이면, 개선을 그 변경에 귀속시킬 수 있습니다. 여러 개를 동시에 바꾸면, 어떤 변경이 차이를 만들었는지 추측할 수밖에 없습니다.

바꾼 것은 4가지입니다.

도구 세트 (Toolset)

모든 도구를 제공한 상태에서, 개별 도구를 의도적으로 제거해 나갑니다. 이를 통해 알 수 있는 것은 그 도구가 유용한지 여부만이 아닙니다. 에이전트가 그 도구에 과도하게 의존하는지, 아니면 다른 증거원을 조합하여 적응할 수 있는지 알 수 있습니다. 메트릭스(Metrics) 도구를 제거하면, 에이전트는 로그와 트레이스 그리고 프로파일에 의지할 수밖에 없게 되며, 단일 신호에 얼마나 의존했는지 알 수 있습니다.

모델 (Model)

배경의 모델을 작고 빠른 것부터 크고 성능 좋은 것으로 바꾸고, 각각에 부여하는 사고 예산(thinking budget)도 바꿉니다. 이를 통해 더 강력한 추론 능력을 부여함으로써 얻은 개선과, 더 좋은 프롬프트나 도구 정비로 인한 개선을 구별할 수 있습니다.

프롬프트 (Prompt)

시스템 프롬프트와 도구별 설명문 개정판을 나란히 비교합니다. 작은 표현의 변경이 에이전트의 행동에 놀라울 정도로 큰 영향을 줄 수 있습니다. 어떤 도구를 선택할지, 얼마나 자신감을 가지고 결론을 내릴지, 손안의 증거가 불충분하다고 언제 판단할지가 바뀝니다. 같은 인시던트에 대해 프롬프트 변종을 돌리면, 그 행동 변화를 직접 측정할 수 있습니다.

외부 에이전트 (External Agent)

비교 기준으로 범용 코딩 에이전트를 3가지 경로로 Grafana Cloud에 연결하여 참여시키고 있습니다. Grafana MCP 서버 경유, gcx 커맨드라인 도구 경유, 그리고 HTTP를 직접 호출하는 경로입니다.

이 외부 에이전트를 왜 넣는지도 설명되어 있습니다. 범용적인 에이전트가 해결한 문제는, 자사(自社)의 에이전트로도 해결할 수 있을 것이기 때문입니다. 만약 외부 에이전트 중 어느 하나라도 자사 에이전트가 놓친 것을 발견했다면, 그 차이는 모델 자체가 아니라 우리 빌드에 있다고 판단할 수 있습니다.

비교가 의미를 가지려면 양(量)이 필요하기 때문에, 빌드와 케이스 전반에 걸쳐 수천 번의 조사를 실행하고 있습니다. 어떤 변경 사항이 우연히 하나의 인시던트에서 유효해 보이는 경우가 있기 때문에, 많은 인시던트에서 패턴이 유지될 때만 프로덕션 환경에 적용한다는 운영 방식입니다.

툴과 프롬프트로 개선하기

평가를 통해 개선에 크게 기여한 요소가 두 가지 밝혀졌습니다. 에이전트가 사용할 수 있는 툴(tool)과, 그 사용을 유도하는 프롬프트(prompt)입니다. 그리고 William은 이렇게 적고 있습니다.

Interestingly, changing the underlying model was less of a contributing factor than either of these.

(흥미롭게도, 기반 모델을 변경하는 것은 이 둘보다 기여도가 작았습니다)

무엇이 발견되었는지에 대한 내용으로 5가지가 언급되었습니다. 먼저 구체적인 변경 사항으로 이어진 네 가지를 살펴보겠습니다.

대부분의 조사는 발생한 알림(alert)에서 시작하지만, 초기 빌드는 알림 이름만으로 문제를 추측하려고 했습니다. 그 추측이 이후 모든 방향을 결정해 버리고, 종종 틀리기도 합니다. 그래서 알림 정의를 가져오고, 실제로 그것을 발화시킨 쿼리를 읽는 툴을 추가했습니다. 조사가 레이블(label)가 아닌 발화 조건에서 시작하게 되었습니다.

어떤 쿼리 툴은 거의 호출되지 않았습니다. 조사해 보니, 그 사용 가이드가 다른 툴에서 복사되어 적용되었을 뿐이라 잘못된 쿼리 언어를 설명하고 있었습니다. 에이전트는 모순된 사양을 받고 그 툴을 회피했습니다. 가이드를 수정하자, 해당 종류의 시그널(signal)이 조사로 돌아왔습니다. 이 글은 여기서 툴 작업의 상당 부분이 스키마(schema)와 설명문이지 핸들러가 아니라는 일반화를 도출하고 있습니다.

에이전트는 인프라 배경 정보를 검색을 통해 가져오지만, 전부를 조사에 흘려보내면 토큰을 소모할 뿐만 아니라, 더 나쁜 것은 무관한 사실들이 에이전트를 본론에서 벗어나게 합니다. 대책으로 작고 저렴한 모델 호출을 하나 끼워 넣고, 얻은 기억(memory)을 현재 인시던트와 관련된 부분으로만 좁혀서 주된 컨텍스트로 전달하도록 했습니다. 토큰 소모가 줄어들고 컨텍스트 오염도 감소하여 조사가 안정화되었습니다.

필요한 데이터가 부족한 케이스에서는, 성능이 좋지 않은 빌드가 증거 없는 추측으로 빈틈을 메우며 단정하는 경향이 있었습니다. 모르는 것은 모른다고 말하도록 에이전트에게 요구하고, 그 행동을 그레이더(grader)로 평가하는 조합으로 완화했지만, 사라지지는 않았습니다.

서두의 주장을 보강하는 관찰도 있습니다. 에이전트 지시어의 표현 방식과 허용된 추론량(inference amount)이 모델 크기보다 품질을 움직였습니다. 몇몇 케이스에서는 추론량을 적절하게 설정한 작은 모델이 더 큰 모델에 견줄 만하다고 보고되었습니다. 프롬프트와 사고량은 모델을 교체하는 것보다 저렴하고 빠른 변경입니다.

공개 벤치마크에서 추론 설정을 비교하기

여기까지는 사내 실제 인시던트를 사용한 평가였습니다. 여기서 시점을 바꿔, 공개된 벤치마크 수치에서도 같은 말이 나오는지 살펴보겠습니다.

Grafana Labs는 2026년 4월에 o11y-bench라는 옵저버빌리티(observability) 태스크의 벤치마크를 오픈소스로 공개했으며, 리더보드도 공개되어 있습니다. 도입 기사에 따르면, 합성 메트릭, 로그, 트레이스를 담은 Grafana Docker 컨테이너에 대해 63개의 태스크를 실행하는 구성입니다. 앞 절의 아레나(Arena)가 실제 해결된 인시던트를 사용하는 반면, 평가 설정 자체가 다르기 때문에 사내 평가의 재현에는 사용될 수 없습니다.

이 리더보드에는 두 가지 지표가 나란히 있습니다. Pass@3는 3회 모두에 합격한 태스크만 세는 일관성(consistency) 지표이며, Pass@k는 k번 중 한 번이라도 해결한 태스크를 세는 최적값(best-case) 지표입니다[2].

게재된 값을 집계하여 두 가지 사실을 알 수 있었습니다.

첫째, 한 번은 해결할 수 있는지와 매번 해결할 수 있는지는 전혀 다른 이야기라는 것입니다. 52개 모델 구성에서 두 지표의 차이는 7.9포인트부터 47.6포인트까지 벌어져 있었습니다. 최적값으로는 80% 가까이 해결되지만, 3회 연속으로 해결되는 태스크는 30%를 밑도는 구성도 있습니다. 실무에 사용할 것이라면 후자를 봐야 합니다.

또 다른 점은 추론을 강화한다고 해서 반드시 좋아지는 것은 아니라는 것입니다. 같은 모델 이름이지만 추론 설정이 다른 구성을 나란히 놓고 비교했을 때, Claude Opus의 4.7과 4.6 모두 추론 기능을 끄는 것이 일관성이 더 높았으며, 추론을 높인 구성과 비교하면 비용도 저렴했습니다. 다만, 추론을 낮춘 구성보다는 비용이 많이 들었습니다. 반면, GPT-5.4 nano는 정반대였습니다. 추론을 높일수록 일관성이 크게 향상되었습니다. 비용 변화 역시 구성에 따라 달랐는데, Claude Opus 5의 경우 추론 설정을 낮음에서 높음으로 변경하자 일관성은 약 8포인트 정도 상승했지만, 총비용은 3배를 초과했습니다.

즉, 추론 설정은 모델을 선택하는 것과는 별개로 품질과 비용 두 가지 측면을 모두 고려하여 결정해야 합니다. 앞서 언급했듯이 도구와 프롬프트의 기여도가 컸던 것처럼, 모델 외부의 설정이 결과에 영향을 미칩니다. 다만 이 비교를 통해 알 수 있는 것은 여기까지이며, 모델 크기의 효과와 도구 및 프롬프트 변경의 기여도를 분리하여 평가할 수는 없습니다.

지시가 아닌 구조에 의한 강제

도구와 프롬프트가 개선에 기여한다는 것을 알았다면, 다음은 그것을 구동하는 하네스(harness) 설계입니다. 여기서는 2026년 6월의 글로 돌아가 Alexander Sniffin[3]의 Inside the harness를 살펴보겠습니다.

인시던트 조사에 고유한 실패 양상이 서두에서 명명되었습니다. 바로

리뷰어가 이 사고방식의 가장 이해하기 쉬운 예입니다. 독립적인 추론 단계로서, 자신만의 프롬프트와 게이트를 가지고 실행됩니다. Sniffin은 이를 Reflexion과 연관시키고 있습니다. Reflexion은 평가 기반의 반성(reflection)을 언어화하여 메모리에 저장하고 다음 시도에 활용하는 기법입니다. 여기서 리뷰어와의 공통점은 평가와 생성을 분리한다는 점이며, 논문이 이 하네스(harness)의 효과를 직접 검증한 것은 아닙니다.

ハーネスのゲート

그림 3: 실선은 조사의 진행을, 왼쪽의 파선은 가설 상태가 미확정일 경우의 되돌림(revert), 오른쪽의 파선은 결론과 모순되는 증거가 남아있는 경우의 되돌림을 나타냅니다. 각 가설 상태를 확정하고, 모순되는 증거를 처리한 후에 보고서를 작성합니다. 트리거를 특정할 수 없는 경우에는 미해결 범위를 명시합니다.

같은 취지는 최적화 과정에서 얻은 교훈으로도 반복됩니다. 하네스의 게이트는 프롬프트 속의 '반드시 ~해야 한다'보다 상위 개념이라고 쓰여 있습니다.

하네스는 모델의 추론을 과도하게 제약하는 것이 아닙니다. 제약하는 것은 무엇을 가지고 조사가 완료되었다고 인정할 것인지에 대한 기준뿐입니다. 쿼리를 선택하고, 결과를 읽고, 결론을 작성하는 것은 모델 측에서 하며, 하네스는 게이트를 통과하지 못한 결론은 받아들이지 않을 뿐입니다. 구조는 딱딱해 보이지만, 실제로는 모델이 처음의 그럴듯한 답변에 머무르지 않고 근본 원인 분석을 더 깊이 진행하도록 유도하는 방향으로 작용했다고 언급되어 있습니다.

툴 설명문과 단계적 발견

'툴과 프롬프트로 개선' 섹션에서는 잘못된 사용 가이드를 수정한 사례를 보았습니다. 여기서는 Cyril Tovena[4]의 Progressive tool discovery를 소재로, 필요한 시점에 툴 설명을 로드하도록 설계한 것을 살펴보겠습니다.

Grafana Assistant가 다룰 수 있는 범위는 넓어서 Prometheus, Loki, Tempo, 알람(alert), IRM, Fleet Management, k6, Agent Observability 등에 걸쳐 있습니다. 각각이 자신만의 조작과 스키마를 가지고 있기 때문에, 전부를 모델에게 매 턴 전달하면 토큰을 소모하고, 툴 선택이 어려워지며, 게다가 현재 사용자에게 쓸 수 없는 능력까지 제시하게 됩니다.

기사에서 보고된 스냅샷에서는 등록된 51개의 툴 정의가 추정 약 54,500 토큰을 차지했습니다. 이는 운영 비용을 높이고 출력 품질을 저하시키는 규모라고 언급되었습니다.

그래서 대부분을 필요할 때 처음 로드하는 방식으로 변경했습니다. 커맨드라인 인터페이스와 유사한 두 개의 명령어만 상시 제시하고, 에이전트는 거기서 능력 목록을 가져온 후 목적 영역의 매뉴얼을 읽고 나서 조작을 실행합니다.

That switch helped us cut 54,000 tokens from our agent’s tool context — a 99.1% reduction — without removing a single reachable capability.

(이 전환 덕분에 에이전트의 툴 컨텍스트에서 54,000 토큰을 줄일 수 있었습니다. 99.1% 감소이며, 단 하나의 도달 가능한 능력도 제거하지 않았습니다.)

ツールの発見を段階的にする

그림 4: 실선은 공개할 툴을 구성하는 순서를 나타냅니다. 권한, 사용 가능성, 에이전트 모드로 등록된 툴을 필터링한 후, 두 개의 진입점을 공개합니다. 에이전트는 필요에 따라 영역을 탐색하고 매뉴얼을 읽은 후에 조작을 실행합니다. 파선은 두 진입점 중 grafana_exec가 가진 명령어 체계를 나타냅니다.

줄어든 수치 자체보다, 설계상의 판단이 두 가지 참고할 만합니다.

첫 번째는 매뉴얼을 원래 툴 설명과 JSON 스키마에서 생성한다는 것입니다. 필수 필드, 열거 값(enum), 검증 제약, 실행 가능한 예시가 그대로 남아 있습니다. 실제 툴과 괴리가 생길 수 있는 두 번째의 간소화된 설명은 유지하지 않는다고 명확히 합니다. 에이전트용으로 설명을 다시 쓰면 그것이 구현체와 멀어집니다. 앞서 본, 복사해서 잘못되었던 사용 가이드와 같은 문제입니다.

두 번째는 공개하는 능력을 실제로 작동하고 있는 시스템의 상태에 맞춘 것입니다. 모드나 권한, 제품의 사용 가능성으로 필터링하여 능력 목록을 구성하므로, 쓸 수 없는 제품은 매뉴얼에도 나타나지 않습니다. 나중에 실패할 경로를 모델에게 알려주지 않기 위해서입니다.

이 방식이 실패하는 조건도 적혀 있습니다. 프롬프트 토큰을 줄여도, 조작에 도달하기까지의 탐색이 길어지면 실패라는 것입니다. 따라서 추가적인 모델 호출, 최초 실제 조작까지 걸리는 시간, 오류로부터의 수정률도 측정하고 있습니다.

같은 문제점은 커맨드라인 툴 측에서도 보고되었습니다. Ward Bekker[5]의 'The CLIs in the Age of Agents'는 회사 내부 오프사이트에서 엔지니어들이 각자의 AI 에이전트를 이전 세대의 Grafana CLI를 향해 던진 관찰에서 시작됩니다.

특히 이해하기 쉬운 예시가 인용되었습니다. 대시보드를 찾으라고 요청받은 에이전트가 gcx CLI에는 대시보드를 검색하는 서브커맨드가 없는 것 같다고 응답하며 Grafana의 HTTP API를 직접 조회했습니다. 그런데 그 커맨드는 존재했습니다. 에이전트는 존재하지 않는다고 자신 있게 선언하고, 훈련 데이터에서 익숙한 원본 API를 직접 사용했으며, CLI가 대신 처리해 줄 모든 것을 우회했습니다.

대책으로 적용된 메커니즘들은 모두 에이전트의 읽기 방식을 전제로 합니다. 커맨드의 전체 계층을 압축한 트리 형태로 출력하고, 이를 컨텍스트에 바로 주입할 수 있도록 했습니다. 원본 API를 직접 호출하는 경로에는 전용 커맨드가 있다면 그쪽을 우선하도록 주석을 달았습니다. 각 커맨드에는 토큰 비용에 대한 주석(소, 중, 대)을 붙여서, 어떤 것이 컨텍스트 오버플로우를 일으킬 수 있는지 실행 전에 알려줍니다. 오류는 구조화하여 구체적인 복구 커맨드를 제안으로 반환합니다.

두 글 모두 같은 결론에 도달합니다. 에이전트에게 툴의 역할은 핸들러 구현 자체가 아니라 스키마와 설명문에 있다는 것입니다.

단순한 설계와 복잡한 설계 비교

하네스(Harness)에는 조정할 수 있는 부분이 많습니다. 대상은 프롬프트, 유도 규칙, 압축 전략, 툴 정의입니다. 글에서는 이러한 것들을 감으로 조절할 수는 없다고 말합니다. 그래서 평가, 벤치마크, 최적화의 세 가지로 나누어 접근하고 있습니다.

평가에서는 하네스와 병행하여 오프라인 평가 프레임워크를 만들었습니다. 각 평가 케이스는 조사용 프롬프트와 이미 해결된 사내 인시던트에 대해 온콜 팀이 작성한 포스트모템을 짝지은 것입니다.

We’ve found that real incidents are better evaluation cases than trying to create synthetic cases.

(합성 사례를 만들려고 하는 것보다, 실제 인시던트가 더 좋은 평가 케이스라는 것을 알게 되었습니다)

점수는 사실에 근거하며, 기준으로 실제로 조회할 수 있는 사실(Prometheus 쿼리, Loki 참조, Grafana API 호출)을 연결합니다. 경로가 아니라 결과를 채점합니다. 여러 경로가 올바를 수 있기 때문입니다. 총 토큰 사용량과 전체 소요 시간은 매번 기록됩니다. 정답에 도달했더라도 너무 느리거나 비용이 많이 드는 에이전트는 인시던트 중에 유용하지 않기 때문입니다.

벤치마크 비교에서 얻은 수치도 공개되었습니다. 처음과 비교한 것은 현재의 하네스와 그것을 대체했던 초기 버전입니다. 근본 원인의 정확도가 2배 이상 높아졌고, 상위 원인을 포착하는 빈도는 몇 배가 되었으며, 조사는 대략 절반의 시간으로 끝났습니다. 가장 큰 개선은 상위 원인 식별에서 왔는데, 구 버전이 최근 장애보다 앞선 것을 추적하는 경우가 드물었던 반면, 현행 버전은 보통 그렇게까지 추적합니다. 둘 다 사내 벤치마크 수치이며, 실제 인시던트 포스트모템에 재현(replay)하고 온콜 팀의 소견에 대해 LLM이 채점한 것임을 주석으로 달았습니다.

이러한 개선의 대부분은 하나의 큰 변경에서 온 것이 아니었습니다.

다른 시제품은 모델 추론을 파일에 강하게 의존시키는 설계였는데, 평가 상으로는 깔끔하게 보였지만 인시던트 중에 사용하기에는 너무 느려서 실용성이 떨어졌습니다. 멀티 에이전트 구성이나 기타 아키텍처적 복잡화 역시 같은 제약 조건 하에서는 대략 단순한 버전을 능가하지 못했습니다.

이 패턴이 반복적으로 나타났기 때문에 원칙으로 다루고 있다고 적혀 있습니다. 더 복잡한 설계가 측정 가능한 개선을 보여주지 못한다면, 단순한 것을 출시한다는 판단 기준입니다.

최적화에서는 평가 데이터셋을 사용하여 프롬프트와 하네스 양쪽 모두를 개선하는 루프를 만들었습니다. 변경 사항을 격리하여 실행하고, 훈련용 세트에서 돌려보고, 개선되었다면 튜닝에 사용하지 않고 분리된 홀드아웃(holdout) 세트에서 돌려 승격시킬지 후퇴시킬지를 결정합니다. 여기서 훈련과 홀드아웃을 분리하는 이유가 설명됩니다. 분리하지 않으면 자신도 모르게 자신의 평가 스위트에 과적합하게 됩니다.

과적합(Overfitting)이 무엇을 초래하는지도 구체적으로 설명됩니다. 루프를 짧은 간격으로 돌리면 종종 과적합이 발생하며, 평가한 케이스에서는 높은 점수가 나오지만 다음 인시던트에서는 실패하는 하네스(harness)가 만들어지게 됩니다. 정확도의 차이가 프롬프트에 기인하는 경우는 드물고, 대부분 컨텍스트 부족에 의한 것이라고 언급됩니다.