리뷰 체인을 3개 모델로 라우팅해서 서로 의견이 갈리길 기대했는데, 거의 안 갈리더라.

swarm-stack.io에 이 기능을 넣었음. 각 페르소나가 서로 다른 실패 유형을 찾도록 명확히 지시하는 역할 분리형 계획 세션임. 다른 사람들도 비슷한 변동성 문제를 겪었는지 궁금하네.

모델들이 비슷한 학습 데이터나 RLHF 편향을 공유하면 결함 있는 계획에 동의해버리는 게 흔한 실패 유형임. '악마의 대변인' 프롬프트를 써서 모델한테 최소 3개의 잠재적 파괴 지점을 찾으라고 명시적으로 지시하면 그런 합의를 깨는 데 도움이 될 때가 있음. 그냥 일반적인 리뷰를 요청하는 대신 모델들한테 구체적인 적대적 역할을 할당해 본 적 있음?

adversarial prompting이 도움은 되는데, 결국 다들 똑같은 질문을 받는다는 걸 알게 됐음. 의견 차이가 나도 대부분 문체 차이 정도임. 확실히 효과 본 건 각 역할이 어떤 유형의 실패를 중점적으로 봐야 하는지 구체적으로 지정해 주는 거였음. '너는 QA니까 부하가 걸릴 때 깨지는 시나리오 3개 찾아봐'라고 하면 '너는 백엔드니까 확장 안 되는 부분 찾아봐'랑은 다른 문제들을 끄집어냄. 계획은 같아도 실패를 바라보는 관점이 다른 거지. '악마의 변호인'이 되어 깨질 만한 지점 3개 찾으라고 하면 결국 모델들이 가장 눈에 띄는 문제로 수렴해버려서 여전히 겹치는 부분이 생김.

모델이 계획을 먼저 읽으면 역할 분담을 해도 80%는 수렴함. 비평가 역할을 하더라도 이미 솔루션의 프레임에 갇혀버리거든. 효과 봤던 방법은 계획을 보여주기 전에 실패 목록부터 생성하는 거임. '스키마 마이그레이션이 프로덕션을 망치는 주요 원인들은?' 이런 식으로 먼저 물어보고, 그 다음에 계획이 각각을 해결하는지 확인하는 거지. 그래야 리뷰어가 원래 설계를 합리화하는 걸 막을 수 있음.

앵커링 효과는 프롬프트를 다르게 해도 진짜 심함. 공유된 계획을 보여주기 전에 각 에이전트에게 미리 실패 맥락을 주입하는 게 프롬프트 수정보다 훨씬 효과적이었음. 계획을 보기 전에 '프로덕션에서 스키마 마이그레이션을 깨뜨리는 요소는 무엇인가'를 먼저 생성하게 하면, 계획의 프레임에 갇히지 않고 기대치가 형성됨. 독립적인 사전 지식을 기준으로 평가하는 건 계획을 눈앞에 두고 비판을 생성하는 것과는 차원이 다름. 우리는 계획을 보여주기 전에 역할을 먼저 로드함.