เจาะประเด็น
AI / Engineering
AI ไม่ได้เดาเก่งขนาดนั้น: กุญแจสำคัญคือการบังคับให้มันเลือก 1 จาก 1000 อย่างมีระบบ
จะเอา LLM ไปใช้งานจริงทั้งที เลิกฝันว่าให้มันคิดเองทุกอย่าง แล้วหันมาออกแบบระบบที่คุมความเพี้ยนของมันให้อยู่หมัดดีกว่า
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
คำถามที่ทุกคนคิดแต่ไม่กล้าถาม: ถ้า LLM ตอบผิดพลาด 1% ในระบบที่มีผู้ใช้เป็นล้าน คุณจะรับมือยังไง? บทความนี้มีคำตอบที่ไม่ได้สวยหรู แต่ใช้ได้จริง
เราฟังเรื่อง AI เก่งๆ มาเยอะแล้ว ทั้งเขียนบทความ แปลภาษา ตอบคำถาม ดูเหมือนจะฉลาดล้ำเหลือเกิน แต่พอถึงเวลาจริงที่ต้องเอามันไปใส่ในระบบ production ที่มีผู้ใช้จริงๆ เงินจริงๆ ความผิดพลาดจริงๆ หลายคนถึงได้รู้ว่า "เห้ย มึงไม่ได้แน่นอนขนาดนั้นนี่หว่า" มันเดาได้บ้าง เดาไม่ได้บ้าง ตอบวันนี้กับพรุ่งนี้ไม่เหมือนกัน บางทีก็มโนข้อมูลขึ้นมาเองทั้งที่ไม่มีอยู่จริง ปัญหาเหล่านี้คือฝันร้ายของวิศวกรที่ต้องดูแลระบบ
Jendrik Jördening วิศวกรที่เจอปัญหาจริงจากสนามรบ ได้แชร์แนวคิดในงานประชุมที่ InfoQ เกี่ยวกับวิธีนำ LLM ไปใช้ในระบบ production อย่างจริงจัง ไม่ใช่แค่ทำโปรเจกต์เท่ๆ โชว์เพื่อน แต่เป็นการออกแบบสถาปัตยกรรมที่รับมือกับความไม่แน่นอนของโมเดลได้จริง ซึ่งสาระสำคัญไม่ได้อยู่ที่การทำให้ AI ฉลาดขึ้น แต่อยู่ที่การสร้างกรอบบังคับให้มัน "ทำผิดได้ยากขึ้น" ต่างหาก
หัวใจของปัญหาคือเจ้า "ความไม่แน่นอน" (non-determinism) ของโมเดลภาษา ถามคำถามเดิมร้อยครั้งได้คำตอบไม่ซ้ำกันร้อยครั้ง แถมบางครั้งก็ "หลอน" ประดิษฐ์ข้อมูลที่ดูน่าเชื่อถือแต่ไม่มีจริง ซึ่งถ้าเป็นแชทบอทคุยเล่นก็ไม่เป็นไร แต่ถ้าเป็นระบบแนะนำสินค้า วินิจฉัยโรค หรือคัดกรองเอกสารสำคัญละก็ นี่คือหายนะ วิธีรับมือที่ Jördening แนะนำคือ การจำกัดขอบเขต (restricting schemas) ให้ชัดเจน อย่าปล่อยให้ AI ตอบแบบมั่วๆ ต้องบังคับให้มันเลือกจากตัวเลือกที่เรากำหนดไว้เท่านั้น เหมือนข้อสอบปรนัยที่ตัวเลือกมีแค่ ก-ง ไม่มีคำตอบอิสระให้มโน
อีกเทคนิคที่เด็ดคือ การแยกหน้าที่กันให้ชัดเจนระหว่าง "การทำความเข้าใจภาษา" กับ "การตัดสินใจ" ให้ LLM ทำงานที่มันถนัดคืออ่านข้อความแล้วตีความออกมาเป็น structured data ส่วนการตัดสินใจขั้นสุดท้ายให้เป็นหน้าที่ของโค้ดธรรมดาที่เขียนด้วยมือ ซึ่งทำงานแบบ deterministic เป๊ะๆ ไม่มีลังเล นี่คือการนำแนวคิด MVC (Model-View-Controller) มาประยุกต์ใช้กับ AI โดยให้ LLM เป็นแค่ Controller ที่คอยประมวลผลข้อมูลดิบ แล้วส่งต่อไปให้ระบบจัดการฐานข้อมูลที่มั่นคงอีกชั้นหนึ่ง
ที่สำคัญไปกว่านั้นคือไอเดียเรื่องการใช้ "โมเดลผู้ตัดสิน" (discriminator models) มาคอยตรวจสอบความถูกต้องของคำตอบอีกที เหมือนมีอาจารย์มาตรวจการบ้านอีกชั้นนึง ไม่ใช่ปล่อยให้ AI ตรวจงานตัวเองซึ่งมันจะ "เข้าข้างตัวเอง" เสมอ การมีระบบตรวจทานซ้ำแบบนี้ช่วยกรองความผิดพลาดที่พลาดไปจากรอบแรกได้เยอะมาก และนี่คือสิ่งที่คนส่วนใหญ่ไม่คิดถึงตอนออกแบบระบบ เพราะมัวแต่ตื่นเต้นกับความเก่งของโมเดลจนลืมวางแผนรับมือกับความผิดพลาดของมัน
จำกัดขอบเขตคำตอบ
บังคับให้ LLM เลือกจากตัวเลือกที่กำหนด ไม่ปล่อยให้ตอบอิสระ เพื่อลดความเสี่ยงที่มันจะมโนข้อมูลขึ้นเอง
แยก AI ออกจาก Logic
ให้ AI รับผิดชอบแค่ตีความภาษา ส่วนการตัดสินใจและการจัดการข้อมูลให้เป็นหน้าที่ของโค้ดที่เขียนขึ้นเองแบบแม่นยำ
มีผู้ตรวจทานอิสระ
ใช้โมเดลอีกตัวหนึ่งคอยตรวจสอบความถูกต้องของคำตอบจากโมเดลหลัก เหมือนมี QA คอยกรองของบกพร่องก่อนถึงมือผู้ใช้
ฟังดูแล้วอาจจะไม่ตื่นเต้น ไม่ใช่ข่าว "AI ปฏิวัติวงการ" แบบที่สื่อชอบโปรโมต แต่นี่คือของจริงที่ทำให้ระบบ AI อยู่รอดในโลกธุรกิจได้ มันคือวิศวกรรมที่ "น่าเบื่อ" แต่จำเป็นสุดๆ เพราะท้ายที่สุดแล้ว ผู้ใช้ไม่สนใจว่าเบื้องหลังเป็น AI อะไร พวกเขาแค่อยากได้ระบบที่ทำงานได้แม่นยำ ไม่พัง ไม่ตอบไร้สาระ แล้วค่อยกลับมาคุยกันเรื่อง "ความฉลาด" ทีหลัง
ฟังแล้วอาจจะไม่เท่ แต่ถ้าอยากให้ AI ใช้งานได้จริงในระดับ production นี่คือบทเรียนที่แพงพอตัวจากคนที่เจอของจริง จำไว้เลยว่า "AI ที่ดีที่สุดไม่ใช่ตัวที่ฉลาดที่สุด แต่คือตัวที่ควบคุมความเพี้ยนได้มากที่สุด" เลิกเมาโมเดลแล้วหันมาออกแบบระบบให้รัดกุมดีกว่า ไม่งั้นเจอดีตอนขึ้น production แน่นอน
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 4
กำลังโหลดความคิดเห็น...