- สรุป 7 แพตเทิร์นหลักตามแกน "เพิ่มประสิทธิภาพ vs. ลดต้นทุน/ความเสี่ยง" และ "เน้นข้อมูล vs เน้นผู้ใช้"
- Evals: การวัดประสิทธิภาพ
- RAG (Retrieval-Augmented Generation): เพิ่มความรู้ภายนอกที่อัปเดตล่าสุด
- Fine-tuning: เพื่อให้ทำงานเฉพาะทางได้ดีขึ้น
- Caching: ลด latency และต้นทุน
- Guardrails: รับประกันคุณภาพของผลลัพธ์
- Defensive UX: เพื่อคาดการณ์และจัดการข้อผิดพลาด
- Collect user feedback: สร้าง data flywheel
Evals: การวัดประสิทธิภาพ
- Evals คือชุดของตัวชี้วัดที่ใช้ประเมินประสิทธิภาพของโมเดลในงานหนึ่ง ๆ
- รวมถึง benchmark data และ metrics
- ใช้วัดว่าระบบหรือผลิตภัณฑ์ทำงานได้ดีแค่ไหน และสามารถตรวจจับการถดถอยของคุณภาพได้
- ในสาย language modeling มี benchmark จำนวนมาก เช่น MMLU, EleutherAI Eval, HELM, AlpacaEval
- สามารถแบ่ง metrics ออกเป็นสองหมวดได้คือ Context-dependent และ Context-free
- metrics ที่ใช้กันทั่วไป: BLEU, ROUGE, BERTScore, MoverScore
- เทรนด์ที่กำลังมาแรงคือการใช้ LLM ที่มีความสามารถสูงเป็น reference-free metric เพื่อประเมินผลลัพธ์ที่สร้างโดย LLM อื่น
- G-Eval, งานวิจัย Vicuna, QLoRA
RAG (Retrieval-Augmented Generation): เพิ่มความรู้ภายนอกที่อัปเดตล่าสุด
- ดึงข้อมูลจากภายนอก foundation model แล้วนำข้อมูลนั้นมาเสริมอินพุต เพื่อให้มีบริบทที่สมบูรณ์ขึ้นและปรับปรุงผลลัพธ์
- RAG ช่วยลด hallucination และเพิ่มความถูกต้องเชิงข้อเท็จจริง โดยอิงโมเดลกับบริบทที่ค้นคืนมา
- อีกทั้งการทำให้ search index ทันสมัยอยู่เสมอยังมีต้นทุนต่ำกว่าการ pre-train LLM ต่อเนื่อง
- ด้วยความคุ้มค่านี้ LLM จึงเข้าถึงข้อมูลล่าสุดได้ผ่าน RAG
- หากต้องอัปเดตหรือลบข้อมูล เช่น เอกสารที่มีอคติหรือเป็นอันตราย การอัปเดต search index ก็ทำได้ง่ายกว่าการ fine-tune LLM
- สำหรับ RAG การเข้าใจ text embedding ก่อนจะเป็นประโยชน์
- text embedding คือการแทนข้อความความยาวใดก็ได้ให้อยู่ในรูปเวกเตอร์ตัวเลขขนาดคงที่ ซึ่งเป็นการแทนเชิงนามธรรมแบบบีบอัดของข้อมูลข้อความ
- โดยทั่วไปฝึกจาก text corpus เช่น Wikipedia
- มองได้ว่าเป็น encoding ทั่วไปของข้อความ โดยรายการที่คล้ายกันจะอยู่ใกล้กัน ส่วนที่ไม่คล้ายกันจะอยู่ไกลออกไป
- embedding ที่ดีคือ embedding ที่ทำงาน downstream เช่นการค้นหารายการที่คล้ายกันได้ดี
- Massive Text Embedding Benchmark (MTEB) ของ Huggingface ให้คะแนนโมเดลในงานหลากหลาย เช่น classification, clustering, retrieval, summarization
- ที่นี่พูดถึง text embedding เป็นหลัก แต่ embedding สามารถใช้กับหลาย modality ได้
- Fusion-in-Decoder (FiD) ใช้ retrieval ร่วมกับ generative model สำหรับ open-domain QA
- Internet-augmented LM เสนอการเสริมความสามารถของ LLM โดยใช้ search engine ที่มีอยู่แล้ว
- วิธีนำ RAG ไปใช้
- hybrid search (traditional search index + embedding-based search) ทำงานได้ดีกว่าใช้แต่ละแบบเพียงลำพัง
Fine-tuning: เพื่อให้ทำงานเฉพาะทางได้ดีขึ้น
- fine-tuning คือกระบวนการนำโมเดลที่ pre-train มาแล้ว (โมเดลที่ผ่านการฝึกด้วยข้อมูลจำนวนมหาศาล) มาปรับแต่งเพิ่มเติมสำหรับงานเฉพาะ
- เพื่อใช้ประโยชน์จากความรู้ที่โมเดลได้เรียนรู้ระหว่าง pre-training แล้วนำไปใช้กับงานเฉพาะที่มักมีชุดข้อมูลขนาดเล็กกว่า
- คำว่า fine-tuning มักถูกใช้แบบกว้าง ๆ เพื่อสื่อถึงหลายแนวคิด
- continued pre-training
- instruction fine-tuning
- single-task fine-tuning
- RLHF
- ทำไมต้อง fine-tuning?
- ประสิทธิภาพและการควบคุม:
- ปรับปรุงประสิทธิภาพของ base model ที่มีอยู่ และอาจเหนือกว่า third-party LLM ได้
- ควบคุมพฤติกรรมของ LLM ได้ดีขึ้น ทำให้ระบบหรือผลิตภัณฑ์มีพลังมากขึ้น
- ใช้ fine-tuning เพื่อสร้างผลิตภัณฑ์ที่แตกต่างจากการใช้ third-party หรือ open LLM แบบตรง ๆ ได้
- ความเป็นโมดูลาร์:
- ใช้ single-task fine-tuning เพื่อสร้างกองทัพของโมเดลขนาดเล็กที่แต่ละตัวเชี่ยวชาญงานเฉพาะ
- แนวทางนี้ช่วยทำให้ระบบเป็นโมดูลตามงานอย่าง content moderation, extraction, summarization ได้
- ลดการพึ่งพา:
- การ fine-tune และ host โมเดลเองช่วยลดปัญหาทางกฎหมายที่เกี่ยวกับข้อมูล proprietary ที่ส่งออกไปยัง API ภายนอก (เช่น PII, เอกสารภายใน และโค้ด)
- อีกทั้งยังช่วยก้าวข้ามข้อจำกัดของ third-party LLM เช่น rate limit, ต้นทุนสูง หรือ safety filter ที่เข้มงวดเกินไป
- Generative Pre-trained Transformers (GPT; decoder only)
- Text-to-text Transfer Transformer (T5; encoder-decoder)
- InstructGPT
- Soft prompt tuning & Prefix Tuning
- Low-Rank Adaptation (LoRA) & QLoRA
- วิธีนำ fine-tuning ไปใช้
- เก็บข้อมูลเดโม/labels
- กำหนดตัวชี้วัดการประเมิน
- เลือกโมเดล pre-train
- ปรับปรุงสถาปัตยกรรมโมเดล
- เลือกวิธี fine-tuning (เช่น LoRA, QLoRA)
- ปรับ hyperparameter พื้นฐาน
Caching: ลด latency และต้นทุน
- caching คือเทคนิคการเก็บข้อมูลที่เคยค้นคืนหรือคำนวณไว้ก่อนหน้า
- ทำให้รองรับคำขอในอนาคตที่ต้องการข้อมูลเดิมได้ดีขึ้น
- ใน LLM คือการ cache คำตอบของ LLM สำหรับ embedding ของคำขออินพุต และเมื่อมีคำขอถัดไปที่มีความหมายใกล้เคียงกัน ก็ส่งคืนคำตอบที่ cache ไว้
- แต่ผู้ปฏิบัติงานบางคนมองว่านี่เหมือนกับ "การรอให้หายนะเกิดขึ้น" และฉันก็เห็นด้วย
- หัวใจสำคัญของการใช้แพตเทิร์น caching คือการหาวิธี cache อย่างปลอดภัย แทนที่จะพึ่งพาเพียงความคล้ายเชิงความหมาย
- ทำไมต้อง caching? : เพื่อลดเวลาแฝง และลดจำนวนคำขอไปยัง LLM เพื่อลดต้นทุน
- จะใช้ caching อย่างไร?
- ควรเริ่มจากการทำความเข้าใจรูปแบบคำขอของผู้ใช้ให้ดี
- พิจารณาว่า caching มีประสิทธิภาพกับรูปแบบการใช้งานนั้นหรือไม่
Guardrails: รับประกันคุณภาพของผลลัพธ์
- ตรวจสอบผลลัพธ์ของ LLM เพื่อให้มั่นใจว่าไม่เพียงดูดี แต่ยังถูกต้องตามไวยากรณ์ ถูกต้องตามข้อเท็จจริง และไม่มีเนื้อหาที่เป็นอันตราย
- ทำไมต้องมี guardrails?
- ช่วยให้มั่นใจว่าผลลัพธ์ของโมเดลมีความน่าเชื่อถือและสม่ำเสมอเพียงพอสำหรับใช้ใน production
- เพิ่มชั้นความปลอดภัย และคงการควบคุมคุณภาพของผลลัพธ์จาก LLM
- แนวทางหนึ่งคือควบคุมคำตอบของโมเดลผ่าน prompt
- Anthropic เคยแชร์ prompt ที่ออกแบบมาเพื่อชี้นำให้โมเดลสร้างคำตอบแบบ helpful, harmless, and honest (HHH)
- แนวทางที่ทั่วไปกว่าคือการตรวจสอบความถูกต้องของผลลัพธ์ (เช่นแพ็กเกจ Guardrails)
- NeMo-Guardrails ของ Nvidia ใช้หลักการคล้ายกัน แต่ถูกออกแบบมาเพื่อชี้นำระบบสนทนาที่ขับเคลื่อนด้วย LLM
- ยังสามารถบังคับผลลัพธ์ให้เป็นไปตาม grammar เฉพาะได้โดยตรง เช่น Microsoft Guidance (อาจมองได้ว่าเป็น DSL สำหรับ LLM)
- วิธีนำ guardrails ไปใช้
- Structural guidance
- Syntactic guardrails
- Content safety guardrails
- Semantic/factuality guardrails
- Input guardrails
Defensive UX: เพื่อคาดการณ์และจัดการข้อผิดพลาด
- defensive UX คือกลยุทธ์การออกแบบที่ยอมรับว่าอาจเกิดเรื่องไม่พึงประสงค์ เช่น ความไม่แม่นยำหรือ hallucination ขึ้นได้ ระหว่างที่ผู้ใช้โต้ตอบกับผลิตภัณฑ์ที่ใช้ machine learning หรือ LLM
- เป้าหมายหลักคือคาดการณ์และจัดการเรื่องเหล่านี้ล่วงหน้า โดยการชี้นำพฤติกรรมผู้ใช้ ป้องกันการใช้งานผิด และจัดการข้อผิดพลาดอย่างเหมาะสม
- ทำไมต้อง defensive UX?
- machine learning และ LLM ไม่ได้สมบูรณ์แบบ และอาจสร้างผลลัพธ์ที่ไม่ถูกต้องได้
- ตอบสนองต่างกันได้แม้เป็นคำถามเดียวกัน
- defensive UX ช่วยบรรเทาปัญหาข้างต้นด้วยการมอบสิ่งต่อไปนี้
- การเข้าถึงที่ดีขึ้น ความน่าเชื่อถือที่เพิ่มขึ้น และ UX ที่ดีกว่า
- ดูแนวทางที่บริษัทต่าง ๆ สรุปไว้
- Microsoft’s Guidelines for Human-AI Interaction
- Google’s People + AI Guidebook
- Apple’s Human Interface Guidelines for Machine Learning
- วิธีนำ defensive UX ไปใช้
- ตั้งความคาดหวังที่ถูกต้อง
- ทำให้ผู้ใช้ปฏิเสธหรือข้ามได้อย่างมีประสิทธิภาพ (Enable efficient dismissal)
- ให้ attribution
- Anchor on familiarity
Collect user feedback: สร้าง data flywheel
- การเก็บ user feedback ช่วยให้เข้าใจความชอบของผู้ใช้ได้
- feedback จากผู้ใช้ที่เฉพาะกับผลิตภัณฑ์ LLM มีส่วนช่วยต่อการประเมิน การ fine-tuning และการสร้าง guardrails
- ข้อมูลอย่าง corpus สำหรับ pre-training, เดโมที่ผู้เชี่ยวชาญสร้าง, และ preference ของมนุษย์สำหรับ reward modeling คือหนึ่งใน moat ที่มีอยู่ไม่กี่อย่างของผลิตภัณฑ์ LLM
- feedback อาจเป็นแบบ explicit หรือ implicit
- explicit feedback คือข้อมูลที่ผู้ใช้ให้เพื่อตอบสนองต่อคำขอของผลิตภัณฑ์
- implicit feedback คือข้อมูลที่เรียนรู้จากปฏิสัมพันธ์ของผู้ใช้ โดยผู้ใช้ไม่จำเป็นต้องตั้งใจให้ feedback
- ทำไมต้องเก็บ user feedback
- user feedback ช่วยปรับปรุงโมเดลได้
- เมื่อเรียนรู้ว่าผู้ใช้ชอบ ไม่ชอบ หรือบ่นเรื่องอะไร ก็สามารถปรับปรุงโมเดลให้ตอบโจทย์ความต้องการได้ดีขึ้น
- อีกทั้งยังสามารถปรับให้เข้ากับความชอบของแต่ละบุคคลได้
- feedback loop ยังช่วยประเมินประสิทธิภาพโดยรวมของระบบได้
- วิธีเก็บ user feedback
- ทำให้ผู้ใช้ส่ง feedback ได้ง่าย: เช่น ให้กดชอบ/ไม่ชอบกับคำตอบแบบ ChatGPT
- พิจารณา implicit feedback ด้วย: ข้อมูลที่เกิดขึ้นเมื่อผู้ใช้โต้ตอบกับผลิตภัณฑ์
1 ความคิดเห็น
ในบทความต้นฉบับมีคำอธิบายรายละเอียดของแต่ละหัวข้อและอัลกอริทึม/เมตริกต่าง ๆ แต่ในที่นี้ได้ละไว้ สรุปคร่าว ๆ จากบทความนี้ก่อน แล้วแนะนำให้อ่านต้นฉบับประกอบด้วย