> ## Documentation Index > Fetch the complete documentation index at: https://docs.platform.nora.my/llms.txt > Use this file to discover all available pages before exploring further. # 실패 진단 > 잘못된 답을 생성한 Flow 의 특정 스텝 위치 파악. 실패를 고치기 전 어디서 잘못됐는지 알아야 함. Nora 의 Diagnose 패스가 실패 트레이스를 걸어 담당한 특정 스텝·리트리벌·프롬프트·도구 식별. ## Diagnose 실행 클러스터 열 때 자동: **Cluster → Diagnose** 가 페이지 랜딩하는 순간 실행. 단일 시그널에서도 사용 가능 (**Signal → Diagnose**) — 개선 프로모트 전 일회성 조사에 유용. ## 진단 카테고리 Diagnose 가 각 실패를 다음 중 하나 이상에 매핑: * **리트리벌 이슈** — 올바른 청크가 top K 에 없었음. 진단이 실패 패턴 동의. * **그라운딩 이슈** — 리트리벌된 청크가 오래됨, 그래프와 모순, 인용 누락. * **프롬프트 이슈** — 프롬프트가 필수 동작을 명확히 지정 안 함. * **도구 이슈** — 도구가 호출 안 됨, 잘못 호출됨, 잘못된 데이터 반환. * **메모리 이슈** — Agent 가 이 스코프에 오래되거나 누락된 메모리. * **모델 이슈** — 모델이 그냥 틀림 (보통 클러스터의 어려운 케이스가 일관된 패턴 보일 때 표면화). * **데이터 이슈** — 필요한 정보가 지식 베이스에 아예 없음. 일부 실패는 여러 원인. Diagnose 가 가능성으로 랭크. ## 진단 증거 각 가설 원인에 대해 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 변경, 모델 제공자 업데이트). 수동 조사. Nora 가 이를 "no confident root cause" 노트로 표면화; 개선 플로우가 제안 자동 생성 안 함.