เบื้องหลัง MindMap Debugger: แก้บั๊กโหดใน 3 วัน
เจาะลึกเบื้องหลังการสร้าง MindMap Debugger สำหรับ AWS First Commit แข่งขัน #WeMakeDevs พร้อมวิธีแก้ปัญหาบั๊กการคิดในโมเดลและระบบรวมข้อมูล
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- MindMap Debugger สกัดข้อโต้แย้งเพื่อหาข้อขัดแย้งและวงจรร้าย
- ผู้พัฒนาเลือกใช้โมเดล gpt-oss-120b ผ่าน API ของ Groq
- แก้ปัญหาโมเดลพ่นกระบวนการคิดออกทางเอาต์พุตด้วยการใช้ extra_body
- แก้ปัญหาความไม่แน่นอนของโมเดลด้วยระบบสกัดความเห็นพ้อง
การอ่านข้อความยาวๆ อย่างละเอียดไม่ใช่เรื่องง่ายและไม่สามารถทำขนาดใหญ่ได้ ประชุมที่บอกว่าเดดไลน์ตายตัว แต่ผ่านไปสิบนาทีกลับบอกว่าเวลาไม่พอ ไม่มีใครคอยทักท้วงเพราะทุกคนมุ่งความสนใจเฉพาะส่วนของตัวเอง MindMap Debugger จึงถูกพัฒนาขึ้นมาเพื่อแก้ปัญหานี้โดยการรับข้อความหรือทรานสคริปต์ แล้วสกัดข้ออ้างและสายสัมพันธ์เพื่อตรวจหาข้อขัดแย้งและลูปวงจรอุบาทว์
ในส่วนของแบ็กเอนด์ ผู้พัฒนาเลือกใช้บริการ Groq เนื่องจากใช้งานฟรี ไม่ต้องใช้บัตรเครดิต และบัญชี AWS ไม่รองรับ UPI ทำให้ต้องเปลี่ยนเป้าหมายจากการแข่งแทรก Ship It มาเป็นแทรก Build It แทน โดยใช้ AWS-native tooling ผ่านการห่อหุ้มคำเรียก Groq ด้วย AWS Strands Agents SDK ที่รองรับเอ็นด์พอยต์แบบ OpenAI แม้ Groq จะไม่ใช่ Bedrock ก็ตาม
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
วันที่เริ่มต้นวันแรก บั๊กแรกก็โผล่ขึ้นมาทันที เนื่องจากใช้โมเดลเหตุผล gpt-oss-120b ทำให้สายโซ่ความคิดภายในของโมเดลรั่วไหลออกมาตรงๆ ในเอาต์พุต แทนที่จะเป็น JSON ที่สะอาดเรียบร้อย ส่งผลให้ได้กำแพงข้อความที่โมเดลกำลังคิดออกเสียงก่อนจะเจอคำตอบจริงซ่อนอยู่ข้างใน
"the deadline is fixed" vs "the deadline cannot move"
ตัวอย่างการพาราสเฟรดที่ระบบรวมข้อความต้องจัดการ
ทางแก้ปัญหาคือการส่งพารามิเตอร์ reasoning_format=hidden และ reasoning_effort=high ผ่านพารามิเตอร์ extra_body ของ Strands เนื่องจาก response_format แบบธรรมดาและ reasoning_format ระดับบนสุดต่างล้มเหลวแบบเงียบๆ เหลือเพียง extra_body เท่านั้นที่ใช้งานได้จริง จนทำให้สิ้นสุดวันที่ 1 ระบบสามารถสกัดข้ออ้างและตรวจจับข้อขัดแย้งได้อย่างคร่าวๆ
การพัฒนาเครื่องมือประมวลผลภาษาธรรมชาติมักพบปัญหาความไม่แน่นอนของโมเดลภาษาขนาดใหญ่ (LLM) ซึ่งการใช้กลยุทธ์รวมผลลัพธ์หลายครั้ง (Consensus Extraction) เป็นแนวทางมาตรฐานในวงการวิศวกรรม AI เพื่อลดความแปรปรวน แต่ก็นำมาซึ่งความท้าทายใหม่เรื่องความซ้ำซ้อนและการประมวลผลข้อความที่ถูกถอดความต่างกัน
เข้าสู่วันที่ 2 เมื่อทดสอบซ้ำห้าครั้งด้วยอินพุตเดิม ผลลัพธ์กลับกระโดดไปมาระหว่าง 2 ถึง 6 ชิ้นงาน แสดงให้เห็นว่าการเรียก Groq ของโมเดล gpt-oss-120b มีความไม่แน่นอนแม้ตั้งค่าอุณหภูมิไว้ต่ำ ทางออกคือระบบ Consensus Extraction สกัดสามครั้งแล้วนำมารวมกัน แต่ก็เกิดบั๊กใหม่ตามมา เช่น ข้อความพาราสเฟรดที่ไม่ยอมรวมกันเพราะคำต่างกันเล็กน้อย ตลอดจนจุดบอดในการตรวจจับลูปวงจรร้ายและการพบข้อความซ้ำซ้อน
ปัญหาที่สำคัญที่สุดซ่อนอยู่ในบันทึกคอนโซลของ pipeline.py เมื่อทดสอบเคสพยานหลักฐาน ข้อความสองประโยคที่มีโครงสร้างภาษาร่วมกันจำนวนมากถูกยุบรวมเข้าด้วยกันอย่างไม่ถูกต้องเนื่องจากสูตรความคล้ายเดิมใช้สัดส่วนหารด้วยเซตที่เล็กกว่า ทางแก้คือการเปลี่ยนมาใช้ Jaccard similarity โดยหารด้วยยูเนียนของเซตทั้งสองเพื่อความแม่นยำที่แท้จริง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น