# Fusion CLI ระบบที่ไม่ได้ให้ AI ตัวเดียวตอบ

Fusion CLI = ส่งคำถามเดียวให้ AI หลายตัวพร้อมกัน (Claude, GPT, Gemini) แล้วให้ Judge model วิเคราะห์และ Synthesizer สรุปคำตอบสุดท้าย

ทำไมถึงได้ผลดีกว่า — แต่ละ model เก่งคนละแบบ Judge จะตัดคำตอบที่ไม่มีแหล่งอ้างอิงออก เหลือแต่สิ่งที่หลาย model เห็นตรงกัน

3 stage หลัก → Panel (ถามพร้อมกัน) → Judge (วิเคราะห์ 5 แนวทาง) → Synthesizer (เขียนคำตอบสุดท้าย)

ข้อจำกัด — ช้ามาก (~3 นาที/คำถาม) เหมาะกับงานที่ต้องการความแม่นยำ ไม่ใช่คำถามทั่วไป งานวิจัยพบว่า debate หลายรอบแพ้ single-pass panel และ model เก่งตัวเดียว resample หลายครั้งบางครั้งชนะ panel ด้วยซ้ำ

ผมได้อ่านเอกสารที่ Openrouter ทำ Fusion ออกมา แล้วน่าสนใจมาก ตรงกับ workflow ที่ผมทำอยู่พอดี AI Loop ให้ claude เขียน code และ gpt คอย audit code ให้

ซึ่ง Fusion ของ Openrouter ก็มีการทำงานแนวเดียวกัน แต่ไม่เหมือนกันซะทีเดียว
ด้านล่าง คือ diagram การทำงานของ model fusion (Openrouter)

จะเห็นว่า เวลาเราใช้ถามอะไร คำถามจะถูกส่งไป panel ที่มี หลายๆ models อยู่ และให้แต่ละตัว หาข้อมูลส่งไปให้ ตัวหลักที่มีหน้าที่วิเคราะและตัดสินใจ เพื่อส่งคำตอบมาให้เรา

ที่ต้องหลายตัว เพราะว่าแต่ละ model ความรู้และความสามารถไม่เหมือนกัน เหมือนคน หลายคน คนนึงอาจจะได้ของมูลส่วนนึง อีกคนหาได้เหมือนกัน แต่ข้อมูลขัดแย้งกัน และมีเพิ่มมาด้วย ทำให้ต้องมี judge model ที่ใช้ตัดสินว่าข้อมูลอันไหนถูกกันแน่ เมื่อได้แล้วก็จะส่งกลับมาหาเรา

เมื่อเราได้ทั้งข้อมูลที่ถูกต้อง จากการยืนยันมาจากหลายๆ model ตัวที่ข้อมูลมั่ว ไม่มีแหล่งอ้างอิง อาจจะถูกปัดตกไป

จาก Model Fusion ทำให้ผมศึกษาและลอง implement “Fusion CLI” ที่มีแนวคิดเหมือน Model Fusion ของ Openrouter หรือ Multi-Model Deliberation Workflow เพื่อใช้กับ model ใน CLI อย่าง claude, codex, agy (Antigravity)

🖥 YOUR MACHINE (local)

👤 You (terminal)
พิมพ์คำสั่งที่ terminal

fusion CLI

installed console command

args / stdin

mode + settings

CLI default · API optional

fusion engine

1 · PANEL (parallel)

fan out to N models

2 · JUDGE

compare → 5-field JSON

3 · SYNTHESIZE — write final answer

default: claude · codex · agy
optional API: OPENROUTER_API_KEY

☁ CLOUD (HTTPS)

Claude
(Anthropic)

GPT
(OpenAI)

Gemini
(Google)

model access: CLI logins or OpenRouter

ด้านบนคือ diagram ที่เอามาปรับใช้กับ CLI ให้ claude, gpt, agy มาช่วย ตอบคำถาม จากที่เราพิมพ์ถามไป คำถามเดียวกันจะถูกส่งไปให้ 3 model CLI และคำตอบของทั้ง 3 จะถูกส่งมาให้ Judge ผมใช้ model Deepseek API รวมรวบและสรุป คำตอบที่ไม่ตรงและไม่มีเหตุผลจะถูกตัดออก

ทำไมต้องใช้ ​Deepseek? … จากเอกสารอ้างอิงที่ research มา มีข้อความที่บอกว่า “เราไม่ควรให้ AI ตัวเดียวกัน ตัดสินหรือรีวิวคำตอบของตัวเอง”

Judge มีหน้าที่ตรวจคำตอบจาก 3 models เท่านั้น โดยการกลับไปดูที่ source ที่ ทั้ง 3 ตัวหามา ถ้าไม่มีแหล่งที่มาหรือชัดเจนไม่พอ Judge จะตัดออกทันที พอได้ข้อสรุปก็ส่งมาให้เรา

question

PANEL (parallel)

Claude
temp .6

GPT
temp .6

Gemini
temp .6

JUDGE

compares, ≠ merges
shuffles order
→ structured JSON

✓ consensus
(high-confidence)

△ contradictions

◑ partial_coverage

★ unique_insights

◎ blind_spots
(gaps)

the judge’s 5-field output

SYNTHESIZE · temp .4

final answer from the JSON

มี 3 stage ที่ทำงานต่อเนื่องกัน

Stage 1 — Panel: ส่งคำถามไปให้ AI 3 ตัวพร้อมกัน (เช่น Claude, GPT, Gemini) แต่ละตัวไม่รู้ว่าตัวอื่นตอบว่าอะไร

Stage 2 — Judge: AI อีกตัวรับคำตอบทั้งหมด แล้ววิเคราะห์ออกมาโดยใช้ 5 อย่างตัดสิน

หัวข้อความหมาย

Consensusสิ่งที่ทุกตัวเห็นตรงกัน → น่าเชื่อถือสูง

Contradictionsคำตอบที่ขัดแย้งกัน → ต้องพิจารณาพิเศษ

Partial coverageบางตัวตอบ บางตัวไม่ตอบ

Unique insightsinsight พิเศษที่มีแค่ตัวเดียวตอบ

Blind spotsไม่มีตัวไหนตอบเลย → Judge ระบุว่าเป็น gap

Stage 3 — Synthesizer: เขียนคำตอบสุดท้าย โดยให้น้ำหนักสิ่งที่ทุกตัวเห็นตรงกัน และ flag จุดที่ยังเป็นคำถาม

=

ระหว่าง research และ implement เจอสิ่งที่น่าสนใจมาก

“คุณภาพสำคัญกว่าความหลากหลาย“

ความเชื่อเดิมคือ ถ้าเอา AI ต่าง vendor ต่าง style มารวมกัน จะได้ผลดีกว่า
แต่งานวิจัยจาก Princeton (ICLR 2025) พบว่า Self-MoA การเอาโมเดลเก่งตัวเดียวมา resample หลายครั้ง — บางครั้งชนะ panel ที่มี AI หลายตัวด้วยซ้ำ

แต่มีข้อยกเว้น คือ ถ้าแต่ละตัวทำผิดคนละแบบ (error-decorrelated) การรวมคำตอบยังได้ผล เพราะจุดแข็งของแต่ละตัวชดเชยจุดอ่อนกันได้ เช่น เอาคำตอบของ model จีน หลายตัวมารวมกัน … model จีนที่ train บน data ต่างกัน, architecture ต่างกัน, ก็จะมี blind spot คนละจุด พอรวมกันแล้ว blind spot ของตัวนึงถูกชดเชยด้วยอีกตัว

ตอนแรกคิดว่าจะให้ AI ถกกันหลายรอบ วนไปจนได้คำตอบที่ดีที่สุด

แต่งานวิจัยหลายชิ้นบอกตรงกันว่าไม่ work … มีสองปัญหาหลัก หนึ่ง ถ้า budget API เท่ากัน เช่น เรียก 6 ครั้ง … debate ระหว่าง 3 model 2 รอบ แพ้การเอา model เก่งตัวเดียวถามซ้ำ 6 รอบแล้วเอาคำตอบที่ออกมาบ่อยที่สุด และสอง เกิด “debate collapse” ที่ทุกตัวเห็นด้วยกันหมดโดยไม่มีเหตุผล เหมือนประชุมที่ทุกคนพยักหน้าตามหัวหน้า

สรุปคือ Panel → Judge → Synth แบบ single-pass ยังดีกว่า debate หลายรอบ

=

Python

Core ของระบบคือ asyncio.gather สำหรับส่งคำถามไปพร้อมกันทุกตัว พร้อม handle กรณีที่ตัวใดตัวหนึ่ง fail

async def run_panel(members, prompt, min_success=2):
results = await asyncio.gather(
*(safe_call(m, prompt) for m in members),
return_exceptions=True
)
ok = [r for r in results if not isinstance(r, Exception)]
if len(ok) < min_success:
raise InsufficientReferencesError(...)
return dict(ok)

asyncio.gather = ยิงคำถามไปหาทุก model พร้อมกันจริงๆ ไม่ได้รอทีละตัว
return_exceptions=True = ถ้า model ไหนล่ม ไม่ crash ทั้งระบบ
if len(ok) < min_success = ถ้าได้คำตอบกลับมาน้อยกว่า 2 ตัว ถึงจะ error

ถ้า panelist ล่มหนึ่งตัว ระบบยังทำงานต่อ ไม่ล่มทั้งหมด

ก่อนส่งคำตอบให้ Judge ระบบจะสลับลำดับคำตอบแบบสุ่มก่อนทุกครั้ง เพราะ AI มีปัญหา position bias .. มักให้น้ำหนักคำตอบแรกมากกว่าโดยไม่รู้ตัว

Judge วิเคราะห์แล้วส่งออกเป็น structured JSON 5 fields ตาม schema ที่กำหนดไว้

ผมให้ Claude code เป็นหลัก เลยสร้าง MCP และ Fusion CLI tool ตรงๆ ให้ claude code เรียกใช้เมื่อต้องการ มี 2 วิธีด้วยกัน

Path A — Bash: เรียกผ่าน terminal ตรงๆ เหมาะสำหรับทดลองใช้

fusion "คำถามที่ต้องการ deliberate"

Path B — MCP Tool: ลงทะเบียนเป็น MCP server ให้ Claude Code ตัดสินใจเองว่าจะเรียกเมื่อไหร่

claude mcp add --env \ --transport stdio fusion -- python -m fusion mcp

ข้อดีของ Path B คือ Claude Code จะเรียก fusion เองเมื่อเจองานที่ซับซ้อน และได้ผลลัพธ์กลับมาเป็น structured JSON พร้อม 5-field analysis

ส่วนตัวผมใช้ B เป็นหลัก เพราะให้ Claude Code ตัดสินใจเองว่าจะ call Fusion เมื่อไหร่ ไม่ต้องจำว่าต้องพิมพ์คำสั่งเพิ่ม ถ้างานซับซ้อนพอ มันจะเรียกเอง

=

Design rules ที่เรียนรู้

Judge เปรียบเทียบ แต่ไม่รวมคำตอบ ถ้ารวมคำตอบ เราได้แค่ค่าเฉลี่ย ซึ่งทำให้ signal ที่น่าสนใจหายไป

ใส่ depth guard Fusion call ห้ามเรียก Fusion ซ้อนกัน

ตอนนี้แค่ลองใช้ ยังไม่มี eval harness ที่พิสูจน์ว่าดีกว่า single model ทุกกรณี ต้องทดสอบต่อไปกับการใช้งานจริง

Fusion เหมาะกับงานที่ความแม่นยำสำคัญกว่าความเร็ว ไม่ใช่คำถาม tactical ทั่วไป เพราะมันช้า prompt นึงใช้เวลาไม่ต่ำกว่า 3 นาที ในการตอบ (ตอบอย่างเดียวไม่รวมแก้)

ถ้า Fusion-CLI ทำได้ตาม concept ที่คิดไว้ สิ่งที่ได้คือ audit harness แบบ multi-model ที่รัน local และมี evidence จริงรองรับ ต่างจาก “AI code review” ทั่วไปที่บอกว่า “ทุก model เห็นตรงกัน = ถูกต้อง” ซึ่ง Fusion CLI ไม่ใช่แบบนั้น

Open questions 

ยังมีสิ่งที่ผมอยากทดสอบต่ออีก

Fusion ชนะ Self-MoA ที่ budget เท่ากันไหม.. ยังไม่มีใครพิสูจน์ในงานวิจัย

Judge prompt ที่ OpenRouter ใช้จริงๆ ไม่ได้เปิด public สิ่งที่ผม implement คือ reconstruct จาก 5 dimensions ที่ documented ไว้

Third synthesizer model ดีกว่าการส่ง JSON กลับให้ caller จริงๆ ไหม — ยังไม่แน่ใจ

Project นี้ยังอยู่ในช่วง active development ข้อมูลบางส่วนอาจ outdated เร็ว โดยเฉพาะ OpenRouter Fusion ที่เพิ่ง launch เมื่อ 13 มิถุนายน 2026 ไม่กี่วันก่อนที่ผมจะ research เรื่องนี้

Ref เอกสารที่ใช้ในการทำทั้งหมด
## Sources

### Primary
- OpenRouter Fusion plugin docs — https://openrouter.ai/docs/guides/features/plugins/fusion
- OpenRouter Fusion router docs — https://openrouter.ai/docs/guides/routing/routers/fusion-router
- Mixture-of-Agents (Wang et al., ICLR 2025) — https://arxiv.org/abs/2406.04692
- Rethinking MoA / Self-MoA (Princeton, ICLR 2025) — https://arxiv.org/html/2502.00674
- LLM-as-judge / MT-Bench (Zheng et al., NeurIPS 2023) — https://arxiv.org/abs/2306.05685
- Multi-agent debate (Du et al., ICML 2024) — https://arxiv.org/abs/2305.14325
- Multi-agent debate vs aggregation — https://arxiv.org/html/2510.12697v1
- Information-theoretic ensemble selection (Greedy-MI) — https://arxiv.org/html/2602.08003
- Pydantic AI harness — fan-out / InsufficientReferencesError (#119) — https://github.com/pydantic/pydantic-ai-harness/issues/119
- LangGraph workflows & agents — https://docs.langchain.com/oss/python/langgraph/workflows-agents
- Anthropic, "Building Effective Agents" — https://www.anthropic.com/research/building-effective-agents

### Secondary / practitioner
- Structured concurrency for AI pipelines — https://tianpan.co/blog/2026-04-09-structured-concurrency-ai-pipelines-parallel-tool-calls
- Asynchronous LLM API calls in Python — https://www.unite.ai/asynchronous-llm-api-calls-in-python-a-comprehensive-guide/
- Karpathy's "LLM Council" — https://starlog.is/articles/llm-engineering/karpathy-llm-council/
- LangGraph map-reduce / Send API — https://machinelearningplus.com/gen-ai/langgraph-map-reduce-parallel-execution/