ทดลองให้ 2 AI Agents ท้องถิ่นสร้างแอปพลิเคชันเอง
โปรเจกต์ RelayLab ใช้ Ollama และโมเดล local อย่าง qwen เพื่อให้ AI ตัวหนึ่งเป็นผู้พัฒนาและอีกตัวเป็นผู้ตรวจทานโค้ดแบบอัตโนมัติ
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ผู้ใช้ทดลองสร้างระบบ multi-agent แบบ local ทั้งหมดด้วย Ollama, Python และพีซีส่วนตัว
- แบ่งบทบาทเป็น Builder (ผู้สร้าง) และ Reviewer (ผู้ตรวจทานโค้ด) ผ่านโปรเจกต์ชื่อ RelayLab
- เผชิญปัญหาฮาร์ดแวร์โอเวอร์โหลดและปัญหาการตั้งค่า Ollama ก่อนจะปรับขนาดโมเดลให้เหมาะสม
- ตัวตรวจทานโค้ดพยายามส่งสถานะที่นอกเหนือจากที่กำหนดไว้จนทำให้ระบบพังและต้องเขียนตัวดักจับข้อผิดพลาด
การใช้งานปัญญาประดิษฐ์ในการเขียนโค้ดและพัฒนาซอฟต์แวร์กลายเป็นเรื่องปกติในปัจจุบัน แต่การปล่อยให้โมเดล AI สองตัวทำงานร่วมกันโดยส่งต่องานไปมาระหว่างกันโดยปราศจากการแทรกแซงของมนุษย์ถือเป็นเรื่องที่ท้าทายและน่าสนใจ โดยผู้พัฒนาได้ทดลองสร้างระบบจำลองที่ไม่มีการเรียกใช้ API จากค่ายใหญ่อย่าง OpenAI หรือ Claude แต่เลือกใช้ Ollama ร่วมกับภาษา Python บนคอมพิวเตอร์ส่วนตัว
ไอเดียหลักของโปรเจกต์นี้มีชื่อว่า RelayLab ซึ่งประกอบด้วยโมเดล AI สองบทบาทหลัก ได้แก่:
- Builder: ทำหน้าที่อ่านคำขอผลิตภัณฑ์ ตรวจสอบพื้นที่ทำงาน และสร้างหรือแก้ไขแอปพลิเคชัน
- Reviewer: ทำหน้าที่รับงานต้นฉบับ ตรวจสอบสิ่งที่ Builder สร้างขึ้น และพิจารณาอนุมัติหรือขอให้ปรับ
ในตอนแรกผู้พัฒนาได้เลือกใช้โมเดลขนาดใหญ่ ได้แก่ qwen2.5-coder:7b สำหรับ Builder และ qwen3:8b สำหรับ Reviewer แต่ผลลัพธ์ที่ได้คือหน่วยประมวลผลกลางหรือ CPU พุ่งสูงถึงร้อยละ 100 จนเครื่องเกือบใช้งานไม่ได้ เนื่องจาก Ollama เก็บโมเดลทั้งสองไว้ในหน่วยความจำระหว่างรอบการทำงาน ทำให้หน่วยความจำบนการ์ดจอไม่พอและต้องไปประมวลผลบนซีพียูแทน
เพื่อแก้ปัญหาดังกล่าว จึงต้องมีการปรับลดขนาดโมเดลลงเหลือ qwen2.5-coder:3b สำหรับ Builder และ qwen3:4b สำหรับ Reviewer พร้อมทั้งปรับแต่งการตั้งค่าคำขอใน Ollama ให้ใช้งานคำสั่ง keep_alive: 0 เพื่อบังคับให้โมเดลล้างข้อมูลออกจากหน่วยความจำทันทีหลังจบแต่ละรอบการทำงาน ช่วยป้องกันไม่ให้ AI ทั้งสองตัวแย่งพื้นที่ VRAM กัน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ก่อนที่ระบบจะเริ่มทำงานได้จริง ยังพบอุปสรรคทางเทคนิคเพิ่มเติมเมื่อพบว่าการติดตั้ง Ollama ขาดส่วนประกอบสำคัญ ทำให้เกิดข้อผิดพลาด llama-server binary not found แม้จะดาวน์โหลดโมเดลและใช้งานคำสั่งตรวจสอบสถานะผ่าน CLI ได้ปกติก็ตาม หลังจากทำการติดตั้งใหม่ได้อย่างถูกต้อง ระบบจึงพร้อมสำหรับการทดสอบจริง
การรันโมเดลภาษาขนาดเล็ก (Small Language Models) ในเครื่องคอมพิวเตอร์ส่วนตัวแสดงให้เห็นถึงความก้าวหน้าสำคัญในการพัฒนาซอฟต์แวร์แบบออฟไลน์ แม้ระบบอัตโนมัติเหล่านี้จะยังขาดความยืดหยุ่นเทียบเท่า API ขนาดใหญ่ แต่การจัดการเรื่องการจัดการทรัพยากร VRAM และการตีความผลลัพธ์ JSON จาก AI ที่อยู่นอกเหนือกรอบเป็นบทเรียนสำคัญสำหรับนักพัฒนาในการสร้างระบบ Orchestration ที่มีความทนทานต่อความผิดพลาดสูง
สำหรับการทดสอบรอบแรก ผู้พัฒนาได้ป้อนโจทย์ง่ายๆ ให้ระบบสร้างแอปพลิเคชันจดบันทึกหน้าเดียวที่สามารถสร้าง ทำเครื่องหมายเสร็จสิ้น และลบโน้ตได้ โมเดล Builder เริ่มต้นสร้างไฟล์ index.html และผ่านกระบวนการส่งให้ Reviewer ตรวจสอบซ้ำแล้วซ้ำเล่าในรอบที่ 1 รอบที่ 2 และรอบที่ 3 โดยที่มนุษย์ไม่ต้องลงมือเขียนโค้ดเองเลยแม้แต่น้อย
"[round 3] builder wrote 1 file(s); reviewer: changes_requested"
RelayLab Log
อย่างไรก็ตาม ระบบเกิดข้อผิดพลาดขึ้นเมื่อ Reviewer ส่งสถานะกลับมานอกเหนือจากที่โปรแกรมกำหนดไว้ เช่น การส่งคำว่า rejected หรือ needs_changes แทนที่จะเป็น approved หรือ changes_requested ตามที่ระบบตั้งค่า enum ไว้ ส่งผลให้เกิดข้อผิดพลาด AgentProtocolError และทำให้โปรแกรมหยุดทำงานในที่สุด ผู้พัฒนาจึงต้องแก้ไขโค้ดตัวกลาง (Orchestrator) ให้มีความยืดหยุ่นมากขึ้นด้วยการแปลงคำศัพท์ต่างๆ ให้กลับมาเป็นสถานะมาตรฐานที่ระบบเข้าใจได้
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น