멀티 모델 리뷰 체인이 계속 수렴했던 이유: 모두 같은 질문에 답하고 있었기 때문
the reason my multi-model review chain kept converging: they were all answering the same question
핵심 요약
멀티 모델 리뷰 체인에서 모델들이 같은 결론으로 수렴하는 문제를 각 모델에 구체적인 역할과 출력 스키마를 부여하여 해결함.
- 리뷰 체인 문제 — 모델들이 같은 프롬프트로 인해 동일한 오류를 범하며 수렴함.
- 역할 기반 접근 — QA, 인프라, 제품 등 각 모델에 구체적인 검토 지침과 출력 스키마를 할당함.
- 결과 개선 — 모델 간 중복이 줄고, 일반적인 검토에서는 놓쳤던 인프라 관련 위험 요소를 발견함.
- 남은 과제 — 여러 실패 유형에 걸친 중복 발견 사항을 보고서의 가독성을 해치지 않으면서 처리하는 방법.
우리는 세 개의 모델이 동일한 아키텍처 계획을 검토하게 했는데, 계속해서 잘못된 결론에 동의하는 문제가 발생했다. 처음에는 학습 유사성이나 동일한 RLHF 지문, 동일한 수렴 방식 때문이라고 생각했지만, 그게 아니었다.
진짜 문제는 프롬프트였다. 동일한 출발점에서 "이 계획의 문제점이 무엇인가"라고 물으면, 각 모델은 이미 자신의 가중치가 약점이라고 식별한 부분만 지적하게 된다. 그건 잘 수행했지만, "어디서든 문제를 찾아라"와 "특정 관점에서 문제를 찾아라"는 서로 다른 지시사항이다.
각 리뷰어에게 구체적인 임무를 부여했다. QA는 시나리오와 트리거 조건, 예상 피해 범위를 포함한 '중단 시나리오'만 반환하도록 했다. 인프라는 부하 및 재시도 실패 지점만, 제품 팀은 사용자에게 보이는 영향만 반환하게 했다. 단순한 프롬프트 변경이 아니라 출력 스키마를 다르게 설정한 것이다. 각 리뷰어는 모든 분야를 훑는 대신 한 분야를 더 깊게 파고들어야 했다.
브랜치 간 중복이 약 35% 감소했다. 더 중요한 점은, 인프라 브랜치가 일반 리뷰에서는 위험도가 낮다고 판단했던 재시도 캐스케이드 시나리오를 찾아냈다는 것이다. 사실 위험도가 낮았던 게 아니라, 부하 임계치를 구체적으로 살펴볼 때만 피해 범위가 드러나기 때문에 일반적인 검토 프레임에서는 그렇게 보였던 것뿐이다.
아직 해결하지 못한 문제는 두 가지 실패 유형의 경계에 있는 발견 사항들이다. QA와 인프라 모두 같은 근본 원인을 지적하지만 프레임이 다르다. 유형별로 먼저 중복을 제거하면 두 프레임을 모두 유지할 수 있는데, 각각 다른 피해 범위 추정치를 담고 있어 아마 그게 맞겠지만 보고서가 너무 길어진다. 보고서를 엉망으로 만들지 않으면서 교차 유형 발견 사항을 처리할 깔끔한 방법을 찾은 사람 있나?
