AI 모델들이 서로 논쟁하게 만든 뒤, Hermes가 판결을 내리게 만들었습니다

이 글은 Hermes Agent Challenge: Build With Hermes Agent를 위한 제출물입니다.

요약 (TL;DR) — 어떤 판단이 필요한 질문을 던지면 세 개의 서로 다른 AI 모델이 논쟁을 벌이고, 그 후 Hermes가 하나의 판결과 신뢰도 점수(confidence score), 그리고 왜 의견이 갈렸는지에 대한 정확한 이유를 전달합니다. 모든 판결, 반대 의견, 그리고 토론 중 바뀐 생각은 Hermes의 자체 메모리에 기록되므로, 다음 질문 시 배심원들은 투표를 하기 전에 미리 가중치(re-weights)가 조정됩니다. 판결은 해당 메모리에 대한 순수 함수(pure function)입니다. 메모리가 없으면 가중치도 없고, 판결도 없습니다. 세 개의 모델, 하나의 판결, 비용은 $0입니다.

내가 만든 것

한번은 LLM(대규모 언어 모델)이 아주 자신만만하게 잘못된 데이터베이스를 추천한 적이 있습니다. 매끄럽고 권위 있는 답변이었죠. 저는 그대로 실행했습니다. 그 결과 주말을 통째로 날렸고, 아직도 극복하지 못한 마이그레이션(migration) 작업을 떠안게 되었습니다.

여기서 악당은 바로 **단일 모델의 과잉 확신 (single-model overconfidence)**입니다. 당신은 다듬어진 하나의 답변만 받게 되며, 당신에게 경고를 주었어야 할 의견 불일치는 보이지 않게 됩니다. 모델 하나에게만 물어봤기 때문에 다른 의견들은 결코 볼 수 없습니다.

그래서 저는 단일 모델을 신뢰하는 것을 그만두었습니다. 대신 배심원단을 소집했습니다.

Council은 어떤 판단이 필요한 질문(

질문을 던지면, Council은 이를 세 명의 배심원(서로 다른 계열의 OpenRouter 무료 모델 2개와 Ollama를 통한 로컬 모델 1개)에게 배분하며, 각 배심원은 근거와 함께 자신의 입장을 취합니다. 그 후, 만약 의견이 일치하지 않으면 **두 번째 심의 라운드 (second deliberation round)**가 실행됩니다. 각 배심원은 다른 배심원들의 답변을 확인하고 자신의 의견을 유지하거나 변경하며, 이를 통해 Council은 단순히 한 번 투표하는 대신 _토론 (debates)_을 수행합니다. 그런 다음 Hermes가 심의된 의견들을 판결합니다: 단일 판결문, 신뢰도 점수 (confidence score) (의견이 일치하면 높고, 2대 1로 갈리면 낮음)

핵심 루프 (The core loop). 하나의 질문에 대해, 세 개의 독립적인 Hermes 서브 에이전트 (2개는 호스팅형 + 1개는 로컬)가 병렬로 분산되어 실행된 후, 네 번째 Hermes (포어맨, foreman)가 하나의 판결을 종합합니다. 모든 화살표는 동일한 hermes -z 인터페이스를 사용하며, 모델과 직접 통신하는 것은 아무것도 없습니다.

베팅 (The bet). 호스팅된 모델과 온디바이스 (on-device) 모델이 동일한 배심원단에 앉아 있으며, 코드 변경 없이 단일 --provider/--model 플래그만으로 교체할 수 있습니다. 이러한 모델 불가지론 (model-agnosticism)은 프로젝트 전체가 구축된 단 하나의 Hermes 속성입니다.

UX 인터페이스 (The UX surface). 배심원들이 동의하면 신뢰도 (Confidence)가 높고, 2대 1로 의견이 갈리면 낮아집니다. 반대 의견 패널 (dissent panel)은 기본적으로 접혀 있으며, 신뢰도 수치를 보고 불안함을 느낄 때 정확히 이를 확장할 수 있습니다.

_실제 제품 (The actual product). 확신에 찬 단일 답변은 이를 숨기지만, Council은 의견 불일치를 헤드라인으로 만듭니다. 여기서 클러스터링 (clustering)을 정확하게 구현하는 것은 미묘한 작업이었습니다 (아래 "배운 점" 섹션 참조).

핵심 기능은 단순히 투표만 하는 것이 아니라 심의(deliberates)하는 위원회입니다. 1라운드가 끝난 후, 의견이 일치하지 않는 배심원들은 서로의 논거를 읽고 투표를 유지하거나 변경할 수 있는 두 번째 Hermes 패스(pass)를 거치게 됩니다. 투표를 변경한 경우 "⇄ changed" 배지가 표시되며, 2대 1의 의견 대립이 합의에 도달하면 신뢰도 다이얼(confidence dial)이 실제로 상승합니다.

에이전트 학습 루프(agentic learning loop), 인간 참여형(human-in-the-loop). Hermes가 제안하면 사용자가 승인하거나 기각합니다. 승인된 규칙은 클라이언트 측(client-side)에 유지되며 다음 소집(convene) 호출 시 함께 전달됩니다.

판사가 검증할 수 있는 지속성(Persistence). 판결은 Hermes 자신의 메모리에 미러링(mirrored)되므로, 회상(recall) 작업은 Hermes가 수행합니다. 그 증거는 docs/hermes-proof/04-memory-recall.txt에 있습니다.

코드

리포지토리(Repo): https://github.com/ArqamWaheed/council

흥미로운 파일들:

• hermes_run.py (모든 배심원/판사 호출이 거치는 Hermes CLI 드라이버)
• run_council.py (오케스트레이션(orchestration) + 결정론적 판사(deterministic judge) + Hermes 포어맨(foreman) + --reflect 루프)
• skills/council/SKILL.md (Hermes가 편집하는 배심원 가중치 브레인)
• server.py (/api/reflect + /api/learn 엔드포인트)
• index.html (포어맨 TTS 낭독 및 localStorage 지속성이 적용된 설계된 판결 UI)

Hermes가 실제로 루프 안에 있다는 증거(하위 에이전트 트랜스크립트, 스킬 차이(skill diff), 메모리 회상)는 docs/hermes-proof/에 있습니다.

# hermes_run.py: 모든 배심원/판사의 호출은 실제 Hermes 실행입니다
def ask(prompt, provider, model, skills=None, timeout=120):
    cmd = [binary(), "--provider", provider, "--model", model]
...

Hermes 에이전트 활용 방법

왜 굳이 Hermes인가: 모델 불가지론적 (model-agnostic) 핵심. Hermes를 사용하면 코드 변경 없이 플래그(flag) 하나만으로 어떤 제공자(provider)를 지정하고 교체할 수 있습니다. Council은 바로 이 단 하나의 속성 위에 구축되었습니다. 즉, 배심원들은 서로 다른 모델이며, Hermes는 "서로 다른 모델"을 저렴하게 사용할 수 있게 만드는 유일한 구성 요소입니다. 가장 명확한 증거는 세 번째 배심원입니다. 다른 두 배심원이 OpenRouter에서 **호스팅 (hosted)**되는 동안, 세 번째 배심원은 Ollama를 통해 **로컬 (locally)**에서 실행되지만, 세 모델 모두 정확히 동일한 hermes -z 인터페이스(위의 모델 불가지론적 다이어그램)를 통해 답변합니다. 호스팅된 모델과 온디바이스 (on-device) 모델이 코드 변경 없이 동일한 배심원단에 앉아 있는 것, 이것이 눈으로 확인할 수 있는 모델 불가지론 (model-agnosticism)입니다. 저는 이번 챌린지에서 이 점을 활용한 다른 사례를 진심으로 찾지 못했습니다. 모두가 하나의 모델을 선택하고 넘어갔습니다. 그것이 바로 이 베팅의 핵심입니다.

하위 에이전트 (Subagents): 배심원당 하나의 실제 Hermes 실행. 각 배심원은 서로 다른 제공자+모델 조합(호스팅된 두 배심원을 위한 hermes -z --provider openrouter --model …, 온디바이스 배심원을 위한 --provider ollama-local …)에 대한 실제적이고 격리된 Hermes 호출이며, 특정 모델의 추론이 다른 모델에 영향을 주지 않도록 병렬로 (in parallel) 분산됩니다 (위의 convene-flow 다이어그램 참조). Hermes가 추론 (inference)을 수행하며, 저의 Python 코드(jurors.py에서 hermes_run.py까지)는 단지 분산 처리를 위한 배관 (plumbing) 역할만 수행합니다. 출력되는 JSON의 모든 배심원은 "via": "hermes"로 태그가 지정됩니다. 주의해야 할 점은 Hermes가 **64K 컨텍스트 하한선 (64K-context floor)**을 강제한다는 것입니다. 로컬 모델의 경우 ollama_num_ctx와 이름이 지정된 custom_providers 항목을 모두 설정해야 함을 의미합니다. 이름이 지정된 제공자(provider)가 없으면 --provider ollama는 잘못된 기본 URL (base URL)로 조용히 라우팅됩니다. setup_hermes.sh는 작동하는 설정을 인코딩하여 판사가 단 한 번의 명령으로 이를 재현할 수 있도록 합니다.

단순한 투표가 아닌 진정한 토론 (2라운드는 진정한 Hermes의 작업입니다). 이것은 제가 가장 자랑스럽게 생각하는 기능입니다. 1라운드 이후 배심원들이 의견이 일치하지 않으면, 각 배심원은 다른 배심원들의 입장과 주요 근거를 보여주는 두 번째 Hermes 실행을 거치게 되며, 자신의 의견을 유지할지 혹은 바꿀지를 결정하도록 요청받습니다. 실제 배심원들은 1라운드와 동일한 hermes -z 경로를 통해 재고(reconsider)하므로, 이 토론은 UI상의 장식이 아닌 진정한 추가적인 에이전트 작업 (agentic work)입니다. 모의 배심원(mock jurors)은 오프라인 데모의 재현성을 위해 결정론적(deterministically)으로 재고합니다. 그 후 판사는 심의된 (deliberated) 의견들을 종합하여 판결을 내리므로, 대화를 통해 설득된 배심원은 실제로 결과에 영향을 미칩니다 (위의 심의 다이어그램 참조). 이 기능은 의견 불일치가 발생했을 때만 작동하며 (1라운드에서 만장일치인 경우 건너뜀), COUNCIL_DEBATE=0으로 토글할 수 있습니다.

판결을 위해 프롬프트가 아닌 기술 (skill)을 사용하는 이유. 배심원장의 판결 자체는 skills/council/SKILL.md에 기반한 하나의 Hermes 실행(hermes -z --skills council)이며, 이는 Hermes에 설치되어 있습니다 (hermes skills list 명령으로 확인 가능). 가중치 로직(weighting logic)은 기계 판독이 가능한 weights 블록에 저장되어 있습니다.