자기 논쟁을 통해 사고를 심화하는 AI 기술, Chain of Recursive Thoughts

• CoRT(Chain of Recursive Thoughts) 는 AI 모델이 답변을 한 번에 확정하지 않고, 스스로 여러 차례 대안을 만들고 평가해 최종 답변을 고르는 방식의 프로젝트임
• 동작 흐름은 초기 응답 생성, 필요한 사고 라운드 수 결정, 라운드별 3개 대안 생성, 전체 응답 평가, 최선의 응답 선택으로 구성됨
• Mistral 3.1 24B로 테스트했을 때, 특히 프로그래밍 작업에서 작은 모델 기준으로 응답 품질이 크게 좋아졌다고 제시함
• Web UI는 아직 초기 개발 단계이며, Windows에서는 start_recthink.bat, Linux에서는 pip, npm, recthink_web.py 실행 흐름을 사용함
• 핵심 구성 요소는 자기 평가, 경쟁적 대안 생성, 반복 개선, 동적 사고 깊이이며, 프로젝트는 MIT 라이선스로 공개됨

---

CoRT가 하는 일

• CoRT는 AI 모델이 자신의 응답을 재귀적으로 검토하고, 대안을 생성한 뒤 가장 나은 답변을 선택하게 만드는 방식임
• 목표는 AI가 한 번 낸 답을 그대로 쓰지 않고, 스스로 의심하고 다시 시도하는 과정을 반복하게 하는 것임
• README는 이를 “AI battle royale”처럼 표현하며, 여러 후보 답변 중 살아남은 응답을 최종 결과로 사용함

응답 생성 방식

• 처리 흐름은 다음 단계로 구성됨
  • AI가 초기 응답을 생성함
  • AI가 필요한 사고 라운드 수를 결정함
  • 각 라운드마다 3개의 대안 응답을 생성함
  • 모든 응답을 평가함
  • 가장 좋은 응답을 선택함
• 최종 응답은 반복적인 대안 생성과 평가를 거쳐 선택된 결과임

테스트와 예시

• Mistral 3.1 24B에 CoRT를 적용해 테스트함
• README는 CoRT 적용 버전이 비적용 버전보다 특히 프로그래밍 작업에서 더 나은 결과를 냈다고 밝힘
• 예시로 Mistral 3.1 24B + CoRT와 Mistral 3.1 24B non CoRT의 결과 이미지가 포함돼 있음

실행 방법

• Web UI는 아직 초기 개발 단계임
• Windows에서는 start_recthink.bat를 열고 의존성 설치가 끝나기를 기다리는 방식으로 안내함
• Linux 실행 절차는 다음과 같음

pip install -r requirements.txt
cd frontend && npm install
cd ..
python ./recthink_web.py

• 새 셸에서 프론트엔드를 실행함

cd frontend
npm start

직접 실행과 구성 요소

• 직접 실행하려면 의존성을 설치하고 OPENROUTER_API_KEY를 설정한 뒤 Python 스크립트를 실행함

pip install -r requirements.txt
export OPENROUTER_API_KEY="your-key-here"
python recursive-thinking-ai.py

• 프로젝트가 강조하는 핵심 요소는 다음 네 가지임

  • Self-evaluation

    • Competitive alternative generation
    • Iterative refinement
    • Dynamic thinking depth
    • 기여는 PR로 받을 수 있으며, 라이선스는 MIT임

[GN⁺]

Hacker News 의견들

• 여러 모델을 서로 맞붙이거나 떼로 돌리면 집단지성이 마법처럼 생길 거라는 흐름을 많이 보지만, 직접 실험하고 ASU/Microsoft Research 작업을 본 뒤엔 더 단순한 결론에 도달함: LLM은 다른 LLM의 검증자로 형편없음
  Subbarao Kambhampati의 “(How) Do LLMs Reason/Plan?” 발표에서는 GPT-4가 기호적 SAT 풀이기가 심판으로 들어오기 전까지, 증명 가능하게 틀린 그래프 색칠 증명을 자신 있게 만들어냄 https://www.youtube.com/watch?v=0u2hdSpNS2o
  Stechly 등의 논문은 GPT-4가 자기 답을 비평하게 하면 정확도가 오히려 떨어지고, 외부의 sound한 검증기를 붙이면 계획·퍼즐 과제 전반에서 약 30%p 향상된다고 정량화함 https://arxiv.org/abs/2402.08115
  즉 현재의 자기회귀 모델에겐 생성보다 검증이 더 어렵고, 컴파일러, 린터, SAT 풀이기, 정답 데이터셋처럼 실제로 세계에 대해 추론하는 검사기가 필요함
  그래서 여러 LLM을 쌓는 방식은 대개 별 도움이 안 됨. “LLM-Modulo” 포지션 논문도 자기회귀 모델은 자체 검증이나 장기 계획을 스스로 할 수 없고, 높은 재현율의 아이디어 생성기로 취급한 뒤 단일하고 sound한 검증기로 감싸야 한다고 봄 https://arxiv.org/abs/2402.01817
  직접 테스트해보니 5개 모델 토론을 강한 모델 하나와 검증기로 바꾸는 편이 답은 같거나 더 좋고, 지연 시간과 오케스트레이션 부담은 훨씬 작았음

  • 제시한 참고자료를 보면 이건 완전히 과제 의존적임. 많은 영역에서는 “비평이 창작보다 쉽다”가 맞음
    책이나 영화가 좋은 예로, 인물이 얕다고 말하긴 쉽지만 깊이 있고 흥미로운 인물을 만들기는 놀라울 정도로 어려움
    소프트웨어 공학에서도 비슷해서, 보안 취약점 찾기 프롬프트를 받은 LLM은 생성된 코드에서 취약할 수 있는 지점을 짚을 수 있음
    하지만 다른 LLM에게 수학 증명의 추론 오류를 찾기 바라면 사실상 전체 추론을 다시 해야 하므로, 유의미한 성능 향상이 있을지는 의문임
  • 좋든 나쁘든 LLM as a Judge 논문 이후 LLM 평가 연구 논문에서는 이 방식이 사실상 표준이 됐음 https://arxiv.org/abs/2306.05685
    LangChain이나 LlamaIndex 같은 프레임워크에서도 RAG 파이프라인 평가에 깊게 들어가 있음 https://arxiv.org/abs/2411.15594
  • “컴파일러, 린터, SAT 풀이기, 정답 데이터셋처럼 실제로 세계에 대해 추론하는 검사기가 필요하다”는 데 동의함
    LLM에게 생성한 코드에 대한 단위 테스트도 함께 만들게 한 다음, 기존 애플리케이션 단위 테스트까지 모두 실행하는 방식은 어떨지 궁금함
    코드가 컴파일되는지, 단위 테스트가 통과하는지를 확인하면 어느 정도 근거 있는 검증이 가능하고, AI가 테스트 결과를 읽어 자기 실수를 고치는 데 쓸 수 있음
  • 똑똑한 AI 회사들이 지금 몰래 하려는 건 우리 인간과 AI에 대한 우리의 답변을 다음 세대의 자기검증 모델 학습에 쓰는 일이라고 봄
    말뭉치 데이터 학습은 한 자릿수 규모의 도약을 만들 수 있지만, 관찰하고 적응할 수 있는 OODA 루프가 있는 상호작용 데이터 학습은 훨씬 강력함
    내가 AI를 하고 있었다면 그렇게 했을 것 같음. 다만 실제로는 BrowserBox를 만들고 있음
  • 답을 생성하고 테스트한다는 발상은 수십 년 전부터 있었고, 올바른 답을 직접 생성하기는 어렵지만 후보 답을 여러 개 만들면 그중 적어도 하나는 맞을 가능성이 큰 문제에서 널리 쓰였음
    생성-검사(generate-and-test) 는 신뢰할 수 있고 비교적 빠르며 메모리 효율적인 검사 알고리즘이 있어야 하고, 정답만 생성하는 정확한 생성 알고리즘이 느리거나 메모리를 많이 쓸 때 특히 유용함
    여기서는 생성기가 LLM이고, 검사기 또는 “검증기”가 컴파일러, 린터, SAT 풀이기, 정답 데이터셋 등인 셈임
    생성-검사는 시행착오와도 관련 있고, 시행착오는 아마 구석기 시대부터 있었을 것임

• 가끔 쓰는 방식은 먼저 AI 채팅 모델이 문제의 답을 내게 하고, 그 답이 왜 맞는지 초기 문제나 기술 분야를 모르는 사람 또는 AI도 이해할 수 있게 보고서로 쓰게 하는 것임
  그다음 문제를 모르는 두 번째 AI 모델에게 보고서를 채점하게 하고, 원래 모델이 제공하지 않은 설명을 요구하거나 논리의 불일치를 짚는 보고서를 쓰게 함
  이 보고서를 원래 모델에 돌려주고 필요한 정보나 수정 사항을 반영한 답변을 다시 쓰게 한 뒤, 두 번째 모델이 설득되거나 첫 번째 모델이 모든 변경 요청을 반영할 때까지 반복함
  매우 투박하지만 시도해본 경우에는 꽤 좋은 결과가 나왔음

  • 어느 정도 대립적 상황이 있는 일에서는 AI에게 먼저 계획을 만들게 한 뒤, 상대편 입장에서 반격이나 계획을 깨는 방법을 생각하게 하고, 마지막으로 그 반응을 고려해 초기 계획을 수정하게 하면 좋은 결과가 나왔음
    최종 계획은 보통 훨씬 균형 잡히고 숙고된 형태가 됨
    흥미롭게도 이 기법은 자기 자신에게 적용해도 잘 작동함. 계획을 다시 보기 전에 결함을 먼저 찾아보는 게 실제로 도움이 됨
  • 같은 방식에 더해, 프로젝트마다 서로 다른 맥락을 가진 채팅을 몇 개 열어두는 기법도 씀
    예를 들어 하나는 기술 중심, 하나는 마케팅 중심, 또 하나는 개인 목표 관련 맥락을 담는 식임
    같은 질문을 서로 다른 맥락의 채팅에 넣으면 같은 문제를 여러 관점에서 보는 것과 비슷하고, 결론도 맥락에 따라 꽤 달라질 수 있음
  • LLM으로 결과 품질을 극대화하기 위해 몬테카를로 트리 탐색을 쓰는 YouTube 영상이 떠오름: https://www.youtube.com/watch?v=mfAV_bigdRA&ab_channel=Treli...
    꽤 좋은 아이디어처럼 보였지만 토큰 사용량은 크게 늘어날 것 같음
    또한 판정자로 쓰는 LLM이 애초에 충분히 좋은 답을 만들 수 없다면, 정확하게 채점하는 데도 어려움을 겪을 수 있다는 점이 걱정됨
  • Kagi의 Assistant 기능을 쓰면 이게 아주 쉬움. 어시스턴트를 바꿔가며 서로의 작업을 확인하게 하면 됨

• 이런 걸 더 큰 규모의 항상 켜진 토론 상원 형태로 해보고 싶음
  프롬프트에 그때그때 답하는 대신, 마감이 있을 수도 있는 작업 목록을 주고 상원이 작업하게 하며, 하위 작업을 위해 그룹으로 갈라지고, 결과에 도전하고, 제안하게 하는 방식임
  더 나아가 분석가 트리를 만들어 부모 노드가 하위 분석이 특히 통찰력 있다고 판단할 때만 제안을 위로 올릴 수도 있음
  모델에게 특정 관점에서 문제를 접근하게 지시하면 결과가 좋아지거나 나빠질 수 있다고 확실히 봄. 다양한 관점과 그 결과에 대한 비판적 분석을 함께 만들면 인상적인 결과가 나올 수 있음
  이런 방식은 엄청난 수의 토큰을 만들겠지만, 토큰당 비용은 이를 가능하게 하는 방향으로 가고 있음. 누구나 자기 모델을 연결할 수 있는 AI 전용 IRC 서버를 만들어 공유 토론장처럼 쓰는 가능성도 있음

  • 최근 Ansible, Packer, Docker, guestfish로 이미지 굽기 같은 DevOps 성격의 일을 하면서, ChatGPT가 존재하지 않는 도구 플래그나 완전히 환각한 함수·동작을 자신 있게 권하는 게 매우 답답했음
    시간을 들여 시도하다 막혀서 돌아오면 “맞아요, 잘 찾아냈네요! 거의 다 왔어요! 다음 단계는 X와 Y입니다”라고 가볍게 말한 뒤, 이전과 같은 상세 튜토리얼을 내놓고 틀렸던 플래그 같은 부분만 살짝 바꿔 둠
    작업을 확인하지 않고 던져놓는 지나치게 열정적인 인턴을 상대하는 느낌이고, 첫 번째 봇 앞에 두 번째 봇을 앉혀 “정말 확실해?”라고 묻게 하면 꽤 나아질 것 같음
  • 1년쯤 전 사용자 프롬프트를 여러 AI 페르소나로 나눠, 각자가 문제를 다른 방식으로 접근한 뒤 최종 중재자가 합의를 끌어내게 하는 실험을 해봤음
    Civilization II의 조언자 개념을 본떠 만들었고, 꽤 괜찮게 작동했지만 단일 LLM인 Mistral에 묶였다는 한계가 어느 정도 있었음
    그리고 내 컴퓨터를 불태울 정도로 무거웠음
  • 이론적으로는 이런 걸 단일 대립적 모델 안에 구워 넣을 수 있지 않을까?
  • 끝없이 토큰을 갈아 넣고, 출력물을 처리해서 끝없는 토론 중 좋은 아이디어가 나올 때 뽑아내는 방식인가?
    충분한 시간과 토큰을 주면 무엇을 만들어낼지 흥미로울 것 같음

• 자주 쓰는 훨씬 단순하고 제한적인 전략은 메시지 끝에 “답하기 전에 태그 안에서 한 번 사고하고, 태그 안에서 한 번 자기비판하고, 마지막으로 최종 답변을 작성해줘”라고 붙이는 것임
  꽤 잘 작동함. 비슷하게 “제안에서 가장 큰 문제 5가지를 찾아줘”라고만 해도 괜찮은데, 5개를 강제하면 대부분 관련성이 낮더라도 뭔가를 찾게 됨

  • Gemini의 거대한 문맥 창을 좋아하는 이유 중 하나가 이 방식임. 한 번에 끝내려 하지 않고 메시지 체인 일부로 쓸 수 있음
    1단계로 계획을 세우게 하고, 2단계로 계획의 결함을 짚게 하고, 3단계로 결함을 반영해 계획을 업데이트하게 함
    자주 묻는 다른 질문은 “우리가 놓친 게 뭘까?”, “성능·보안·법무·비용 측면 고려사항은?” 같은 것임
    “또 있을까?” 식의 유도 프롬프트도 몇 번 반복할 수 있고, 특히 고려할 주제를 안내하면 좋음. 매번 끝나면 그 고려사항을 반영해 계획을 갱신하게 함
  • 항상 “이제 다시 하되 비판 모자를 쓰고 해봐”라고 함
  • 그 방식이 마음에 듦. 아이디어에 지표별 점수를 매기게 하고, 어떤 점수를 만족할 때까지 계속 반복하게 해보고 싶어짐

• 제목에서 기대한 것과는 조금 다름. 명시적으로 대립적 절차일 줄 알았음

  1. 너는 어시스턴트다. 질문에 직접 답하라
  2. 너는 반대신문자다. 어시스턴트는 틀렸다. 이유를 설명하라
  3. 너는 어시스턴트다. 반대신문자가 틀렸다. 네 주장을 방어하라
  4. 너는 판사다. 어느 쪽이 논증에 성공했나, 아니면 추가 논쟁이 필요한가?
     이걸 직접 해보진 않았고 작동할지도 모름. 다만 ChatGPT에 별도 프롬프트로 “XYZ는 참이다, 이유를 설명하라”와 “XYZ는 거짓이다, 이유를 설명하라”를 각각 물어보고 어느 쪽이 더 설득력 있는지 보는 건 도움이 됨
  • “my AI”라고 해놓고 전부 Mistral이라 약간 클릭베이트 같기도 함
  • Fast Agent를 확인해볼 만함. 관련은 없고 그냥 쓰고 있음
    https://github.com/evalstate/fast-agent
  • 이런 기법은 GPT-3.5 때부터 있었고 관련 논문도 엄청 많음
    왜 누군가 이걸 새롭다고 생각하는지 모르겠음. HN의 상태를 보여주는 것 같기도 함
  • ChatGPT는 채팅 간 맥락을 공유함. 그게 어떤 영향을 주는지 궁금함
    접근 자체는 좋아 보이지만, 절대 직접 “네가 틀렸다”고 암시하면 안 됨. 보통은 그냥 자기가 틀렸다고 가정해버림
    오히려 이런 식으로 해도 실제로 반박하며 자신을 방어할 때가 인상적임

• 이런 실험이 꽤 재미있어서, 사람들이 이런 워크플로를 설계할 수 있는 Unreal Engine 블루프린트 스타일 그래프 편집기를 만들고 있음
  사용자 프롬프트가 한 에이전트로 들어가 초기 시도를 만들고, 그 대화 기록이 다른 시스템 프롬프트를 가진 “에이전트”에게 넘어가 혹독한 비평자가 되며, 통과·실패 신호를 주고, 비평자가 통과라고 판단할 때까지 루프를 돈 뒤 사용자에게 출력하는 형태임
  자기 LLM 엔드포인트를 호출하고 워크플로 그래프를 저장·불러오기·공유할 수 있는 작은 웹사이트가 이상적임
  Mistral Small 3.1과 Gemma 3는 로컬에서 돌릴 수 있는 첫 반쯤 유능한 모델처럼 느껴지지만, 그 유능함은 씨앗일 뿐이고 계속 궤도에 올려두는 프레임워크가 필요함
  반복 루프 안에서 Python 실행 권한을 주고 세계를 탐색하라고 하면, 뉴스 같은 걸 내려받아 읽기 시작함

  • 같은 생각을 하고 있음. 여러 성격을 병렬 또는 직렬로 두는 방식임
    예를 들어 GPT에게 못되게 굴라고 지시하면, Gemini가 허튼소리나 허술한 사고를 짚어내는 능력을 GPT에서 어느 정도 흉내 낼 수 있었음. 예의 바름이 가치 있는 많은 것을 걸러내는 듯함
    하지만 결과물이 읽기 불쾌해짐. Gemini는 이를 학습에서 두 단계로 처리하고 첫 단계를 비공개 “사고”로 만들어 해결한 것 같음
    그래서 필요한 건 그 “못된” 출력을 조금 인간적으로 다듬는 2단계 접근이라고 봄. 그렇게 작업하면 짧은 시간 이상은 꽤 피곤해짐
    서로 다른 LLM 성격들이 있는 그룹 채팅 UI도 큰 가치가 있을 것 같음. 메시지 객체 형식이 각 메시지에 이름을 두는 등 여러 사용자와 여러 AI를 염두에 둔 듯한데, 아직 그런 UI는 못 봤음
    여러 제공자를 지원하면 더 좋음. 서로 강점이 달라서 두 번째 의견을 받는 것과 비슷함
  • 이 중 대부분은 이미 llm-consortium으로 가능할 것 같음. 아마 내 PR이 병합된 llm-openrouter 플러그인이 필요할 수도 있음
    consortium은 같은 프롬프트를 여러 모델에 병렬로 보내고, 모든 응답을 중재자 모델에게 보내 평가하게 함. 중재자는 더 반복이 필요한지 결정함
    신뢰도 임계값이나 최소 반복 횟수에 도달할 때까지 강제로 더 반복하게 할 수도 있음
    llm-openrouter에 만든 PR을 쓰면 여러 모델 옵션을 포함한 모델 별칭을 저장할 수 있음. 예를 들어 llm openrouter save -m qwen3 -o online -o temperature 0, system "research prompt" --name qwen-researcher처럼 온라인 조사 전문가를 만들 수 있음
    다른 구성원은 JSON 모드로 개체 추출을 하게 하고, 또 다른 구성원은 블라인드 초안을 쓰게 할 수 있음. 중재자는 이 모든 것을 활용해 좋은 답을 종합함
  • n8n을 써봤는지 궁금함. 그런 흐름을 만들 수 있고, 커뮤니티 버전을 Docker 컨테이너로 몇 분 안에 띄운 뒤 만든 플로 설정도 아주 쉽게 공유할 수 있음

• 이런 GPU들을 빨리 친환경 전력으로 굴릴 방법을 찾아야 함. 아니면 AI들이 틱택토 최적 해법을 두고 자기들끼리 토론하다가 지구를 녹일 것임

  • 간단한 검색에 ChatGPT를 쓸 때도 이렇게 느낌. Google로도 처리할 수 있지만, 내가 직접 걸러야 해서 더 느릴 뿐인 일들이 있음
    아주 작은 작업을 끝내는 가장 쉬운 방법일 때도 있지만, 백엔드 비용 차이는 꽤 클 수밖에 없음. 사용자는 결국 전혀 신경 쓰지 않게 됨. 현실감이 없기 때문임
  • 인프라 쪽 사람들이 지금 데이터센터의 거의 유일한 병목은 전력과 냉각이라고 말하는 걸 들었음
    AI가 자기 자신을 상대로 계속 실행되어야 한다는 건 이미 사실처럼 받아들여지고 있음

• 기계학습 모델이 새로운 아이디어를 내게 하는 방식이 이거라고 봄
  자기논쟁을 통해 이미 시도하고 버린 모든 아이디어에 대해 대각화하되, 특정 일관성 제약은 유지하는 것임. 물론 말처럼 훨씬 쉽지는 않음

  • 규모를 키우고 분산하면 의식에 꽤 가까워질지도 모름
    Conway의 Game of Life인데, 규칙을 가진 색 사각형 대신 어떤 가중치를 가진 LLM들이 서로 계속 떠들고, 어딘가에서 말이나 행동으로 솟아오르는 형태임
  • 방금 한 말이 내가 10분 전에 말하려다 실패한 바로 그 내용임
    https://news.ycombinator.com/item?id=43835798

• 이게 어디까지 갈까? 몇 시간마다 스탠드업 회의를 하는 AI 에이전트 스크럼 팀이 생길까?
  온종일 주제를 토론해서 최선의 견해를 찾는 에이전트들로 정부 관료제를 복제하게 될까?

  • 1년 전쯤 한 테크리드가 실제로 그렇게 했다는 발표를 들은 적 있음
    서로 다른 역할을 가진 AI 에이전트들이 스크럼 팀을 운영했고, 각 에이전트 프롬프트는 모두에게 반대하거나 매우 비판적으로 자기 관점을 제시하도록 되어 있었으며, 최종 결정은 중재자가 내렸다고 함
    발표자는 자기들에게는 잘 작동했다고 주장했음
  • 그럴 수도 있음. 인간이 팀을 이루는 데는 이유가 있음
    인간은 서로 다른 경험과 관점을 가지지만 LLM은 그 정도가 덜하긴 함. 그래도 때로는 다른 모자 하나면 충분함. 예를 들어 코드 리뷰어와 코더의 차이처럼
  • 그럴 가능성이 커 보임. 더 추가하는 게 도움이 되는 것처럼 보이는 한 사람들은 계속 추가할 것임
    언젠가는 효과가 평평해지는 지점이 있을 테고, 그 지점을 정하기 위해 AI 위원회도 생기겠지
    바다를 끓이고 싶지는 않을 테니까

• 이걸 쉽게 포크해서 가지고 놀 수 있게 해준 건 좋음
  이제 막 Nash Equilibrium을 추가하고 “프롬프트 엔지니어링”을 다중 에이전트 협상으로 재구성하는 내 반복 작업을 시작했음. 다른 사람들이 어떻게 생각하는지 궁금함
  https://github.com/faramarz/NECoRT/
  기업용 LLM은 추가 연산 비용에 큰 문제가 없을 것이고, 여러 모델링 최적화를 통해 복잡한 재무를 조정하는 쪽을 더 선호할 거라는 판단임
  공개 저장소와 기여에는 아주 익숙하지 않아서, 잘못하고 있다면 누가 짚어주면 좋겠음
  의도는 원본 코드베이스를 포크해 이론을 테스트하고, 결국 PR로 올리는 것임