เจาะประเด็น
AI / LLM
ปัญหา AI มั่วไม่ได้แก้ที่โมเดล แต่อยู่ที่โครงสร้างพื้นฐานที่ไม่มีใครอยากสร้าง
บทเรียนจากระบบแนะนำสินค้าคงคลังที่ AI ตอบมั่ว จนต้องรื้อวิธีคิดใหม่ทั้งหมด
ทีมข่าว เอไอไทย.com
⏱ อ่าน 3 นาที
ถ้า AI ตอบผิดซ้ำๆ หลายทีม ปัญหาอาจไม่ใช่ที่ตัวโมเดล แต่คือเรายังไม่มี "แพลตฟอร์ม" กลางให้ทุกคนเกาะ
เรื่องนี้เริ่มจากประสบการณ์ตรงของ Aditya Mulik ที่เจอปัญหา AI agent "hallucinate" หรือตอบมั่วในระบบแนะนำสินค้าคงคลัง (inventory recommendation system) ซึ่งฟังดูเหมือนปัญหาธรรมดาของคนทำ AI ทั่วไป แต่ประเด็นที่เขาชี้คือ วิธีที่ทีมแก้ปัญหาต่างหากที่น่าสนใจ
แทนที่จะไปนั่งจูน prompt หรือเปลี่ยนโมเดลให้ฉลาดขึ้น เขาเลือกมองว่า LLM stack ทั้งหมดควรถูกจัดการในฐานะ "platform infrastructure" ไม่ใช่ "application" — ซึ่งเป็นมุมที่คนทำ AI จำนวนไม่น้อยยังไม่คิดแบบนี้
เวลาทีมส่วนใหญ่เจอปัญหา AI ตอบผิด คำตอบแรกที่โผล่มาในหัวคือ "โมเดลห่วย" หรือ "prompt ยังไม่ดีพอ" แล้วก็วนอยู่กับการแก้ที่จุดนั้น แต่ Mulik เสนอว่าถ้าคุณมีหลายทีมที่ใช้ LLM คนละแบบ คนละ prompt คนละ context สิ่งที่ขาดจริงๆ คือชั้นกลางที่ทุกทีมสามารถใช้ร่วมกันได้
ไอเดียคือสร้าง shared LLM platform ที่รวมบริการพื้นฐานที่ทุกทีมต้องใช้ ไม่ว่าจะเป็น prompt registry & versioning (เก็บ prompt เป็นเวอร์ชัน แก้แล้วย้อนกลับได้ รู้ว่าใครเปลี่ยนอะไร) schema enforcement (บังคับว่า output ต้องเป็นรูปแบบที่กำหนด) และ token cost attribution by request (รู้ว่าคำขอไหนกิน token เท่าไหร่ ใครเป็นคนใช้ ต้นทุนไปตกที่ทีมไหน)
พูดตรงๆ นะ ฟังดูเหมือนงานหนักที่ทีมส่วนใหญ่ไม่อยากทำ เพราะมันไม่ glamorous เท่าการเทรนโมเดลใหม่หรือเล่น prompt engineering สนุกๆ แต่ปัญหาที่ Mulik เจอคือปัญหาที่แทบทุกองค์กรที่ scale LLM ขึ้นจะเจอเหมือนกัน — แล้วถ้าไม่มีโครงสร้างกลางไว้รองรับ คุณจะแก้ปัญหาเดิมซ้ำๆ แยกกันในทุกทีม
Prompt Registry & Versioning
เก็บ prompt เป็นเวอร์ชัน ตรวจสอบย้อนหลังได้ว่าใครแก้อะไร เมื่อไหร่ ลดปัญหา prompt เปลี่ยนแล้วระบบพังโดยไม่มีใครรู้
Schema Enforcement
บังคับว่า output ของ LLM ต้องตรงตามรูปแบบที่กำหนด ลดปัญหา agent ตอบมั่วหรือให้ข้อมูลผิดโครงสร้าง
Token Cost Attribution
ติดตามว่าคำขอไหนใช้ token เท่าไหร่ ผูกต้นทุนกลับไปที่ทีมหรือ feature ที่เรียกใช้ เพื่อคุมงบและหาจุดที่เปลืองเกินจำเป็น
ทั้งหมดนี้ไม่ใช่เรื่องใหม่ในโลก software engineering — เราทำ caching layer, logging, auth เป็น shared service กันมานานแล้ว แต่วัฒนธรรมการทำ AI ในหลายที่ยัง treat มันเป็น sandbox ส่วนตัวของ data scientist หรือ ML engineer ที่แต่ละคนมี pipeline ของตัวเอง
พอ scale ขึ้น ปัญหาที่ตามมาคือ debugging ไม่ได้ ต้นทุนบานปลาย และที่แย่สุดคือไม่รู้ว่าปัญหามาจากไหน เพราะทุกอย่างอยู่ใน silo ของใครของมัน
บทความนี้ไม่ได้บอกว่าโมเดลไม่สำคัญ แต่มันบอกว่าถ้าคุณยังแก้ปัญหา AI แบบ application-by-application อยู่ คุณจะจมกับปัญหาเดิมซ้ำๆ การลงทุนสร้าง LLM platform กลางอาจดูไม่ sexy แต่เป็นสิ่งที่แยกทีมที่ scale ได้จริง ออกจากทีมที่วนอยู่ใน demo ตลอดกาล
ที่มา: InfoQ AI/ML — อ่านต้นฉบับ
ความคิดเห็น 6
กำลังโหลดความคิดเห็น...