- 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 แบบ
- ประเมินคำตอบทั้งหมด
- เลือกคำตอบที่ดีที่สุด
- คำตอบสุดท้ายคือผลลัพธ์ที่ผ่านการสร้างทางเลือกและประเมินซ้ำหลายครั้งแล้ว
การทดสอบและตัวอย่าง
- มีการทดสอบโดยนำ CoRT ไปใช้กับ Mistral 3.1 24B
- README ระบุว่าเวอร์ชันที่ใช้ CoRT ให้ผลลัพธ์ดีกว่าเวอร์ชันที่ไม่ใช้ CoRT โดยเฉพาะใน งานเขียนโปรแกรม
- มีภาพตัวอย่างผลลัพธ์ของ Mistral 3.1 24B + CoRT และ Mistral 3.1 24B non CoRT รวมอยู่ด้วย
วิธีรัน
- Web UI ยังอยู่ใน ระยะพัฒนาเริ่มต้น
- บน Windows แนะนำให้เปิด
start_recthink.bat แล้วรอจนการติดตั้ง dependency เสร็จสิ้น
- ขั้นตอนการรันบน Linux มีดังนี้
pip install -r requirements.txt
cd frontend && npm install
cd ..
python ./recthink_web.py
- จากนั้นรัน frontend ในเชลล์ใหม่
cd frontend
npm start
การรันโดยตรงและองค์ประกอบหลัก
- หากต้องการรันโดยตรง ให้ติดตั้ง dependency ตั้งค่า
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
- รับ contribution ผ่าน PR ได้ และใช้สัญญาอนุญาต MIT
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
มักเห็นกระแสที่เชื่อว่า ถ้านำโมเดลหลายตัวมาแข่งกันหรือรันเป็นกลุ่มแล้ว ปัญญารวมหมู่ จะเกิดขึ้นราวกับเวทมนตร์ แต่หลังจากได้ทดลองเองและดูงานของ ASU/Microsoft Research แล้ว ผมได้ข้อสรุปที่เรียบง่ายกว่า: LLM เป็นตัวตรวจสอบของ LLM ตัวอื่นได้แย่มาก
ในการบรรยาย “(How) Do LLMs Reason/Plan?” ของ Subbarao Kambhampati นั้น GPT-4 สร้างบทพิสูจน์การระบายสีกราฟที่พิสูจน์ได้ว่าผิดขึ้นมาอย่างมั่นใจ จนกระทั่งมีตัวแก้ปัญหา SAT เชิงสัญลักษณ์เข้ามาเป็นผู้ตัดสิน https://www.youtube.com/watch?v=0u2hdSpNS2o
งานวิจัยของ Stechly และคณะวัดเชิงปริมาณว่า เมื่อให้ GPT-4 วิจารณ์คำตอบของตัวเอง ความแม่นยำกลับลดลง และเมื่อใส่ตัวตรวจสอบภายนอกที่ sound เข้าไป จะทำให้ดีขึ้นราว 30 จุดเปอร์เซ็นต์ในงานวางแผนและโจทย์ปริศนาโดยรวม https://arxiv.org/abs/2402.08115
กล่าวคือ สำหรับโมเดล autoregressive ในปัจจุบัน การตรวจสอบยากกว่าการสร้าง และจำเป็นต้องมีตัวตรวจที่ให้เหตุผลเกี่ยวกับโลกได้จริง เช่น compiler, linter, SAT solver หรือชุดข้อมูลคำตอบที่ถูกต้อง
ดังนั้นการซ้อน LLM หลายตัวเข้าด้วยกันโดยทั่วไปแทบไม่ช่วยอะไรนัก บทความแสดงจุดยืน “LLM-Modulo” ก็เห็นว่าโมเดล autoregressive ไม่สามารถตรวจสอบตัวเองหรือวางแผนระยะยาวเองได้ และควรถูกมองเป็นตัวสร้างไอเดียที่มี recall สูง จากนั้นครอบด้วยตัวตรวจสอบเดียวที่ sound https://arxiv.org/abs/2402.01817
เมื่อลองทดสอบเอง พบว่าการเปลี่ยนจากการให้โมเดล 5 ตัวถกเถียงกัน มาเป็นโมเดลที่แข็งแกร่งตัวเดียวพร้อมตัวตรวจสอบ ให้คำตอบเท่ากันหรือดีกว่า และมี latency กับภาระการ orchestration น้อยกว่ามาก
หนังสือหรือภาพยนตร์เป็นตัวอย่างที่ดี การบอกว่าตัวละครตื้นเขินนั้นง่าย แต่การสร้างตัวละครที่ลึกซึ้งและน่าสนใจกลับยากอย่างน่าประหลาด
ในวิศวกรรมซอฟต์แวร์ก็คล้ายกัน LLM ที่ได้รับพรอมป์ให้ค้นหาช่องโหว่ด้านความปลอดภัย สามารถชี้จุดในโค้ดที่สร้างขึ้นซึ่งอาจมีความเปราะบางได้
แต่ถ้าคาดหวังให้ LLM อีกตัวหนึ่งหาข้อผิดพลาดในการให้เหตุผลของบทพิสูจน์ทางคณิตศาสตร์ ก็แทบต้องทำการให้เหตุผลทั้งหมดใหม่ จึงน่าสงสัยว่าจะมีการยกระดับประสิทธิภาพอย่างมีนัยสำคัญหรือไม่
ในเฟรมเวิร์กอย่าง LangChain หรือ LlamaIndex ก็ฝังอยู่ลึกในการประเมิน pipeline แบบ RAG ด้วย https://arxiv.org/abs/2411.15594
ผมสงสัยว่าวิธีให้ LLM สร้าง unit test สำหรับโค้ดที่มันสร้างขึ้นมาพร้อมกัน แล้วรันรวมกับ unit test ของแอปพลิเคชันที่มีอยู่ทั้งหมด จะเป็นอย่างไร
หากตรวจได้ว่าโค้ด compile ได้หรือไม่ และ unit test ผ่านหรือไม่ ก็จะทำให้มี การตรวจสอบที่มีหลักฐานรองรับ ได้ในระดับหนึ่ง และ AI สามารถอ่านผลการทดสอบเพื่อนำไปแก้ข้อผิดพลาดของตัวเองได้
การฝึกด้วยข้อมูลคลังข้อความอาจสร้างการก้าวกระโดดได้ในระดับหลักเดียว แต่การฝึกด้วยข้อมูลปฏิสัมพันธ์ที่มี OODA loop ซึ่งสังเกตและปรับตัวได้ จะทรงพลังกว่ามาก
ถ้าผมทำ AI อยู่ก็คงทำแบบนั้นเหมือนกัน แต่ในความเป็นจริงตอนนี้ผมกำลังทำ BrowserBox อยู่
generate-and-test จำเป็นต้องมีอัลกอริทึมตรวจสอบที่เชื่อถือได้ ค่อนข้างเร็ว และใช้หน่วยความจำอย่างมีประสิทธิภาพ และจะมีประโยชน์เป็นพิเศษเมื่ออัลกอริทึมสร้างที่แม่นยำซึ่งสร้างเฉพาะคำตอบที่ถูกต้องนั้นช้า หรือใช้หน่วยความจำมาก
ในที่นี้ ตัวสร้างก็คือ LLM และตัวตรวจหรือ “ตัวตรวจสอบ” ก็คือ compiler, linter, SAT solver, ชุดข้อมูลคำตอบที่ถูกต้อง เป็นต้น
generate-and-test ยังเกี่ยวข้องกับการลองผิดลองถูกด้วย และการลองผิดลองถูกก็คงมีมาตั้งแต่ยุคหินเก่าแล้ว
วิธีที่ใช้บ้างเป็นครั้งคราวคือให้โมเดลแชต AI ตอบปัญหาออกมาก่อน แล้วให้มันเขียนเป็น รายงาน ว่าทำไมคำตอบนั้นถึงถูกต้อง ในแบบที่คนหรือ AI ที่ไม่รู้โจทย์ตั้งต้นหรือสาขาเทคนิคที่เกี่ยวข้องก็เข้าใจได้
จากนั้นให้โมเดล AI ตัวที่สองซึ่งไม่รู้ปัญหานั้นให้คะแนนรายงาน และเขียนรายงานที่ขอคำอธิบายที่โมเดลเดิมไม่ได้ให้ไว้ หรือชี้ความไม่สอดคล้องทางตรรกะ
แล้วส่งรายงานนี้กลับไปให้โมเดลเดิม ให้มันเขียนคำตอบใหม่โดยสะท้อนข้อมูลหรือการแก้ไขที่จำเป็น จากนั้นทำซ้ำจนกว่าโมเดลที่สองจะถูกโน้มน้าวได้ หรือโมเดลแรกสะท้อนคำขอแก้ไขทั้งหมดแล้ว
เป็นวิธีที่ดิบมาก แต่เท่าที่ลองมาก็ได้ผลค่อนข้างดี
แผนสุดท้ายมักจะออกมาสมดุลและผ่านการไตร่ตรองมากขึ้นมาก
ที่น่าสนใจคือเทคนิคนี้ใช้กับตัวเองก็ได้ผลดีด้วย การลองหาข้อบกพร่องก่อนกลับไปทบทวนแผนช่วยได้จริง ๆ
เช่น ห้องหนึ่งเน้นเทคนิค ห้องหนึ่งเน้นการตลาด และอีกห้องมีบริบทเกี่ยวกับเป้าหมายส่วนตัว
ถ้าใส่คำถามเดียวกันลงในแชตที่มีบริบทต่างกัน ก็คล้ายกับการมองปัญหาเดียวกันจากหลายมุมมอง และข้อสรุปก็อาจแตกต่างกันไม่น้อยตามบริบท
ดูเหมือนเป็นไอเดียที่ค่อนข้างดี แต่คงใช้โทเคนเพิ่มขึ้นมาก
อีกอย่างที่น่ากังวลคือ ถ้า LLM ที่ใช้เป็นผู้ตัดสินไม่สามารถสร้างคำตอบที่ดีพอได้ตั้งแต่แรก มันก็อาจมีปัญหาในการให้คะแนนอย่างแม่นยำด้วย
อยากลองทำสิ่งนี้ในสเกลที่ใหญ่ขึ้น เป็น วุฒิสภาอภิปรายที่เปิดอยู่ตลอดเวลา
แทนที่จะตอบพรอมป์เป็นครั้ง ๆ ก็ให้รายการงานที่อาจมีเดดไลน์ แล้วให้วุฒิสภาทำงาน แยกเป็นกลุ่มสำหรับงานย่อย ท้าทายผลลัพธ์ และเสนอแนะ
ยิ่งไปกว่านั้น อาจสร้างต้นไม้ของนักวิเคราะห์ โดยให้โหนดแม่ส่งข้อเสนอขึ้นไปก็ต่อเมื่อเห็นว่าการวิเคราะห์ย่อยนั้นมี insight เป็นพิเศษ
เห็นชัดเจนว่าการสั่งให้โมเดลเข้าหาปัญหาจากมุมมองเฉพาะอาจทำให้ผลลัพธ์ดีขึ้นหรือแย่ลงได้ ถ้าสร้างมุมมองหลากหลายพร้อมการวิเคราะห์เชิงวิพากษ์ต่อผลลัพธ์เหล่านั้น ก็น่าจะได้ผลลัพธ์ที่น่าประทับใจ
วิธีนี้จะสร้างโทเคนจำนวนมหาศาล แต่ต้นทุนต่อโทเคนกำลังเดินไปในทิศทางที่ทำให้เป็นไปได้ นอกจากนี้ยังมีความเป็นไปได้ที่จะสร้างเซิร์ฟเวอร์ IRC สำหรับ AI โดยเฉพาะ ที่ใครก็เชื่อมโมเดลของตัวเองเข้ามาได้ แล้วใช้เหมือนพื้นที่อภิปรายร่วมกัน
พอเสียเวลาลองทำแล้วติดปัญหากลับมา มันก็พูดเบา ๆ ว่า “ใช่ครับ หาเจอได้ดีมาก! เกือบถึงแล้ว! ขั้นต่อไปคือ X กับ Y” แล้วก็ให้ tutorial ละเอียดแบบเดิม โดยเปลี่ยนแค่ส่วนอย่าง flag ที่ผิดไปเล็กน้อย
ให้ความรู้สึกเหมือนต้องรับมือกับอินเทิร์นที่กระตือรือร้นเกินเหตุและโยนงานมาโดยไม่ตรวจสอบ ถ้าเอาบอตตัวที่สองมานั่งหน้าบอตตัวแรกแล้วให้ถามว่า “แน่ใจจริง ๆ เหรอ?” ก็น่าจะดีขึ้นไม่น้อย
ทำโดยอิงแนวคิดที่ปรึกษาจาก Civilization II และมันทำงานได้ค่อนข้างดี แต่ก็มีข้อจำกัดอยู่บ้างเพราะผูกกับ Mistral ซึ่งเป็น LLM ตัวเดียว
และมันหนักจนแทบเผาเครื่องคอมพิวเตอร์ของผม
ถ้าให้เวลาและโทเคนมากพอ ก็น่าสนใจว่าจะสร้างอะไรออกมาได้
กลยุทธ์ที่ง่ายกว่าและจำกัดกว่ามากซึ่งใช้บ่อย คือเติมท้ายข้อความว่า “ก่อนตอบ ให้คิดหนึ่งรอบในแท็ก วิจารณ์ตัวเองหนึ่งรอบในแท็ก แล้วสุดท้ายค่อยเขียนคำตอบสุดท้าย”
ใช้ได้ค่อนข้างดี ในทำนองเดียวกัน แค่บอกว่า “ช่วยหาปัญหาใหญ่ที่สุด 5 ข้อในข้อเสนอนี้” ก็โอเค แต่ถ้าบังคับให้มี 5 ข้อ ส่วนใหญ่แล้วมันจะหาอะไรบางอย่างมาได้ แม้จะเกี่ยวข้องน้อยก็ตาม
ขั้นที่ 1 ให้มันวางแผน ขั้นที่ 2 ให้ชี้ข้อบกพร่องของแผน ขั้นที่ 3 ให้อัปเดตแผนโดยสะท้อนข้อบกพร่อง
คำถามอื่นที่ถามบ่อยคือ “เราพลาดอะไรไป?”, “มีข้อควรพิจารณาด้าน performance, security, legal, cost อะไรบ้าง?”
พรอมป์ชี้นำแบบ “มีอีกไหม?” ก็ทำซ้ำได้หลายครั้ง และจะดีเป็นพิเศษถ้าชี้หัวข้อที่ควรพิจารณาให้ ทุกครั้งที่จบก็ให้ปรับแผนใหม่โดยสะท้อนข้อพิจารณานั้น
ต่างจากที่คาดไว้จากชื่อเรื่องเล็กน้อย คิดว่าจะเป็น กระบวนการแบบโต้แย้งกันอย่างชัดเจน
ยังไม่ได้ลองทำเอง และก็ไม่รู้ว่าจะได้ผลหรือไม่ แต่การถาม ChatGPT ด้วยพรอมป์แยกกันว่า “XYZ เป็นจริง จงอธิบายเหตุผล” และ “XYZ เป็นเท็จ จงอธิบายเหตุผล” แล้วดูว่าฝั่งไหนน่าเชื่อกว่าก็ช่วยได้
https://github.com/evalstate/fast-agent
ไม่เข้าใจว่าทำไมถึงมีคนคิดว่านี่เป็นของใหม่ อาจสะท้อนสภาพของ HN ก็ได้
แนวทางนี้ดูดี แต่ห้ามบอกเป็นนัยตรง ๆ ว่า “คุณผิด” เด็ดขาด ปกติมันจะสมมติไปเลยว่าตัวเองผิด
แต่กลับน่าประทับใจเวลาทำแบบนี้แล้วมันยังโต้กลับและปกป้องตัวเองจริง ๆ
การทดลองแบบนี้ค่อนข้างสนุก ผมเลยกำลังทำ ตัวแก้ไขกราฟสไตล์ Blueprint ของ Unreal Engine ให้ผู้คนออกแบบเวิร์กโฟลว์แบบนี้ได้
รูปแบบคือพรอมป์ของผู้ใช้เข้าไปยังเอเจนต์หนึ่งเพื่อสร้างความพยายามครั้งแรก จากนั้นประวัติการสนทนานั้นถูกส่งต่อไปยัง “เอเจนต์” ที่มี system prompt อีกแบบให้กลายเป็นนักวิจารณ์สุดโหด ส่งสัญญาณผ่าน/ไม่ผ่าน แล้ววนลูปจนกว่านักวิจารณ์จะตัดสินว่าผ่าน ก่อนส่งผลลัพธ์ให้ผู้ใช้
เว็บไซต์เล็ก ๆ ที่เรียกใช้ LLM endpoint ของตัวเอง และบันทึก/โหลด/แชร์กราฟเวิร์กโฟลว์ได้ น่าจะเป็นอุดมคติ
Mistral Small 3.1 และ Gemma 3 รู้สึกเหมือนเป็นโมเดลชุดแรกที่พอมีความสามารถในระดับครึ่ง ๆ กลาง ๆ และรันในเครื่องได้ แต่ความสามารถนั้นเป็นแค่เมล็ดพันธุ์เท่านั้น ยังต้องมีเฟรมเวิร์กคอยรักษาให้อยู่ในเส้นทางต่อไป
ถ้าให้สิทธิ์รัน Python ในลูปการทำซ้ำและสั่งให้สำรวจโลก มันจะเริ่มดาวน์โหลดและอ่านอะไรอย่างข่าว
ตัวอย่างเช่น ถ้าสั่ง GPT ให้ทำตัวร้าย ๆ ก็สามารถเลียนแบบความสามารถของ Gemini ในการจับเรื่องไร้สาระหรือความคิดที่หละหลวมได้ในระดับหนึ่ง ดูเหมือนว่าความสุภาพจะกรองสิ่งมีค่าหลายอย่างออกไป
แต่ผลลัพธ์จะอ่านแล้วไม่สบายใจ Gemini ดูเหมือนจะแก้ด้วยการจัดการเรื่องนี้เป็นสองขั้นในระหว่างการฝึก และทำให้ขั้นแรกเป็น “ความคิด” แบบไม่เปิดเผย
ดังนั้นผมคิดว่าสิ่งที่ต้องการคือแนวทาง 2 ขั้นที่ปรับผลลัพธ์ “ใจร้าย” นั้นให้นุ่มนวลแบบมนุษย์ขึ้นเล็กน้อย ถ้าทำงานแบบนั้นนานเกินช่วงสั้น ๆ ก็จะค่อนข้างเหนื่อย
UI แชตกลุ่ม ที่มีบุคลิก LLM ต่าง ๆ กันก็น่าจะมีคุณค่ามาก รูปแบบออบเจ็กต์ข้อความดูเหมือนออกแบบเผื่อผู้ใช้หลายคนและ AI หลายตัว เช่น ให้แต่ละข้อความมีชื่อ แต่ยังไม่เคยเห็น UI แบบนั้น
ถ้ารองรับผู้ให้บริการหลายรายก็ยิ่งดี เพราะแต่ละรายมีจุดแข็งต่างกัน คล้ายกับการขอความเห็นที่สอง
consortium ส่งพรอมป์เดียวกันไปยังหลายโมเดลแบบขนาน แล้วส่งคำตอบทั้งหมดให้โมเดลผู้ไกล่เกลี่ยประเมิน ผู้ไกล่เกลี่ยจะตัดสินว่าจำเป็นต้องทำซ้ำอีกหรือไม่
จะบังคับให้ทำซ้ำเพิ่มจนกว่าจะถึงเกณฑ์ความเชื่อมั่นหรือจำนวนรอบขั้นต่ำก็ได้
ถ้าใช้ PR ที่ทำไว้ใน llm-openrouter จะบันทึก alias ของโมเดลที่รวมตัวเลือกโมเดลหลายอย่างได้ เช่นสร้างผู้เชี่ยวชาญด้านการค้นคว้าออนไลน์ด้วย
llm openrouter save -m qwen3 -o online -o temperature 0, system "research prompt" --name qwen-researcherสมาชิกอื่นอาจให้ทำการสกัดออบเจ็กต์ในโหมด JSON และอีกสมาชิกหนึ่งให้เขียนร่างแบบ blind ได้ ผู้ไกล่เกลี่ยจะใช้ทั้งหมดนี้มาสังเคราะห์เป็นคำตอบที่ดี
ต้องรีบหาวิธีใช้ พลังงานสีเขียว ขับเคลื่อน GPU พวกนี้ ไม่อย่างนั้น AI จะถกเถียงกันเองเรื่องวิธีแก้ tic-tac-toe ที่เหมาะที่สุดจนทำให้โลกละลาย
บางครั้งมันเป็นวิธีที่ง่ายที่สุดในการทำงานเล็ก ๆ ให้เสร็จ แต่ส่วนต่างของต้นทุนฝั่งแบ็กเอนด์ต้องค่อนข้างมากแน่ ๆ สุดท้ายผู้ใช้จะไม่สนใจเลย เพราะมันไม่รู้สึกเป็นรูปธรรม
การที่ AI ต้องรันแข่งกับตัวเองไปเรื่อย ๆ ถูกยอมรับเหมือนเป็นความจริงไปแล้ว
ผมคิดว่านี่คือวิธีทำให้โมเดลแมชชีนเลิร์นนิงสร้าง ไอเดียใหม่
คือการทำ diagonalization ผ่านการถกเถียงกับตัวเองเหนือไอเดียทั้งหมดที่เคยลองและทิ้งไปแล้ว แต่ยังรักษาข้อจำกัดด้านความสอดคล้องบางอย่างไว้ แน่นอนว่าทำจริงยากกว่าพูดมาก
มันคือ Conway's Game of Life แต่แทนที่จะเป็นช่องสี่เหลี่ยมสีที่มีกฎ ก็เป็น LLM ที่มีน้ำหนักบางอย่างคุยกันไม่หยุด แล้วผุดขึ้นมาเป็นคำพูดหรือการกระทำที่ไหนสักแห่ง
https://news.ycombinator.com/item?id=43835798
สิ่งนี้จะไปได้ไกลแค่ไหน? จะเกิด ทีมสกรัมของ AI agent ที่ประชุมสแตนด์อัปกันทุก ๆ ไม่กี่ชั่วโมงไหม?
เราจะจำลองระบบราชการของรัฐด้วยเหล่า agent ที่ถกเถียงหัวข้อกันทั้งวันเพื่อหามุมมองที่ดีที่สุดหรือเปล่า?
เขาให้ AI agent ที่มีบทบาทต่างกันมาบริหารทีมสกรัม และพรอมป์ตของแต่ละ agent ถูกตั้งให้คัดค้านทุกคนหรือเสนอจุดยืนของตัวเองอย่างวิพากษ์วิจารณ์มาก ๆ ส่วนการตัดสินใจขั้นสุดท้ายให้ผู้ไกล่เกลี่ยเป็นคนทำ
ผู้นำเสนออ้างว่าวิธีนี้ได้ผลดีกับพวกเขา
มนุษย์มีประสบการณ์และมุมมองที่แตกต่างกัน แต่ LLM อาจไม่ได้ต่างกันถึงขนาดนั้น ถึงอย่างนั้น บางครั้งแค่สวมหมวกอีกใบก็เพียงพอแล้ว เช่น ความแตกต่างระหว่างผู้รีวิวโค้ดกับคนเขียนโค้ด
สักวันหนึ่งคงมีจุดที่ผลลัพธ์เริ่มราบลง และก็คงจะมีคณะกรรมการ AI เพื่อกำหนดจุดนั้นด้วย
เพราะคงไม่มีใครอยาก “ต้มทะเล” หรอก
ดีที่ทำให้ฟอร์กมาลองเล่นได้ง่าย
ตอนนี้ผมเพิ่งเริ่มงานวนซ้ำของตัวเอง โดยเพิ่ม Nash Equilibrium และตีกรอบ “prompt engineering” ใหม่ให้เป็นการเจรจาแบบหลาย agent อยากรู้ว่าคนอื่นคิดอย่างไร
https://github.com/faramarz/NECoRT/
ผมประเมินว่า LLM สำหรับองค์กรคงไม่มีปัญหาใหญ่กับต้นทุนการคำนวณที่เพิ่มขึ้น และจะชอบแนวทางการปรับแต่งการเงินที่ซับซ้อนผ่านการเพิ่มประสิทธิภาพการโมเดลหลายรูปแบบมากกว่า
ผมยังไม่ค่อยคุ้นกับ repository สาธารณะและการรับ contribution เท่าไร ถ้าผมทำอะไรผิดก็อยากให้ใครสักคนช่วยชี้แนะ
เจตนาคือฟอร์ก codebase ต้นฉบับมาเพื่อทดสอบทฤษฎี และท้ายที่สุดจะส่งเป็น PR