- 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
- プロジェクトが強調する中核要素は次の4つ
-
Self-evaluation
- Competitive alternative generation
- Iterative refinement
- Dynamic thinking depth
- コントリビューションはPRで受け付けており、ライセンスは MIT
1件のコメント
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 ポイント改善することが定量化されている https://arxiv.org/abs/2402.08115
つまり現在の自己回帰モデルにとっては、生成より検証のほうが難しく、コンパイラ、リンタ、SAT ソルバー、正解データセットのように、実際に世界について推論する検査器が必要だということだ
だから複数の LLM を積み重ねる方式は、たいていあまり役に立たない。「LLM-Modulo」ポジション論文でも、自己回帰モデルは自己検証や長期計画を自力では行えず、高再現率のアイデア生成器として扱ったうえで、単一で sound な検証器で包むべきだとしている https://arxiv.org/abs/2402.01817
実際に試してみると、5 つのモデルによる議論を強いモデル 1 つと検証器に置き換えたほうが、答えは同等かそれ以上で、遅延やオーケストレーションの負担ははるかに小さかった
本や映画がよい例で、人物描写が浅いと言うのは簡単ですが、深みがあって魅力的な人物を作るのは驚くほど難しいです
ソフトウェア工学でも似ていて、セキュリティ脆弱性を見つけるようプロンプトを与えられた LLM は、生成されたコードの中で脆弱になり得る箇所を指摘できます
しかし別の LLM に数学的証明の推論ミスを見つけさせようとすると、事実上その推論全体をやり直す必要があるので、有意な性能向上があるのかは疑問です
LangChain や LlamaIndex のようなフレームワークでも、RAG パイプラインの評価に深く組み込まれています https://arxiv.org/abs/2411.15594
LLM に生成したコードの ユニットテスト も一緒に作らせ、そのうえで既存アプリケーションのユニットテストまで含めてすべて実行する方式はどうだろうかと気になります
コードがコンパイルできるか、ユニットテストが通るかを確認すれば、ある程度 根拠ある検証 が可能で、AI はテスト結果を読んで自分のミスを修正するのに使えます
コーパスデータの学習は一桁規模の飛躍を生み得ますが、観察して適応できる OODA ループを持つインタラクションデータの学習は、はるかに強力です
自分が AI をやっていたらそうしていたと思います。ただ実際には BrowserBox を作っています
生成-検査(generate-and-test) は、信頼できて比較的高速かつメモリ効率のよい検査アルゴリズムがあり、正答だけを生成する正確な生成アルゴリズムが遅い、あるいはメモリを多く使うときに特に有用です
ここでは生成器が LLM で、検査器または「検証器」がコンパイラ、リンタ、SAT ソルバー、正解データセットなどに当たります
生成-検査は試行錯誤とも関係しており、試行錯誤はおそらく旧石器時代からあったのでしょう
ときどき使う方法として、まず AI チャットモデルに問題の答えを出させ、その答えがなぜ正しいのかを、元の問題や技術分野を知らない人や AI でも理解できるようにレポートとして書かせることがある。
次に、その問題を知らない 2つ目の AI モデルにそのレポートを採点させ、元のモデルが提示していない説明を求めたり、論理の不整合を指摘したりするレポートを書かせる。
そのレポートを元のモデルに戻し、必要な情報や修正点を反映した回答を書き直させたうえで、2つ目のモデルが納得するか、1つ目のモデルがすべての変更要求を反映するまで繰り返す。
とても粗削りだが、試してみた範囲ではかなり良い結果が出た。
最終的な計画はたいてい、ずっとバランスが取れていてよく練られたものになる。
興味深いことに、この手法は自分自身に適用してもよく機能する。計画を見直す前にまず欠陥を探してみるのは、実際に役に立つ。
たとえば、1つは技術中心、1つはマーケティング中心、もう1つは個人目標に関する文脈を持たせる、といった具合だ。
同じ質問を異なる文脈のチャットに入れると、同じ問題を複数の観点から見るのに近く、結論も文脈によってかなり変わり得る。
かなり良いアイデアに見えたが、トークン使用量は大きく増えそうだ。
また、判定役として使う LLM がそもそも十分に良い答えを作れないなら、正確に採点すること自体にも苦労するかもしれない点が気になっている。
こういうことを、もっと大きな規模の常時稼働する討論上院のような形でやってみたい。
プロンプトにその場その場で答える代わりに、締め切りがあるかもしれない作業リストを与えて上院に作業させ、サブタスクのためにグループに分かれ、結果に異議を唱え、提案させるようなやり方だ。
さらに進めて、分析者ツリーを作り、親ノードが下位の分析を特に洞察的だと判断したときだけ提案を上に上げることもできるかもしれない。
モデルに特定の観点から問題へ取り組むよう指示すると、結果が良くも悪くもなるのは確かに見てきた。多様な観点と、その結果に対する批判的分析を一緒に作れば、印象的な結果が出るかもしれない。
このやり方は膨大な数のトークンを生みそうだが、トークン単価はそれを可能にする方向へ進んでいる。誰でも自分のモデルを接続できる AI 専用の IRC サーバーを作り、共有の討論場として使う可能性もある。
時間をかけて試して行き詰まり、戻ってくると、「そうです、よく見つけましたね！ もうほとんどできています！ 次のステップは X と Y です」と軽く言ったあと、前と同じような詳細チュートリアルを出し、間違っていたフラグのような部分だけを少し変えてくる。
作業を確認せずに投げっぱなしにする、熱意だけは過剰なインターンを相手にしている感じで、1つ目のボットの前に2つ目のボットを座らせて「本当に確か？」と聞かせれば、かなり良くなりそうだ。
Civilization II のアドバイザーの概念を手本にしたもので、かなりうまく動いたが、単一の LLM である Mistral に縛られていたという限界がある程度あった。
それに、自分のコンピュータが燃えそうなくらい重かった。
十分な時間とトークンを与えたら何を生み出すのか、興味深い気がする。
よく使う、もっと単純で制約の強い戦略としては、メッセージの末尾に「答える前にタグの中で一度考え、タグの中で一度自己批判し、最後に最終回答を書いてください」と付けることだ。
かなりうまく機能する。似たように、「提案の最大の問題を 5 つ見つけて」と言うだけでも悪くないが、5つを強制すると、たいていは関連性が低くても何かを見つけようとしてしまう。
1段階目で計画を立てさせ、2段階目でその計画の欠陥を指摘させ、3段階目で欠陥を反映して計画を更新させる。
よく聞く別の質問は、「私たちが見落としているものは何だろう？」「性能・セキュリティ・法務・コスト面での考慮事項は？」といったものだ。
「他にある？」のような誘導プロンプトも何度か繰り返せるし、特に考慮すべきテーマを示すと効果的だ。毎回終わるたびに、その考慮事項を反映して計画を更新させる。
タイトルから期待したものとは少し違った。明示的に対立的な手続きなのかと思っていた
これを実際に試したことはなく、うまく動くかもしれない。とはいえ、ChatGPT に別々のプロンプトで「XYZ は真である、理由を説明せよ」と「XYZ は偽である、理由を説明せよ」をそれぞれ尋ね、どちらがより説得力があるかを見るのは役に立つ
https://github.com/evalstate/fast-agent
なぜこれを新しいと思う人がいるのか分からない。HN の現状を示しているようにも思える
アプローチ自体は良さそうだが、絶対に直接「お前は間違っている」と示唆してはいけない。たいていは単に自分が間違っていると仮定してしまう
むしろ、こうしても実際に反論し、自分を弁護するときがあるのが印象的だ
こういう実験はかなり面白いので、人々はこうしたワークフローを設計できるUnreal Engine のブループリント風グラフエディタを作っている
ユーザープロンプトが1つのエージェントに入り最初の試みを作り、その会話履歴が別のシステムプロンプトを持つ「エージェント」に渡されて容赦ない批評家になり、合格・不合格のシグナルを出し、批評家が合格と判断するまでループした後でユーザーに出力する、という形だ
自分の LLM エンドポイントを呼び出せて、ワークフローのグラフを保存・読み込み・共有できる小さな Web サイトが理想的だ
Mistral Small 3.1 と Gemma 3 は、ローカルで動かせる最初の半分くらい有能なモデルのように感じるが、その有能さは種にすぎず、継続して軌道に乗せておくフレームワークが必要だ
反復ループの中で Python 実行権限を与えて世界を探索しろと言うと、ニュースのようなものをダウンロードして読み始める
たとえば GPT に意地悪く振る舞えと指示すると、Gemini がデタラメや雑な思考を見抜く能力を、GPT でもある程度は模倣できた。礼儀正しさが価値あるものを多くふるい落としているようだ
しかし、出力は読んでいて不快になる。Gemini はこれを学習時に2段階で処理し、第1段階を非公開の「思考」にして解決したように見える
だから必要なのは、その「意地悪な」出力を少し人間向けに整える2段階アプローチだと思う。そうやって作業すると、短時間以上はかなり疲れる
異なる LLM の性格を持つグループチャット UIにも大きな価値がありそうだ。メッセージオブジェクト形式は、各メッセージに名前を付けるなど、複数ユーザーと複数 AI を念頭に置いているようだが、まだそういう UI は見たことがない
複数のプロバイダーをサポートすればさらに良い。強みが互いに違うので、セカンドオピニオンを得るのに近い
consortium は同じプロンプトを複数モデルに並列送信し、すべての応答を審判モデルに送って評価させる。審判はさらに反復が必要かどうかを決める
信頼度しきい値や最小反復回数に達するまで、強制的にさらに反復させることもできる
llm-openrouter に作った PR を使えば、複数のモデルオプションを含むモデル別名を保存できる。たとえば
llm openrouter save -m qwen3 -o online -o temperature 0, system "research prompt" --name qwen-researcherのように、オンライン調査の専門家を作れる別の構成員には JSON モードでオブジェクト抽出をさせ、さらに別の構成員にはブラインド草案を書かせることができる。審判はそれらすべてを活用して良い答えを総合する
こういう GPU を早くクリーン電力で回す方法を見つけないといけない。さもないと AI たちが三目並べの最適解をめぐって議論し合いながら地球を溶かしてしまう
とても小さな作業を終わらせる最も簡単な方法であることもあるが、バックエンドのコスト差はかなり大きいはずだ。ユーザーは結局まったく気にしなくなる。現実感がないからだ
AI が自分自身を相手に走り続けなければならない、というのはすでに事実として受け入れられているようだ
機械学習モデルが新しいアイデアを生み出す仕組みはこれだと思う
自己論争を通じて、すでに試して捨てたあらゆるアイデアに対して対角化しつつ、特定の一貫性制約は維持するということだ。もちろん、言うほどずっと簡単ではない
Conway の Game of Life のように、ルールを持つ色付きの四角形の代わりに、何らかの重みを持つ LLM たちが互いにずっとしゃべり続け、どこかで言葉や行動として立ち現れる形だ
https://news.ycombinator.com/item?id=43835798
これはどこまで行くのだろう？ 数時間おきにスタンドアップ会議をするAIエージェントのスクラムチームが生まれるのだろうか。
一日中トピックを議論して最善の見解を探すエージェントたちによって、政府官僚制が再現されるのだろうか。
異なる役割を持つAIエージェントたちがスクラムチームを運営し、各エージェントのプロンプトは全員に反対するか、非常に批判的に自分の観点を示すよう設定されており、最終決定は仲裁役が下したそうだ。
発表者は、自分たちにはうまく機能したと主張していた。
人間はそれぞれ異なる経験や視点を持っているが、LLMはその幅がやや小さい。それでも、時には別の帽子を1つかぶせるだけで十分だ。たとえばコードレビュアーとコーダーの違いのように。
いずれ効果が頭打ちになる地点があるはずで、その地点を決めるためのAI委員会までできるかもしれない。
海を煮立てたいわけではないのだから。
これを簡単にフォークしていじれるようにしてくれたのは良いことだ。
いまちょうどNash Equilibriumを追加して、「プロンプトエンジニアリング」をマルチエージェント交渉として再構成する自分の反復作業を始めたところだ。他の人がどう考えるのか気になる。
https://github.com/faramarz/NECoRT/
エンタープライズ向けLLMは、追加の計算コストを大きな問題とはしないだろうし、複雑な財務を調整するために複数のモデリング最適化を使う方向をむしろ好むだろうという判断だ。
公開リポジトリやコントリビューションにはあまり慣れていないので、何かまずいことをしていたら誰かに指摘してもらえるとありがたい。
意図としては、元のコードベースをフォークして理論をテストし、最終的にはPRを送ることだ。