Diagnose 실행
클러스터 열 때 자동: Cluster → Diagnose 가 페이지 랜딩하는 순간 실행. 단일 시그널에서도 사용 가능 (Signal → Diagnose) — 개선 프로모트 전 일회성 조사에 유용.진단 카테고리
Diagnose 가 각 실패를 다음 중 하나 이상에 매핑:- 리트리벌 이슈 — 올바른 청크가 top K 에 없었음. 진단이 실패 패턴 동의.
- 그라운딩 이슈 — 리트리벌된 청크가 오래됨, 그래프와 모순, 인용 누락.
- 프롬프트 이슈 — 프롬프트가 필수 동작을 명확히 지정 안 함.
- 도구 이슈 — 도구가 호출 안 됨, 잘못 호출됨, 잘못된 데이터 반환.
- 메모리 이슈 — Agent 가 이 스코프에 오래되거나 누락된 메모리.
- 모델 이슈 — 모델이 그냥 틀림 (보통 클러스터의 어려운 케이스가 일관된 패턴 보일 때 표면화).
- 데이터 이슈 — 필요한 정보가 지식 베이스에 아예 없음.
진단 증거
각 가설 원인에 대해 Diagnose 표시:- 클러스터의 어느 트레이스가 이 가설 뒷받침.
- 각 트레이스의 어느 특정 스텝이 연루됨.
- 신뢰 점수.
근본 원인 노트
Diagnose 끝에 Nora 가 근본 원인 노트 — 한 단락 사람 읽기 요약 — 작성. 이런 것:근본 원인: 리트리벌 미스. 10 실패 트레이스 중 8 에서 고객 대상 환불 정책 청크가 top-K 결과에 없었음. 청크는 존재하고 잘 형성됐지만 키워드 점수가 낮아 위치 12-15 에 있음 (쿼리는 “money back” 사용, 청크는 “refund” 사용).노트가 사람이 먼저 읽는 것. 개선 플로우가 제안 생성에 쓰는 것이기도 함.
진단 오버라이드
Nora 의 진단에 동의하지 않으면 Suggest different root cause 클릭 후 메뉴에서 선택 또는 자체 타이핑. 오버라이드가 제안 생성에 피드백. 오버라이드하는 흔한 이유:- Diagnose 가 리트리벌 탓했지만 소스 문서가 오래됐다 아는 (데이터 이슈).
- Diagnose 가 프롬프트 탓했지만 도구가 오설정임 아는 (도구 이슈).
여러 근본 원인
일부 클러스터는 진짜 혼합 원인. Diagnose 가 이를 “primary + secondary 근본 원인” 으로 표면화하고 각각에 제안 생성. 흔한 패턴: primary 가 프롬프트 이슈, secondary 가 리트리벌 이슈. 둘 다 고쳐야; 보통 primary 먼저.진단 이력
Diagnose 실행이 클러스터별 캐시. 마지막 실행 이후 클러스터에 새 시그널 없으면 재실행 멱등. 수동 재진단:- 클러스터에 새 시그널 합류.
- 분석 바꿀 수 있는 새 지식 추가.
- 관련 설정 (리트리벌 프리셋, 프롬프트 등) 바꿔 진단 이동하는지 보고 싶음.
Diagnose 가 실패할 때
가끔 Diagnose 가 “모르겠다” — 실패 트레이스가 고칠 수 있는 원인에 매핑되는 공통 스레드 공유 안 함. 그 경우:- 클러스터가 너무 이질적일 가능성 — 분할 고려.
- 또는 근본 원인이 외부 (상류 API 변경, 모델 제공자 업데이트). 수동 조사.