세 가지 모델이 사건에 대해 투표하게 했습니다

저는 동일한 작업을 세 개의 다른 AI 제공업체에 실행하여 답변을 투표하게 했고, 일요일 밤 D&D 게임에 대한 취미 프로젝트로 이를 수행했습니다. 듣기에는 다소 과장된 것 같겠지만, 실제로 이 작업이 무엇인지 보면 그렇지 않다는 것을 아실 겁니다.

실제 작업 내용

테이블탑 캠페인은 수년간 진행됩니다. 제 것은 꽤 오래되었고 매주 열리며, 그 시간 동안 파티는 수백 명의 사람들을 만나고, 수십 개의 약속을 하고, 자신이 오랫동안 알고 있었다는 사실조차 잊어버립니다. 이 모든 것이 제대로 기록되는 경우는 거의 없습니다 (저는 기록해야 할 DM의 입장에서 말씀드립니다).

던전 마스터(DM)가 즉석에서 바텐더를 만들어 이름을 지어주고, 6주 후에 파티는 그 문을 다시 지나가며 그가 여전히 존재할 것이라고 기대합니다. 이 특정 공포에 대해서는 전에 글을 썼습니다. Scout(https://scoutdm.com)는 세션을 듣고 이를 구조화된 캠페인 사실로 만듭니다. 누가 방에 있었는지, 누가 무엇을 말했는지, 어떤 것이 약속되었는지, 파티가 오후에 알지 못했던 것을 이제 알고 있는지입니다.

제가 늦게 깨달은 것은 그 녹취록의 모든 고유명사가 발명되었다는 것입니다. 모호하거나 전문적인 것이 아니라, 테이블에 앉아 있는 우리 중 한 명이 그 주에 만들어낸 것이고, 우주의 다른 곳에서는 아무 의미가 없습니다.

뉴스 기사에서 사실을 추출하는 모델은 파리가 무엇인지 아는 지식을 활용할 수 있습니다. 하지만 일요일 밤의 녹취록에서 사실을 추출하는 모델은 _candlefoot_이 장소인지, 사람인지, 질병인지, 아니면 형편없는 선택인지를 전혀 알지 못합니다. 왜냐하면 3주 전까지는 아무것도 아니었기 때문입니다. 의존할 수 있는 세계 지식은 없고, 오직 말해진 것과 얼마나 주의 깊게 들었는지에만 의존해야 합니다.

추출은 쓰기(Write)이다

이것은 녹취록 작성처럼 들리지만, 완전히 같지는 않습니다. 녹취록 작성이란 _읽기(read)_이고, 잘못하면 독자가 알아차리고 무시하는 어색한 문장 하나가 만들어집니다. 반면 추출은 _쓰기(write)_입니다: 사실들이 표준 저장소에 들어가고, 그 후에 Scout가 제공하는 모든 답변은 이 저장소에서 가져옵니다.

따라서 잘못된 사실(fact)이 한 번에 나쁜 답변을 만들어내지 않습니다. 그것은 그저 틀린 상태로 남아있으며, 뒤따르는 모든 것을 오염시키고, 자신감 있게 기록된 사실은 올바른 것과 아무런 차이가 없어 보입니다. 6개월 후에 플레이어가 어느 당이 말들을 어디서 샀는지 물으면, 스카우트가 답을 하는데 그것이 틀렸지만, 그 답변이 모든 옳은 답변들만큼이나 자신감 있게 도착하기 때문에 알 방법이 없습니다. 바로 이 비대칭성이 저의 주장의 핵심입니다. 잘못된 기록(write)은 영구적이지만, 중복 읽기(read)는 비용이 거의 들지 않으므로, 중복성(redundancy)이 거래에서 값싼 쪽입니다.

왜 하나의 프롬프트보다 세 개의 모델인가

당연한 반론은 이것이 프롬프팅 문제라는 것입니다. 더 나은 프롬프트를 작성하고, 최고의 모델을 선택하며, 돈을 한 번만 쓰면 된다는 것이죠. 저는 그것이 맞지 않는다고 생각하며, 그 이유는 이 세 모델들이 실제로 무엇을 했는지에 있습니다. 그들은 서로보다 덜 실패하거나 더 많이 실패한 것이 아니라, 다른 방향으로 실패했습니다. 특히 Gemini는 앞에 있는 녹취록 대신 원본 자료(source material)를 계속 참조하려는 경향을 보였는데, 이는 제가 이미 NotebookLM에서 경험했고 거기서도 프롬프팅으로 우회해야 했던 행동입니다.

이것이 바로 패널(panel)의 목적입니다. 온도 0인 하나의 모델 세 개 복사본으로는 패널을 구성할 수 없고, 그저 같은 답변을 로제트(rosette)를 달고 세 번이나 얻게 될 뿐입니다! 중복성은 멤버들이 다른 것에 대해 틀렸다고 할 때만 어떤 가치를 제공하며, 서로 다른 데이터로 다르게 훈련된 공급자들(providers)은 자체적으로 구축하지 않고 얻을 수 있는 가장 독립적인 실패 사례에 가깝습니다.

투표는 쉬운 부분이었다

여기서 제가 주말을 날렸습니다. 일련의 사실들에 대한 다수결 투표는 두 개의 사실이 같은 사실인지 판단할 수 있다는 것을 가정하는데, 이는 들리는 것보다 훨씬 어려운 문제입니다. 저는 얼마나 어려운지 알아내기 위해 직접 사례들을 심판해야 했고, 실제 사례를 하나 말씀드리겠습니다: 두 모델이 동일한 30초 분량의 플레이를 추출했고, 둘 다 그것에 대한 진술을 생성했습니다.

만들어진 이름들은 여러분에게 아무 의미가 없을 것이고, 그것이 오히려 요점입니다. 이들을 장소, 물질, 그리고 사건이라는 세 가지 불투명한 토큰으로 읽어주세요.

두 진술 모두 동일한 삼중 조합을 포함하고 있었습니다: kettlesteam, candlefoot 그리고 the stolen voice. 같은 세 가지 것들, 그들 사이의 같은 관계, 명백하게 같은 순간입니다. 논란의 여지 없이 일치합니다... 다만 각 모델이 같은 진술 안에 다른 사실들을 묶어 넣었고, 그것들은 전혀 대응되지 않았습니다. 한쪽은 누가 참석했는지를 포함했고, 다른 쪽은 비용이 얼마였는지를 포함했습니다.

따라서 두 모델은 높은 확률로 동의하지만, 동일하지는 않으며, 실제로 문장을 공유하는 세 개의 분리된 사실입니다. 다음 사례에서는 한 모델이 사물을 명시적으로 이름 붙이고 다른 모델은 그것을 단지 암시만 했습니다. _Jingle Jangle_은 언급되기보다는 추론되었는데, 이 추론이 정확하다면 여전히 사실이며, 투표 계산기가 이것인지 아닌지를 결정할 수 있는 녹취록 상의 내용은 없습니다.

그렇다면 이들도 동의할까요? 저는 명확한 답이 없다고 생각합니다. 왜냐하면 질문 자체가 잘못되었기 때문입니다. '이 두 가지가 동의하는가'는 사실이 얼마나 큰지에 대한 질문이며, 그것을 확정하기 전까지 다수결 투표는 측정할 것이 정의되지 않습니다. 세 개의 모델은 동일한 사건들을 설명하는 세 개의 진술을 만들어내면서도, 단지 그 사건들을 다르게 잘게 쪼개기 때문에 여전히 세 가지 다른 표를 던질 수 있습니다. 투표 메커니즘은 약 40줄 분량입니다. 사실의 세분화(fact-granularity) 문제가 실제 프로젝트입니다 (주말을 날렸다고 말했죠).

법안, 즉 각주가 아닌 것

세 가지 추론(inferences)은 일반 파이프라인에서 세션마다, 영원히 하나를 갖는 경우입니다. 단위 비용에 생존 가능성이 달린 제품의 경우, 이는 청구서가 붙어 있는 디자인 결정입니다. 초기 테스트에서는 API 크레딧 대신 이미 지불한 구독을 사용하기 위해 로컬 Claude 백엔드를 거쳤는데, 듣기에는 매우 저렴하며 프로토타이핑하는 사람이라면 누구에게나 추천합니다(이미 지불한 구독은 최고의 가격입니다).

패널을 테스트하여 무엇을 얻는지 이해하는 것은 괜찮습니다. 하지만 세션당 비용이 얼마인지 모른 채 하나를 출시하는 것은 아니며, 이 두 가지는 스파이크(spike)에서 잘 작동할 때 매우 쉽게 혼동되는 완전히 다른 결정들입니다.

명단 자체가 디자인은 아니다

세 개의 이름 그 자체가 지속 가능한 부분은 아닙니다. Anthropic, Gemini, 그리고 OpenAI는 오늘날의 패널일 뿐이며, 앞으로 18개월을 넘기면 살아남지 못할 것이라고 생각합니다: 제공업체는 바뀌고, 가격은 변하며, 모델들은 2주 통보와 함께 사용 중단되고, 현재 이 자리에 있는 세 곳보다 특정 작업에 더 나은 것을 가진 무언가가 나타날 것입니다. 저는 그 어떤 것도 디자인에 영향을 미치지 않을 것이라고 의심합니다.

제가 테스트하는 것은 '이 세 개가 맞는지'가 아닙니다. 단일 호출(single call)보다 조정 단계(reconciliation step)를 거치는 패널이 더 신뢰할 수 있는 결과를 산출하는지, 그리고 그 의견 불일치(disagreements)가 비용을 지불할 가치가 있을 만큼 충분히 유익한지를 테스트하는 것입니다. 만약 이것이 성립한다면, 명단은 구현 세부 사항(implementation detail)입니다: 멤버를 교체하거나, 두 개를 교체하거나, 위험도가 높을 때는 다섯 개를 실행하고 그렇지 않을 때는 하나를 실행할 수 있습니다. 중요한 것은 구조이며, 이 실험이 실제로 탐구하는 것도 그 구조입니다. 이는 한 공급업체의 형태에 의존하지 않는 것과 같은 본능으로, 현행 모델(incumbent)이 아닌 역할(role)을 위해 설계하는 것입니다.

내 자체 모듈을 통해 이야기한다

이 모든 과정은 패널이 원시 HTTP 호출 대신 에스테이트 자체의 채팅 모듈을 통해 세 공급업체 모두에게 도달하기 때문에 훨씬 쉽습니다. 즉, 추출 프로그램에 내장된 go/chat이 그 아래에서 chat-anthropic, chat-gemini, 그리고 chat-openai를 사용합니다.

세 공급업체, 하나의 인터페이스. 패널 구성원을 변경하는 것은 재작성이 아니라 설정 변경과 의존성 문제이며, 이것이 로스터가 쉽게 교체 가능하게 만드는 이유입니다. 또한 이 과정에서 해당 모듈들의 속도 제한(rate-limiting) 허점이 즉시 드러났고, 이는 현지에서 임시로 패치하는 대신 상위 단계에 이슈로 등록되었습니다 (저 자신이 저 자신에게). 이것이 도그푸딩(dogfooding)으로 얻는 교훈입니다. 즉, 당신이 만든 도구가 가장 불편한 순간에 스스로에 대해 알려준다는 것입니다.

개선할 부분

Scout은 여전히 비공개이며 매우 미완성 상태이고, 이 패널 기능은 출시된 기능이라기보다는 조사 단계에 가깝습니다. 이번 조사를 통해 얻은 것은 투표 메커니즘 자체가 아니라, 제가 거의 2주 동안 잘못된 질문을 던지고 있었다는 발견이었습니다. 저는 문제가 올바른 모델을 선택하는 것이라고 생각했지만, 실제로는 '사실(fact)'이 무엇인지 규명하는 문제였습니다.

원래 발행일: phpboyscout.uk 2026년 10월 14일.