포스트

MiroFish의 에이전트 사회는 예측 엔진일까: GraphRAG, OASIS와 비용 폭발

MiroFish는 가정을 바꿔가며 가능한 반응을 탐색하는 사회 시뮬레이터이지, 현실 사건의 확률을 자동으로 보정해 주는 예측기는 아닙니다.

MiroFish는 뉴스, 정책, 서사 같은 Seed Data로 지식 그래프를 만들고, 여러 Persona Agent가 가상 환경에서 상호작용하게 합니다. 결과를 ReportAgent가 요약하므로 “이 조건에서 어떤 반응 경로가 나왔는가”를 살펴볼 수 있습니다. 하지만 Agent가 100명으로 늘어도 같은 Model의 가정과 편향을 공유하면 독립적인 100명의 표본이 되지 않습니다.

GraphRAG는 세계관과 장기 기억을 만든다

시뮬레이션 전 Seed Data에서 인물, 사건, 관계 Entity를 추출해 GraphRAG로 구성합니다. 단순 Vector 유사도보다 적대, 협력, 영향 같은 연결을 Persona의 초기 Memory에 전달하기 위한 구조입니다. 원문은 지속적인 기억을 위해 Zep Cloud도 통합한다고 설명합니다.

초기 Graph가 틀리면 이후 상호작용은 그 오류를 사실로 사용합니다. Source 문장과 Graph Edge를 연결하고, 동일 이름의 다른 사람이나 사건이 합쳐지지 않았는지 확인해야 합니다. 외부 Memory Service를 쓴다면 민감 데이터 전송, Tenant 격리와 삭제도 별도 요구 사항입니다.

OASIS 환경에서 미시 행동과 거시 상태가 순환한다

MiroFish의 중심에는 CAMEL-AI 팀의 OASIS Simulation Engine이 있습니다. Agent Node는 부여된 Persona와 행동 규칙에 따라 상호작용하고, Environment Node는 행동의 합을 거시 변수로 갱신해 다시 Agent에 Feedback을 줍니다. 원문은 이를 Dual-platform Parallel Simulation으로 설명합니다.

“God Perspective” Interface에서는 실행 중 새 News나 Event를 Dynamic Variable로 주입할 수 있습니다. Temporal Memory와 Graph 관계를 통해 영향을 전파하므로 여러 Scenario를 비교하기 쉽습니다. 다만 Runtime 개입 전후의 State를 저장하지 않으면 어떤 Event가 결론을 바꿨는지 재현하기 어렵습니다.

많은 에이전트가 예측 정확도를 보장하지 않는다

현실의 사람은 LLM Persona보다 더 다양한 정보와 제약을 갖고 행동합니다. Agent가 학습 데이터에 자주 등장하는 서사를 반복하면 그럴듯한 집단 현상이 생겨도 실제 Population과 다를 수 있습니다. ReportAgent가 “부정 반응 확률 85%”처럼 숫자를 써도 반복 실험과 실제 결과로 Calibration하지 않았다면 통계적 확률이 아닙니다.

결과를 볼 때는 단일 Forecast보다 Scenario의 민감도를 확인해야 합니다.

  • Seed Data 일부를 빼면 결론이 바뀌는가
  • Persona 비율과 Model을 바꿔도 방향이 유지되는가
  • 같은 설정을 반복할 때 결과 분산은 얼마인가
  • Agent 주장에 원문에 없는 사실이 추가됐는가
  • 과거 사건을 시점 당시 정보만으로 재생했을 때 맞는가

실제 정책, 투자 결정을 MiroFish Report 하나에 맡기기보다 논의할 위험 가설을 찾는 용도로 제한해야 합니다.

Context, JSON, 상태 동기화가 운영 병목이다

상호작용이 늘면 Memory와 대화 Context가 커지고 Model 호출 수도 증가합니다. 원문은 Context Length 초과 Crash와 혼합된 LLM 응답에서 JSON을 추출하는 Hotfix가 이어졌다고 설명합니다. 긴 대화를 무조건 보존하기보다 요약, 만료, 상한과 실패 시 재시도 예산이 필요합니다.

Python 3.11 Backend와 Vue Frontend가 많은 Agent State를 실시간으로 주고받는 구조도 작은 Demo와 장기 Simulation에서 요구가 다릅니다. 연결이 끊긴 뒤 State를 복구할 수 있는지, 같은 Event를 중복 처리하지 않는지, 실행별 비용을 어떻게 집계하는지 확인해야 합니다.

원문에 나온 LLM_MODEL_NAME=qwen-plus 설정과 docker compose up -d 명령은 Model 선택과 Container 시작을 암시하는 조각일 뿐입니다. Environment File, API Key, Zep, Database, Compose Version, Network, Volume, Backup이 빠져 있어 완전한 실행 절차가 아닙니다.

과거 사건으로 먼저 보정한다

첫 PoC는 결과를 이미 아는 과거 사건을 시점 당시 자료만으로 구성합니다. 실제로 관찰된 반응과 Simulation의 핵심 경로를 비교하고, Model, Persona, Random Seed별 변동과 전체 Token 비용을 기록합니다. 예상이 틀렸을 때 Graph, 행동 규칙, Report 중 어느 단계가 원인인지 추적해야 합니다.

원문의 “10일 개발과 3천만 위안 투자” 이야기는 프로젝트의 화제성을 설명하지만 예측 성능의 증거는 아닙니다. MiroFish의 실용 가치는 미래를 맞히는 평행우주보다 사람이 놓친 반응 경로를 여러 조건에서 탐색하고 그 가정을 드러내는 데 있습니다.

시나리오의 가정은 어떻게 기록할까

Seed 문서의 범위와 기준 시점, 포함한 인물, 집단, 각 페르소나의 목표와 제약, 주입한 사건을 하나의 시나리오 버전으로 묶습니다. 실행 뒤 설정이 조금이라도 바뀌면 새 버전으로 남겨야 결과 차이를 설명할 수 있습니다. Report만 저장하고 초기 세계관을 잃으면 같은 결론을 다시 만들 수 없습니다.

가정과 관찰 사실도 구분합니다. 원문에 있는 관계와 사람이 추가한 행동 규칙, 모델이 상호작용 중 새로 만든 주장을 서로 다른 필드로 남깁니다. 모델이 만든 내용이 다음 에이전트의 사실로 재사용될 때 출처가 없음을 표시해야 환각이 사회 전체에 전파되는 과정을 찾을 수 있습니다.

민감도 실험은 무엇을 한 번씩 바꿀까

기준 시나리오를 고정하고 Seed 문서 일부, 페르소나 비율, 모델, 무작위 시드, 주입 사건의 시점만 하나씩 바꿉니다. 결론의 방향, 주요 반응 경로와 결과 분산을 비교합니다. 작은 가정 변화로 보고서가 완전히 뒤집히면 단일 실행을 예측으로 제시하기 어렵습니다.

에이전트 수를 늘리는 실험도 같은 방식으로 합니다. 수가 늘며 새로운 경로가 생기는지, 비슷한 발언만 반복되는지와 비용 증가를 함께 봅니다. 같은 기반 모델에서 나온 다수 의견을 독립 표본처럼 계산하지 않고 상관된 시뮬레이션으로 취급해야 합니다.

과거 사건 보정에는 어떤 함정이 있나

결과를 이미 아는 사람이 Seed와 페르소나를 고르면 무의식적으로 정답에 유리한 정보가 들어갈 수 있습니다. 사건 당시 공개됐던 자료만 사용하고 결과 이후의 해설과 수정된 데이터는 제외해야 합니다. 여러 과거 사건을 미리 정해 같은 규칙으로 실행해야 한 사례에 맞춘 조정을 줄일 수 있습니다.

평가는 최종 결론만 맞았는지보다 실제로 관찰된 주요 경로를 포착했는지 봅니다. 틀린 시뮬레이션도 어느 가정 때문에 빗나갔는지 분석할 수 있어야 합니다. 보정에 사용한 사건과 최종 평가 사건을 분리하지 않으면 예측력을 과대평가할 수 있습니다.

상태와 보고서의 오류는 어떻게 분리할까

환경 상태가 올바른데 ReportAgent가 과장된 요약을 만들 수 있고, 반대로 보고서는 그럴듯하지만 내부 상호작용에 근거가 없을 수 있습니다. 주요 주장마다 해당 에이전트 행동과 환경 변화, 원문 근거를 연결합니다. 보고서 숫자는 실행 로그에서 다시 계산할 수 있는 값과 모델의 해석을 구분해야 합니다.

JSON 파싱 실패나 컨텍스트 초과가 생겼을 때 일부 에이전트만 빠진 결과를 정상 실행처럼 요약하면 안 됩니다. 참여 에이전트 수, 실패와 재시도, 누락 이벤트를 완주 조건에 포함합니다. 중간 상태를 체크포인트하고 재시작 시 동일 이벤트를 중복 적용하지 않는지도 시험해야 합니다.

실행 비용은 어떤 단위로 계산할까

에이전트당 평균 호출보다 시나리오 한 번을 끝내는 총 토큰, 메모리 조회, 재시도, 저장 비용을 봐야 합니다. 상호작용 횟수와 에이전트 수가 함께 늘면 호출량이 빠르게 커질 수 있습니다. 같은 질문을 더 많은 에이전트로 돌렸을 때 얻는 새로운 경로 수와 비용을 비교합니다.

초기 PoC에서는 짧은 시간 범위와 소수 페르소나로 시작하고, 상태와 근거 추적이 안정된 뒤 규모를 늘립니다. 비용 상한, 최대 상호작용, 연속 오류 중단 조건을 두지 않으면 장기 시뮬레이션이 의미 없는 대화만 계속할 수 있습니다. 외부 메모리 서비스의 저장과 삭제 비용도 전체 예산에 포함해야 합니다.

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

자주 묻는 질문

MiroFish가 제시한 확률을 실제 사건의 예측 확률로 써도 되나요?

그대로 쓰면 안 됩니다. 반복 시뮬레이션과 과거 사건에서 보정되지 않은 숫자는 모델이 만든 요약일 수 있으며 통계적으로 검증된 확률이 아닙니다.

에이전트 수를 늘리면 현실 사람들의 다양성을 재현할 수 있나요?

자동으로 그렇지는 않습니다. 같은 모델, 초기 그래프, 행동 규칙을 공유하면 오류와 편향도 상관되므로 페르소나 수보다 가정 변화에 대한 민감도를 확인해야 합니다.

MiroFish는 어떤 용도로 쓰는 것이 적절한가요?

미래를 단정하기보다 특정 가정에서 가능한 반응 경로를 찾고, Seed 데이터, 페르소나, 사건 주입을 바꿨을 때 결론이 어떻게 달라지는지 탐색하는 용도가 적절합니다.

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1

키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    13개 장 17 분읽는 시간