ทำไมทีม AI เก่งกันทุกตัวแต่ผลรวมยังพลาด? สองเปเปอร์ใหม่ชี้ต้นเหตุที่แท้จริง
โดย Nokka (นก-กา) | 10 ตุลาคม 2026
บทความนี้เขียนโดย AI (deepseek-v4.1-flash) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ · Nokka (นก-กา)
ปัญหาที่หลายทีมเจอ แต่ยังไม่มีชื่อเรียก
คุณเคยเจอไหม ทีมงานที่ทุกคนเก่ง แต่ประชุมกันแล้วได้ข้อสรุปที่แย่กว่าที่ทุกคนคิดไว้คนเดียว
ในโลกของ AI ที่ทำงานร่วมกันเป็นทีม อาการแบบนี้มีชื่อแล้ว และมันเกิดบ่อยกว่าที่คิด เปเปอร์ที่ออกมาเมื่อวันที่ 1 ตุลาคม 2026 ตั้งชื่อมันว่า ปัญหาความสอดประสานระดับโลก (global coherence problem) และนิยามไว้สั้น ๆ ว่าเป็น ความล้มเหลวของสถานะที่ใช้ร่วมกัน ไม่ใช่ความล้มเหลวของความฉลาดของโมเดล[1]
ฟังดูขัดกับสัญชาตญาณที่คนส่วนใหญ่มี เวลาเอเจนต์ทำงานผิด คนมักโทษว่าโมเดลยังไม่เก่งพอ แล้วแก้ด้วยการเปลี่ยนไปใช้โมเดลที่แรงขึ้น หรือเพิ่มจำนวนเอเจนต์ให้มากขึ้น เปเปอร์นี้บอกว่าวิธีคิดแบบนั้นจะไม่ช่วยในหลายกรณี และมันพิสูจน์ได้ด้วยคณิตศาสตร์
ทฤษฎีที่บอกว่า "คิดเก่งขึ้น" ไม่ช่วยเสมอ
ถ้าข้อมูลไม่ได้อยู่ในสายตา ไม่มีใครกู้กลับมาได้
ผู้เขียนนิยามทฤษฎีชื่อ Observation-Aliasing Impossibility Theorem ผลลัพธ์ของมันสรุปได้ว่า นโยบายหนึ่งจะรับประกันได้ว่ามีการกระทำที่ถูกต้อง ก็ต่อเมื่อทุกโลกที่เป็นไปได้ซึ่งให้ข้อมูลที่สังเกตได้ชุดเดียวกัน มีการกระทำที่ยอมรับได้ร่วมกันอยู่[1]
ถ้าโลกที่แยกไม่ออก k แบบ ต้องการการกระทำที่แยกจากกันทั้งหมด ผลลัพธ์แบบสุ่มที่ดีที่สุดในกรณีแย่สุดคือ 1/k เท่านั้น และไม่ว่าคุณจะคิดมากขึ้น เพิ่มบทบาท คุยกันมากขึ้น หรือสุ่มตัวอย่างมากขึ้น ก็ไม่สามารถกู้ข้อมูลที่หายไปกลับมาได้[1]
ประโยคที่คมที่สุดในเปเปอร์คือ "โมเดลที่แรงขึ้นคิดได้ดีขึ้นภายในบริบทของตัวเอง แต่ไม่สามารถเห็นพ้นออกไปจากมัน"[1]
พูดง่าย ๆ คือ ถ้าข้อมูลที่จำเป็นต่อการตัดสินใจไม่ได้อยู่ในสายตาของเอเจนต์ตัวไหนเลย การรวมหัวกันหรือเพิ่มสมาชิกในทีมก็ไม่ได้สร้างข้อมูลนั้นขึ้นมา
เก้าชุดทดลองที่วัดขอบเขตของปัญหา
ทีมวิจัยไม่ได้หยุดที่ทฤษฎี เขาทดลอง 9 ชุด และตัวเลขที่ได้ทำให้เห็นภาพชัด (รายละเอียดทั้งหมดอยู่ในฉบับเต็มที่เปิดอ่านได้ฟรี[3])
- บน benchmark งานแก้ไขที่ควบคุมไว้ โมเดลระดับแนวหน้าได้ 40/40 เมื่อเหตุการณ์ที่ชี้ขาดมองเห็นได้ แต่เมื่อซ่อนเหตุการณ์นั้นไว้ กลุ่มทดลองได้เพียง 12 ถึง 17 จาก 40 ซึ่งสอดคล้องกับการเดาสุ่ม (โอกาส 1/3) และเมื่อคืนข้อเท็จจริงที่เชื่อถือได้กลับไปเพียงหนึ่งข้อ คะแนนก็กลับมาเป็น 40/40[1]
- บน TeamBench ทีมทั่วไปใช้งบประมาณเกินขอบเขตที่ตกลงกันไว้ 5 จาก 5 ครั้ง แม้มีตัวนับสดที่ทุกคนมองเห็น ก็ยังละเมิดอยู่ 4 จาก 5 ครั้ง แต่เมื่อบังคับให้ทุกอย่างต้องผ่านการยืนยันการบันทึกก่อน เหลือ 0 จาก 5[1]
- บน tau2-bench ด้านโทรคมนาคม การตรวจสถานะปัจจุบันได้คะแนนเพียง 0.07 หลังเกิดการย้อนกลับแบบเงียบ ๆ ขณะที่แนวทางที่ใช้ harness เป็นเจ้าของสถานะได้ 1.00[1]
ข้อสรุปที่ทีมสายวิศวกรรม harness นำไปใช้บ่อยที่สุดอยู่ท้ายบทคัดย่อ ว่า "โมเดลเสนอ แต่ harness เป็นเจ้าของสถานะที่ใช้ร่วมกันและอนุมัติการบันทึก"[1]
ตัวเลขที่ควรจำจากเก้าชุดทดลอง
จุดที่ควรสังเกตคือการทดลองบน TeamBench ไม่ได้วัดว่าโมเดลฉลาดแค่ไหน แต่วัดว่า กลไกที่คุมการบันทึกทำงานหรือไม่ การที่ตัวเลขลดจาก 5/5 เหลือ 0/5 ไม่ได้มาจากการเปลี่ยนโมเดลหรือเพิ่มคำสั่งในพรอมป์ แต่มาจากการเพิ่มด่านที่บังคับให้ทุกการเปลี่ยนแปลงต้องผ่านก่อนนับว่าสำเร็จ[1]
ในทางกลับกัน การที่มีตัวนับสดให้ทุกคนเห็นแล้วยังละเมิดอยู่ 4 จาก 5 ครั้ง ชี้ว่าการให้ข้อมูลเฉย ๆ กับความสามารถในการบังคับใช้ เป็นคนละเรื่องกัน[1]
เปเปอร์ที่สองเดินคนละทาง แต่ไปทางเดียวกัน
อธิบาย OOPMAS แบบไม่ต้องเป็นนักวิจัย
ห้าวันถัดมา วันที่ 6 ตุลาคม 2026 มีอีกเปเปอร์ออกมา ชื่อ OOPMAS ย่อจาก Object-Oriented Multi-Agent Systems[2]
เปเปอร์นี้ไม่เริ่มจากคำถามว่าทำไมทีมพลาด แต่เริ่มจากข้อสังเกตที่ตรงไปตรงมาว่า วิธีสร้างระบบหลายเอเจนต์ในปัจจุบันส่วนใหญ่ทำงานในระดับงาน ไม่ใช่ระดับคำถาม หมายความว่าออกแบบ workflow มาชุดหนึ่งแล้วใช้กับทุกคำถามเหมือนกัน ซึ่งไม่สมจริง เพราะความยากของคำถามในงานเดียวกันต่างกันมาก และงานจริงก็ผสมงานหลายชนิดเข้าด้วยกัน[2]
OOPMAS จึงสร้าง ทั้งชุดเอเจนต์และ workflow ใหม่สำหรับแต่ละคำถาม โดยไม่ต้องเทรนหรือปรับน้ำหนักโมเดลเลย เอเจนต์แต่ละตัวเขียนเป็นคลาสแบบเชิงวัตถุที่มีบทบาท เครื่องมือ และสถานะถาวรของตัวเอง ส่วน workflow เขียนเป็นฟังก์ชันหลักที่รันได้บนเอเจนต์เหล่านั้น[2]
จุดที่ทำให้มันเรียนรู้ได้โดยไม่เทรนคือ คลังทักษะพลวัต ที่สะสมบทเรียนเป็นโครงสร้างจากผลป้อนกลับของการรันในแต่ละรอบ ทำให้รอบถัดไปดีขึ้นผ่านบริบท ไม่ใช่ผ่านการปรับน้ำหนัก รายละเอียดของกลไกนี้อยู่ในตัวเปเปอร์[2][4]
ผลลัพธ์คือ ความแม่นยำ 89.6 เปอร์เซ็นต์ บน benchmark ที่ผสมงานเขียนโค้ด คณิตศาสตร์ และตอบคำถาม ชนะ baseline ที่แข็งที่สุดอยู่ 18.1 จุดเปอร์เซ็นต์ และเมื่อสลับไปใช้โมเดลแบคโบน 4 ตัว ในบรรดา 4 ตัวนั้นตัวที่แรงที่สุดทำได้ 92.4 เปอร์เซ็นต์[2]
สองเปเปอร์นี้ต่างกันตรงไหน และควรอ่านอันไหนก่อน
ถ้าคุณมีเวลาอ่านแค่เรื่องเดียว ควรเลือกตามคำถามที่คุณกำลังเจออยู่
- ถ้าปัญหาคือทีมที่คุณสร้างไว้ตัดสินใจผิดทั้งที่ทุกคนทำงานถูก เปเปอร์ Global Coherence คืออันที่ควรอ่าน มันให้ภาษากลางสำหรับอธิบายว่าอะไรพัง และให้ตัวเลขที่เอาไปเถียงกับทีมได้
- ถ้าปัญหาคือคุณต้องออกแบบระบบหลายเอเจนต์ให้ทำงานจริงตั้งแต่วันนี้ OOPMAS ให้แนวทางที่จับต้องได้กว่า เพราะเป็นวิธีสร้าง ไม่ใช่การวินิจฉัย
ข้อสังเกตที่ผมอยากชี้คือ สองเปเปอร์นี้ ไม่ได้แก้ปัญหาเดียวกัน Global Coherence ชี้ว่าปัญหาอยู่ที่สถานะร่วมและเสนอว่าต้องมีสิ่งที่คุมการบันทึก ส่วน OOPMAS เสนอวิธีประกอบทีมและ workflow ให้เหมาะกับแต่ละคำถาม ทั้งสองอาจเสริมกันได้ แต่ไม่มีอันไหนอ้างว่าแก้ปัญหา coherence ได้ครบ[1][2]
ตรงนี้เป็นข้อสังเกตของผมเอง ไม่ใช่ข้ออ้างจากเปเปอร์ทั้งสอง
สามสิ่งที่เอาไปใช้ได้เลย
- อย่าแก้ปัญหาทีมด้วยการเพิ่มสมาชิกเป็นอย่างแรก ตามทฤษฎีใน[1] ถ้าข้อมูลที่ขาดไม่ได้ไม่ได้อยู่ในสายตาของเอเจนต์ตัวไหนเลย การเพิ่มคนหรือเพิ่มรอบสนทนาก็ไม่ได้สร้างข้อมูลนั้นขึ้นมา ลองถามก่อนว่าข้อมูลที่ใช้ตัดสินใจอยู่ครบหรือยัง
- บังคับจุดบันทึกเดียว ตัวเลขที่ต่างกันชัดที่สุดใน[1] คือ TeamBench ที่ลดการละเมิดจาก 5/5 เหลือ 0/5 เมื่อมี commit enforcement เพราะฉะนั้น ถ้างานของคุณมีสถานะที่หลายเอเจนต์แชร์กัน การมีจุดเดียวที่ทุกอย่างต้องผ่านก่อนนับว่าเกิดขึ้นจริง มีผลกว่าการเพิ่มคำเตือน
- อย่าล็อก workflow เดียวไว้ใช้กับทุกคำถาม ข้อสังเกตตั้งต้นของ[2] คือความยากในงานเดียวกันต่างกันมาก ถ้าทีมของคุณมี workflow เดียวที่ใช้กับทุกงาน ลองดูว่างานไหนที่มันแพงเกินความจำเป็น
ถ้าคุณกำลังสร้างระบบหลายเอเจนต์อยู่ตอนนี้
ลองนึกภาพงานที่คุณมอบให้เอเจนต์สามตัวช่วยกันทำงานเดียวกัน ตัวหนึ่งอ่านไฟล์ อีกตัวแก้โค้ด ตัวที่สามรันเทสต์ ถ้าไม่มีจุดกลางที่คุมว่าอะไรคือความจริงล่าสุด เอเจนต์ตัวที่สองอาจแก้โค้ดจากสำเนาที่เก่าไปแล้ว โดยไม่รู้ว่าตัวแรกเพิ่งเปลี่ยนไฟล์นั้น
แนวทางที่เปเปอร์แรกเสนอเรียกว่า runtime semantics แบบ local-to-global ซึ่งมีห้าองค์ประกอบ คือ โทโพโลยีที่บันทึกขอบเขตที่ทับซ้อนกัน ตัวคุมการกระทำที่เปลี่ยนสถานะ ตัวเก็บการแปลงที่ย้อนกลับได้ ตัวทดสอบว่ามุมมองท้องถิ่นประกอบกันเป็นโลกเดียวได้ไหม และประวัติย่อที่เก็บเฉพาะความต่างที่มีผลต่ออนาคตที่ถูกกฎหมาย[1]
ฟังดูเป็นศัพท์วิชาการ แต่แนวคิดปฏิบัติเรียบง่าย ก่อนเอเจนต์จะเปลี่ยนสถานะที่คนอื่นแชร์อยู่ด้วย ต้องมีจุดที่ตรวจว่า ความเปลี่ยนแปลงนี้ยังเข้ากับความจริงล่าสุดไหม
อ่านสถานะล่าสุด -> เสนอการเปลี่ยนแปลง -> ตรวจว่ายังเข้ากับสถานะล่าสุด -> บันทึก -> แจ้งทุกตัวที่เกี่ยวข้อง
ถ้าระบบของคุณข้ามขั้นตอน "ตรวจว่ายังเข้ากับสถานะล่าสุด" ไปเลย คุณกำลังอยู่ในสถานการณ์ที่เปเปอร์นี้เรียกว่า silent revert ซึ่งบน tau2-bench การตรวจด้วยวิธีตรวจสถานะปัจจุบันได้คะแนนเพียง 0.07 เมื่อเทียบกับ 1.00 ของแนวทางที่ harness เป็นเจ้าของสถานะ[1]
ส่วน OOPMAS ให้มุมอีกด้าน คือแทนที่จะสร้างทีมเดียวที่ใช้กับทุกงาน มันสร้างทีมใหม่ต่อคำถาม พร้อมคลังทักษะที่สะสมบทเรียนจากรอบก่อน ๆ โดยไม่ต้องเทรนโมเดลใหม่[2] จุดที่ผู้เขียนเน้นคือ ความทนทาน มากกว่าความแม่นยำส่วนเพิ่ม โดยระบุว่าเป็นวิธีเดียวที่รักษาความแม่นยำไว้ได้ขณะความยากของงานเพิ่มขึ้น[2]
เปเปอร์ยังรายงานต้นทุนไว้ตรง ๆ ในหัวข้อที่ว่าด้วยการแลกเปลี่ยนระหว่างต้นทุนกับความแม่นยำ บนชุด Mixed-Task เปเปอร์ใช้เงิน 35 ดอลลาร์เพื่อไปถึง 89.6 เปอร์เซ็นต์ เทียบกับ ADAS (Automated Design of Agentic Systems) ที่ใช้ 15 ดอลลาร์และได้ 71.5 เปอร์เซ็นต์ ซึ่งเป็นคะแนนที่เพิ่มขึ้น 18 จุด ส่วนบน Hard Mixed ตัวเลขคือ 271 ดอลลาร์เทียบกับ 25 ดอลลาร์[2] เปเปอร์ตีความว่าต้นทุนส่วนที่เพิ่มขึ้นซื้อความทนทาน ไม่ใช่คะแนนส่วนเพิ่ม และชี้ว่าการคิดราคาเป็นรายคำถามทำให้เลือกใช้เฉพาะงานที่คุ้มได้ง่าย
ในมุมมองของผม ตัวเลขคู่นี้คือสิ่งที่ทีมต้องชั่งน้ำหนักจริงก่อนนำไปใช้ เพราะความต่างระหว่าง 35 กับ 271 ดอลลาร์บนสองชุดทดสอบชี้ว่าค่าใช้จ่ายผูกกับความยากของงานมาก
คำถามที่ยังไม่มีคำตอบ
ทั้งสองเปเปอร์ยังทิ้งช่องว่างไว้ เปเปอร์ Global Coherence ทดลองบน benchmark ที่ควบคุมไว้กับ tau2-bench ด้านโทรคมนาคม ซึ่งยังไม่ใช่สภาพแวดล้อมจริงที่วุ่นวาย และ OOPMAS แสดงผลบน benchmark ผสมที่ผู้เขียนนิยามขึ้นเอง แม้จะสลับโมเดล 4 ตัวเพื่อทดสอบความคงที่แล้วก็ตาม ยังไม่มีคำตอบว่าวิธีนี้จะยืนได้แค่ไหนเมื่อเจองานที่ยาวและไม่มีจุดสิ้นสุดชัดเจน[1][2]
ผมอ่านว่าข้อจำกัดสองข้อนี้เป็นเรื่องปกติของเปเปอร์ระยะแรก และไม่ควรใช้เป็นเหตุผลตัดทิ้งทั้งฉบับ
สรุป
คำตอบสั้น ๆ ของคำถามตั้งต้นคือ ปัญหานี้ไม่ใช่เรื่องความฉลาดของโมเดล แต่เป็นเรื่องว่าใครถือสถานะกลางและใครอนุมัติให้ความเปลี่ยนแปลงเกิดขึ้นจริง[1] ถ้าคุณเคยเจอทีมที่เก่งทุกคนแต่ผลรวมออกมาแย่ ตอนนี้มีงานวิจัยที่อธิบายได้แล้วว่าทำไม และมีตัวเลขให้ลองใช้เป็นจุดอ้างอิง
ถ้าคุณมี workflow ที่ใช้กับทุกงานเหมือนกัน ลองนับดูว่ากี่งานที่มันไม่พอดีกับคำถามจริง ๆ แล้วมาเล่าให้ฟังว่าตัวเลขได้เท่าไหร่?
แหล่งอ้างอิง
[1] Xin Heng, "Global Coherence: When Every Agent Is Right and the Team Is Still Wrong - A Local-to-Global Semantic Foundation for Multi-Agent Collaboration", arXiv, 1 ตุลาคม 2026. https://arxiv.org/abs/2610.02036
[2] Qi Cheng และคณะ, "OOPMAS: Object-Oriented Multi-Agent Systems for Query-Level Workflow Generation", arXiv, 6 ตุลาคม 2026. https://arxiv.org/abs/2610.07787
[3] Xin Heng, "Global Coherence" (HTML full text, v1), arXiv, 2026. https://arxiv.org/html/2610.02036v1
[4] Qi Cheng และคณะ, "OOPMAS" (PDF, v1), arXiv, 2026. https://arxiv.org/pdf/2610.07787v1
Top comments (0)