คู่มือภาคสนามสำหรับการปรับปรุงผลิตภัณฑ์ AI อย่างรวดเร็ว

• หลายทีม AI มัวแต่โฟกัสกับการเลือกเครื่องมือ แต่กลับมองข้ามสิ่งสำคัญอย่าง การวัดผลและการเรียนรู้แบบทำซ้ำ
• ผู้เขียนอาศัยประสบการณ์จากการช่วยสร้างผลิตภัณฑ์ AI มากกว่า 30 รายการ เพื่อแนะนำ แนวทางการลงมือทำร่วมกันของทีมที่ประสบความสำเร็จ
• หัวใจสำคัญคือ แนวคิดที่ยึดการวัดผลเป็นศูนย์กลางและการสร้างโรดแมปที่ขับเคลื่อนด้วยการทดลอง

1. ความผิดพลาดที่พบบ่อยที่สุด: ข้ามการวิเคราะห์ข้อผิดพลาด

• ทีม AI ส่วนใหญ่มัก หมกมุ่นกับการออกแบบสถาปัตยกรรมหรือเฟรมเวิร์ก และไม่ได้วัดผลลัพธ์จริง
• เมตริกบนแดชบอร์ดทั่วไปไม่ได้ช่วยมากนัก
  • ยึดติดกับ “vanity metrics” ที่ไม่มีความหมาย
  • มีเมตริกมากเกินไปจนทำให้ทีมเสียสมาธิ
• การวิเคราะห์ข้อผิดพลาดคือกิจกรรมที่ให้ ROI สูงที่สุด
  • เปิดดูบันทึกบทสนทนาจริง
  • จัดหมวดหมู่ประเภทของความล้มเหลว
  • เขียนเทสต์สำหรับปัญหานั้นและวัดผลการปรับปรุง
• กรณีของ NurtureBoss:
  • แก้ปัญหาข้อผิดพลาดในการจัดการวันที่
  • ความแม่นยำดีขึ้นจาก 33% → 95%
• การวิเคราะห์แบบ bottom-up มีประสิทธิภาพมากกว่าแบบ top-down
  • สกัดรูปแบบความล้มเหลวจากข้อมูลจริง
  • แม้แต่ pivot table แบบง่าย ๆ ก็ให้ข้อมูลเชิงลึกที่สำคัญได้

2. การลงทุนด้าน AI ที่สำคัญที่สุด: ตัวดูข้อมูลแบบเรียบง่าย

• เครื่องมือที่ทำให้ทีมเห็นผลลัพธ์ AI จริงได้ง่าย คือสิ่งสำคัญที่สุด
  • เมื่อเทียบกับเครื่องมือโอเพนซอร์สแล้ว อินเทอร์เฟซแบบปรับตามโดเมน มักได้ผลดีกว่า
  • NurtureBoss ใช้ตัวดูข้อมูลภายในเพื่อรองรับการปรับปรุงแบบวนซ้ำอย่างรวดเร็ว
• คุณสมบัติของตัวดูข้อมูลที่ดี:
  • แสดงบริบททั้งหมดในหน้าจอเดียว
  • เก็บฟีดแบ็กได้ง่าย
  • อนุญาตให้ใส่หมายเหตุแบบปลายเปิด
  • กรองและจัดเรียงได้รวดเร็ว
  • รองรับคีย์ลัดเพื่อเพิ่มความสะดวกในการใช้งาน
• สร้างได้ภายในไม่กี่ชั่วโมงด้วย FastHTML, MonsterUI เป็นต้น
  • เริ่มจากสเปรดชีตแบบง่าย ๆ ก่อนได้เช่นกัน

3. มอบอำนาจในการปรับพรอมป์ต์ให้ผู้เชี่ยวชาญโดเมน

• การปรับปรุงประสิทธิภาพ AI กลับได้ผลดีกว่าเมื่อ ผู้เชี่ยวชาญที่ไม่ได้รู้เรื่อง AI มากนัก เป็นผู้ขับเคลื่อน
• เนื่องจาก พรอมป์ต์คือประโยคภาษาอังกฤษ ผู้ที่ไม่ใช่ผู้เชี่ยวชาญก็เขียนได้
• หากมี สภาพแวดล้อมพรอมป์ต์แบบรวมศูนย์ ใน UI ของผลิตภัณฑ์ในรูปแบบ “โหมดผู้ดูแลระบบ” จะเหมาะอย่างยิ่งต่อการเรียนรู้แบบทำซ้ำ
• เคล็ดลับการสื่อสารกับผู้เชี่ยวชาญโดเมน:
  • ตัดศัพท์เทคนิคที่ไม่จำเป็นออก
  • เช่น: “แนวทาง RAG” → “ทำให้ AI มีบริบทสำหรับตอบคำถาม”
  • เหตุผลที่ การใช้ภาษาที่แม่นยำ สำคัญต่อการสื่อสารภายในทีม

4. ทำได้แม้ไม่มีผู้ใช้: บูตสแตรประบบด้วยข้อมูลสังเคราะห์

• แม้ไม่มีข้อมูลผู้ใช้ก็ยังประเมิน AI ได้
  • LLM สามารถสร้างข้อมูลสังเคราะห์ได้
• 3 มิติสำหรับข้อมูลสังเคราะห์ที่มีประสิทธิภาพ:
  • ฟังก์ชัน (เช่น ค้นหาอสังหาริมทรัพย์, การจอง เป็นต้น)
  • สถานการณ์ (เช่น ไม่พบรายการที่ตรงกัน, พบหลายรายการที่ตรงกัน เป็นต้น)
  • เพอร์โซนา (เช่น ผู้ซื้อมือใหม่, นักลงทุน เป็นต้น)
• ตัวอย่างจากโปรเจกต์อสังหาริมทรัพย์จริง:
  • จัดโครงสร้าง DB ตามแต่ละสถานการณ์เพื่อสร้าง synthetic queries
  • ให้ LLM สร้างคำถามของผู้ใช้และทดสอบระบบ
• แนวทางการเขียนข้อมูลสังเคราะห์:
  • สร้างตัวอย่างที่หลากหลาย
  • สร้างโดยยึดข้อมูลอินพุตเป็นศูนย์กลาง
  • สะท้อนข้อจำกัดของระบบ
  • ตรวจสอบความถูกต้องของสถานการณ์ทดสอบ
  • เริ่มจากกรณีง่าย ๆ แล้วค่อย ๆ ขยาย

5. รักษาความเชื่อมั่นต่อระบบประเมินผล

• หลายทีมสร้างระบบประเมินขึ้นมา แต่ภายหลังก็ ละเลยเพราะไม่เชื่อถือมัน
• เป็นเรื่องปกติที่เกณฑ์ประเมินจะเกิด criteria drift เมื่อเวลาผ่านไป
• แนวทางในการรักษาความน่าเชื่อถือ:
  • นิยมใช้ การประเมินแบบไบนารี (pass/fail): เพื่อความชัดเจนและความสม่ำเสมอ
  • เพิ่ม critique แบบละเอียด: เพื่อให้บริบทผ่านคำอธิบายเชิงคุณภาพ
  • วัดความสอดคล้องระหว่างการประเมินอัตโนมัติกับการประเมินของมนุษย์
    • ตัวอย่าง: ในโปรเจกต์ Honeycomb สามารถทำให้การประเมินของ LLM สอดคล้องเกิน 90% หลังปรับซ้ำ 3 รอบ
    • สามารถใช้เครื่องมือ AlignEval ของ Eugene Yan ได้
• กลยุทธ์ในการขยายสเกล:
  • อย่าตัดการประเมินโดยมนุษย์ทิ้งทั้งหมด แต่ให้ โฟกัสกับตัวอย่างที่มีข้อมูลสูง
  • เปรียบเทียบการประเมินอัตโนมัติกับการตัดสินของมนุษย์เป็นระยะเพื่อปรับเกณฑ์ใหม่

6. โรดแมป AI ที่ขับเคลื่อนด้วยการทดลอง ไม่ใช่ฟีเจอร์

• “โรดแมปที่ยึดฟีเจอร์เป็นศูนย์กลาง” แบบดั้งเดิมไม่เหมาะกับ AI
• ข้อเสนอแนวทาง “capability funnel” จาก Bryan Bischof อดีตหัวหน้าฝ่าย AI ของ Hex
  • ตัวอย่าง funnel ของผู้ช่วยเขียนคิวรี
    1. ทำให้ไวยากรณ์ของคิวรีถูกต้องเท่านั้น
    2. รันได้โดยไม่เกิดข้อผิดพลาด
    3. คืนผลลัพธ์ที่เกี่ยวข้อง
    4. สอดคล้องกับเจตนาของผู้ใช้
    5. แก้ปัญหาได้อย่างสมบูรณ์
• การวางแผนแบบอิงการทดลองของ Eugene Yan:
  • ตรวจสอบความเป็นไปได้ด้านข้อมูล → ตรวจสอบความเป็นไปได้ด้านเทคนิค → สร้างต้นแบบ → A/B test
  • แบ่งปันผลของการทดลองกับผู้บริหาร และหากไม่มีแนวโน้มก็ ตัดสินใจเปลี่ยนทิศทางตั้งแต่ระยะแรก
• การสร้างวัฒนธรรมที่แบ่งปันความล้มเหลว:
  • แบ่งปันภายในทีมว่า “ความล้มเหลวก็เป็นผลงาน”
  • สร้างสภาพแวดล้อมที่ส่งเสริมการทำซ้ำและการทดลอง

บทสรุปและหลักการสำคัญ

• ทีม AI ที่ประสบความสำเร็จจะโฟกัสที่ การวัดผล การทำซ้ำ และการเรียนรู้ มากกว่าเครื่องมือที่ซับซ้อน
• หลักการ 6 ข้อที่ควรนำไปปฏิบัติ:
  1. ตรวจดูข้อมูลด้วยตัวเอง และทำการวิเคราะห์ข้อผิดพลาด
  2. สร้าง เครื่องมือที่เรียบง่ายและมีประสิทธิภาพ เพื่อสนับสนุนการเรียนรู้แบบทำซ้ำ
  3. ส่งเสริมการมีส่วนร่วมของ ผู้เชี่ยวชาญโดเมน และมอบอำนาจให้พวกเขา
  4. บูตสแตรประบบประเมินเบื้องต้นด้วยข้อมูลสังเคราะห์
  5. รักษาความน่าเชื่อถือด้วยการประเมินแบบไบนารี + critique + การตรวจสอบความสอดคล้อง
  6. บริหารโรดแมปโดยวัดจากจำนวนการทดลอง ไม่ใช่ฟีเจอร์