สิ่งที่ได้เรียนรู้จากการสร้างร่วมกับ LLM ตลอด 1 ปี

• การพัฒนาโดยใช้โมเดลภาษาขนาดใหญ่ (LLM) อยู่ในช่วงเวลาที่น่าตื่นเต้น
  • ตลอด 1 ปีที่ผ่านมา LLM มีคุณภาพถึงระดับที่ "ดีพอ" สำหรับแอปพลิเคชันจริงแล้ว และกำลังดีขึ้นพร้อมทั้งมีต้นทุนถูกลงทุกปี
  • นอกเหนือจากเดโมบนโซเชียลมีเดีย ยังมีการประเมินว่าจะมีเงินลงทุนใน AI ราว 2 แสนล้านดอลลาร์ภายในปี 2025
  • ด้วย API จากผู้ให้บริการต่าง ๆ ทำให้ LLM เข้าถึงได้ง่ายขึ้น ไม่ใช่แค่สำหรับวิศวกร ML และนักวิทยาศาสตร์เท่านั้น แต่ทุกคนสามารถสร้างความฉลาดให้กับผลิตภัณฑ์ได้
• แม้อุปสรรคในการเริ่มสร้างด้วย AI จะลดลง แต่การสร้างผลิตภัณฑ์และระบบที่มีประสิทธิภาพเกินกว่าระดับเดโมก็ยังคงยากอยู่
• เราได้สร้างสิ่งต่าง ๆ มาตลอด 1 ปีที่ผ่านมา และพบความยากลำบากมากมายในกระบวนการนั้น
  • เราต้องการแบ่งปันสิ่งที่ได้เรียนรู้ เพื่อให้ผู้อื่นหลีกเลี่ยงความผิดพลาดแบบเดียวกับเราและวนรอบการพัฒนาได้เร็วขึ้น
• บทความนี้ประกอบด้วย 3 ส่วน:
  1. Tactical (เชิงยุทธวิธี): แนวปฏิบัติบางอย่างสำหรับ prompting, RAG, workflow engineering, การประเมินผล และการมอนิเตอร์
     • เขียนขึ้นสำหรับผู้ปฏิบัติงานที่สร้างด้วย LLM หรือผู้ที่ทำโปรเจกต์ช่วงสุดสัปดาห์
  2. Operational (เชิงปฏิบัติการ): ประเด็นด้านองค์กรและงานประจำวันของการเปิดตัวผลิตภัณฑ์ รวมถึงวิธีสร้างทีมที่มีประสิทธิภาพ
     • สำหรับผู้นำด้านผลิตภัณฑ์/เทคโนโลยีที่ต้องการ deploy อย่างยั่งยืนและเสถียร
  3. Strategic (เชิงกลยุทธ์): มุมมองระยะยาวและภาพใหญ่ รวมถึงวิธีทำซ้ำ โดยมีความเห็นอย่าง "No GPU before PMF" และ "โฟกัสที่ระบบ ไม่ใช่โมเดล"
     • เขียนโดยคำนึงถึงผู้ก่อตั้งและผู้บริหาร
• คู่มือนี้มีเป้าหมายเพื่อเป็นแนวทางเชิงปฏิบัติสำหรับการสร้างผลิตภัณฑ์ที่ประสบความสำเร็จด้วย LLM
  • มีที่มาจากประสบการณ์ของเราเอง และยกตัวอย่างกรณีจากทั่วทั้งอุตสาหกรรม

[ยุทธวิธี: แก่นสำคัญของการใช้ LLM]

• ในส่วนนี้ เราจะแชร์แนวปฏิบัติที่ดีสำหรับองค์ประกอบหลักของ LLM stack ที่กำลังก่อตัวขึ้นใหม่
  • ครอบคลุมทั้งเคล็ดลับด้าน prompting เพื่อยกระดับคุณภาพและความน่าเชื่อถือ กลยุทธ์สำหรับประเมินผลลัพธ์ และแนวคิดด้าน retrieval-augmented generation เพื่อปรับปรุง grounding
  • นอกจากนี้ยังจะสำรวจวิธีออกแบบ workflow แบบ human-in-the-loop ด้วย

ยุทธวิธี 1. Prompting

• เมื่อพัฒนาแอปพลิเคชันใหม่ เราแนะนำให้เริ่มจาก prompting
  • เป็นเรื่องง่ายที่จะประเมินความสำคัญของ prompting ต่ำเกินไปหรือสูงเกินไป
  • มักถูกประเมินต่ำไป เพราะหากใช้เทคนิค prompting ที่เหมาะสมอย่างถูกต้อง ก็ไปได้ไกลมาก
  • และมักถูกประเมินสูงเกินไป เพราะแม้แต่แอปพลิเคชันที่อิง prompt ก็ยังต้องการงานวิศวกรรมรอบ ๆ prompt อีกมากเพื่อให้ทำงานได้ดี

โฟกัสที่การใช้เทคนิค prompting พื้นฐานให้คุ้มที่สุด

• มีเทคนิค prompting บางอย่างที่ช่วยยกระดับประสิทธิภาพได้อย่างต่อเนื่องในหลายโมเดลและหลายงาน
  • เช่น N-shot prompt + in-context learning, Chain-of-Thought และการจัดเตรียมทรัพยากรที่เกี่ยวข้อง
• N-shot prompt และ in-context learning
  • แนวคิดของ in-context learning ผ่าน N-shot prompt คือการสาธิตงานให้ LLM ดู และยกตัวอย่างบางส่วนเพื่อปรับผลลัพธ์ให้ตรงกับความคาดหวัง
  • หากค่า N ต่ำเกินไป โมเดลอาจยึดติดกับตัวอย่างเฉพาะมากเกินไปจนความสามารถในการ generalize ลดลง
  • จากประสบการณ์ ควรตั้งเป้า N ≥ 5 และไม่ต้องกลัวที่จะใช้ถึงระดับหลายสิบตัวอย่าง
  • ตัวอย่างควรเป็นตัวแทนของการกระจายตัวของอินพุตที่คาดว่าจะเจอ
  • ไม่จำเป็นต้องให้คู่ input-output แบบครบถ้วนเสมอไป หลายกรณีเพียงตัวอย่างของ output ที่ต้องการก็เพียงพอ
  • หากใช้ LLM ที่รองรับการใช้เครื่องมือ ในตัวอย่าง N-shot ก็ควรใช้เครื่องมือที่คุณต้องการให้เอเจนต์ใช้งานด้วย
• Chain-of-Thought (CoT) prompting
  • ใน CoT prompting จะกระตุ้นให้ LLM อธิบายกระบวนการคิดก่อนส่งคำตอบสุดท้ายกลับมา
  • คุณอาจมองว่านี่คือการให้สเก็ตช์แพดกับ LLM เพื่อไม่ให้ต้องทำทุกอย่างจากหน่วยความจำ
  • แนวทางดั้งเดิมคือเพียงเพิ่มวลีอย่าง "ลองคิดทีละขั้น" เป็นส่วนหนึ่งของคำสั่ง แต่เราพบว่าการทำ CoT ให้เฉพาะเจาะจงมากขึ้นจะช่วยได้
  • การเพิ่มความเฉพาะเจาะจงเพียง 1-2 ประโยค มักช่วยลดอัตราการเกิด hallucination ได้อย่างมาก
  • ช่วงหลังเริ่มมีการตั้งคำถามว่าเทคนิคนี้ทรงพลังอย่างที่เชื่อกันหรือไม่
  • และยังมีการถกเถียงกันมากพอสมควรว่าระหว่างการให้เหตุผลเมื่อใช้ CoT นั้นเกิดอะไรขึ้นกันแน่
  • ถึงอย่างนั้นก็ยังเป็นเทคนิคที่ควรทดลองเมื่อมีโอกาส
• การจัดเตรียมทรัพยากรที่เกี่ยวข้อง
  • การให้ทรัพยากรที่เกี่ยวข้องเป็นกลไกทรงพลังในการขยายฐานความรู้ของโมเดล ลด hallucination และเพิ่มความเชื่อมั่นของผู้ใช้
  • มักทำผ่าน retrieval-augmented generation (RAG)
  • การให้ text snippet ที่โมเดลนำไปใช้ตอบได้โดยตรงถือเป็นเทคนิคสำคัญ
  • เมื่อจัดเตรียมทรัพยากรที่เกี่ยวข้อง การใส่ไว้เฉย ๆ ยังไม่เพียงพอ
    • อย่าลืมสั่งให้โมเดลให้ความสำคัญกับการใช้ทรัพยากร อ้างอิงโดยตรง และบางครั้งควรระบุด้วยเมื่อทรัพยากรไม่เพียงพอ
  • สิ่งเหล่านี้ช่วยให้คำตอบของเอเจนต์ "ground" อยู่กับ resource corpus ได้

จัดโครงสร้างอินพุตและเอาต์พุต

• อินพุตและเอาต์พุตแบบมีโครงสร้างช่วยให้โมเดลเข้าใจอินพุตได้ดีขึ้น และส่งคืนผลลัพธ์ที่เชื่อมต่อกับระบบปลายน้ำได้อย่างเสถียร
  • การเพิ่มรูปแบบการ serialize ให้กับอินพุต อาจช่วยอธิบายความสัมพันธ์ระหว่างโทเค็นในบริบท เพิ่ม metadata ให้โทเค็นเฉพาะ (เช่น ประเภท) หรือช่วยเชื่อมคำขอกับตัวอย่างคล้ายกันในข้อมูลฝึกของโมเดล
  • ตัวอย่างเช่น คำถามจำนวนมากบนอินเทอร์เน็ตเกี่ยวกับการเขียน SQL มักเริ่มต้นด้วยการระบุ SQL schema
    • ดังนั้น prompting ที่มีประสิทธิภาพสำหรับ Text-to-SQL ควรมีคำจำกัดความของ schema แบบมีโครงสร้างรวมอยู่ด้วย
• เอาต์พุตแบบมีโครงสร้างมีเป้าหมายคล้ายกัน แต่ช่วยทำให้การเชื่อมต่อกับองค์ประกอบปลายน้ำของระบบง่ายขึ้น
  • Instructor และ Outlines ทำงานได้ดีกับเอาต์พุตแบบมีโครงสร้าง
    • (หากใช้งาน LLM API SDK ให้ใช้ Instructor และหากใช้โมเดลโฮสต์เองผ่าน Huggingface ให้ใช้ Outlines)
  • อินพุตแบบมีโครงสร้างช่วยให้แสดงงานได้ชัดเจนและคล้ายกับรูปแบบในข้อมูลฝึก จึงเพิ่มโอกาสที่จะได้เอาต์พุตที่ดีขึ้น
• เมื่อใช้อินพุตแบบมีโครงสร้าง ควรทราบว่าแต่ละตระกูล LLM มีแนวทางที่ชอบต่างกัน
  • Claude ชอบ <xml> ขณะที่ GPT ชอบ Markdown และ JSON
  • หากใช้ XML ก็สามารถใส่แท็ก <response> เพื่อ prefill คำตอบของ Claude ได้ด้วย

สร้าง prompt ที่เล็กและทำสิ่งเดียวให้ดี

• anti-pattern/code smell ที่พบบ่อยในซอฟต์แวร์คือ "God Object" ซึ่งเป็นคลาสหรือฟังก์ชันเดียวที่ทำทุกอย่าง
  • สิ่งนี้ใช้ได้กับ prompt เช่นกัน
• โดยทั่วไป prompt มักเริ่มต้นอย่างเรียบง่าย
  • อาจเริ่มจากคำสั่งไม่กี่ประโยคและตัวอย่างเล็กน้อย
  • แต่เมื่อพยายามปรับปรุงประสิทธิภาพและรองรับ edge case มากขึ้น ความซับซ้อนก็เพิ่มขึ้น
    • มีทั้งคำสั่งที่มากขึ้น การให้เหตุผลหลายขั้นตอน ตัวอย่างหลายสิบรายการ ฯลฯ ถูกเพิ่มเข้ามา
  • สุดท้าย prompt ที่ตอนแรกเรียบง่ายก็กลายเป็นแฟรงเกนสไตน์ขนาด 2,000 โทเค็น
    • แถมประสิทธิภาพกับอินพุตที่ทั่วไปและเป็นธรรมชาติกว่ากลับแย่ลงด้วย
    • GoDaddy จัดให้ปัญหานี้เป็นบทเรียนอันดับ 1 ที่ได้จากการสร้างด้วย LLM
• เช่นเดียวกับที่เราพยายามทำให้ระบบและโค้ดเรียบง่าย prompt ก็ควรเป็นเช่นนั้น
  • แทนที่จะใช้ prompt อเนกประสงค์เพียงตัวเดียวสำหรับตัวสรุปบันทึกการประชุม คุณสามารถแยกเป็นขั้นตอนอย่างเช่น
    • ดึงประเด็นการตัดสินใจหลัก รายการสิ่งที่ต้องทำ และผู้รับผิดชอบออกมาในรูปแบบมีโครงสร้าง
    • ตรวจสอบความสอดคล้องของรายละเอียดที่ดึงออกมาโดยเทียบกับบันทึกต้นฉบับ
    • สร้างสรุปแบบกระชับจากรายละเอียดเชิงโครงสร้าง
• ผลลัพธ์คือการแยก prompt เดียวออกเป็นหลาย prompt ที่เรียบง่าย มีจุดโฟกัส และเข้าใจได้ง่าย
  • เมื่อแยกเช่นนี้แล้ว คุณก็สามารถปรับปรุงและประเมินแต่ละ prompt แยกกันได้

การสร้าง context token

• ควรทบทวนและท้าทายสมมติฐานเกี่ยวกับปริมาณคอนเท็กซ์ที่ต้องส่งให้เอเจนต์จริง ๆ
  • ไม่ใช่การปั้นรูปสลักจากคอนเท็กซ์เหมือน Michelangelo แต่ต้องค่อย ๆ เฉือนวัสดุที่ไม่จำเป็นออกเพื่อเผยให้เห็นรูปสลัก
  • RAG เป็นวิธีที่ใช้กันอย่างแพร่หลายในการรวบรวมบล็อกหินอ่อนทั้งหมดที่อาจเกี่ยวข้อง แต่กำลังทำอะไรอยู่เพื่อดึงสิ่งที่จำเป็นออกมา?
• พบว่าการดึงพรอมป์ต์สุดท้ายที่ส่งให้โมเดลออกมา แล้ววางลงบนหน้ากระดาษเปล่าพร้อมองค์ประกอบคอนเท็กซ์ทั้งหมด meta prompting และผลลัพธ์ RAG จากนั้นอ่านมัน จะช่วยให้ทบทวนคอนเท็กซ์ได้ดีขึ้น
  • วิธีนี้ช่วยให้พบความซ้ำซ้อน ภาษาที่ขัดแย้งกันเอง และส่วนที่มีรูปแบบไม่ถูกต้องได้
• การปรับให้เหมาะสมที่สำคัญอีกอย่างคือโครงสร้างของคอนเท็กซ์
  • การแทนแบบ bag-of-docs ไม่ได้ช่วยมนุษย์ ดังนั้นอย่าคิดไปเองว่าจะดีกับเอเจนต์
  • ควรพิจารณาอย่างรอบคอบว่าจะจัดโครงสร้างคอนเท็กซ์อย่างไร เพื่อเน้นความสัมพันธ์ระหว่างแต่ละส่วนของคอนเท็กซ์ และทำให้การดึงข้อมูลเรียบง่ายที่สุดเท่าที่จะเป็นไปได้

ยุทธวิธี 2. การค้นคืนข้อมูล / RAG

• นอกจากการพรอมป์ต์แล้ว อีกวิธีที่มีประสิทธิภาพในการปรับ LLM คือการให้ความรู้เป็นส่วนหนึ่งของพรอมป์ต์
  • สิ่งนี้ช่วย ground ให้ LLM ยึดโยงกับคอนเท็กซ์ที่ให้มา และถูกใช้สำหรับการเรียนรู้ในบริบท
  • สิ่งนี้เรียกว่า Retrieval-Augmented Generation (RAG)
  • ผู้ปฏิบัติงานพบว่า RAG มีประสิทธิภาพในการให้ความรู้และปรับปรุงเอาต์พุต โดยใช้แรงและต้นทุนน้อยกว่าการ fine-tuning มาก
  • RAG จะดีได้เท่ากับความเกี่ยวข้อง ความหนาแน่นของข้อมูล และรายละเอียดของเอกสารที่ดึงมา

คุณภาพของผลลัพธ์ RAG ขึ้นอยู่กับคุณภาพของเอกสารที่ดึงมา และมีหลายปัจจัยที่ควรพิจารณา

• ตัวชี้วัดแรกและชัดเจนที่สุดคือ "ความเกี่ยวข้อง"
  • โดยทั่วไปจะวัดเชิงปริมาณด้วยตัวชี้วัดด้านอันดับ เช่น Mean Reciprocal Rank (MRR) หรือ Normalized Discounted Cumulative Gain (NDCG)
  • MRR ใช้ประเมินว่าระบบวางผลลัพธ์ที่เกี่ยวข้องรายการแรกไว้ในลำดับผลลัพธ์ได้ดีแค่ไหน ขณะที่ NDCG จะพิจารณาทั้งความเกี่ยวข้องและตำแหน่งของผลลัพธ์ทั้งหมด
  • ตัวชี้วัดเหล่านี้ใช้วัดความสามารถของระบบในการจัดอันดับเอกสารที่เกี่ยวข้องให้อยู่สูงขึ้น และเอกสารที่ไม่เกี่ยวข้องให้อยู่ต่ำลง
  • ตัวอย่างเช่น หากกำลังดึงสรุปจากผู้ใช้เพื่อสร้างบทสรุปรีวิวภาพยนตร์ ก็ควรจัดอันดับรีวิวของภาพยนตร์เรื่องนั้นให้สูงกว่า และตัดรีวิวของภาพยนตร์เรื่องอื่นออก
  • เช่นเดียวกับระบบแนะนำแบบดั้งเดิม อันดับของรายการที่ถูกดึงมามีผลอย่างมากต่อวิธีที่ LLM ทำงานดาวน์สตรีม
  • หากต้องการวัดผลกระทบ ให้ลองรันงานแบบ RAG โดยสลับลำดับรายการที่ดึงมา แล้วดูว่าผลลัพธ์ RAG ทำงานได้อย่างไร
• อย่างที่สองคือ "ความหนาแน่นของข้อมูล"
  • หากเอกสารสองฉบับมีความเกี่ยวข้องเท่ากัน ควรเลือกฉบับที่กระชับกว่าและมีรายละเอียดที่ไม่เกี่ยวข้องน้อยกว่า
  • กลับไปที่ตัวอย่างภาพยนตร์ บทภาพยนตร์และรีวิวผู้ใช้ทั้งหมดอาจถือว่าเกี่ยวข้องในความหมายกว้าง ๆ
  • ถึงอย่างนั้น รีวิวที่ได้คะแนนสูงและรีวิวจากบรรณาธิการก็มักจะมีความหนาแน่นของข้อมูลสูงกว่า
• สุดท้าย ให้พิจารณา "ระดับรายละเอียด" ที่เอกสารให้ไว้
  • ลองนึกภาพว่ากำลังสร้างระบบ RAG สำหรับสร้าง SQL query จากภาษาธรรมชาติ
    • การให้เพียง schema ของตารางพร้อมชื่อคอลัมน์เป็นคอนเท็กซ์อาจเพียงพอแล้ว
    • แต่ถ้าเพิ่มคำอธิบายคอลัมน์และค่าตัวอย่างบางส่วนล่ะ?
  • รายละเอียดเพิ่มเติมอาจช่วยให้ LLM เข้าใจความหมายของตารางได้ดีขึ้น และสร้าง SQL ที่แม่นยำยิ่งขึ้น

อย่าลืมการค้นหาแบบคีย์เวิร์ด และใช้มันสำหรับ baseline และ hybrid retrieval

• เพราะเดโม RAG แบบอิง embedding แพร่หลายมาก จึงง่ายที่จะลืมหรือมองข้ามงานวิจัยและโซลูชันด้านการค้นคืนข้อมูลที่สั่งสมมาหลายทศวรรษ
  • ถึงอย่างนั้น embedding ก็เป็นเครื่องมือที่ทรงพลังอย่างไม่ต้องสงสัย แต่ไม่ใช่คำตอบสำหรับทุกอย่าง
• ข้อดีของการค้นหาแบบคีย์เวิร์ด
  • ประการแรก embedding เก่งมากในการจับความคล้ายคลึงเชิงความหมายระดับสูง แต่สามารถมีปัญหากับคำค้นที่เฉพาะเจาะจงและอิงคีย์เวิร์ดมากกว่า เช่น เมื่อผู้ใช้ค้นหาชื่อ (เช่น Ilya) ตัวย่อ (เช่น RAG) หรือ ID (เช่น claude-3-sonnet)
    • การค้นหาแบบคีย์เวิร์ดอย่าง BM25 ถูกออกแบบมาโดยตรงเพื่อสิ่งนี้
    • ผู้ใช้คุ้นเคยกับการค้นหาแบบคีย์เวิร์ดมานานจนมองว่าเป็นเรื่องปกติ และอาจรู้สึกหงุดหงิดหากเอกสารที่ต้องการค้นหาไม่ถูกส่งกลับมา
  • ประการที่สอง การเข้าใจว่าเหตุใดเอกสารถูกค้นพบด้วยการค้นหาแบบคีย์เวิร์ดนั้นเป็นธรรมชาติกว่า
    • เพราะสามารถเห็นคีย์เวิร์ดที่ตรงกับคำค้นได้
    • ในทางกลับกัน การค้นหาแบบอิง embedding ตีความได้ยากกว่า
  • ประการที่สาม การค้นหาแบบคีย์เวิร์ดมักมีประสิทธิภาพด้านการคำนวณดีกว่า เนื่องจากมีระบบอย่าง Lucene หรือ OpenSearch ที่ผ่านการปรับแต่งและใช้งานจริงมาหลายทศวรรษ
• ในกรณีส่วนใหญ่ วิธีแบบ hybrid มีประสิทธิภาพที่สุด
  • ใช้การจับคู่คีย์เวิร์ดสำหรับผลลัพธ์ที่ตรงอย่างชัดเจน และใช้ embedding สำหรับคำพ้อง ความหมายกว้างกว่า การสะกดผิด และมัลติโหมดัล (เช่น ภาพและข้อความ)
  • Shortwave เคยแชร์วิธีที่พวกเขาสร้าง RAG pipeline ของตัวเอง เช่น การเขียนคำค้นใหม่ การค้นหาแบบคีย์เวิร์ด + embedding และการจัดอันดับ

สำหรับความรู้ใหม่ ให้เลือก RAG ก่อน fine-tuning

• ทั้ง RAG และ fine-tuning สามารถใช้เพื่อผสานข้อมูลใหม่เข้าใน LLM และปรับปรุงประสิทธิภาพสำหรับงานเฉพาะได้
  • ถ้าอย่างนั้นควรลองอะไรก่อน?
• ข้อดีของ RAG
  • งานวิจัยล่าสุดชี้ว่า RAG อาจเหนือกว่า
  • งานวิจัยหนึ่งเปรียบเทียบ RAG กับการ fine-tuning แบบไม่มีผู้กำกับ (หรือที่เรียกว่า continual pretraining) โดยประเมินบน MMLU และชุดย่อยของเหตุการณ์ปัจจุบัน
    • RAG ให้ผลดีกว่า fine-tuning อย่างสม่ำเสมอ ทั้งกับความรู้ที่พบระหว่างการฝึกและความรู้ใหม่ทั้งหมด
  • อีกบทความหนึ่งเปรียบเทียบ RAG กับการ fine-tuning แบบมีผู้กำกับบนชุดข้อมูลด้านการเกษตร
    • เช่นกัน การปรับปรุงประสิทธิภาพของ RAG สูงกว่า fine-tuning โดยเฉพาะอย่างยิ่งกับ GPT-4 (ดูตาราง 20 ในบทความ)
  • นอกจากการเพิ่มประสิทธิภาพแล้ว RAG ยังมีข้อได้เปรียบเชิงปฏิบัติหลายอย่าง
    • ประการแรก การทำให้ดัชนีค้นหาทันสมัยอยู่เสมอทำได้ง่ายและถูกกว่าการ continual pretraining หรือ fine-tuning
    • ประการที่สอง หากมีเอกสารที่มีปัญหาซึ่งมีเนื้อหาเป็นอันตรายหรือมีอคติอยู่ในดัชนีค้นหา ก็สามารถลบหรือแก้ไขเอกสารที่มีปัญหาได้ง่าย
  • นอกจากนี้ R ใน RAG ยังให้การควบคุมวิธีค้นหาเอกสารได้ละเอียดมากขึ้น
    • ตัวอย่างเช่น หากกำลังโฮสต์ระบบ RAG ให้หลายองค์กร ก็สามารถแยกดัชนีค้นหาเพื่อให้องค์กรแต่ละแห่งค้นหาได้เฉพาะเอกสารในดัชนีของตนเอง
    • สิ่งนี้ช่วยป้องกันไม่ให้ข้อมูลขององค์กรหนึ่งหลุดไปยังอีกองค์กรโดยไม่ตั้งใจ

โมเดลคอนเท็กซ์ยาวจะไม่ได้ทำให้ RAG หมดความจำเป็น

• เมื่อ Gemini 1.5 ให้ context window ที่มีขนาดสูงสุด 10 ล้านโทเค็น บางส่วนก็เริ่มตั้งคำถามกับอนาคตของ RAG
  • context window ขนาด 10 ล้านโทเค็นทำให้เฟรมเวิร์ก RAG เดิมส่วนใหญ่ไม่จำเป็นอีกต่อไป
    • แค่นำข้อมูลใส่ไว้ใน context แล้วคุยกับโมเดลตามปกติก็พอ
  • ลองนึกดูว่าสิ่งนี้จะส่งผลอย่างไรต่อสตาร์ตอัป เอเจนต์ และโปรเจกต์ langchain ที่ทุ่มความพยายามด้านวิศวกรรมส่วนใหญ่ไปกับ RAG
    • ถ้าสรุปเป็นประโยคเดียว ก็คือ context 10 ล้านโทเค็นจะฆ่า RAG
• ความจำเป็นของ RAG ที่ยังคงอยู่
  • แม้เป็นความจริงว่า long-context จะเป็น game changer สำหรับกรณีใช้งานอย่างการวิเคราะห์เอกสารหลายชุดหรือการแชตกับ PDF แต่ข่าวลือเรื่องจุดจบของ RAG นั้นเกินจริงไปมาก
    • ประการแรก ต่อให้มี context window 10 ล้านโทเค็น ก็ยังจำเป็นต้องมีวิธีเลือกข้อมูลที่จะป้อนให้โมเดล
    • ประการที่สอง นอกเหนือจากการประเมินแบบ needle-in-a-haystack แล้ว ก็ยังไม่เห็นข้อมูลที่น่าเชื่อถือพอจะยืนยันได้ว่าโมเดลสามารถให้เหตุผลกับ context ขนาดใหญ่มหาศาลเช่นนั้นได้อย่างมีประสิทธิภาพ
    • ดังนั้น หากไม่มีการค้นคืนที่ดี (รวมถึงการจัดอันดับ) ก็มีความเสี่ยงที่จะทำให้โมเดลล้นไปด้วยข้อมูลที่ทำให้เสียสมาธิ หรือถึงขั้นเติม context window ด้วยข้อมูลที่ไม่เกี่ยวข้องเลย
• สุดท้ายคือเรื่องต้นทุน
  • ต้นทุนการอนุมานของ Transformer เพิ่มขึ้นตามกำลังสองของความยาว context (หรือเพิ่มขึ้นแบบเชิงเส้นทั้งในด้านหน่วยความจำและเวลา)
  • การที่มีโมเดลซึ่งอ่านเนื้อหาทั้งหมดใน Google Drive ขององค์กรได้ ไม่ได้แปลว่าการทำแบบนั้นก่อนตอบทุกคำถามเป็นความคิดที่ดี
  • ลองพิจารณาอุปมาเรื่องการใช้ RAM
    • แม้จะมีคอมพิวต์อินสแตนซ์ที่มี RAM ระดับหลายสิบเทราไบต์อยู่จริง แต่เราก็ยังคงอ่านและเขียนจากดิสก์
• ดังนั้น อย่าเพิ่งโยน RAG ลงถังขยะ
  • แพตเทิร์นนี้จะยังคงมีประโยชน์ต่อไป แม้ context window จะมีขนาดใหญ่ขึ้นเรื่อย ๆ

ยุทธวิธี 3. การจูนและเพิ่มประสิทธิภาพเวิร์กโฟลว์

• การให้พรอมป์ต์กับ LLM เป็นเพียงจุดเริ่มต้น
  • หากต้องการใช้ LLM ให้เกิดประโยชน์สูงสุด ต้องมองให้ไกลกว่าพรอมป์ต์เดียวและยอมรับแนวคิดแบบเวิร์กโฟลว์
  • ตัวอย่างเช่น จะสามารถแยกงานเดี่ยวที่ซับซ้อนออกเป็นงานย่อยที่ง่ายกว่าหลายงานได้อย่างไร?
  • เมื่อใดที่การ fine-tuning หรือ caching จะช่วยเพิ่มประสิทธิภาพและลด latency/ต้นทุนได้?
• ในส่วนนี้จะแชร์กลยุทธ์ที่พิสูจน์แล้วและกรณีใช้งานจริง เพื่อช่วยในการเพิ่มประสิทธิภาพและสร้างเวิร์กโฟลว์ LLM

"Flow" แบบหลายขั้นตอน หลายเทิร์น สามารถเพิ่มประสิทธิภาพได้อย่างมาก

• เรารู้อยู่แล้วว่าสามารถได้ผลลัพธ์ที่ดีกว่าด้วยการแยกพรอมป์ต์ใหญ่หนึ่งอันออกเป็นพรอมป์ต์เล็กหลายอัน
  • AlphaCodium เป็นตัวอย่างของเรื่องนี้
    • ด้วยการเปลี่ยนจากพรอมป์ต์เดียวไปเป็นเวิร์กโฟลว์หลายขั้นตอน ทำให้เพิ่มความแม่นยำของ GPT-4 (pass@5) บน CodeContests จาก 19% เป็น 44%
  • เวิร์กโฟลว์ประกอบด้วย
    • การไตร่ตรองปัญหา
    • การให้เหตุผลกับชุดทดสอบสาธารณะ
    • การสร้างวิธีแก้ที่เป็นไปได้
    • การจัดอันดับวิธีแก้ที่เป็นไปได้
    • การสร้างชุดทดสอบสังเคราะห์
    • การวนปรับวิธีแก้กับชุดทดสอบสาธารณะและชุดทดสอบสังเคราะห์
• งานขนาดเล็กที่มีเป้าหมายชัดเจนจะสร้างพรอมป์ต์เอเจนต์หรือพรอมป์ต์ flow ที่ดีที่สุด
  • พรอมป์ต์เอเจนต์ไม่จำเป็นต้องร้องขอ structured output ทุกอัน แต่ structured output ช่วยได้มากในส่วนอินเทอร์เฟซกับระบบที่ประสานปฏิสัมพันธ์ระหว่างเอเจนต์กับสภาพแวดล้อม
• สิ่งที่ควรลอง
  • ขั้นตอนการวางแผนแบบชัดเจนที่ระบุอย่างเข้มงวดให้มากที่สุด
    • ควรพิจารณาให้เลือกจากแผนที่กำหนดไว้ล่วงหน้า
  • เขียนพรอมป์ต์ผู้ใช้เดิมใหม่ให้เป็นพรอมป์ต์เอเจนต์
    • ควรระวังเพราะกระบวนการนี้ทำให้เกิดการสูญเสียข้อมูลได้
  • พฤติกรรมของเอเจนต์ในรูปแบบ linear chain, DAG และ state machine
    • ความสัมพันธ์เชิงพึ่งพาและตรรกะที่หลากหลายอาจเหมาะหรือไม่เหมาะกับสเกลที่แตกต่างกัน
    • จะสามารถดึงการเพิ่มประสิทธิภาพออกมาจากสถาปัตยกรรมงานที่หลากหลายได้หรือไม่?
  • การตรวจสอบแผน
    • แผนอาจรวมคำแนะนำเกี่ยวกับวิธีประเมินคำตอบของเอเจนต์อื่น เพื่อให้ผลลัพธ์สุดท้ายทำงานได้ดี
  • การทำ prompt engineering โดยใช้อัปสตรีมสเตตที่คงที่
    • ควรตรวจสอบให้แน่ใจว่าพรอมป์ต์เอเจนต์ถูกประเมินกับความแปรผันต่าง ๆ ที่อาจเกิดขึ้นก่อนหน้านั้น

ณ ตอนนี้ ควรให้ความสำคัญกับเวิร์กโฟลว์แบบกำหนดแน่นอนก่อน

• AI agent สามารถตอบสนองต่อคำขอของผู้ใช้และสภาพแวดล้อมได้แบบไดนามิก แต่ลักษณะที่ไม่เป็นกำหนดแน่นอนของมันทำให้การนำขึ้นใช้งานจริงเป็นเรื่องยาก
  • แต่ละขั้นตอนที่เอเจนต์ทำมีโอกาสล้มเหลว และโอกาสฟื้นตัวจากข้อผิดพลาดก็ต่ำ
  • ดังนั้น ความน่าจะเป็นที่เอเจนต์จะทำงานหลายขั้นตอนให้สำเร็จจึงลดลงแบบทวีคูณตามจำนวนขั้นตอนที่เพิ่มขึ้น
  • ผลก็คือ ทีมที่สร้างเอเจนต์มักประสบปัญหาในการนำเอเจนต์ที่เชื่อถือได้ขึ้นใช้งาน
• แนวทางที่มีอนาคตคือมีระบบเอเจนต์ที่สร้างแผนแบบกำหนดแน่นอน แล้วนำแผนนั้นไปดำเนินการอย่างมีโครงสร้างและทำซ้ำได้
  • ในขั้นแรก เมื่อได้รับเป้าหมายระดับสูงหรือพรอมป์ต์ เอเจนต์จะสร้างแผนขึ้นมาก่อน
  • จากนั้นแผนจะถูกดำเนินการแบบกำหนดแน่นอน
  • วิธีนี้ช่วยให้แต่ละขั้นตอนคาดการณ์ได้และเชื่อถือได้มากขึ้น
  • ข้อดี
    • แผนที่สร้างขึ้นสามารถใช้เป็นตัวอย่าง few-shot สำหรับป้อนพรอมป์ต์ให้เอเจนต์หรือใช้ในการ fine-tuning
    • การดำเนินการแบบกำหนดแน่นอนทำให้ระบบเชื่อถือได้มากขึ้น จึงทดสอบและดีบักได้ง่ายขึ้น อีกทั้งยังสามารถไล่ย้อนความล้มเหลวไปยังขั้นตอนเฉพาะในแผนได้
    • แผนที่สร้างขึ้นสามารถแทนในรูป directed acyclic graph (DAG) ได้ ซึ่งเข้าใจง่ายกว่าและปรับให้เข้ากับสถานการณ์ใหม่ได้ง่ายกว่าพรอมป์ต์แบบคงที่
• ผู้สร้างเอเจนต์ที่ประสบความสำเร็จที่สุดอาจเป็นคนที่มีประสบการณ์สูงในการบริหารวิศวกรระดับจูเนียร์
  • เพราะกระบวนการสร้างแผนคล้ายกับวิธีสั่งงานและดูแลจูเนียร์
  • เช่นเดียวกับที่คุณควรให้เป้าหมายชัดเจนและแผนที่เป็นรูปธรรมกับจูเนียร์ แทนที่จะให้ทิศทางที่คลุมเครือและเปิดกว้าง คุณก็ควรทำแบบเดียวกันกับเอเจนต์
• ท้ายที่สุด หัวใจสำคัญของเอเจนต์ที่เชื่อถือได้และใช้งานได้จริงคือ
  • การใช้แนวทางที่มีโครงสร้างมากขึ้นและกำหนดแน่นอนมากขึ้น และ
  • การเก็บข้อมูลเพื่อปรับปรุงพรอมป์ต์และทำ fine-tuning ให้โมเดล
• หากไม่มีสิ่งเหล่านี้ คุณจะได้เอเจนต์ที่บางครั้งทำงานได้ดีมาก แต่โดยเฉลี่ยแล้วทำให้ผู้ใช้ผิดหวังและมี retention ต่ำ

การสร้างผลลัพธ์ที่หลากหลาย โดยไม่พึ่งแค่พารามิเตอร์อุณหภูมิ

• สมมติว่ามีงานที่ต้องการความหลากหลายในผลลัพธ์ของ LLM
  • คุณอาจกำลังเขียน LLM pipeline ที่แนะนำสินค้าที่ควรซื้อจากแค็ตตาล็อก โดยพิจารณาจากรายการสินค้าที่ผู้ใช้เคยซื้อก่อนหน้านี้
  • เมื่อรันพรอมป์ต์หลายครั้ง คุณอาจสังเกตว่าคำแนะนำที่ได้คล้ายกันเกินไป
  • ดังนั้นคุณอาจเพิ่มพารามิเตอร์ Temperature (อุณหภูมิ) ของคำขอ LLM
• การเพิ่มพารามิเตอร์อุณหภูมิจะทำให้คำตอบของ LLM มีความหลากหลายมากขึ้น
  • ระหว่างการสุ่มตัวอย่าง การกระจายความน่าจะเป็นของโทเค็นถัดไปจะเรียบแบนขึ้น ทำให้โทเค็นที่ปกติมีโอกาสถูกเลือกต่ำถูกเลือกบ่อยขึ้น
• อย่างไรก็ตาม เมื่อเพิ่มอุณหภูมิ อาจเกิด failure mode บางอย่างที่เกี่ยวข้องกับความหลากหลายของผลลัพธ์
  • ตัวอย่างเช่น สินค้าบางรายการในแค็ตตาล็อกอาจเหมาะสม แต่ไม่ถูก LLM ส่งออกมา
  • หาก LLM มีแนวโน้มจะทำตามสิ่งที่เรียนรู้มาระหว่างการฝึก ผลลัพธ์อาจมีสินค้ากลุ่มเดิมไม่กี่รายการถูกนำเสนอมากเกินไป
  • หากอุณหภูมิสูงเกินไป อาจเกิดผลลัพธ์ที่อ้างถึงสินค้าที่ไม่มีอยู่จริง (หรือเนื้อหาที่ไร้ความหมาย)
• การเพิ่มอุณหภูมิไม่ได้รับประกันว่า LLM จะสุ่มตัวอย่างผลลัพธ์จากการกระจายความน่าจะเป็นที่คุณคาดหวังไว้เสมอ (เช่น การสุ่มแบบสม่ำเสมอ)
• ถึงอย่างนั้น ก็ยังมีเทคนิคอื่นในการเพิ่มความหลากหลายของผลลัพธ์
  • วิธีที่ง่ายที่สุดคือปรับองค์ประกอบภายในพรอมป์ต์
    • ตัวอย่างเช่น หากเทมเพลตพรอมป์ต์มีรายการอย่างประวัติการซื้อที่ผ่านมา การสลับลำดับของรายการเหล่านี้ทุกครั้งที่แทรกลงในพรอมป์ต์สามารถสร้างความแตกต่างได้มาก
  • นอกจากนี้ การเก็บรายการสั้น ๆ ของผลลัพธ์ล่าสุดไว้ก็ช่วยป้องกันความซ้ำซ้อนได้
    • ในตัวอย่างการแนะนำสินค้า คุณสามารถสั่ง LLM ให้หลีกเลี่ยงการเสนอรายการจากลิสต์ล่าสุดนี้ หรือเพิ่มความหลากหลายของคำตอบด้วยการปฏิเสธผลลัพธ์ที่คล้ายกับข้อเสนอล่าสุดแล้วสุ่มใหม่
  • อีกกลยุทธ์ที่มีประสิทธิภาพคือทำให้ถ้อยคำที่ใช้ในพรอมป์ต์หลากหลายขึ้น
    • ตัวอย่างเช่น การใส่วลีอย่าง "เลือกสินค้าที่ผู้ใช้น่าจะชอบใช้เป็นประจำ" หรือ "เลือกสินค้าที่ผู้ใช้น่าจะแนะนำให้เพื่อน" สามารถเปลี่ยนจุดโฟกัสและส่งผลต่อความหลากหลายของสินค้าที่แนะนำได้

Caching ยังถูกประเมินค่าต่ำเกินไป

• การแคชช่วยลดต้นทุนด้วยการไม่ต้องคำนวณคำตอบใหม่สำหรับอินพุตเดิม และช่วยตัดเวลาแฝงในการสร้างผลลัพธ์
  • นอกจากนี้ หากคำตอบนั้นเคยผ่านการใส่ guardrail มาก่อนแล้ว ก็สามารถส่งคำตอบที่ผ่านการตรวจสอบนี้กลับไปเพื่อลดความเสี่ยงของการแสดงเนื้อหาที่เป็นอันตรายหรือไม่เหมาะสม
• แนวทางง่าย ๆ สำหรับการแคชคือการใช้ ID เฉพาะสำหรับรายการที่กำลังประมวลผล เช่น กรณีสรุปบทความข่าวใหม่หรือรีวิวสินค้า
  • เมื่อมีคำขอเข้ามา ก็สามารถตรวจได้ว่ามีบทสรุปอยู่ในแคชแล้วหรือไม่
    • ถ้ามี ก็ส่งกลับได้ทันที; ถ้าไม่มี ก็สร้าง ใส่ guardrail และให้บริการ จากนั้นบันทึกลงแคชไว้สำหรับคำขอในอนาคต
• สำหรับคิวรีที่เปิดกว้างมากขึ้น อาจยืมเทคนิคจากงานสาย retrieval ที่ใช้ประโยชน์จากการแคชกับอินพุตแบบเปิดกว้างได้เช่นกัน
  • ฟีเจอร์อย่าง autocomplete และการแก้สะกดคำช่วยปรับอินพุตของผู้ใช้ให้เป็นมาตรฐานมากขึ้น เพื่อเพิ่มอัตรา cache hit

ช่วงเวลาที่ต้องใช้ finetune (การปรับจูนละเอียด)

• อาจมีบางงานที่แม้แต่ prompt ที่ออกแบบมาอย่างชาญฉลาดที่สุดก็ยังไม่เพียงพอ
  • ตัวอย่างเช่น แม้จะทำ prompt engineering ไปมากแล้ว ระบบก็อาจยังห่างไกลจากการให้เอาต์พุตที่เชื่อถือได้และมีคุณภาพสูงอย่างสม่ำเสมอ
  • ในกรณีนี้ อาจจำเป็นต้องทำ fine-tune โมเดลสำหรับงานเฉพาะนั้น
• กรณีของการทำ fine-tune ที่ประสบความสำเร็จ
  • Natural Language Query Assistant ของ Honeycomb
    • ในช่วงแรก มีการใส่ "คู่มือการเขียนโปรแกรม" ไว้ในพรอมป์ต์พร้อมตัวอย่าง n-shot สำหรับการเรียนรู้ในบริบท
    • แม้วิธีนี้จะใช้ได้ผล แต่การ fine-tune โมเดลช่วยให้ได้เอาต์พุตที่ดีกว่าสำหรับไวยากรณ์และกฎของภาษาที่เฉพาะเจาะจงต่อโดเมน
  • Lucy ของ Rechat
    • LLM ต้องสร้างคำตอบในรูปแบบที่เฉพาะมาก โดยผสมทั้งข้อมูลที่มีโครงสร้างและไม่มีโครงสร้าง เพื่อให้ฟรอนต์เอนด์เรนเดอร์ได้อย่างถูกต้อง
    • การ fine-tune เป็นสิ่งจำเป็นเพื่อให้ทำงานได้อย่างสม่ำเสมอ
• แม้ fine-tuning จะมีประสิทธิภาพ แต่ก็มาพร้อมต้นทุนที่สูงพอสมควร
  • ต้องทำ annotation ให้กับข้อมูลสำหรับ fine-tune, ปรับจูนและประเมินโมเดล แล้วสุดท้ายก็มักต้องโฮสต์เอง
  • ดังนั้นจึงควรพิจารณาว่าต้นทุนเริ่มต้นที่สูงขึ้นนั้นคุ้มค่าหรือไม่
• หากใช้ prompting แล้วไปได้ถึง 90% ก็อาจยังไม่คุ้มที่จะลงทุนกับ fine-tuning
  • แต่หากตัดสินใจจะ fine-tune ก็สามารถสร้างและ fine-tune ด้วยข้อมูลสังเคราะห์ หรือ bootstrap จากข้อมูลโอเพนซอร์ส เพื่อลดต้นทุนการเก็บข้อมูลที่มนุษย์ทำ annotation

กลยุทธ์ 4. การประเมินและการมอนิเตอร์

• การประเมิน LLM อาจเป็นเหมือนทุ่งกับระเบิด
  • อินพุตและเอาต์พุตของ LLM เป็นข้อความอิสระ และงานที่ตั้งให้ทำก็มีความหลากหลาย
  • ถึงอย่างนั้น การประเมินอย่างเข้มงวดและรอบคอบก็ยังสำคัญ
    • ไม่ใช่เรื่องบังเอิญที่ผู้นำด้านเทคนิคของ OpenAI มีส่วนร่วมในการประเมินและให้ฟีดแบ็กต่อการประเมินแต่ละรายการ
• การประเมินแอปพลิเคชัน LLM ต้องอาศัยการนิยามและการย่อยปัญหาในหลายแบบ
  • มันอาจเป็นเพียง unit test, คล้ายกับเรื่อง observability มากกว่า หรืออาจเป็นแค่งาน data science ก็ได้
  • เราพบว่ามุมมองทั้งหมดนี้มีประโยชน์
• ในส่วนนี้จะสรุปบทเรียนที่ได้เกี่ยวกับสิ่งสำคัญในการสร้าง pipeline สำหรับการประเมินและการมอนิเตอร์

สร้าง unit test แบบ assertion จากตัวอย่างอินพุตและเอาต์พุตจริงจำนวนหนึ่ง

• สร้าง unit test (หรือ assertion) จากตัวอย่างอินพุตและเอาต์พุตในโปรดักชัน และกำหนดความคาดหวังต่อเอาต์พุตตามเกณฑ์อย่างน้อย 3 ข้อ
  • ตัวเลข 3 อาจดูเป็นการกำหนดแบบหยาบ ๆ แต่ถือว่าใช้งานได้จริงสำหรับการเริ่มต้น
    • หากน้อยกว่านี้ งานนั้นอาจยังนิยามไม่ชัดพอ หรือเปิดกว้างเกินไป เช่น แชตบอตทั่วไป
  • unit test หรือ assertion เหล่านี้ควรถูกทริกเกอร์เมื่อมีการเปลี่ยนแปลงใน pipeline เช่น การแก้ไข prompt, การเพิ่มคอนเท็กซ์ใหม่ผ่าน RAG หรือการแก้ไขอย่างอื่น
• ลองเริ่มจาก assertion ที่กำหนดวลีหรือแนวคิดที่ต้องมีหรือห้ามมีในทุกคำตอบ
  • นอกจากนี้ยังควรพิจารณาการตรวจสอบว่าจำนวนคำ รายการ หรือประโยคอยู่ในช่วงที่กำหนดหรือไม่
  • สำหรับงานสร้างผลลัพธ์ประเภทอื่น assertion ก็อาจหน้าตาแตกต่างออกไป
    • ตัวอย่างเช่น ใน execution evaluation ซึ่งเป็นวิธีที่ทรงพลังสำหรับประเมินการสร้างโค้ด จะมีการรันโค้ดที่ถูกสร้างขึ้นและตรวจว่ารันไทม์สเตตเพียงพอต่อคำขอของผู้ใช้หรือไม่
• ตัวอย่างเช่น หากผู้ใช้ขอฟังก์ชันใหม่ชื่อ foo หลังจากรันโค้ดที่เอเจนต์สร้างขึ้นแล้ว ก็ควรจะสามารถเรียก foo ได้
• ความท้าทายอย่างหนึ่งของ execution evaluation คือ โค้ดของเอเจนต์มักทิ้งรันไทม์ไว้ในรูปแบบที่ต่างจากโค้ดเป้าหมายเล็กน้อย
  • การ "ผ่อน" assertion ให้เหลือสมมติฐานที่อ่อนที่สุดซึ่งยังรองรับคำตอบที่สมเหตุสมผลได้ทุกแบบ อาจเป็นวิธีที่ได้ผล
• การใช้งานผลิตภัณฑ์ตามที่ตั้งใจไว้สำหรับลูกค้าเอง (หรือ "dogfooding") สามารถให้ข้อมูลเชิงลึกเกี่ยวกับ failure mode บนข้อมูลจริงได้
  • แนวทางนี้ไม่เพียงช่วยระบุจุดอ่อนที่อาจเกิดขึ้น แต่ยังเป็นแหล่งของตัวอย่างโปรดักชันที่มีประโยชน์ซึ่งสามารถแปลงเป็นการประเมินได้อีกด้วย

LLM-as-Judge อาจใช้ได้ผล (ในระดับหนึ่ง) แต่ไม่ใช่ยาครอบจักรวาล

• LLM-as-Judge คือวิธีใช้ LLM ที่ทรงพลังตัวหนึ่งเพื่อประเมินเอาต์พุตของ LLM อีกตัว ซึ่งบางคนก็มองด้วยความสงสัย
• ถึงอย่างนั้น หากนำไปใช้อย่างเหมาะสม LLM-as-Judge ก็สามารถให้ผลที่สอดคล้องกับการตัดสินของมนุษย์ได้ในระดับสูง และอย่างน้อยก็ช่วยสร้างความเข้าใจล่วงหน้าได้ว่า prompt หรือเทคนิคใหม่อาจทำงานได้ดีแค่ไหน
  • โดยเฉพาะเมื่อใช้การเปรียบเทียบแบบเป็นคู่ (เช่น กลุ่มควบคุม vs กลุ่มทดลอง) LLM-as-Judge มักจับทิศทางได้ถูกต้อง แต่ขนาดของผลแพ้ชนะอาจมี noise อยู่
• ข้อเสนอแนะเพื่อใช้ LLM-as-Judge ให้ได้ประโยชน์สูงสุด
  • ใช้การเปรียบเทียบแบบเป็นคู่
    • แทนที่จะขอให้ LLM ให้คะแนนเอาต์พุตเดี่ยวด้วยสเกล Likert ให้แสดงตัวเลือกสองแบบแล้วให้เลือกอันที่ดีกว่า
    • วิธีนี้มักนำไปสู่ผลลัพธ์ที่เสถียรกว่า
  • ควบคุมอคติจากตำแหน่ง
    • ลำดับของตัวเลือกที่นำเสนออาจทำให้การตัดสินของ LLM เอนเอียงได้
    • เพื่อบรรเทาปัญหานี้ ให้ทำการเปรียบเทียบแต่ละคู่สองครั้ง โดยสลับลำดับของคู่ในแต่ละครั้ง
    • หลังจากสลับแล้ว ต้องนับชัยชนะให้กับตัวเลือกที่ถูกต้อง
  • อนุญาตให้เสมอได้
    • ในบางกรณี ตัวเลือกทั้งสองอาจดีเท่ากัน
    • ดังนั้นควรอนุญาตให้ LLM ตัดสินว่าเสมอได้ เพื่อไม่ต้องฝืนเลือกผู้ชนะโดยไม่มีเหตุผล
  • ใช้ Chain-of-Thought
    • หากให้ LLM อธิบายการตัดสินใจก่อนสรุปความชอบสุดท้าย ความน่าเชื่อถือของการประเมินอาจดีขึ้น
    • เป็นโบนัสเพิ่มเติม วิธีนี้ยังทำให้ใช้ LLM ที่อ่อนกว่าแต่เร็วกว่า และยังได้ผลลัพธ์ใกล้เคียงกันได้
    • เนื่องจากส่วนนี้ของ pipeline มักทำงานในโหมดแบตช์ เวลาแฝงที่เพิ่มขึ้นจาก CoT จึงไม่ใช่ปัญหา
  • ควบคุมความยาวของคำตอบ
    • LLM มักมีแนวโน้มเอนเอียงไปทางคำตอบที่ยาวกว่า
    • เพื่อลดปัญหานี้ ควรตรวจว่าความยาวของคำตอบทั้งคู่ใกล้เคียงกัน
• การประยุกต์ใช้ LLM-as-Judge ที่ทรงพลังอย่างยิ่งอย่างหนึ่งคือการตรวจสอบกลยุทธ์ prompt ใหม่กับปัญหา regression
  • หากคุณเก็บชุดผลลัพธ์จากโปรดักชันไว้ บางครั้งก็สามารถนำตัวอย่างโปรดักชันเหล่านั้นมารันใหม่ด้วยกลยุทธ์ prompt ใหม่ และใช้ LLM-as-Judge เพื่อประเมินอย่างรวดเร็วได้ว่ายุทธศาสตร์ใหม่นั้นอาจมีปัญหาตรงไหนบ้าง
• ตัวอย่างแนวทางที่เรียบง่ายแต่มีประสิทธิภาพของ LLM-as-Judge
  • เพียงบันทึกคำตอบของ LLM, คำวิจารณ์ของผู้ตัดสิน (คือ CoT) และผลลัพธ์สุดท้าย
  • จากนั้นนำไปทบทวนกับผู้มีส่วนได้ส่วนเสียเพื่อระบุจุดที่ควรปรับปรุง
  • หลังทำซ้ำ 3 รอบ ความสอดคล้องระหว่างมนุษย์กับ LLM เพิ่มขึ้นจาก 68% เป็น 94%
• อย่างไรก็ตาม LLM-as-Judge ไม่ใช่ยาครอบจักรวาล
  • แม้แต่โมเดลที่ทรงพลังที่สุดก็ยังประเมินแง่มุมทางภาษาที่ละเอียดอ่อนบางอย่างได้ไม่สม่ำเสมออย่างน่าเชื่อถือ
• นอกจากนี้ เรายังพบว่าตัวจำแนกประเภทแบบดั้งเดิมและ reward model สามารถให้ความแม่นยำได้สูงกว่า LLM-as-Judge โดยมีต้นทุนและเวลาแฝงต่ำกว่า
  • สำหรับการสร้างโค้ด LLM-as-Judge อาจด้อยกว่าวิธีประเมินที่ตรงกว่า เช่น execution evaluation

"การทดสอบระดับเด็กฝึกงาน" สำหรับการประเมินผลลัพธ์ที่สร้างขึ้น

• เวลาประเมินผลลัพธ์ที่สร้างขึ้น ควรใช้ "การทดสอบแบบเด็กฝึกงาน" ดังนี้
  • หากนำอินพุตที่ถูกต้องสำหรับ language model พร้อมบริบท ไปมอบเป็นงานให้กับนักศึกษามหาวิทยาลัยทั่วไปในสาขาที่เกี่ยวข้อง พวกเขาจะทำสำเร็จได้หรือไม่?
  • จะใช้เวลานานแค่ไหน?
• หากคำตอบคือไม่
  • หากเป็นเพราะ LLM ขาดความรู้ที่จำเป็น ให้พิจารณาวิธีทำให้บริบทสมบูรณ์ยิ่งขึ้น
  • หากปรับปรุงบริบทแล้วก็ยังแก้ไม่ได้ งานนั้นอาจยากเกินไปสำหรับ LLM ยุคปัจจุบัน
• หากคำตอบคือใช่ แต่ใช้เวลา
  • อาจลองลดความซับซ้อนของงาน
    • แยกย่อยได้หรือไม่?
    • มีด้านใดของงานที่ทำให้เป็นเทมเพลตได้มากขึ้นหรือไม่?
• หากคำตอบคือใช่ และทำได้อย่างรวดเร็ว
  • เมื่อลงลึกในข้อมูล
    • โมเดลกำลังทำอะไรผิดอยู่?
    • มองหารูปแบบของความล้มเหลวได้หรือไม่?
  • ลองขอให้โมเดลอธิบายด้วยตัวเองก่อนหรือหลังการตอบ

การให้น้ำหนักกับการประเมินเฉพาะจุดมากเกินไปอาจทำให้ประสิทธิภาพโดยรวมแย่ลง

"เมื่อมาตรวัดกลายเป็นเป้าหมาย มันก็จะไม่ใช่มาตรวัดที่ดีอีกต่อไป" - กฎของ Goodhart

• ตัวอย่างหนึ่งคือการประเมิน Needle-in-a-Haystack (NIAH)
  • เดิมที การประเมินนี้ช่วยวัดเชิงปริมาณเรื่องการเรียกคืนของโมเดลเมื่อขนาดบริบทใหญ่ขึ้น และดูว่าตำแหน่งของเข็มส่งผลต่อการเรียกคืนอย่างไร
  • แต่กลับถูกเน้นมากเกินไปจนถูกนำเสนอเป็น Figure 1 ในรายงาน Gemini 1.5
  • การประเมินนี้เกี่ยวข้องกับการแทรกวลีเฉพาะ ("The special magic {city} number is: {number}") ลงในเอกสารยาวที่มีการทำซ้ำบทความของ Paul Graham แล้วให้โมเดลระลึกถึง magic number
• แม้บางโมเดลจะทำ recall ได้เกือบสมบูรณ์แบบ แต่ก็ยังน่าสงสัยว่า NIAH สะท้อนความสามารถด้านการให้เหตุผลและการเรียกคืนที่จำเป็นต่อแอปพลิเคชันจริงได้จริงหรือไม่
• ลองพิจารณาสถานการณ์ที่ใช้งานได้จริงมากกว่า
  • หากให้ทรานสคริปต์การประชุม 1 ชั่วโมงแก่ LLM มันสามารถสรุปการตัดสินใจสำคัญและขั้นตอนถัดไป พร้อมระบุผู้รับผิดชอบที่เกี่ยวข้องในแต่ละรายการได้ถูกต้องหรือไม่?
  • งานนี้สมจริงกว่า เพราะนอกจากการท่องจำ ยังต้องมีความสามารถในการเข้าใจการสนทนาที่ซับซ้อน ระบุข้อมูลที่เกี่ยวข้อง และสังเคราะห์สรุป
• ตัวอย่างของการประเมิน NIAH ที่ใช้งานได้จริง
  • ใช้ทรานสคริปต์วิดีโอคอลระหว่างแพทย์กับผู้ป่วย แล้วถาม LLM เกี่ยวกับยาของผู้ป่วย
  • รวมถึง NIAH ที่ท้าทายยิ่งขึ้น เช่น แทรกวลีเกี่ยวกับวัตถุดิบสุ่มที่ต้องใช้เป็นท็อปปิ้งพิซซ่า เช่น อินทผลัมแช่เอสเปรสโซ เลมอน และชีสนมแพะ
  • ในงานเกี่ยวกับยา recall อยู่ที่ประมาณ 80% และในงานพิซซ่าอยู่ที่ 30%
• การเน้นการประเมิน NIAH มากเกินไปอาจลดประสิทธิภาพของงานสกัดข้อมูลและสรุปความได้
  • เนื่องจาก LLM เหล่านี้ถูก fine-tune ให้ใส่ใจกับทุกประโยค จึงอาจเริ่มมองรายละเอียดที่ไม่เกี่ยวข้องและสิ่งรบกวนว่าเป็นสิ่งสำคัญ
  • แล้วสิ่งเหล่านั้นอาจถูกใส่ลงในผลลัพธ์สุดท้ายได้ (ทั้งที่ไม่ควรใส่!)
• สิ่งนี้อาจใช้ได้กับการประเมินและกรณีใช้งานอื่น ๆ ด้วย
  • เช่น การสรุปความ
    • หากเน้นความสอดคล้องตามข้อเท็จจริงมากเกินไป อาจทำให้ได้สรุปที่เฉพาะเจาะจงน้อยลง (จึงมีโอกาสขัดกับข้อเท็จจริงน้อยลง) แต่ก็อาจเกี่ยวข้องน้อยลงด้วย
    • ในทางกลับกัน หากเน้นสไตล์การเขียนและความคมคาย ก็อาจทำให้เกิดภาษาสไตล์การตลาดที่หวือหวากว่า ซึ่งอาจนำไปสู่ความไม่สอดคล้องตามข้อเท็จจริง

ทำงาน annotation ให้ง่ายลงเป็นงานแบบไบนารีหรือการเปรียบเทียบแบบคู่ (pairwise)

• การให้ feedback แบบปลายเปิดกับผลลัพธ์ของโมเดล หรือการประเมินด้วยสเกล Likert เป็นภาระทางความคิดค่อนข้างสูง
  • ส่งผลให้ข้อมูลที่เก็บมามี noise มากขึ้นจากความแปรปรวนระหว่างผู้ประเมินที่เป็นมนุษย์ และจึงมีประโยชน์น้อยลง
• แนวทางที่มีประสิทธิภาพกว่าคือทำให้งานง่ายขึ้นและลดภาระทางความคิดของผู้ทำ annotation
  • งานที่ใช้ได้ผลดีมี 2 แบบคือการจัดประเภทแบบไบนารีและการเปรียบเทียบแบบคู่
• ในการจัดประเภทแบบไบนารี ผู้ทำ annotation จะถูกขอให้ตัดสินแบบง่าย ๆ ว่าใช่หรือไม่ใช่ต่อผลลัพธ์ของโมเดล
  • อาจถามว่าสรุปที่สร้างขึ้นสอดคล้องกับเอกสารต้นทางตามข้อเท็จจริงหรือไม่ คำตอบที่เสนอมีความเกี่ยวข้องหรือไม่ มีเนื้อหาที่เป็นอันตรายหรือไม่ เป็นต้น
  • เมื่อเทียบกับสเกล Likert การตัดสินแบบไบนารีแม่นยำกว่า มีความสอดคล้องระหว่างผู้ประเมินสูงกว่า และมี throughput สูงกว่า
  • เช่นวิธีที่ Doordash ตั้ง labeling queue เพื่อติดแท็กเมนูอาหารผ่านชุดคำถามแบบใช่/ไม่ใช่
• ในการเปรียบเทียบแบบคู่ (Pairwise Comparison) ผู้ทำ annotation จะได้รับคำตอบจากโมเดลมาหนึ่งคู่ แล้วถามว่าอันไหนดีกว่า
  • เพราะสำหรับมนุษย์ การบอกว่า "A ดีกว่า B" ง่ายกว่าการให้คะแนน A หรือ B แยกกัน จึงทำให้การทำ annotation เร็วและเชื่อถือได้มากกว่า (เมื่อเทียบกับสเกล Likert)
• ในงาน Llama2 meetup, Thomas Scialom ซึ่งเป็นหนึ่งในผู้เขียนบทความ Llama2 ยืนยันว่า การเปรียบเทียบแบบคู่เร็วและถูกกว่าการเก็บข้อมูล supervised fine-tuning ที่เป็นคำตอบซึ่งเขียนขึ้นมา
  • แบบแรกมีต้นทุน $3.5 ต่อหน่วย และแบบหลังมีต้นทุน $25 ต่อหน่วย

การประเมินแบบไม่ต้องมีข้อมูลอ้างอิง (reference-free) และ guardrail สามารถใช้แทนกันได้

• guardrail ช่วยจับคอนเทนต์ที่ไม่เหมาะสมหรือเป็นอันตราย ขณะที่การประเมินช่วยวัดคุณภาพและความถูกต้องของผลลัพธ์จากโมเดล
  • สำหรับการประเมินแบบไม่ต้องมีข้อมูลอ้างอิง สามารถมองได้ว่าเป็นคนละด้านของเหรียญเดียวกัน
    • การประเมินแบบไม่ต้องมีข้อมูลอ้างอิงคือการประเมินที่สามารถวัดคุณภาพของผลลัพธ์ได้จากเพียง prompt อินพุตและคำตอบของโมเดล โดยไม่ต้องพึ่ง reference แบบ "golden" เช่นคำตอบที่มนุษย์เขียน
• ตัวอย่างของการประเมินแบบไม่ต้องมีข้อมูลอ้างอิง: การประเมินสรุปความ
  • ต้องพิจารณาเพียงเอกสารอินพุตเพื่อประเมินความสอดคล้องตามข้อเท็จจริงและความเกี่ยวข้องของสรุป
  • หากสรุปได้คะแนนต่ำในตัวชี้วัดเหล่านี้ ก็สามารถเลือกไม่แสดงให้ผู้ใช้เห็นได้ ทำให้ใช้การประเมินเป็น guardrail ได้อย่างมีประสิทธิภาพ
• การประเมิน "การแปล" แบบไม่ต้องมีข้อมูลอ้างอิง:
  • สามารถประเมินคุณภาพของคำแปลได้โดยไม่ต้องมีคำแปลอ้างอิงจากมนุษย์ และนำมาใช้เป็น guardrail ได้อีกเช่นกัน

LLM มักคืนผลลัพธ์แม้ในเวลาที่ไม่ควรคืน

• ความท้าทายหลักอย่างหนึ่งในการทำงานกับ LLM คือมันมักสร้างผลลัพธ์ออกมา แม้ในเวลาที่ไม่ควรทำเช่นนั้น
  • สิ่งนี้อาจนำไปสู่คำตอบที่ไม่เป็นอันตรายแต่ไร้ความหมาย หรือข้อบกพร่องที่ร้ายแรงกว่า เช่น เนื้อหาที่เป็นอันตรายหรือเสี่ยง
  • ตัวอย่างเช่น เมื่อถูกขอให้ดึงคุณลักษณะหรือ metadata บางอย่างจากเอกสาร LLM อาจคืนค่ากลับมาอย่างมั่นใจแม้ว่าค่านั้นจะไม่มีอยู่จริง
  • หรือโมเดลอาจตอบเป็นภาษาที่ไม่ใช่อังกฤษ เพราะมีการให้เอกสารที่ไม่ใช่ภาษาอังกฤษอยู่ในบริบท
• แม้จะ prompt ให้ LLM ตอบว่า "ไม่เกี่ยวข้อง" หรือ "ไม่ทราบ" ได้ แต่ก็ไม่สมบูรณ์แบบ
  • แม้ในกรณีที่ใช้ log probability ได้ มันก็ยังเป็นตัวชี้วัดคุณภาพของผลลัพธ์ที่ไม่ดี
    • log probability แสดงความน่าจะเป็นที่โทเคนจะปรากฏในผลลัพธ์ แต่ไม่ได้สะท้อนความถูกต้องของข้อความที่สร้างขึ้น
  • ยิ่งไปกว่านั้น สำหรับ instruction-tuned model ที่ถูกฝึกให้ตอบสนองต่อคำถามและสร้างคำตอบที่สอดคล้องกัน log probability อาจไม่ได้ถูก calibrate มาอย่างดี
    • ดังนั้น log probability ที่สูงอาจบอกได้เพียงว่าผลลัพธ์ลื่นไหลและสอดคล้องกัน แต่ไม่ได้หมายความว่าถูกต้องหรือเกี่ยวข้อง
• prompt engineering อย่างระมัดระวังอาจช่วยได้ระดับหนึ่ง แต่ควรเสริมด้วย guardrail ที่แข็งแรงในการตรวจจับและกรอง/สร้างใหม่เมื่อมีผลลัพธ์ที่ไม่ต้องการ
  • ตัวอย่างเช่น OpenAI มี Content Moderation API ที่สามารถระบุคำตอบที่ไม่ปลอดภัย เช่น hate speech การทำร้ายตัวเอง หรือผลลัพธ์เชิงเพศ
  • เช่นเดียวกัน ยังมีแพ็กเกจจำนวนมากสำหรับตรวจจับข้อมูลระบุตัวตนส่วนบุคคล (PII)
• ข้อดีอย่างหนึ่งของ guardrail คือโดยมากไม่ผูกกับกรณีใช้งานมากนัก จึงสามารถนำไปใช้กว้าง ๆ กับผลลัพธ์ทั้งหมดในภาษาหนึ่งได้
  • นอกจากนี้ หากไม่มีเอกสารที่เกี่ยวข้องจากการค้นหาที่แม่นยำ ระบบก็สามารถตอบว่า "ไม่ทราบ" ได้อย่างเด็ดขาด
• LLM อาจไม่สร้างผลลัพธ์ ทั้งที่คาดหวังให้สร้าง
  • สิ่งนี้เกิดได้จากหลายสาเหตุ ตั้งแต่ปัญหาง่าย ๆ อย่าง latency สูงจากผู้ให้บริการ API ไปจนถึงปัญหาซับซ้อนกว่า เช่น ผลลัพธ์ถูกบล็อกโดย content moderation filter
• ดังนั้นจึงสำคัญที่จะต้องบันทึกอินพุต และ (รวมถึงการไม่มีเอาต์พุตที่อาจเกิดขึ้น) อย่างสม่ำเสมอ เพื่อการดีบักและมอนิเตอร์

อาการหลอน (Hallucination) เป็นปัญหาที่แก้ไม่ตก

• ในขณะที่ปัญหาด้านความปลอดภัยของเนื้อหาหรือข้อบกพร่องเกี่ยวกับ PII ได้รับความสนใจอย่างมากจนแทบไม่เกิดขึ้นเลย แต่ความไม่สอดคล้องกับข้อเท็จจริงยังคงเกิดขึ้นอย่างต่อเนื่องและตรวจจับได้ยากกว่า
  • เกิดขึ้นบ่อยกว่า โดยมีอัตราเกิดพื้นฐานอยู่ที่ 5~10% และจากสิ่งที่เรียนรู้จากผู้ให้บริการ LLM การลดให้ต่ำกว่า 2% แม้ในงานง่าย ๆ อย่างการสรุปก็อาจทำได้ยาก
• เพื่อแก้ปัญหานี้ สามารถผสาน prompt engineering (ต้นน้ำของการสร้าง) เข้ากับ guardrail สำหรับความไม่สอดคล้องกับข้อเท็จจริง (ปลายน้ำของการสร้าง) ได้
  • ในกรณีของ prompt engineering เทคนิคอย่าง CoT ช่วยลด hallucination ได้โดยให้ LLM อธิบายเหตุผลก่อนส่งผลลัพธ์สุดท้าย
  • จากนั้นจึงใช้ guardrail สำหรับความไม่สอดคล้องกับข้อเท็จจริงเพื่อประเมินความถูกต้องเชิงข้อเท็จจริงของบทสรุป และกรองหรือสร้างใหม่เมื่อพบ hallucination
• ในบางกรณี hallucination สามารถตรวจจับได้แบบกำหนดแน่นอน
  • เมื่อใช้ทรัพยากรจากการค้นคืนของ RAG หากผลลัพธ์มีโครงสร้างและระบุได้ว่าทรัพยากรคืออะไร ก็ควรสามารถตรวจสอบด้วยตนเองได้ว่ามีที่มาจากบริบทอินพุตหรือไม่

[การปฏิบัติการ: งานประจำวัน (Day-to-Day) และปัญหาระดับองค์กร ]

การปฏิบัติการ 1. ข้อมูล

• เช่นเดียวกับที่คุณภาพของวัตถุดิบกำหนดรสชาติของอาหาร คุณภาพของข้อมูลนำเข้าก็เป็นข้อจำกัดต่อประสิทธิภาพของระบบแมชชีนเลิร์นนิง
• นอกจากนี้ ข้อมูลผลลัพธ์ยังเป็นวิธีเดียวที่จะรู้ได้ว่าผลิตภัณฑ์ทำงานหรือไม่
• ผู้เขียนทุกคนใช้เวลาหลายชั่วโมงในแต่ละสัปดาห์เพื่อตรวจดูอินพุตและเอาต์พุตอย่างละเอียด เพื่อให้เข้าใจการกระจายของข้อมูล (โหมด, edge case, ขีดจำกัดของโมเดล) ได้ดียิ่งขึ้น

ตรวจสอบอคติระหว่างการพัฒนา-โปรดักชัน

• ในไปป์ไลน์แมชชีนเลิร์นนิงแบบดั้งเดิม สาเหตุทั่วไปของข้อผิดพลาดคือ training-serving skew
  • สิ่งนี้เกิดขึ้นเมื่อข้อมูลที่ใช้ฝึกแตกต่างจากข้อมูลที่โมเดลพบเจอในโปรดักชัน
• แม้จะสามารถใช้ LLM ได้โดยไม่ต้องฝึกหรือ fine-tune จึงไม่มีชุดฝึก แต่ก็ยังเกิดปัญหาคล้ายกันในรูปของอคติของข้อมูลระหว่างการพัฒนา-โปรดักชัน
  • โดยพื้นฐานแล้ว ข้อมูลที่ใช้ทดสอบระบบระหว่างการพัฒนาควรสะท้อนข้อมูลที่ระบบจะต้องเผชิญในโปรดักชัน
    • มิฉะนั้น ความแม่นยำในโปรดักชันอาจลดลง
• อคติระหว่างการพัฒนา-โปรดักชันของ LLM สามารถแบ่งได้เป็นสองประเภท: อคติเชิงโครงสร้างและอคติตามเนื้อหา
  • อคติเชิงโครงสร้างรวมถึงปัญหาอย่างความไม่ตรงกันของรูปแบบ เช่น ความแตกต่างระหว่าง JSON dictionary ที่มีค่ารูปแบบลิสต์กับ JSON list, การใช้ตัวพิมพ์ใหญ่เล็กไม่สม่ำเสมอ, และข้อผิดพลาดอย่างการพิมพ์ผิดหรือเศษประโยค
    • ข้อผิดพลาดเหล่านี้อาจนำไปสู่ประสิทธิภาพของโมเดลที่คาดเดาไม่ได้ เพราะ LLM แต่ละตัวถูกฝึกกับรูปแบบข้อมูลเฉพาะ และ prompt อาจไวต่อการเปลี่ยนแปลงเล็กน้อยมาก
  • อคติตามเนื้อหาหรือ "เชิงความหมาย" หมายถึงความแตกต่างของความหมายหรือบริบทของข้อมูล
• เช่นเดียวกับ ML แบบดั้งเดิม การวัดอคติระหว่างคู่ข้อมูลอินพุต/เอาต์พุตของ LLM เป็นระยะ ๆ มีประโยชน์
  • เมตริกง่าย ๆ เช่น ความยาวของอินพุตและเอาต์พุต หรือข้อกำหนดด้านรูปแบบเฉพาะ (เช่น JSON หรือ XML) เป็นวิธีง่าย ๆ ในการติดตามการเปลี่ยนแปลง
• สำหรับการตรวจจับอคติที่ "ขั้นสูง" ยิ่งขึ้น ควรพิจารณาการทำคลัสเตอร์ embedding ของคู่ข้อมูลอินพุต/เอาต์พุต เพื่อจับอคติเชิงความหมาย เช่น การเปลี่ยนแปลงของหัวข้อที่ผู้ใช้พูดถึง ซึ่งอาจบ่งชี้ว่าผู้ใช้กำลังสำรวจพื้นที่ที่โมเดลไม่เคยเห็นมาก่อน
• เมื่อทดสอบการเปลี่ยนแปลง เช่น prompt engineering ให้แน่ใจว่าชุดข้อมูล holdout ทันสมัยและสะท้อนรูปแบบปฏิสัมพันธ์ของผู้ใช้ล่าสุด
  • ตัวอย่างเช่น หากอินพุตในโปรดักชันมีคำสะกดผิดอยู่บ่อย ชุดข้อมูล holdout ก็ควรมีด้วย
• นอกเหนือจากการวัดอคติเป็นตัวเลขเพียงอย่างเดียว การทำการประเมินเชิงคุณภาพกับเอาต์พุตก็มีประโยชน์
  • การตรวจทานเอาต์พุตของโมเดลเป็นประจำ (แนวปฏิบัติที่เรียกกันเล่น ๆ ว่า "vibe check") ช่วยยืนยันว่าผลลัพธ์ยังสอดคล้องกับความคาดหวังและยังเกี่ยวข้องกับความต้องการของผู้ใช้อยู่
• การผสานความไม่เป็นเชิงกำหนดแน่นอนเข้ากับการตรวจสอบอคติก็มีประโยชน์เช่นกัน
  • โดยรันไปป์ไลน์หลายครั้งสำหรับแต่ละอินพุตในชุดข้อมูลทดสอบและวิเคราะห์เอาต์พุตทั้งหมด ก็จะมีโอกาสสูงขึ้นในการจับความผิดปกติที่อาจเกิดขึ้นเป็นครั้งคราวเท่านั้น

ตรวจสอบตัวอย่างอินพุต/เอาต์พุตของ LLM ทุกวัน

• LLM มีความเปลี่ยนแปลงและพัฒนาอย่างต่อเนื่อง
  • แม้จะมีความสามารถแบบ zero-shot ที่น่าประทับใจและเอาต์พุตที่มักดูน่าพอใจ แต่รูปแบบความล้มเหลวของ LLM กลับคาดเดาได้ยากมาก
• สำหรับงานที่ปรับแต่งเฉพาะ การตรวจทานตัวอย่างข้อมูลอย่างสม่ำเสมอเป็นสิ่งจำเป็นเพื่อสร้างความเข้าใจเชิงสัญชาตญาณเกี่ยวกับประสิทธิภาพของ LLM
  • คู่ข้อมูลอินพุต/เอาต์พุตในโปรดักชันคือ "ของจริง ในสถานที่จริง" (genchi genbutsu) ของแอปพลิเคชัน LLM และไม่มีสิ่งใดทดแทนได้
• งานวิจัยล่าสุดชี้ให้เห็นว่า ยิ่งนักพัฒนามีปฏิสัมพันธ์กับข้อมูลมากขึ้น การรับรู้ว่าเอาต์พุตแบบใดคือ "ดี" และแบบใดคือ "ไม่ดี" ก็จะยิ่งเปลี่ยนไป (กล่าวคือ criteria bias)
  • นักพัฒนาสามารถกำหนดเกณฑ์บางอย่างสำหรับการประเมินเอาต์พุตของ LLM ล่วงหน้าได้ แต่เกณฑ์ที่กำหนดล่วงหน้าเหล่านี้มักไม่สมบูรณ์
• ตัวอย่างเช่น ในระหว่างการพัฒนา อาจอัปเดต prompt เพื่อเพิ่มโอกาสของคำตอบที่ดีและลดโอกาสของคำตอบที่ไม่ดี
  • กระบวนการวนซ้ำของการประเมิน ประเมินใหม่ และอัปเดตเกณฑ์นี้เป็นสิ่งจำเป็น เพราะยากที่จะคาดการณ์พฤติกรรมของ LLM หรือความชอบของมนุษย์ได้โดยไม่สังเกตเอาต์พุตโดยตรง
• เพื่อจัดการเรื่องนี้อย่างมีประสิทธิภาพ ควรบันทึกอินพุตและเอาต์พุตของ LLM
  • การตรวจสอบตัวอย่างจาก log เหล่านี้ทุกวันจะช่วยให้ระบุรูปแบบใหม่ ๆ หรือโหมดความล้มเหลวได้อย่างรวดเร็วและปรับตัวได้ทัน
  • เมื่อพบปัญหาใหม่ ก็สามารถเขียน assertion หรือ eval สำหรับปัญหานั้นได้ทันที
• ในทำนองเดียวกัน การอัปเดตใด ๆ เกี่ยวกับนิยามของโหมดความล้มเหลวควรถูกสะท้อนในเกณฑ์การประเมิน
  • "vibe check" เหล่านี้เป็นสัญญาณของเอาต์พุตที่ผิดพลาด ส่วนโค้ดและ assertion จะทำหน้าที่ทำให้สิ่งเหล่านั้นถูกนำไปใช้งานจริง
• สุดท้าย ทัศนคติแบบนี้ควรถูกทำให้เป็นวัฒนธรรมร่วมกัน
  • ตัวอย่างเช่น เพิ่มการตรวจทานหรือการใส่คำอธิบายประกอบให้กับอินพุตและเอาต์พุตเข้าไปใน on-call rotation

การปฏิบัติการ 2. ทำงานร่วมกับโมเดล

• การใช้ LLM API ทำให้สามารถพึ่งพาความฉลาดของผู้ให้บริการเพียงไม่กี่รายได้
  • นี่เป็นข้อดี แต่การพึ่งพาเช่นนี้ก็มาพร้อม trade-off ในแง่ของประสิทธิภาพ, latency, throughput และต้นทุน
• นอกจากนี้ ตลอดปีที่ผ่านมา มีการเปิดตัวโมเดลที่ใหม่กว่าและดีกว่าแทบทุกเดือน ดังนั้นจึงต้องเตรียมพร้อมอัปเดตผลิตภัณฑ์เมื่อถึงเวลายกเลิกโมเดลเก่าและย้ายไปใช้โมเดลใหม่
  • ในส่วนนี้จะแชร์บทเรียนที่ได้จากการใช้เทคโนโลยีที่เราไม่สามารถควบคุมได้ทั้งหมด กล่าวคือ เทคโนโลยีที่ไม่สามารถ self-host และดูแลจัดการโมเดลเองได้
• สำหรับกรณีใช้งานจริงส่วนใหญ่ เอาต์พุตของ LLM จะถูกใช้งานต่อโดยแอปพลิเคชันปลายน้ำผ่านรูปแบบที่เครื่องอ่านได้บางประเภท
  • ตัวอย่างเช่น ReChat ซึ่งเป็น CRM สำหรับอสังหาริมทรัพย์ ต้องการคำตอบแบบมีโครงสร้างเพื่อเรนเดอร์วิดเจ็ตในฟรอนต์เอนด์
  • ในทำนองเดียวกัน Boba ซึ่งเป็นเครื่องมือสร้างไอเดียกลยุทธ์ผลิตภัณฑ์ ต้องการเอาต์พุตแบบมีโครงสร้างที่มีฟิลด์อย่างชื่อเรื่อง สรุป คะแนนความเป็นไปได้ และช่วงเวลา
  • สุดท้าย LinkedIn ได้แชร์วิธีจำกัด LLM ให้สร้าง YAML ซึ่งใช้ในการตัดสินใจว่าจะใช้เทคโนโลยีใดและกำหนดพารามิเตอร์สำหรับเรียกใช้เทคโนโลยีนั้น
• รูปแบบการใช้งานแอปพลิเคชันนี้เป็นเวอร์ชันสุดขั้วของกฎของ Postel
  • จงยืดหยุ่นในสิ่งที่รับเข้า (ภาษาธรรมชาติแบบใดก็ได้) และเข้มงวดในสิ่งที่ส่งออก (อ็อบเจ็กต์แบบกำหนดชนิดที่เครื่องอ่านได้)
  • ดังนั้นจึงคาดว่าวิธีนี้จะมีความทนทานสูงมาก
• ปัจจุบัน Instructor และ Outlines คือมาตรฐานโดยพฤตินัยสำหรับการดึงเอาต์พุตแบบมีโครงสร้างจาก LLM
  • หากใช้ LLM API (เช่น Anthropic, OpenAI) ให้ใช้ Instructor และหากใช้โมเดลแบบ self-host (เช่น Huggingface) ให้ใช้ Outlines

การย้าย prompt ข้ามโมเดลเป็นเรื่องที่เจ็บปวด

• บางครั้งพรอมต์ที่ออกแบบมาอย่างพิถีพิถันอาจทำงานได้ยอดเยี่ยมกับโมเดลหนึ่ง แต่กลับทำงานได้ไม่ดีนักกับอีกโมเดลหนึ่ง
  • สิ่งนี้อาจเกิดขึ้นได้ไม่เพียงตอนสลับไปมาระหว่างผู้ให้บริการโมเดลหลายรายเท่านั้น แต่ยังเกิดขึ้นได้ตอนอัปเกรดระหว่างเวอร์ชันของโมเดลเดียวกันด้วย
• ตัวอย่างเช่น Voiceflow พบว่าการย้ายจาก gpt-3.5-turbo-0301 ไปเป็น gpt-3.5-turbo-1106 ทำให้ประสิทธิภาพของงานจัดประเภทเจตนาลดลง 10%
  • (โชคดีที่พวกเขามี evaluation อยู่แล้ว!)
• ในทำนองเดียวกัน GoDaddy สังเกตเห็นแนวโน้มในทางบวกว่า เมื่ออัปเกรดเป็นเวอร์ชัน 1106 ช่องว่างด้านประสิทธิภาพระหว่าง gpt-3.5-turbo กับ gpt-4 แคบลง
  • (หรือถ้าคุณเป็นคนประเภทมองแก้วน้ำครึ่งใบ คุณอาจผิดหวังที่การอัปเกรดใหม่นี้ทำให้ gpt-4 นำห่างน้อยลงก็ได้)
• ดังนั้นหากต้องย้ายพรอมต์ข้ามโมเดล ควรคาดไว้เลยว่าจะใช้เวลามากกว่าแค่เปลี่ยน API endpoint
  • อย่าสมมติว่าการเสียบพรอมต์เดิมเข้าไปจะให้ผลลัพธ์ที่คล้ายเดิมหรือดีกว่าเดิม
• นอกจากนี้ evaluation ที่เชื่อถือได้และทำงานอัตโนมัติยังช่วยวัดประสิทธิภาพของงานก่อนและหลังการย้าย และลดภาระของการตรวจสอบด้วยมือได้

การจัดการเวอร์ชันของโมเดลและการ pin

• ในทุก machine learning pipeline นั้น “ถ้าเปลี่ยนอะไรก็ตาม ทุกอย่างก็เปลี่ยนตาม”
  • เรื่องนี้ยิ่งสำคัญเป็นพิเศษเมื่อเราพึ่งพาองค์ประกอบอย่าง large language model (LLM) ที่เราไม่ได้เป็นคนฝึกเองและอาจถูกเปลี่ยนโดยที่เราไม่รู้ตัว
• โชคดีที่ผู้ให้บริการโมเดลหลายรายมีตัวเลือกให้ “pin” เวอร์ชันโมเดลเฉพาะได้ (เช่น gpt-4-turbo-1106)
  • วิธีนี้ทำให้เราสามารถใช้เวอร์ชันเฉพาะของ model weights และป้องกันไม่ให้มีการเปลี่ยนแปลง
• การ pin เวอร์ชันโมเดลในโปรดักชันช่วยป้องกันการเปลี่ยนแปลงพฤติกรรมของโมเดลโดยไม่คาดคิดได้
  • ซึ่งอาจช่วยหลีกเลี่ยงข้อร้องเรียนจากลูกค้าเกี่ยวกับปัญหาอย่างเอาต์พุตที่ยืดยาวเกินไปหรือ failure mode อื่น ๆ ที่ไม่คาดคิดซึ่งอาจเกิดขึ้นเมื่อมีการสลับโมเดล
• นอกจากนี้ควรพิจารณาดูแล “shadow pipeline” ที่ mirror การตั้งค่าโปรดักชัน แต่ใช้เวอร์ชันโมเดลล่าสุด
  • วิธีนี้ช่วยให้ทดลองและทดสอบกับรีลีสใหม่ได้อย่างปลอดภัย
• หลังจากตรวจสอบความเสถียรและคุณภาพของเอาต์พุตจากโมเดลใหม่เหล่านี้แล้ว คุณก็สามารถอัปเดตเวอร์ชันโมเดลในสภาพแวดล้อมโปรดักชันได้อย่างมั่นใจ

เลือกโมเดลที่เล็กที่สุดซึ่งยังทำงานนั้นได้สำเร็จ

• เมื่อทำงานกับแอปพลิเคชันใหม่ ๆ มักมีสิ่งล่อใจให้ใช้โมเดลที่ใหญ่และทรงพลังที่สุดเท่าที่มี
  • แต่เมื่อยืนยันได้แล้วว่างานนั้นทำได้จริงในเชิงเทคนิค ก็คุ้มค่าที่จะทดลองดูว่าสามารถได้ผลลัพธ์ใกล้เคียงกันด้วยโมเดลที่เล็กกว่าหรือไม่
• ข้อดีของโมเดลเล็กคือ latency ต่ำและต้นทุนต่ำ
  • แม้มันอาจอ่อนกว่าก็ตาม แต่เทคนิคอย่าง Chain-of-Thought, n-shot prompting และ in-context learning สามารถช่วยให้โมเดลเล็กทำได้เกินกว่าขีดความสามารถเดิม
• นอกเหนือจาก LLM API แล้ว การ fine-tuning สำหรับงานเฉพาะก็อาจช่วยเพิ่มประสิทธิภาพได้เช่นกัน
• โดยรวมแล้ว workflow ที่ออกแบบอย่างรอบคอบโดยใช้โมเดลเล็ก อาจทั้งเร็วกว่าและถูกกว่า พร้อมทั้งให้คุณภาพเอาต์พุตเทียบเท่าหรือแม้แต่เหนือกว่าโมเดลใหญ่เพียงตัวเดียว
  • ตัวอย่างเช่น ทวีตนี้ แชร์เกร็ดประสบการณ์เกี่ยวกับวิธีที่ Haiku + 10-shot prompt เอาชนะ zero-shot Opus และ GPT-4 ได้
• ในระยะยาวคาดว่าจะมีตัวอย่างของ flow engineering ด้วยโมเดลเล็กเพิ่มขึ้นอีกมาก ซึ่งให้สมดุลที่ดีที่สุดระหว่างคุณภาพเอาต์พุต latency และต้นทุน
• อีกตัวอย่างหนึ่งคืองานจัดประเภทที่ดูธรรมดา
  • โมเดลขนาดเบาอย่าง DistilBERT (พารามิเตอร์ 67 ล้านตัว) เป็น baseline ที่ทรงพลังอย่างน่าประหลาดใจ
  • DistilBART ขนาด 400 ล้านพารามิเตอร์ก็เป็นอีกตัวเลือกที่ยอดเยี่ยม
    • เมื่อ fine-tune บนข้อมูลโอเพนซอร์ส มันสามารถระบุ hallucination ได้ด้วย ROC-AUC 0.84 และเอาชนะ LLM ส่วนใหญ่ได้โดยใช้ latency และต้นทุนน้อยกว่า 5%
• ประเด็นสำคัญคืออย่ามองข้ามโมเดลเล็ก
  • แม้จะเป็นเรื่องง่ายที่จะเอาโมเดลยักษ์ไปใช้กับทุกปัญหา แต่ด้วยความคิดสร้างสรรค์และการทดลองอีกเล็กน้อย เรามักหาทางออกที่มีประสิทธิภาพกว่านั้นได้

Operations 3. Product

• เทคโนโลยีใหม่มอบความเป็นไปได้ใหม่ ๆ แต่หลักการของการสร้างผลิตภัณฑ์ที่ยอดเยี่ยมยังคงไม่เปลี่ยนแปลง
  • ดังนั้นแม้เราจะแก้ปัญหาแบบใหม่เป็นครั้งแรก ก็ไม่จำเป็นต้องประดิษฐ์วงล้อใหม่ในเรื่องการออกแบบผลิตภัณฑ์
• การยึดการพัฒนาแอปพลิเคชัน LLM ไว้กับพื้นฐานผลิตภัณฑ์ที่แข็งแรงนั้นมีประโยชน์อย่างมาก
  • วิธีนี้ช่วยให้เราส่งมอบคุณค่าที่แท้จริงแก่ผู้คนที่เราให้บริการได้

ดึงงานออกแบบเข้ามาตั้งแต่เนิ่น ๆ

• การมีดีไซเนอร์ทำให้เราเข้าใจและคิดลึกขึ้นว่าจะสร้างผลิตภัณฑ์และนำเสนอให้ผู้ใช้อย่างไร
  • บางครั้งเราอาจเหมารวมว่าดีไซเนอร์คือคนที่ทำให้สิ่งต่าง ๆ ดูสวยงาม
  • แต่ในความเป็นจริง พวกเขายังช่วยทบทวนด้วยว่าเราจะปรับปรุงประสบการณ์ผู้ใช้อย่างไรได้บ้าง แม้ต้องทลายกฎและกรอบคิดเดิม ๆ ไม่ใช่แค่เรื่อง user interface เท่านั้น
• ดีไซเนอร์มีความสามารถเป็นพิเศษในการ reframing ความต้องการของผู้ใช้ให้อยู่ในรูปแบบต่าง ๆ
  • บางรูปแบบแก้ได้ง่ายกว่ารูปแบบอื่น จึงอาจเปิดโอกาสให้กับโซลูชัน AI ได้มากหรือน้อยต่างกัน
• เช่นเดียวกับผลิตภัณฑ์อีกมากมาย การสร้างผลิตภัณฑ์ AI ควรยึดที่งานที่ต้องทำ ไม่ใช่เทคโนโลยีที่ขับเคลื่อนผลิตภัณฑ์
• ควรโฟกัสกับการตั้งคำถามกับตัวเอง เช่น
  • “งานที่ผู้ใช้ต้องการให้ผลิตภัณฑ์นี้ช่วยทำคืออะไร? งานนั้นเป็นสิ่งที่แชตบอตน่าจะทำได้ดีหรือไม่? แล้ว autocomplete ล่ะ? หรืออาจเป็นอย่างอื่นก็ได้!”
• พิจารณา pattern การออกแบบที่มีอยู่และความเกี่ยวข้องของมันกับงานที่ต้องทำ
  • สิ่งเหล่านี้คือทรัพย์สินล้ำค่าที่ดีไซเนอร์เพิ่มให้กับศักยภาพของทีม

การออกแบบ UX สำหรับ human-in-the-loop

• วิธีหนึ่งในการได้ annotation คุณภาพดีคือการผสาน Human-in-the-Loop (HITL) เข้ากับประสบการณ์ผู้ใช้ (UX)
  • หากเปิดให้ผู้ใช้ส่ง feedback และการแก้ไขได้อย่างง่ายดาย ก็จะช่วยปรับปรุงผลลัพธ์ทันทีและเก็บข้อมูลที่มีประโยชน์ต่อการปรับปรุงโมเดลได้
• ลองนึกถึงแพลตฟอร์มอีคอมเมิร์ซที่ผู้ใช้อัปโหลดและจัดหมวดหมู่สินค้า
  • มีหลายวิธีในการออกแบบ UX
    1. ผู้ใช้เลือกหมวดหมู่สินค้าที่ถูกต้องด้วยตนเอง และ LLM จะตรวจสอบสินค้าใหม่เป็นระยะ ๆ พร้อมแก้การจัดหมวดหมู่ที่ผิดในฝั่ง backend
    2. ผู้ใช้ไม่ต้องเลือกหมวดหมู่เลย และ LLM จะจัดหมวดหมู่สินค้าในฝั่ง backend เป็นระยะ ๆ (ซึ่งอาจมีข้อผิดพลาดได้)
    3. LLM แนะนำหมวดหมู่สินค้าแบบเรียลไทม์ และผู้ใช้สามารถตรวจสอบและอัปเดตได้ตามต้องการ
• ทั้งสามแนวทางมี LLM เหมือนกัน แต่ให้ UX ที่แตกต่างกันมาก
  • แนวทางแรกผลักภาระเริ่มต้นไปที่ผู้ใช้ และให้ LLM ทำหน้าที่เป็นตัวตรวจสอบภายหลัง
  • แนวทางที่สองไม่ต้องให้ผู้ใช้ลงแรงเลย แต่ก็ไม่ให้ความโปร่งใสหรือการควบคุม
  • แนวทางที่สามรักษาสมดุลที่เหมาะสม
    • LLM แนะนำหมวดหมู่ล่วงหน้าเพื่อลดภาระการรับรู้ของผู้ใช้ และทำให้ไม่ต้องเรียนรู้ taxonomy ของเราเพื่อจัดหมวดหมู่สินค้า
    • ในขณะเดียวกัน การเปิดให้ผู้ใช้ตรวจสอบและแก้ไขคำแนะนำได้ ก็ทำให้สิทธิ์ตัดสินใจสุดท้ายเกี่ยวกับวิธีจัดหมวดหมู่สินค้ายังคงอยู่ในมือผู้ใช้อย่างมั่นคง
  • และเป็นโบนัส แนวทางที่สามยังสร้าง feedback loop ตามธรรมชาติสำหรับการปรับปรุงโมเดล
    • คำแนะนำที่ดีจะถูกยอมรับ (positive label) และคำแนะนำที่ไม่ดีจะถูกอัปเดต (negative ตามด้วย positive label)
• รูปแบบของการแนะนำ การตรวจสอบโดยผู้ใช้ และการเก็บข้อมูลนี้พบได้ทั่วไปในหลายแอปพลิเคชัน
  • coding assistant: ผู้ใช้สามารถยอมรับคำแนะนำ (positive แบบเข้มข้น), ยอมรับแล้วปรับแก้ (positive) หรือเพิกเฉย (negative) ได้
  • Midjourney: ผู้ใช้สามารถอัปสเกลและดาวน์โหลดภาพ (positive แบบเข้มข้น), ปรับเปลี่ยนภาพ (positive) หรือสร้างชุดภาพใหม่ (negative) ได้
  • แชตบอต: ผู้ใช้สามารถกดถูกใจคำตอบ (positive) หรือไม่ถูกใจ (negative) หรือหากคำตอบแย่มากก็เลือกให้สร้างคำตอบใหม่ (negative แบบเข้มข้น) ได้
• feedback อาจเป็นแบบชัดแจ้งหรือแบบโดยนัย
  • feedback แบบชัดแจ้งคือข้อมูลที่ผู้ใช้ให้เพื่อตอบสนองต่อคำขอจากผลิตภัณฑ์
  • feedback แบบโดยนัยคือข้อมูลที่เรียนรู้จากปฏิสัมพันธ์ของผู้ใช้โดยที่ผู้ใช้ไม่จำเป็นต้องตั้งใจให้ feedback
• coding assistant และ Midjourney เป็นตัวอย่างของ feedback แบบโดยนัย ส่วนการกดถูกใจและไม่ถูกใจเป็น feedback แบบชัดแจ้ง
  • หากออกแบบ UX ได้ดีแบบ coding assistant และ Midjourney ก็จะสามารถเก็บ feedback แบบโดยนัยจำนวนมากเพื่อนำไปปรับปรุงทั้งผลิตภัณฑ์และโมเดลได้

จัดลำดับความสำคัญของชั้นข้อกำหนด (Hierarchy) อย่างไร้ความปรานี

• เมื่อต้องคิดเรื่องนำเดโมขึ้นสู่ production จำเป็นต้องพิจารณาข้อกำหนดต่อไปนี้
  • ความน่าเชื่อถือ: uptime 99.9%, การปฏิบัติตาม structured output
  • ความไม่เป็นอันตราย: ไม่สร้างเนื้อหาก้าวร้าว NSFW หรือเนื้อหาอันตรายอื่น ๆ
  • ความสอดคล้องกับข้อเท็จจริง: ยึดตามบริบทที่ให้มาและไม่บิดเบือนข้อเท็จจริง
  • ความมีประโยชน์: เกี่ยวข้องกับความต้องการและคำขอของผู้ใช้
  • ความสามารถในการขยาย: latency SLA, throughput ที่รองรับ
  • ต้นทุน: เพราะงบประมาณไม่ได้มีไม่จำกัด
  • อื่น ๆ: ความปลอดภัย, ความเป็นส่วนตัว, ความเป็นธรรม, GDPR, DMA เป็นต้น
• หากพยายามแก้ทุกข้อกำหนดเหล่านี้พร้อมกัน ก็จะปล่อยอะไรออกมาไม่ได้เลย
  • ดังนั้นต้องจัดลำดับความสำคัญ อย่างไร้ความปรานี
• นั่นหมายถึงต้องทำให้ชัดว่าอะไรคือสิ่งที่ประนีประนอมไม่ได้ ซึ่งหากขาดไปผลิตภัณฑ์อาจใช้งานไม่ได้หรือไม่สามารถเดินหน้าต่อได้ (เช่น ความน่าเชื่อถือ, ความไม่เป็นอันตราย)
  • การระบุ MVP (Minimum Lovable Product) จึงสำคัญมาก
• ต้องยอมรับว่าเวอร์ชันแรกจะไม่สมบูรณ์แบบ แล้วปล่อยออกไปและทำซ้ำต่อ

ปรับระดับการยอมรับความเสี่ยงตาม use case

• เมื่อต้องกำหนดระดับการตรวจทานของโมเดลภาษาและแอปพลิเคชัน ควรพิจารณา use case และกลุ่มเป้าหมาย
  • สำหรับแชตบอตที่ติดต่อกับลูกค้าและให้คำแนะนำด้านการแพทย์หรือการเงิน จำเป็นต้องมีมาตรฐานด้านความปลอดภัยและความแม่นยำที่สูงมาก
    • ความผิดพลาดหรือผลลัพธ์ที่ไม่ถูกต้องอาจก่อให้เกิดอันตรายในโลกจริงและทำให้สูญเสียความเชื่อมั่น
  • แต่สำหรับแอปพลิเคชันที่สำคัญน้อยกว่า เช่น ระบบแนะนำ หรือแอปภายในองค์กรอย่างการจัดหมวดหมู่เนื้อหาหรือการสรุป การตั้งข้อกำหนดที่เข้มงวดเกินไปมักไม่เพิ่มคุณค่ามากนักและมีแต่ทำให้ความคืบหน้าช้าลง
• เรื่องนี้สอดคล้องกับรายงานล่าสุดของ a16z ที่ระบุว่าหลายบริษัทกำลังขยับตัวกับแอป LLM ภายในองค์กรมากกว่าแอปภายนอก
  • ด้วยการทดลองใช้ AI เพื่อเพิ่มผลิตภาพภายในองค์กร องค์กรสามารถเริ่มเก็บเกี่ยวคุณค่าได้ พร้อมเรียนรู้วิธีจัดการความเสี่ยงในสภาพแวดล้อมที่ควบคุมได้มากกว่า
  • จากนั้นเมื่อมีความมั่นใจแล้วก็สามารถขยายไปสู่ use case ที่ติดต่อกับลูกค้าได้

การดำเนินงาน 4. ทีมและบทบาท (Roles)

• ไม่มีตำแหน่งงานไหนนิยามได้ง่ายนัก แต่การเขียนคำบรรยายลักษณะงานสำหรับงานในพื้นที่ใหม่นี้ยิ่งยากกว่านั้น
  • ผมจะขอข้ามทั้งแผนภาพเวนน์ของตำแหน่งที่ทับซ้อนกันและข้อเสนอแนะเรื่องคำบรรยายลักษณะงาน
  • แต่จะยอมรับการมีอยู่ของบทบาทใหม่อย่าง AI engineer และพูดถึงบทบาทนี้
• สิ่งสำคัญคือจะพูดถึงว่าควรจัดสรรหน้าที่และความรับผิดชอบให้กับทีมที่เหลืออย่างไร

โฟกัสที่กระบวนการ ไม่ใช่เครื่องมือ

• เมื่อเผชิญกับพาราไดม์ใหม่อย่าง LLM วิศวกรซอฟต์แวร์มักมีแนวโน้มจะให้ความสำคัญกับเครื่องมือ
  • ผลคือมักมองข้ามปัญหาและกระบวนการที่เครื่องมือพยายามจะแก้
  • เมื่อทำเช่นนี้ วิศวกรจำนวนมากกลับรับเอาความซับซ้อนที่เกิดขึ้นโดยบังเอิญเข้ามา ซึ่งส่งผลเสียต่อผลิตภาพระยะยาวของทีม
• ตัวอย่างเช่น บทความนี้ อธิบายถึงวิธีที่เครื่องมือบางอย่างสามารถสร้าง prompt สำหรับโมเดลภาษาขนาดใหญ่โดยอัตโนมัติ
  • ผู้เขียนโต้แย้งว่า (และ IMO ก็อย่างมีเหตุผล) วิศวกรที่ใช้เครื่องมือเหล่านี้โดยยังไม่เข้าใจวิธีคิดหรือกระบวนการแก้ปัญหาก่อน สุดท้ายจะต้องแบกรับ technical debt ที่ไม่จำเป็น
• นอกเหนือจากความซับซ้อนที่เกิดขึ้นโดยบังเอิญแล้ว เครื่องมือก็มักถูกระบุสเปกไว้ไม่เพียงพอ
  • ตัวอย่างเช่น ตอนนี้อุตสาหกรรมเครื่องมือประเมิน LLM กำลังเติบโต โดยนำเสนอ “กล่องเครื่องมือประเมิน LLM” พร้อม evaluator ทั่วไปสำหรับความเป็นอันตราย ความกระชับ โทนเสียง และอื่น ๆ
  • เราเห็นหลายทีมรับเครื่องมือเหล่านี้ไปใช้โดยไม่ได้คิดอย่างวิพากษ์ถึง failure mode เฉพาะของโดเมนตนเอง
• ตรงกันข้าม EvalGen มุ่งเน้นการสอนผู้ใช้ให้สร้างการประเมินแบบเฉพาะโดเมน โดยให้ผู้ใช้มีส่วนร่วมอย่างลึกซึ้งในแต่ละขั้นตอน เช่น การระบุเกณฑ์ การติดป้ายกำกับข้อมูล และการยืนยันผลประเมิน
  • ซอฟต์แวร์จะพาผู้ใช้ผ่าน workflow ดังนี้
• แนวปฏิบัติที่ดีที่สุดของการสร้างการประเมิน LLM ที่ EvalGen แนะนำ
  1. นิยามการทดสอบเฉพาะโดเมน (bootstrap อัตโนมัติจาก prompt)
     • นิยามเป็น assertion ด้วยโค้ดหรือ LLM-as-a-Judge
  2. ความสำคัญของการปรับการทดสอบให้สอดคล้องกับการตัดสินของมนุษย์ เพื่อให้ผู้ใช้ตรวจสอบได้ว่าการทดสอบจับเกณฑ์ที่ระบุไว้จริง
  3. ทำซ้ำการทดสอบเมื่อระบบ (เช่น prompt) เปลี่ยนแปลง
• EvalGen มอบ mental model เกี่ยวกับกระบวนการสร้าง evaluation ให้กับนักพัฒนา แต่ไม่ได้ผูกติดกับเครื่องมือเฉพาะตัวใดตัวหนึ่ง
  • เราพบว่าหลังจากให้บริบทนี้กับ AI engineer แล้ว พวกเขามักตัดสินใจเลือกเครื่องมือที่เรียบง่ายกว่า หรือสร้างเครื่องมือของตนเองขึ้นมา
• นอกเหนือจากการเขียน prompt และการประเมินแล้ว ยังมีองค์ประกอบของ LLM อีกมากเกินกว่าจะไล่รายการทั้งหมดที่นี่ได้
  • แต่สิ่งสำคัญคือ AI engineer ควรพยายามทำความเข้าใจกระบวนการก่อนนำเครื่องมือมาใช้

ทดลองอยู่เสมอ

• ผลิตภัณฑ์ ML เชื่อมโยงกับการทดลองอย่างลึกซึ้ง
  • ไม่ได้หมายถึงแค่ A/B test หรือ randomized controlled trial เท่านั้น แต่ยังรวมถึงการปรับแก้องค์ประกอบที่เล็กที่สุดเท่าที่เป็นไปได้ของระบบและลองประเมินแบบออฟไลน์บ่อย ๆ
  • เหตุผลที่ทุกคนตื่นเต้นกับ evaluation ก็เพราะมันไม่ใช่เรื่องความน่าเชื่อถือและความมั่นใจเพียงอย่างเดียว แต่เป็นสิ่งที่ทำให้การทดลองเกิดขึ้นได้จริง!
    • ยิ่ง evaluation ดีมากเท่าไร ก็ยิ่งวนรอบการทดลองได้เร็วขึ้น และทำให้ไปถึงระบบเวอร์ชันที่ดีที่สุดได้ไวขึ้นเท่านั้น
• เพราะการทดลองมีต้นทุนถูกลงมาก จึงเป็นเรื่องปกติที่จะลองหลายแนวทางเพื่อแก้ปัญหาเดียวกัน
  • ต้นทุนสูงของการเก็บข้อมูลและการฝึกโมเดลลดลงอย่างมาก
    • ต้นทุนของ prompt engineering แทบมีแค่เวลาของคนเพิ่มขึ้นมาเล็กน้อย
  • ควรจัดทีมให้ทุกคนได้เรียนรู้พื้นฐานของ prompt engineering
    • สิ่งนี้ช่วยกระตุ้นให้ทุกคนทดลอง และนำไปสู่ไอเดียที่หลากหลายทั่วทั้งองค์กร
• อย่าทดลองเพื่อการสำรวจอย่างเดียว แต่ควรใช้การทดลองเพื่อการนำไปใช้จริงด้วย!
  • มีเวอร์ชันที่ใช้งานได้ของงานใหม่แล้วหรือยัง?
    • ลองให้คนอื่นในทีมพิจารณาเข้าหามันด้วยวิธีที่ต่างออกไป
  • ลองทำด้วยวิธีอื่นที่อาจเร็วกว่า
  • ศึกษาเทคนิคพรอมป์ต์อย่าง Chain-of-Thought หรือ Few-Shot เพื่อยกระดับคุณภาพ
  • อย่าให้เครื่องมือมาขัดขวางการทดลอง
    • ถ้าเป็นแบบนั้น ก็ควรซื้อสิ่งที่นำมาปรับปรุงหรือสร้างใหม่ได้
• ระหว่างวางแผนผลิตภัณฑ์/โปรเจ็กต์ ควรเผื่อเวลาสำหรับการสร้าง evaluation และการทดลองหลายรูปแบบโดยเฉพาะ
  • ลองคิดสเปกผลิตภัณฑ์สำหรับผลิตภัณฑ์เชิงวิศวกรรม แล้วเพิ่มเกณฑ์ที่ชัดเจนสำหรับ evaluation เข้าไปด้วย
• เวลาจัดทำ roadmap อย่าประเมินเวลาที่ต้องใช้สำหรับการทดลองต่ำเกินไป
  • ควรคาดว่าจะมีหลายรอบของการพัฒนาและ evaluation ก่อนจะได้รับการอนุมัติให้นำขึ้น production

มอบอำนาจให้ทุกคนใช้เทคโนโลยี AI ใหม่ได้

• เมื่อการใช้งาน generative AI เพิ่มขึ้น คุณย่อมอยากให้ไม่ใช่แค่ผู้เชี่ยวชาญ แต่ทั้งทีมรู้สึกว่าสามารถเข้าใจและใช้เทคโนโลยีใหม่นี้ได้
  • ไม่มีวิธีใดดีกว่าการพัฒนาสัญชาตญาณเกี่ยวกับวิธีที่ LLM ทำงานจริง ๆ (เช่น latency, failure mode, UX)
  • LLM เข้าถึงได้ค่อนข้างง่าย
    • ไม่จำเป็นต้องรู้วิธีเขียนโค้ดเพื่อปรับปรุงประสิทธิภาพของ pipeline และทุกคนสามารถมีส่วนร่วมผ่าน prompt engineering และ evaluation ได้
• ส่วนสำคัญของเรื่องนี้คือการศึกษา
  • สามารถเริ่มจากพื้นฐานของ prompt engineering เช่นเทคนิคอย่าง n-shot prompting และ CoT ที่ช่วยปรับเงื่อนไขให้โมเดลสร้างผลลัพธ์ไปในทิศทางที่ต้องการ
• ผู้ที่มีความรู้สามารถสอนด้านที่เทคนิคมากขึ้นได้เช่นกัน เช่นข้อเท็จจริงที่ว่า LLM มีลักษณะเป็น autoregressive โดยเนื้อแท้
  • กล่าวคือ input token ถูกประมวลผลแบบขนาน แต่ output token ถูกสร้างขึ้นตามลำดับ
  • ดังนั้น latency จึงเป็นฟังก์ชันของความยาวเอาต์พุตมากกว่าความยาวอินพุต
    • นี่เป็นปัจจัยสำคัญในการออกแบบ UX และกำหนดความคาดหวังด้านประสิทธิภาพ
• อาจเปิดโอกาสให้มีการลงมือทดลองและสำรวจจริงด้วย
  • แล้ว hackathon ล่ะ?
    • แม้การให้ทั้งทีมใช้เวลาหลายวันไปกับการแฮ็กโปรเจ็กต์เชิงคาดการณ์จะดูมีค่าใช้จ่ายสูง แต่ผลลัพธ์อาจทำให้คุณประหลาดใจได้
  • มีทีมที่เกือบทำ roadmap 3 ปีเสร็จได้ภายใน 1 ปีผ่าน hackathon
    • อีกทีมหนึ่งได้ UX ที่พลิกกระบวนทัศน์ผ่าน hackathon ซึ่งตอนนี้เป็นไปได้แล้วเพราะ LLM และกลายเป็นลำดับความสำคัญของปีนี้และปีต่อ ๆ ไป

อย่าตกหลุมพรางว่า "AI engineering คือทุกสิ่งทุกอย่าง"

• เมื่อมีตำแหน่งงานใหม่เกิดขึ้น ในช่วงแรกมักมีแนวโน้มจะประเมินความสามารถที่เกี่ยวข้องกับบทบาทนั้นสูงเกินจริง
  • สิ่งนี้มักนำไปสู่การปรับความเข้าใจอย่างเจ็บปวด เมื่อขอบเขตงานที่แท้จริงของอาชีพเหล่านี้เริ่มชัดเจนขึ้น
  • ผู้มาใหม่ในสายงานนี้และผู้จัดการที่กำลังจ้างงานอาจอ้างเกินจริงหรือตั้งความคาดหวังไว้สูงเกินไป
• ตัวอย่างที่เห็นได้ชัดในช่วง 10 ปีที่ผ่านมา ได้แก่
  • data scientist: "คนที่เก่งสถิติมากกว่าวิศวกรซอฟต์แวร์ทุกคน และเก่งวิศวกรรมซอฟต์แวร์มากกว่านักสถิติทุกคน"
  • machine learning engineer (MLE): มุมมองด้านวิศวกรรมซอฟต์แวร์ที่เน้น machine learning
• ในช่วงแรก หลายคนสมมติว่าโปรเจ็กต์ที่ขับเคลื่อนด้วยข้อมูลนั้นมีแค่ data scientist ก็พอ
  • แต่ต่อมาก็ชัดเจนว่า data scientist ต้องทำงานร่วมกับวิศวกรซอฟต์แวร์และวิศวกรข้อมูล เพื่อพัฒนาและนำผลิตภัณฑ์ข้อมูลไปใช้งานได้อย่างมีประสิทธิภาพ
• ความเข้าใจผิดนี้กลับมาเกิดซ้ำอีกในบทบาทใหม่อย่าง AI engineer โดยบางทีมเชื่อว่า AI engineer คือทั้งหมดที่ต้องมี
  • แต่ในความเป็นจริง การสร้างผลิตภัณฑ์ machine learning หรือ AI ต้องอาศัยบทบาทเฉพาะทางที่หลากหลาย
• เราได้ให้คำปรึกษาแก่บริษัทมากกว่า 12 แห่งเกี่ยวกับผลิตภัณฑ์ AI และพบอย่างสม่ำเสมอว่าพวกเขาตกหลุมความเชื่อว่า "AI engineering คือทั้งหมดที่ต้องมี"
  • ผลลัพธ์คือผลิตภัณฑ์มักขยายไปได้ไม่ไกลเกินเดโม ขณะที่มองข้ามองค์ประกอบสำคัญที่จำเป็นต่อการสร้างผลิตภัณฑ์จริง
• ตัวอย่างเช่น evaluation และการวัดผลมีความสำคัญต่อการขยายผลิตภัณฑ์ให้เลยไปจากแค่ Vibe check
  • ทักษะที่จำเป็นต่อ evaluation ที่มีประสิทธิภาพนั้นสอดคล้องกับจุดแข็งบางอย่างที่มักพบใน machine learning engineer
    • ทีมที่มีแต่ AI engineer อย่างเดียวมีแนวโน้มจะขาดทักษะเหล่านี้
• Hamel Husain ผู้ร่วมเขียน ได้อธิบายความสำคัญของทักษะเหล่านี้จากงานล่าสุดที่เกี่ยวข้องกับการตรวจจับ data bias และการออกแบบ evaluation เฉพาะโดเมน
• ประเภทของบทบาทที่ต้องมีและช่วงเวลาที่ต้องใช้ในเส้นทางการสร้างผลิตภัณฑ์ AI
  1. อันดับแรก ให้โฟกัสที่การสร้างผลิตภัณฑ์ก่อน
  • อาจมี AI engineer ก็ได้ แต่ไม่จำเป็นเสมอไป
  • AI engineer มีประโยชน์ในการทำต้นแบบผลิตภัณฑ์ (UX, plumbing ฯลฯ) และทำซ้ำอย่างรวดเร็ว
  2. ถัดมา ให้ instrument ระบบและเก็บข้อมูลเพื่อสร้างรากฐานที่ถูกต้อง
  • ขึ้นอยู่กับประเภทและขนาดของข้อมูล อาจต้องมี platform engineer และ/หรือ data engineer
  • นอกจากนี้ยังควรมีระบบสำหรับ query และวิเคราะห์ข้อมูลเหล่านี้เพื่อดีบักปัญหา
  3. จากนั้นจึงค่อยปรับ AI system ให้เหมาะสมที่สุด
  • สิ่งนี้ไม่จำเป็นต้องรวมถึงการฝึกโมเดลเสมอไป
  • พื้นฐานประกอบด้วยขั้นตอนอย่างการออกแบบ metric, การสร้างระบบ evaluation, การรันการทดลอง, การปรับแต่ง RAG retrieval, การดีบักระบบเชิงความน่าจะเป็น เป็นต้น
  • MLE มีความเชี่ยวชาญด้านนี้มากเป็นพิเศษ (แน่นอนว่า AI engineer ก็เรียนรู้ได้)
  • หากยังไม่ทำขั้นตอนก่อนหน้าให้เสร็จ การจ้าง MLE มักยังไม่สมเหตุสมผล
• นอกเหนือจากนี้ ยังต้องมีผู้เชี่ยวชาญโดเมนเสมอ
  • ในบริษัทขนาดเล็ก ตามอุดมคติแล้วทีมผู้ก่อตั้งควรทำหน้าที่นี้ ส่วนในบริษัทใหญ่ product manager อาจทำหน้าที่นี้ได้
• การตระหนักถึงลำดับและจังหวะเวลาของบทบาทต่าง ๆ เป็นเรื่องสำคัญ
  • การจ้างคนผิดเวลา (เช่น จ้าง MLE เร็วเกินไป) หรือสร้างสิ่งต่าง ๆ ผิดลำดับ เป็นการเสียทั้งเวลาและเงิน และยังนำไปสู่การลาออกอีกด้วย
• นอกจากนี้ การเช็กอินกับ MLE เป็นประจำในช่วงขั้นตอนที่ 1-2 (แต่ยังไม่ต้องจ้างประจำ) ก็ช่วยให้บริษัทวางรากฐานได้ถูกต้อง

[กลยุทธ์: ทำอย่างไรไม่ให้ตามหลังในการสร้างด้วย LLM]

• การพัฒนาผลิตภัณฑ์ให้ประสบความสำเร็จต้องอาศัยการวางแผนและการจัดลำดับความสำคัญอย่างรอบคอบ มากกว่าการทำต้นแบบแบบสะเปะสะปะหรือไล่ตามโมเดลและเทรนด์ล่าสุด
• เมื่อต้องพัฒนาผลิตภัณฑ์ AI ควรพิจารณา trade-off สำคัญ เช่น จะสร้างเองหรือซื้อ
• นำเสนอ "playbook" สำหรับการพัฒนาแอปพลิเคชัน LLM ระยะเริ่มต้น

กลยุทธ์ 1: ก่อน PMF ไม่ต้องใช้ GPU

• การจะเป็นผลิตภัณฑ์ที่ยอดเยี่ยมได้ ต้องเป็นมากกว่าแค่การเอา API ของคนอื่นมาห่อบาง ๆ
• แต่การพลาดไปอีกด้านหนึ่งอาจมีต้นทุนสูงกว่า
  • ในปีที่ผ่านมา มีการใช้เงินทุนร่วมลงทุนจำนวนมหาศาลไปกับการฝึกและคัสตอมโมเดล ทั้งที่ยังไม่มีวิสัยทัศน์ผลิตภัณฑ์หรือเป้าหมายตลาดที่ชัดเจน
  • บริษัทหนึ่งถึงขั้นระดมทุน Series A ได้มากถึง 6 พันล้านดอลลาร์
• ส่วนนี้จะอธิบายว่าทำไมการเริ่มฝึกโมเดลของตัวเองทันทีจึงเป็นความผิดพลาด และจะพิจารณาบทบาทของการโฮสต์เองด้วย

การฝึกใหม่ (เกือบทั้งหมด) ตั้งแต่ต้นนั้นไม่มีความหมาย

• สำหรับองค์กรส่วนใหญ่ การพรีเทรน LLM ตั้งแต่ต้นเป็นเรื่องที่ไม่สมจริงและหลุดจากการพัฒนาผลิตภัณฑ์
  • การพัฒนาและดูแลรักษาโครงสร้างพื้นฐานแมชชีนเลิร์นนิงต้องใช้ทรัพยากรจำนวนมาก
    • รวมถึงการเก็บข้อมูล การฝึกและประเมินโมเดล ตลอดจนการดีพลอย
  • หากยังอยู่ในขั้นตรวจสอบ product-market fit ความพยายามลักษณะนี้จะดึงทรัพยากรออกจากการพัฒนาผลิตภัณฑ์หลัก
  • แม้จะมีทรัพยากรคอมพิวต์ ข้อมูล และความสามารถทางเทคนิค แต่ LLM ที่พรีเทรนไว้ก็อาจล้าสมัยได้ภายในไม่กี่เดือน
• กรณีของ BloombergGPT
  • BloombergGPT ซึ่งเป็น LLM ที่เฉพาะทางสำหรับงานการเงิน ได้รับการพรีเทรนด้วยโทเคน 363B
  • ใช้ความพยายามอย่างมหาศาลจากพนักงานประจำ 9 คน รวมถึงวิศวกร AI 4 คน และทีมผลิตภัณฑ์/วิจัย ML 5 คน
  • ถึงกระนั้น ภายใน 1 ปี ก็ยังตามหลัง gpt-3.5-turbo และ gpt-4 ในงานประเภทนั้น
• กรณีเหล่านี้ชี้ให้เห็นว่า ในแอปพลิเคชันจริงส่วนใหญ่ การพรีเทรน LLM ตั้งแต่ต้นไม่ใช่วิธีใช้ทรัพยากรที่ดีที่สุด
  • ทางเลือกที่ดีกว่าคือทีมควร fine-tune โมเดลโอเพนซอร์สที่ทรงพลังที่สุดเท่าที่ใช้งานได้ให้เหมาะกับความต้องการเฉพาะ
• แน่นอนว่ามีข้อยกเว้น
  • โมเดลโค้ดของ Replit เป็นตัวอย่างที่ยอดเยี่ยมของการพรีเทรนที่เฉพาะทางด้านการสร้างและทำความเข้าใจโค้ด
  • จากการพรีเทรน ทำให้มีประสิทธิภาพเหนือกว่าโมเดลขนาดใหญ่กว่าอย่าง CodeLlama7b
  • อย่างไรก็ตาม เมื่อมีโมเดลที่ทรงพลังยิ่งกว่าถูกปล่อยออกมา ก็จำเป็นต้องลงทุนต่อเนื่องเพื่อรักษาประโยชน์ใช้งานไว้

อย่า fine-tune จนกว่าจะยืนยันแล้วว่าจำเป็น

• สำหรับองค์กรส่วนใหญ่ การ fine-tune มักถูกขับเคลื่อนด้วย FOMO (Fear Of Missing Out หรือความกลัวว่าจะพลาด) มากกว่าการคิดเชิงกลยุทธ์
  • องค์กรมักรีบลงทุนกับการ fine-tune เร็วเกินไปเพื่อหลีกเลี่ยงคำครหาว่าเป็นแค่ "wrapper ธรรมดา"
  • ในความเป็นจริง การ fine-tune เปรียบเหมือนอุปกรณ์หนักที่ควรนำมาใช้ก็ต่อเมื่อรวบรวมกรณีตัวอย่างได้มากพอแล้วว่าทางเลือกอื่นไม่เพียงพอ
• เมื่อ 1 ปีก่อน หลายทีมแสดงความคาดหวังต่อการ fine-tune แต่มีเพียงไม่กี่ทีมที่พบ product-market fit และส่วนใหญ่กลับเสียใจกับการตัดสินใจนั้น
  • หากจะทำ fine-tune ก็ควรเตรียมพร้อมที่จะทำซ้ำเรื่อย ๆ เมื่อโมเดลฐานได้รับการปรับปรุง
    • ดูหัวข้อ "โมเดลไม่ใช่ผลิตภัณฑ์" และ "สร้าง LLMOps" ด้านล่าง
• กรณีที่การ fine-tune อาจเป็นทางเลือกที่ถูกต้องจริง ๆ
  • เมื่อจำเป็นต้องใช้ข้อมูลที่ไม่มีอยู่ในชุดข้อมูลขนาดเว็บแบบเปิดซึ่งใช้ฝึกโมเดลเดิมส่วนใหญ่
  • เมื่อได้สร้าง MVP ที่แสดงให้เห็นแล้วว่าโมเดลเดิมยังไม่เพียงพอ
  • แต่ต้องระวัง: หากแม้แต่ผู้สร้างโมเดลยังหา training data คุณภาพสูงได้ไม่ง่าย แล้วคุณจะหาได้จากที่ไหน?
• แอปพลิเคชันที่อิง LLM ไม่ใช่โปรเจกต์งานวิทยาศาสตร์
  • การลงทุนควรสอดคล้องกับเป้าหมายเชิงกลยุทธ์และระดับการสร้างความแตกต่างในการแข่งขัน

เริ่มจาก inference API แต่อย่ากลัวการ self-host

• การใช้ LLM API ช่วยให้สตาร์ตอัปนำความสามารถด้าน language modeling มาใช้และผสานเข้ากับระบบได้ง่าย โดยไม่ต้องฝึกโมเดลของตัวเองตั้งแต่แรก
  • ผู้ให้บริการอย่าง Anthropic และ OpenAI มี API ทั่วไปที่เพิ่มความฉลาดให้ผลิตภัณฑ์ได้ด้วยโค้ดเพียงไม่กี่บรรทัด
  • การใช้บริการเหล่านี้ช่วยลดภาระงานและทำให้โฟกัสกับการสร้างคุณค่าให้ลูกค้าได้มากขึ้น จึงตรวจสอบไอเดียและวนซ้ำหา product-market fit ได้เร็วขึ้น
• อย่างไรก็ตาม เช่นเดียวกับฐานข้อมูล บริการแบบ managed service ไม่ได้เหมาะกับทุก use case เมื่อขนาดและความต้องการเพิ่มขึ้น
  • ในความเป็นจริง การโฮสต์เองอาจเป็นวิธีเดียวที่จะใช้โมเดลได้โดยไม่ต้องส่งข้อมูลลับ/ข้อมูลส่วนบุคคลออกนอกเครือข่าย ตามข้อกำหนดของอุตสาหกรรมที่มีการกำกับดูแลอย่างการแพทย์และการเงิน หรือข้อผูกพันตามสัญญาและข้อกำหนดด้านการรักษาความลับ
• นอกจากนี้ การโฮสต์เองยังช่วยหลีกเลี่ยงข้อจำกัด เช่น rate limit การยุติการให้บริการโมเดล หรือข้อจำกัดการใช้งานที่ผู้ให้บริการ inference กำหนด
  • การโฮสต์เองให้สิทธิ์ควบคุมโมเดลอย่างเต็มรูปแบบ ทำให้สร้างระบบที่แตกต่างและมีคุณภาพสูงได้ง่ายขึ้น
• สุดท้าย การโฮสต์เอง โดยเฉพาะการ fine-tune สามารถลดต้นทุนได้เมื่อใช้งานในสเกลใหญ่
  • ตัวอย่างเช่น Buzzfeed เคยแชร์กรณีที่ลดต้นทุนได้ 80% ด้วยการ fine-tune LLM โอเพนซอร์ส

กลยุทธ์ 2: วนซ้ำไปสู่สิ่งที่ดีกว่า

• หากต้องการรักษาความได้เปรียบในการแข่งขันระยะยาว ต้องคิดให้เกินกว่าแค่ตัวโมเดล และมองหาสิ่งที่ทำให้ผลิตภัณฑ์แตกต่างได้
• ความเร็วในการลงมือทำสำคัญ แต่ไม่ควรเป็นข้อได้เปรียบเพียงอย่างเดียว

โมเดลไม่ใช่ผลิตภัณฑ์ แต่ระบบรอบโมเดลต่างหากที่เป็นผลิตภัณฑ์

• สำหรับทีมที่ไม่ได้สร้างโมเดลเอง ความเร็วของนวัตกรรมถือเป็นพร
  • เพราะสามารถย้ายไปใช้โมเดลใหม่ล่าสุดเพื่อสร้างผลิตภัณฑ์ที่ดีกว่า โดยอาศัยการพัฒนาเรื่องขนาด context ความสามารถในการให้เหตุผล และความคุ้มค่าต่อราคา
  • ความก้าวหน้าเหล่านี้น่าตื่นเต้นเสียจนแทบคาดเดาได้
  • เมื่อรวมกันแล้ว มีความเป็นไปได้สูงว่าโมเดลจะเป็นองค์ประกอบที่คงทนน้อยที่สุดในระบบ
• ดังนั้นควรทุ่มความพยายามไปที่ส่วนที่สร้างคุณค่าอย่างต่อเนื่องได้
  • Evals: เพื่อวัดประสิทธิภาพของงานในแต่ละโมเดลได้อย่างสม่ำเสมอ
  • Guardrails: เพื่อป้องกันเอาต์พุตที่ไม่พึงประสงค์โดยไม่ขึ้นกับโมเดล
  • Caching: เพื่อลด latency และต้นทุนด้วยการหลีกเลี่ยงการเรียกใช้โมเดลโดยตรง
  • Data flywheel: เพื่อผลักดันการปรับปรุงแบบวนซ้ำของทุกอย่างข้างต้น
  • องค์ประกอบเหล่านี้สร้างคูเมืองด้านคุณภาพผลิตภัณฑ์ที่หนากว่าความสามารถดิบของโมเดล
• อย่างไรก็ตาม นั่นไม่ได้หมายความว่าการสร้างในชั้นแอปพลิเคชันจะไร้ความเสี่ยง
  • หาก OpenAI หรือผู้ให้บริการโมเดลรายอื่นจะออกซอฟต์แวร์องค์กรที่ใช้งานได้จริง ก็อย่าไปตัดต่อในส่วนที่ควรถูกแทนที่ได้ง่าย
• ตัวอย่างเช่น บางทีมลงทุนสร้างเครื่องมือเฉพาะทางเพื่อทำ validation ของ structured output จากโมเดล proprietary
  • การลงทุนน้อยที่สุดในส่วนนี้เป็นเรื่องสำคัญ แต่การลงลึกมากเกินไปไม่ใช่การใช้เวลาที่คุ้มค่า
  • OpenAI ควรทำให้แน่ใจว่าเมื่อร้องขอ function calling ก็จะได้รับ function call ที่ถูกต้อง เพราะเป็นสิ่งที่ลูกค้าทุกรายต้องการ
  • ใช้แนวคิด "การผัดวันประกันพรุ่งเชิงกลยุทธ์" กับเรื่องนี้: สร้างเฉพาะสิ่งที่จำเป็นจริง ๆ และรอให้ผู้ให้บริการขยายความสามารถ

เริ่มจากเล็ก ๆ แล้วค่อยสร้างความเชื่อมั่น

• การพยายามสร้างผลิตภัณฑ์ที่เป็นทุกอย่างสำหรับทุกคนคือสูตรสำเร็จของความธรรมดา
• เพื่อสร้างผลิตภัณฑ์ที่น่าเชื่อถือ บริษัทต้องเชี่ยวชาญในการสร้างประสบการณ์ที่เหนียวแน่นจนผู้ใช้กลับมาใช้อีก
• ลองพิจารณาระบบ RAG ทั่วไปที่ตั้งเป้าจะตอบทุกคำถามของผู้ใช้
  • การขาดความเฉพาะทางหมายความว่าระบบไม่สามารถจัดลำดับความสำคัญของข้อมูลล่าสุด แยกวิเคราะห์รูปแบบเฉพาะของโดเมน หรือเข้าใจความละเอียดอ่อนของงานบางประเภทได้
  • ผลลัพธ์คือผู้ใช้จะได้รับประสบการณ์ที่ตื้นและไม่น่าเชื่อถือ ไม่ตอบโจทย์ความต้องการ และสุดท้ายก็เลิกใช้
• ทางแก้คือโฟกัสไปที่โดเมนและ use case ที่เฉพาะเจาะจง
  • ต้องลดขอบเขตเพื่อเพิ่มความลึก แทนที่จะไล่ตามความกว้าง
  • วิธีนี้ทำให้สร้างเครื่องมือเฉพาะโดเมนที่ตรงใจผู้ใช้ได้
• ความเชี่ยวชาญเฉพาะทางยังช่วยให้สื่อสารความสามารถและข้อจำกัดของระบบได้อย่างตรงไปตรงมา
  • การเปิดเผยอย่างโปร่งใสว่าระบบทำอะไรได้และทำอะไรไม่ได้ แสดงถึงการตระหนักรู้ในตัวเอง ช่วยให้ผู้ใช้เข้าใจว่าตรงไหนที่ระบบเพิ่มคุณค่าได้มากที่สุด และท้ายที่สุดก็สร้างความไว้วางใจและความมั่นใจในเอาต์พุต

สร้าง LLMOps แต่ต้องมีเหตุผลที่เหมาะสม: การวนซ้ำอย่างรวดเร็ว

• DevOps โดยพื้นฐานแล้วไม่ใช่เรื่องของเวิร์กโฟลว์ที่ทำซ้ำได้, การ shift-left หรือการมอบอำนาจให้ทีม two-pizza และยิ่งไม่ใช่การเขียนไฟล์ YAML
• DevOps คือการย่นวงจรป้อนกลับระหว่างงานกับผลลัพธ์ของงาน เพื่อให้สิ่งที่สะสมคือการปรับปรุง ไม่ใช่ข้อผิดพลาด
  • รากของแนวคิดนี้ย้อนกลับไปได้ถึง lean startup movement, lean manufacturing และ Toyota Production System โดยเน้น Single-Minute Exchange of Die และ kaizen
• MLOps คือการนำรูปแบบของ DevOps มาประยุกต์ใช้กับ ML
  • มีชุดเครื่องมือแบบ all-in-one สำหรับการทดลองที่ทำซ้ำได้และช่วยให้ผู้สร้างโมเดลสามารถ deploy ได้เอง และแน่นอนว่ามีไฟล์ YAML จำนวนมาก
• อย่างไรก็ตาม ในฐานะอุตสาหกรรม MLOps ยังไม่ได้รับเอาหน้าที่ของ DevOps มาใช้อย่างแท้จริง ยังไม่ได้ลดช่องว่างของ feedback ระหว่างตัวโมเดลกับการอนุมานและการโต้ตอบในโปรดักชัน
• โชคดีที่วงการ LLMOps กำลังเปลี่ยนทิศจากปัญหาเล็กน้อยอย่างการจัดการพรอมป์ต์ ไปสู่การปรับปรุงอย่างต่อเนื่องที่เชื่อมกับปัญหายากซึ่งขัดขวางการทำซ้ำ นั่นคือการมอนิเตอร์โปรดักชันและการประเมินผล
• ตอนนี้มี conversational arena สำหรับการประเมินโมเดลแชตและโมเดลโค้ดดิ้งแบบเป็นกลางและอาศัย crowdsourcing แล้ว นี่คือ external loop ของการปรับปรุงแบบส่วนรวมและทำซ้ำ
  • เครื่องมืออย่าง LangSmith, Log10, LangFuse, W&B Weave และ HoneyHive ไม่ได้แค่เก็บและจัดระเบียบข้อมูลเกี่ยวกับผลลัพธ์ของระบบในโปรดักชัน แต่ยังสัญญาว่าจะผสานเข้ากับการพัฒนาอย่างลึกซึ้งเพื่อใช้ข้อมูลเหล่านั้นมาปรับปรุงระบบ จงใช้เครื่องมือเหล่านี้หรือสร้างขึ้นเอง

อย่าสร้างฟีเจอร์ LLM ที่หาซื้อได้

• ธุรกิจที่ประสบความสำเร็จส่วนใหญ่ไม่ใช่ธุรกิจ LLM แต่ในขณะเดียวกัน ธุรกิจส่วนใหญ่ก็มีโอกาสที่จะดีขึ้นได้ด้วย LLM
• ข้อสังเกตสองข้อนี้มักทำให้ผู้นำหลงทาง จนรีบยกเครื่องระบบด้วย LLM และปล่อยฟีเจอร์ "AI" เทียมๆ ที่ดูหวือหวาแต่ไร้สาระ ซึ่งเพิ่มต้นทุนและลดคุณภาพ ตอนนี้ก็ได้ไอคอนประกายวิบวับที่น่าหวาดหวั่นครบแล้ว
• มีวิธีที่ดีกว่า: ให้โฟกัสกับแอปพลิเคชัน LLM ที่สอดคล้องกับเป้าหมายของผลิตภัณฑ์จริงๆ และเสริมความแข็งแกร่งให้การดำเนินงานหลัก
• ลองพิจารณาความพยายามที่ผิดทางบางอย่างซึ่งทำให้ทีมเสียเวลา
  • สร้างฟังก์ชัน text-to-SQL แบบปรับแต่งเองสำหรับธุรกิจ
  • สร้างแชตบอตที่คุยกับเอกสารได้
  • ผสาน knowledge base ของบริษัทเข้ากับแชตบอตบริการลูกค้า
• สิ่งเหล่านี้อาจเป็น hello world ของแอปพลิเคชัน LLM แต่ไม่สมเหตุสมผลที่บริษัทผลิตภัณฑ์จะสร้างเองโดยตรง
  • เพราะนี่เป็นปัญหาทั่วไปที่พบร่วมกันในหลายธุรกิจ ช่องว่างระหว่างเดโมที่ดูมีอนาคตกับคอมโพเนนต์ที่เชื่อถือได้ยังใหญ่มาก และเป็นพื้นที่ตามธรรมเนียมของบริษัทซอฟต์แวร์
  • การทุ่มทรัพยากร R&D อันมีค่าไปกับปัญหาทั่วไปที่ batch ปัจจุบันของ Y Combinator กำลังแก้กันในวงกว้างถือเป็นความสิ้นเปลือง
• หากฟังดูเหมือนคำแนะนำธุรกิจที่เชยๆ นั่นเป็นเพราะท่ามกลางความตื่นเต้นของกระแส hype ในตอนนี้ มันง่ายมากที่จะเข้าใจผิดว่าอะไรที่มีคำว่า "LLM" นั้นล้ำหน้าและแตกต่าง ทั้งที่จริงอาจเป็นแอปพลิเคชันที่เก่าไปแล้ว

ใส่ AI ไว้ในลูป และให้มนุษย์เป็นศูนย์กลาง

• แอปพลิเคชันที่อิงกับ LLM ในปัจจุบันยังเปราะบาง ต้องการมาตรการความปลอดภัยและ defensive engineering จำนวนมาก แต่ก็ยังคาดเดาได้ยาก ถึงอย่างนั้น หากกำหนดขอบเขตอย่างเข้มงวด แอปพลิเคชันเหล่านี้ก็มีประโยชน์อย่างมหาศาล ซึ่งหมายความว่า LLM เป็นเครื่องมือชั้นยอดในการเร่งเวิร์กโฟลว์ของผู้ใช้
• คุณอาจอยากจินตนาการว่าแอปพลิเคชันที่อิงกับ LLM จะเข้ามาแทนที่เวิร์กโฟลว์ทั้งหมดหรือแทนหน้าที่งานไปเลย แต่กระบวนทัศน์ที่ได้ผลที่สุดในปัจจุบันคือมนุษย์-คอมพิวเตอร์แบบเคนทอร์ (Centaur chess)
  • เมื่อมนุษย์ที่มีความสามารถจับคู่กับความสามารถของ LLM ที่ปรับแต่งมาเพื่อการใช้งานที่รวดเร็วของตนเอง ประสิทธิภาพและความพึงพอใจในการทำงานจะเพิ่มขึ้นอย่างมาก
  • หนึ่งในแอปพลิเคชันตัวอย่างของ LLM อย่าง GitHub CoPilot ได้พิสูจน์พลังของเวิร์กโฟลว์ลักษณะนี้แล้ว
    • "โดยรวมแล้ว นักพัฒนากล่าวว่าเมื่อใช้ GitHub Copilot และ GitHub Copilot Chat การเขียนโค้ดทำได้ง่ายขึ้น มีข้อผิดพลาดน้อยลง อ่านง่ายขึ้น นำกลับมาใช้ซ้ำได้มากขึ้น กระชับขึ้น ดูแลรักษาง่ายขึ้น และมีความยืดหยุ่นมากขึ้น" - Mario Rodriguez, GitHub
• คนที่ทำงานด้าน ML มานานมักจะนึกถึงแนวคิด "human-in-the-loop" อย่างรวดเร็ว แต่ก็อย่าเพิ่งรีบไปถึงจุดนั้น
  • HITL machine learning คือกระบวนทัศน์ที่อาศัยผู้เชี่ยวชาญมนุษย์เพื่อให้แน่ใจว่าโมเดล ML ทำงานตามที่คาดไว้
  • แต่สิ่งที่เสนอในที่นี้ แม้จะเกี่ยวข้องกัน ก็มีความละเอียดอ่อนกว่านั้น ระบบที่อิงกับ LLM ไม่ควรเป็นแรงขับหลักของเวิร์กโฟลว์ส่วนใหญ่ในวันนี้ แต่ควรเป็นเพียงทรัพยากร
• การให้มนุษย์เป็นศูนย์กลางแล้วถามว่า LLM จะสนับสนุนเวิร์กโฟลว์ได้อย่างไร ส่งผลต่อการตัดสินใจด้านผลิตภัณฑ์และการออกแบบอย่างมีนัยสำคัญ
  • ในท้ายที่สุด คุณจะได้สร้างผลิตภัณฑ์ที่ต่างจากคู่แข่งที่รีบโยนความรับผิดชอบทั้งหมดให้ LLM นั่นคือผลิตภัณฑ์ที่ดีกว่า มีประโยชน์กว่า และเสี่ยงน้อยกว่า

กลยุทธ์ 3. เริ่มจากการทำ Prompting, Eval และการเก็บข้อมูล

• ในส่วนก่อนหน้านี้ เราได้ระดมทั้งเทคนิคและคำแนะนำไว้มากมาย ซึ่งมีเยอะพอสมควร ลองพิจารณาชุดคำแนะนำขั้นต่ำที่ยังมีประโยชน์กัน
  • ถ้าทีมอยากสร้างผลิตภัณฑ์ LLM ควรเริ่มจากตรงไหน?
• ตลอดปีที่ผ่านมา เราได้เห็นมามากพอที่จะมั่นใจว่าแอปพลิเคชัน LLM ที่ประสบความสำเร็จมักเดินตามวิถีที่สอดคล้องกัน ในส่วนนี้เราจะดู playbook พื้นฐานสำหรับการ "เริ่มต้น" นี้
• แนวคิดหลักคือเริ่มแบบเรียบง่าย แล้วค่อยเพิ่มความซับซ้อนเมื่อจำเป็น
  • Rule of Thumb: โดยทั่วไปแล้ว ความประณีตในแต่ละระดับมักต้องใช้ความพยายามมากกว่าขั้นก่อนหน้าอย่างน้อยหนึ่งหลักของขนาด เมื่อจำไว้แบบนี้แล้ว...

Prompt engineering มาก่อนเป็นอันดับหนึ่ง

• เริ่มจาก prompt engineering
  • ใช้ทุกเทคนิคที่ได้พูดถึงในส่วน tactics ก่อนหน้านี้
  • Chain-of-thought, ตัวอย่างแบบ n-shot และ structured input/output แทบจะเป็นความคิดที่ดีเสมอ
  • ให้สร้าง prototype ด้วยโมเดลที่มีประสิทธิภาพสูงที่สุดก่อนที่จะพยายามเค้นประสิทธิภาพจากโมเดลที่อ่อนกว่า
• ให้พิจารณา fine-tuning ก็ต่อเมื่อไม่สามารถไปถึงระดับประสิทธิภาพที่ต้องการได้ด้วย prompt engineering เท่านั้น
  • เรื่องนี้จะเกิดบ่อยขึ้นเมื่อมีข้อกำหนดที่ไม่ใช่เชิงฟังก์ชันซึ่งกันการใช้โมเดล proprietary และบังคับให้ต้อง self-host เช่น ความเป็นส่วนตัวของข้อมูล การควบคุมได้เต็มรูปแบบ หรือค่าใช้จ่าย
  • และต้องระวังไม่ให้ข้อกำหนดด้านความเป็นส่วนตัวแบบเดียวกันนั้นกลับมาขัดขวางการใช้ข้อมูลผู้ใช้สำหรับการ fine-tuning

สร้างการประเมินและเริ่ม data flywheel

• แม้แต่ทีมที่เพิ่งเริ่มต้นก็ต้องมีการประเมิน (evals) ไม่เช่นนั้นจะไม่รู้เลยว่า prompt engineering เพียงพอหรือยัง หรือโมเดลที่ fine-tune แล้วพร้อมจะมาแทนโมเดลฐานหรือไม่
• การประเมินที่มีประสิทธิภาพจะต้องเฉพาะกับงานและสะท้อน use case ที่ตั้งใจไว้
  • ระดับแรกของการประเมินที่แนะนำคือ unit test
  • assertion ง่ายๆ เหล่านี้ช่วยตรวจจับ failure mode ที่รู้กันอยู่แล้วหรือที่ตั้งเป็นสมมติฐานไว้ และช่วยในการตัดสินใจด้านการออกแบบในระยะแรก
  • และควรอ้างอิงการประเมินเฉพาะงานอื่นๆ สำหรับงานอย่าง classification, summarization เป็นต้น
• แม้ unit test และการประเมินแบบใช้โมเดลจะมีประโยชน์ แต่ก็ไม่ได้แทนความจำเป็นของการประเมินโดยมนุษย์
  • ให้ผู้คนได้ใช้โมเดล/ผลิตภัณฑ์และให้ feedback
  • สิ่งนี้มีจุดประสงค์สองทาง คือทั้งใช้วัดประสิทธิภาพจริงและอัตราข้อบกพร่อง ขณะเดียวกันก็เก็บข้อมูลที่มีการใส่คำกำกับคุณภาพสูงเพื่อนำไปใช้ fine-tune โมเดลในอนาคต
  • สิ่งนี้สร้างวงจรป้อนกลับเชิงบวกหรือ data flywheel ที่ทบต้นเมื่อเวลาผ่านไป
    • การประเมินโดยมนุษย์เพื่อวัดประสิทธิภาพของโมเดลหรือค้นหาข้อบกพร่อง
    • ใช้ข้อมูลที่มีการใส่คำกำกับเพื่อ fine-tune โมเดลหรืออัปเดต prompt
    • ทำซ้ำ
• ตัวอย่างเช่น เมื่อตรวจสอบข้อบกพร่องของสรุปที่สร้างโดย LLM คุณสามารถกำหนดป้าย feedback แบบละเอียดระดับประโยคเพื่อระบุความไม่สอดคล้องกับข้อเท็จจริง ความไม่เกี่ยวข้อง หรือสไตล์ที่ไม่ดี
  • จากนั้นคุณสามารถใช้ annotation เรื่องความไม่สอดคล้องกับข้อเท็จจริงเหล่านี้เพื่อฝึกตัวจำแนก hallucination หรือใช้ annotation เรื่องความเกี่ยวข้องเพื่อฝึก relevance reward model ได้
• LinkedIn ได้แบ่งปันกรณีความสำเร็จของการใช้ผู้ประเมินแบบอิงโมเดลเพื่อประเมิน hallucination, การละเมิด Responsible AI, ความสอดคล้อง และอื่นๆ
• ด้วยการสร้างสินทรัพย์ที่มีมูลค่าเพิ่มขึ้นตามเวลา การสร้างการประเมิน (evals) จึงเปลี่ยนจากเพียงต้นทุนในการดำเนินงานไปเป็นการลงทุนเชิงกลยุทธ์ พร้อมกับสร้าง data flywheel ไปด้วยในกระบวนการ

กลยุทธ์ 4. แนวโน้มระดับสูงของการรับรู้ต้นทุนต่ำ (The high-level trend of low-cost cognition)

• ในปี 1971 นักวิจัยที่ Xerox PARC ได้คาดการณ์โลกของคอมพิวเตอร์ส่วนบุคคลที่เชื่อมต่อกันด้วยเครือข่ายแบบที่เราอาศัยอยู่ในปัจจุบัน
  • พวกเขายังมีบทบาทสำคัญในการให้กำเนิดอนาคตนั้นด้วยการมีส่วนหลักในการประดิษฐ์เทคโนโลยีที่ทำให้สิ่งนี้เป็นไปได้ (Ethernet, การเรนเดอร์กราฟิก, เมาส์, วินโดวส์ เป็นต้น)
• พวกเขายังทำแบบฝึกหัดง่าย ๆ อย่างหนึ่ง
  • พิจารณาแอปพลิเคชันที่มีประโยชน์มาก (เช่น วิดีโอดิสเพลย์) แต่ยังไม่คุ้มค่าในเชิงเศรษฐกิจ (RAM ที่มากพอจะขับวิดีโอดิสเพลย์มีราคาหลายพันดอลลาร์)
  • จากนั้นดูแนวโน้มราคาย้อนหลังของเทคโนโลยีนั้น (คล้ายกฎของมัวร์) และคาดการณ์ว่าเทคโนโลยีนั้นจะคุ้มค่าเมื่อใด
• เราสามารถทำแบบเดียวกันกับเทคโนโลยี LLM ได้ แม้จะไม่เรียบง่ายเท่าจำนวนทรานซิสเตอร์ต่อดอลลาร์ก็ตาม
  • เลือกเบนช์มาร์กยอดนิยมที่ใช้มายาวนาน (เช่น ชุดข้อมูล Massively-Multitask Language Understanding) และวิธีป้อนข้อมูลที่สม่ำเสมอ (5-shot prompting)
  • จากนั้นเปรียบเทียบต้นทุนของการรัน language model ที่มีระดับความสามารถต่างกันบนเบนช์มาร์กนี้เมื่อเวลาผ่านไป
• สำหรับต้นทุนคงที่ ความสามารถเพิ่มขึ้นอย่างรวดเร็ว และสำหรับระดับความสามารถคงที่ ต้นทุนก็ลดลงอย่างรวดเร็ว
  • ในช่วง 4 ปีนับตั้งแต่ OpenAI เปิดตัวโมเดล davinci ผ่าน API ค่าใช้จ่ายในการรันโมเดลที่มีสมรรถนะเทียบเท่าสำหรับงานนั้นในระดับ 1 ล้านโทเค็น (ประมาณ 100 สำเนาของเอกสารนี้) ลดลงจาก $20 เหลือต่ำกว่า 10 เซ็นต์ โดยมีครึ่งชีวิตเพียง 6 เดือน
  • ในทำนองเดียวกัน ณ เดือนพฤษภาคม 2024 ค่าใช้จ่ายในการรัน Meta's LLaMA 3 8B ไม่ว่าจะผ่านผู้ให้บริการ API หรือรันเอง มีเพียง 20 เซ็นต์ต่อ 1 ล้านโทเค็น และให้สมรรถนะใกล้เคียงกับ OpenAI's text-davinci-003 ซึ่งเป็นโมเดลที่ทำให้ ChatGPT เป็นไปได้
  • ตอนที่โมเดลดังกล่าวเปิดตัวเมื่อปลายเดือนพฤศจิกายน 2023 มันยังมีค่าใช้จ่ายราว $20 ต่อ 1 ล้านโทเค็นอยู่เลย ภายในเวลาเพียง 18 เดือน ต้นทุนต่างกันถึงสองหลัก ซึ่งเป็นช่วงเวลาเดียวกับการเพิ่มขึ้นแบบเท่าตัวอย่างง่ายที่กฎของมัวร์คาดการณ์ไว้
• ลองพิจารณาแอปพลิเคชัน LLM ที่มีประโยชน์มาก (เช่น การขับเคลื่อนตัวละครวิดีโอเกมเชิงกำเนิดแบบงานของ Park et al) แต่ยังไม่คุ้มค่าในเชิงเศรษฐกิจ (คาดว่ามีค่าใช้จ่าย $625 ต่อชั่วโมง)
  • นับตั้งแต่บทความนั้นเผยแพร่ในเดือนสิงหาคม 2023 ต้นทุนได้ลดลงมาประมาณหนึ่งหลัก เหลือราว $62.50 ต่อชั่วโมง
  • อีก 9 เดือนถัดไป ก็คาดได้ว่าจะลดลงเหลือ $6.25 ต่อชั่วโมง
• ขณะเดียวกัน เมื่อ Pac-Man เปิดตัวในปี 1980 เงิน $1 ในมูลค่าปัจจุบันสามารถซื้อเครดิตเล่นได้ไม่กี่นาทีหรือหลายสิบนาที เรียกได้ว่า 6 เกมต่อชั่วโมง หรือ $6 ต่อชั่วโมง
  • การคำนวณแบบคร่าว ๆ นี้ชี้ว่าประสบการณ์เกมที่เสริมด้วย LLM แบบน่าดึงดูดจะคุ้มค่าในเชิงเศรษฐกิจราวปี 2025
• แนวโน้มเหล่านี้เป็นเรื่องใหม่และเพิ่งเกิดขึ้นได้ไม่กี่ปี แต่แทบไม่มีเหตุผลให้คาดว่ากระบวนการนี้จะช้าลงในอีกหลายปีข้างหน้า
  • แม้เราจะใช้ผลไม้ที่เก็บง่ายของอัลกอริทึมและชุดข้อมูล เช่น การสเกลเกิน "Chinchilla ratio" ที่ ~20 โทเค็นต่อพารามิเตอร์ แต่นวัตกรรมและการลงทุนที่ลึกขึ้นทั้งภายในดาต้าเซ็นเตอร์และในชั้นซิลิคอนจะเข้ามาชดเชยช่องว่างนั้น
• และนี่อาจเป็นข้อเท็จจริงเชิงกลยุทธ์ที่สำคัญที่สุด
  • เดโมบนเวทีหรืองานวิจัยที่วันนี้ยังไม่สามารถทำได้จริงเลย จะกลายเป็นฟีเจอร์พรีเมียมในอีกไม่กี่ปี และหลังจากนั้นไม่นานก็จะกลายเป็นสินค้าทั่วไป
  • เราต้องสร้างทั้งระบบและองค์กรโดยคำนึงถึงสิ่งนี้

[เดโมจาก 0 ไป 1 ตอนนี้มีมากพอแล้ว ถึงเวลาสร้างผลิตภัณฑ์ที่ไปจาก 1 ถึง N]

• การสร้างเดโม LLM นั้นสนุกมาก แค่โค้ดไม่กี่บรรทัด vector database และพรอมป์ต์ที่เขียนอย่างพิถีพิถัน ก็สร้าง "เวทมนตร์" ขึ้นมาได้
• ตลอดปีที่ผ่านมา เวทมนตร์นี้ถูกนำไปเปรียบเทียบกับอินเทอร์เน็ต สมาร์ตโฟน หรือแม้แต่แท่นพิมพ์
• น่าเสียดายที่อย่างที่ใครก็ตามที่เคยทำงานเปิดตัวซอฟต์แวร์จริงรู้กันดี ระหว่างเดโมที่ทำงานได้ในสภาพแวดล้อมควบคุม กับผลิตภัณฑ์ที่ทำงานได้อย่างเสถียรในวงกว้างนั้น มีช่องว่างมหาศาล
• มีปัญหามากมายที่จินตนาการและทำเป็นเดโมได้ง่าย แต่ทำให้เป็นผลิตภัณฑ์จริงนั้นยากมาก
  • ตัวอย่างเช่น รถยนต์ไร้คนขับ: การสาธิตให้รถขับอัตโนมัติได้หนึ่งบล็อกนั้นทำได้ง่าย แต่การทำให้มันเป็นผลิตภัณฑ์ใช้เวลา 10 ปี - Andrej Karpathy
• ลองดูตัวอย่างรถยนต์ไร้คนขับ
  • ในปี 1988 รถคันแรกที่ขับเคลื่อนด้วย neural network ได้ถือกำเนิดขึ้น
  • 25 ปีต่อมา Andrej Karpathy ได้ทดลองนั่งเดโมครั้งแรกที่ Waymo
  • อีก 10 ปีหลังจากนั้น บริษัทได้รับใบอนุญาตให้ให้บริการขับขี่ไร้คนขับ
  • กว่าจะไปจากต้นแบบสู่ผลิตภัณฑ์เชิงพาณิชย์ ต้องผ่านวิศวกรรมที่เข้มงวด การทดสอบ การปรับปรุง และการเดินเกมด้านกฎระเบียบเป็นเวลา 35 ปี
• ตลอดปีที่ผ่านมา เราได้สังเกตทั้งขึ้นและลงทั่วทั้งอุตสาหกรรมและแวดวงวิชาการ: ปีที่ 1 จาก N ของแอปพลิเคชัน LLM
  • เราหวังว่าบทเรียนที่เราเรียนรู้ ไม่ว่าจะเป็นตั้งแต่แท็กติกอย่าง evaluation, prompt engineering, guardrails ไปจนถึงมุมมองเชิงกลยุทธ์อย่างความสามารถด้านปฏิบัติการ การสร้างทีม และการเลือกว่าจะสร้างอะไรภายในองค์กร จะเป็นประโยชน์ต่อปีที่ 2 และหลังจากนั้น
  • เราตั้งตารอที่จะช่วยกันพัฒนาเทคโนโลยีใหม่น่าตื่นเต้นนี้ต่อไป

[inthelife]

เนื้อหาดีมาก เลยลองทำเป็น Mindmap เก็บไว้ดูยาวๆ ครับ ^^;

https://drive.google.com/file/d/…

[hheungsu]

เป็นบทความที่ดีมากจริงๆ!! มีหลายประเด็นที่เป็นประโยชน์และชวนให้ขบคิดทบทวนได้ตั้งแต่ต้นจนจบ ขอบคุณมากที่แปลและนำบทความล้ำค่าแบบนี้มาโพสต์ให้ได้อ่านกัน!!

[nutella]

ตอนนี้ช่วยได้มากจริง ๆ เลยนะ

[komanabi]

เมกะสตัดดี้จบแล้ว โอเมก้า 3 กำลังมา!!!

[ssifood]

ตอนนี้ Skynet จบแล้ว MegaStudy กำลังมา

[my0075425]

ตอนนี้มวลมนุษยชาติถึงจุดจบแล้ว Skynet กำลังมา!!

[zihado]

เส้นทางอาชีพของผู้เขียนต้นฉบับก็น่าสนใจเช่นกัน
https://th.news.hada.io/topic?id=1626

[eungook]

ว้าว.. ได้แรงบันดาลใจมากเลยครับ.. ขอบคุณที่แนะนำครับ

[humblebee]

เป็นบทความที่ยอดเยี่ยมมากจนสัมผัสได้ถึงมุมมองเชิงลึกและประสบการณ์อย่างชัดเจน! คิดว่าน่าจะเป็นประโยชน์อย่างมากกับผมและทีม อ่านได้อย่างเพลิดเพลินมากครับ ขอบคุณครับ ☺️