จากพร้อมท์สู่ผลิตภัณฑ์: เปลี่ยน LLM ให้เป็นแอปจริง
วิธีการของผู้ประกอบวิชาชีพในการสร้างแอปพลิเคชัน LLM: การประเมิน รั้ว เวลาในการตอบสนองและงบประมาณต้นทุน การควบคุมโดยมนุษย์ และการรู้ว่าสิ่งใดไม่ควรทำให้เป็นอัตโนมัติ
By Vitor Lima
พรอมต์ที่ใช้งานได้ใน Playground เป็นการสาธิต ไม่ใช่ผลิตภัณฑ์ ช่องว่างระหว่างทั้งสองคือจุดที่โปรเจ็กต์ AI ส่วนใหญ่เงียบหายไป การสร้างแอปพลิเคชัน LLM ที่ใช้งานได้จริงนั้นเกี่ยวข้องกับการแจ้งเตือนที่ชาญฉลาดน้อยกว่าที่สาธิตแนะนำ และเกี่ยวข้องกับระเบียบวินัยของซอฟต์แวร์ทั่วไปน้อยกว่ามาก เราได้จัดส่ง Youp, MadaiOps และตอนนี้ Linea มามากพอแล้ว เพื่อให้มีความคิดเห็นเกี่ยวกับสิ่งที่ปิดช่องว่างนั้นได้จริงๆ ไม่มีสิ่งใดที่มีเสน่ห์
กับดักคือเวอร์ชันแรกรู้สึกว่าเสร็จแล้ว คุณวางพรอมต์ที่ชาญฉลาด โมเดลจะส่งกลับสิ่งที่น่าประทับใจ และเป็นการยากที่จะรวมไว้ใน UI และเรียกมันว่าการเปิดตัว จากนั้นผู้ใช้จริงจะเข้ามาพร้อมกับข้อมูลที่คุณไม่เคยจินตนาการมาก่อน โมเดลทำอะไรผิดพลาดอย่างมั่นใจ และคุณพบว่าคุณไม่มีทางบอกได้ว่าการแก้ไขของคุณทำให้สิ่งต่างๆ ดีขึ้นหรือแย่ลง งานชิ้นนี้เป็นเรื่องเกี่ยวกับโครงนั่งร้านที่เปลี่ยนการสาธิตที่น่าประทับใจให้กลายเป็นสิ่งที่คุณสามารถดำเนินการผลิตและนอนหลับได้ตลอดทั้งคืน
เริ่มต้นด้วยการประเมิน ไม่ใช่การแจ้ง
สิ่งที่ใช้ประโยชน์สูงสุดที่คุณสามารถสร้างได้ตั้งแต่เนิ่นๆ คือชุดการประเมิน ไม่ใช่เกณฑ์มาตรฐาน ไม่ใช่ลีดเดอร์บอร์ด — โฟลเดอร์ของอินพุตจริงที่จับคู่กับเอาต์พุตที่ดี ตัวอย่างยี่สิบตัวอย่างชนะศูนย์ และตัวอย่างห้าสิบตัวอย่างเอาชนะตัวอย่างที่คัดลอกมาหนึ่งพันตัวอย่าง
เหตุผลง่ายๆ เมื่อคุณมีการประเมินแล้ว วิศวกรรมพร้อมท์ก็จะเลิกเป็นแค่ความรู้สึกอีกต่อไป คุณเปลี่ยนเส้น คุณรันเซต คุณดูตัวเลขที่เคลื่อนไหว หากไม่มีพวกเขา การปรับแต่งทุกครั้งก็ถือเป็นความเชื่อโชคลาง เราได้เฝ้าดูทีมต่างๆ ใช้เวลาหนึ่งสัปดาห์ในการปรับปรุงการแจ้งเตือนเพียงเพื่อถดถอยในกรณีที่พวกเขาแก้ไขไปเมื่อหลายเดือนก่อน เนื่องจากไม่มีสิ่งใดมาวัดกรณีที่พวกเขาไม่ได้พิจารณา
ความคิดเห็นบางส่วนที่เรายึดมั่น:
- ให้คะแนนตามผลลัพธ์ ไม่ใช่ถ้อยคำ สำหรับสิ่งใดก็ตามที่มีโครงสร้าง เช่น การแยก การจำแนกประเภท การกำหนดเส้นทาง ยืนยันผลลัพธ์ที่แยกวิเคราะห์ ไม่ใช่ความคล้ายคลึงกันของสตริง สำหรับข้อความปลายเปิด การใช้ LLM ในฐานะผู้ตัดสินที่มีรูบริกที่แคบก็ใช้ได้ แต่ต้องตรวจสอบผู้ตัดสินกับป้ายกำกับที่เป็นมนุษย์จำนวนหนึ่งก่อน หรือคุณจะเพียงวัดรสนิยมของโมเดลเพียงตัวเดียว
- เก็บไฟล์การถดถอย ความล้มเหลวในการผลิตทุกครั้งจะกลายเป็นกรณีทดสอบถาวร นี่คือวิธีที่ชุดการประเมินของคุณยังคงความซื่อสัตย์ โดยจะเติบโตไปในทิศทางที่ความเป็นจริงผลักดันไป
- กำหนดเวอร์ชันการประเมินของคุณด้วยพร้อมท์ของคุณ พรอมต์ที่ไม่มีชุดการประเมินคือการเปลี่ยนแปลงโค้ดที่ยังไม่ทดสอบ
หากคุณสร้างสิ่งหนึ่งจากบทความนี้ ให้สร้างสิ่งนี้ ทุกอย่างที่อยู่ปลายน้ำขึ้นอยู่กับความสามารถในการตอบ นั่นทำให้ดีขึ้นหรือไม่
Guardrails ราคาถูกกว่าคำขอโทษ
โมเดลล้มเหลวในแบบที่ซอฟต์แวร์ทั่วไปไม่ทำ พวกเขาจะประดิษฐ์ API ที่ไม่มีอยู่จริง เห็นด้วยกับหลักฐานเท็จของผู้ใช้ หรือปล่อย JSON ที่ดูถูกต้องพร้อมกับฟิลด์ที่หลอน Guardrails เป็นเลเยอร์ที่จะจับสิ่งนี้ก่อนที่จะถึงผู้ใช้หรือที่แย่กว่านั้นคือขั้นตอนการดำเนินการ
คิดในสามตำแหน่ง
- ราวกั้นอินพุต ปฏิเสธหรือฆ่าเชื้อก่อนที่โมเดลจะทำงาน: การคัดกรองการฉีดทันที การแก้ไข PII การกรองนอกประเด็น
- รางป้องกันเอาท์พุต ตรวจสอบสิ่งที่กลับมา: การตรวจสอบสคีมา การตรวจสอบการอ้างอิงและพื้นฐาน ตัวกรองนโยบาย
- ราวกันแอ็คชั่น นั่งอยู่ระหว่างโมเดลกับสิ่งใดก็ตามที่มีผลข้างเคียง
อันที่สามคือจุดที่มีความเสี่ยงที่แท้จริง ใน Linea ซึ่งเป็นเอเจนต์เวิร์กโฟลว์อัตโนมัติของเรา โมเดลสามารถเสนอการดำเนินการ — เรียก API ย้ายบันทึก ส่งข้อความ ข้อเสนอและการดำเนินการเป็นขั้นตอนที่แยกจากกันโดยเจตนา การดำเนินการที่เป็นผลสืบเนื่องทุกครั้งจะต้องผ่านสัญญาที่พิมพ์ไว้และการตรวจสอบนโยบายก่อนที่จะดำเนินการใดๆ และการดำเนินการที่เป็นการทำลายหรือไม่สามารถย้อนกลับได้จำเป็นต้องมีช่องทางการยืนยันที่ชัดเจน เจ้าหน้าที่ที่แนะนำสิ่งที่ผิดคือปัญหา UX ที่คุณสามารถทำซ้ำได้ ตัวแทน ทำ สิ่งผิดคือเหตุการณ์ เก็บโหมดความล้มเหลวทั้งสองนี้ไว้ฝั่งตรงข้ามของขอบเขตที่เข้มงวด
เวอร์ชันที่ยึดถือความคิดเห็น: ตรวจสอบความถูกต้องของเอาต์พุตที่มีโครงสร้างกับสคีมา และลองอีกครั้งเมื่อเกิดความล้มเหลว แทนที่จะเชื่อว่าโมเดลมีความสอดคล้องกัน และอย่าปล่อยให้เอาท์พุตดิบของโมเดลเป็นสิ่งที่กระตุ้นให้เกิดการกระทำที่ไม่สามารถย้อนกลับได้ ใส่การตรวจสอบที่กำหนดไว้ระหว่างกันเสมอ
เวลาแฝงของงบประมาณและค่าใช้จ่ายเช่นคุณสมบัติ
เวลาแฝงและต้นทุนไม่ใช่สิ่งที่คุณวัดในตอนท้าย สิ่งเหล่านี้เป็นข้อจำกัดที่คุณออกแบบไว้ตั้งแต่เริ่มต้น เพราะมันเปลี่ยนแปลงสถาปัตยกรรม ไม่ใช่แค่การเรียกเก็บเงินเท่านั้น
กำหนดงบประมาณที่ชัดเจนต่อการกระทำที่ผู้ใช้เผชิญ: เป้าหมายเวลาแฝง p95 และเพดานต้นทุนต่อการโทร เมื่อเขียนสิ่งเหล่านี้แล้ว การตัดสินใจออกแบบก็จะง่ายขึ้น รูปแบบบางอย่างที่เราเข้าถึงซ้ำแล้วซ้ำเล่า:
- ปรับขนาดโมเดลให้เหมาะสมในแต่ละขั้นตอน ไปป์ไลน์ส่วนใหญ่มีหนึ่งหรือสองขั้นตอนที่ต้องการโมเดลชายแดนอย่างแท้จริง และหลายขั้นตอนที่เล็กกว่าและเร็วกว่าก็จัดการได้ดี การกำหนดเส้นทางการจำแนกประเภทแบบง่ายไปยังโมเดลราคาถูกและจองโมเดลราคาแพงไว้สำหรับขั้นตอนการให้เหตุผลที่ซับซ้อนถือเป็นการปรับให้เหมาะสมที่ให้ผลตอบแทนสูงสุด และมักจะปรับปรุงเวลาแฝงด้วย
- สตรีมโทเค็นแรก สำหรับการสนทนาใดๆ ก็ตาม เวลาแฝงที่รับรู้จะถูกครอบงำโดยโทเค็นเวลาถึงโทเค็นแรก การตอบสนองแบบสตรีมที่ใช้เวลาสี่วินาทีให้ความรู้สึกดีกว่าการปิดกั้นที่ใช้เวลาสองวินาที
- แคชเชิงรุก แคชทันทีในบริบทของระบบที่เสถียร แคชผลลัพธ์ปกติในอินพุตซ้ำ สัดส่วนของปริมาณการใช้งานจริงที่มีความหมายเกือบจะซ้ำกัน
ข้อดีที่ต้องคำนึงถึง: โมเดลที่ใหญ่กว่าช่วยลดความพยายามด้านวิศวกรรมของคุณ แต่เพิ่มต้นทุนและเวลาแฝงที่เพิ่มขึ้นตลอดไป รุ่นที่ราคาถูกกว่าผลักดันงานของคุณ — การดูแลที่รวดเร็วมากขึ้น, รั้วที่มากขึ้น, การประเมินที่มากขึ้น — แต่งานนั้นเป็นต้นทุนเพียงครั้งเดียวเมื่อเทียบกับการประหยัดแบบถาวร สำหรับสิ่งใดที่มีปริมาณมาก ใช้จ่ายด้านวิศวกรรม
ให้มนุษย์อยู่ในวงโดยตั้งใจ
"Human in the loop" มักถูกพูดถึงจนไม่มีความหมายอะไรเลย ทำได้ดี มันไม่ใช่ทางเลือกสำรองเมื่อ AI ล้มเหลว แต่เป็นการแบ่งงานที่ออกแบบมาโดยเฉพาะ คำถามไม่ใช่ *ว่าจะรวมมนุษย์หรือไม่ แต่ ซึ่งการตัดสินของมนุษย์มีค่ามากกว่าเวลาแฝงที่เพิ่มเข้ามา
รูปแบบที่เป็นประโยชน์ต่อเรามากที่สุดคือ การยกระดับความมั่นใจ ระบบจะจัดการกับคนส่วนใหญ่ที่มีความมั่นใจโดยอัตโนมัติ และกำหนดเส้นทางของชนกลุ่มน้อยที่ไม่แน่นอนไปยังบุคคล โดยแนบเหตุผลของแบบจำลองไว้เพื่อให้มนุษย์ตัดสินใจได้ในไม่กี่วินาที ไม่ใช่ไม่กี่นาที ใน MadaiOps การดำเนินการสั่งซื้อภายในพารามิเตอร์ปกติจะไหลผ่าน สิ่งใดก็ตามที่ผิดปกติปรากฏต่อผู้ปฏิบัติงานโดยมีบริบท แทนที่จะดำเนินการอย่างเงียบๆ ผู้รีวิวไม่ได้ดูแลเครื่อง พวกเขาให้ความสนใจเฉพาะในกรณีที่มันหายากและมีคุณค่าเท่านั้น
กฎอีกข้อหนึ่ง: เครื่องมือแก้ไขของมนุษย์และป้อนกลับเข้าไปในชุดการประเมินและคำแนะนำของคุณ ระบบ Human-in-the-loop ที่ไม่ได้เรียนรู้จากมนุษย์นั้นจ่ายเพียงสองเท่าสำหรับงานชิ้นเดียวกัน
รู้ว่าอะไรไม่ควรทำให้เป็นอัตโนมัติ
การตัดสินที่ยากที่สุดในวินัยนี้คือความยับยั้งชั่งใจ ไม่ใช่ทุกงานที่ควรมอบให้กับแบบจำลอง และความเป็นผู้ใหญ่คือการรู้ว่างานไหนควรปล่อยให้อยู่คนเดียว
การทดสอบคร่าวๆ ของเรา: ทำให้เป็นอัตโนมัติโดยที่ต้นทุนของข้อผิดพลาดต่ำ หรือข้อผิดพลาดนั้นตรวจพบและย้อนกลับได้ง่าย การร่าง การสรุป การแตกข้อมูล การแยกประเภท การกำหนดเส้นทาง — ตัวเลือกที่ดี มีการแก้ไขแบบร่างที่ไม่ถูกต้อง สรุปผิดถูกจับได้ว่าอ่าน ให้ระมัดระวังมากขึ้นในกรณีที่ข้อผิดพลาดมีราคาแพง ตรวจพบได้ยาก หรือไม่สามารถย้อนกลับได้: สิ่งใดก็ตามที่โอนเงิน ส่งการสื่อสารที่เพิกถอนไม่ได้ หรือโทรทางกฎหมายหรือทางการแพทย์ ที่นั่น โมเดลมีบทบาทในการช่วยเหลือ — นำเสนอตัวเลือกต่างๆ , ร่างเพื่อการตรวจสอบ — ไม่ใช่บนที่นั่งคนขับ
บรรทัดที่เรายึดถือ: หากคุณไม่สามารถอธิบายได้ว่าคุณจะตรวจจับโมเดลที่ผิดได้อย่างไร แสดงว่าคุณยังไม่พร้อมที่จะดำเนินการขั้นตอนนั้นโดยอัตโนมัติ ความสามารถในการตรวจจับความล้มเหลวเป็นข้อกำหนดเบื้องต้นที่แท้จริง มากกว่าความแม่นยำ ขั้นตอนที่แม่นยำ 95% ที่คุณสามารถตรวจสอบได้ครบถ้วนนั้นปลอดภัยกว่าในการจัดส่งมากกว่าขั้นตอนที่มีความแม่นยำ 99% ที่คุณทำไม่ได้
รูปร่างของงาน
การเปลี่ยนข้อความแจ้งให้เป็นผลิตภัณฑ์ส่วนใหญ่เป็นส่วนที่ไม่สวยงาม เช่น การประเมินเพื่อให้คุณสามารถวัดผลได้ ราวกั้นเพื่อป้องกันไม่ให้เกิดความล้มเหลว งบประมาณเพื่อให้ดำเนินการได้รวดเร็วและราคาไม่แพง มนุษย์ถูกจัดให้อยู่ในจุดที่การตัดสินใจมีความสำคัญ และวินัยในการทิ้งบางสิ่งที่ไม่เป็นระบบอัตโนมัติ แบบจำลองนี้อาจจะเป็นยี่สิบเปอร์เซ็นต์ของระบบ อีกแปดสิบเปอร์เซ็นต์คือวิศวกรรมที่ทำให้ความแวววาวเป็นครั้งคราวนั้นปลอดภัยที่จะพึ่งพาได้
ข่าวดีก็คือว่านี่เป็นงานที่คุ้นเคย มันให้รางวัลตามสัญชาตญาณเดียวกับที่สร้างซอฟต์แวร์ดีๆ ทุกประเภท: วัดผลก่อนที่จะเปลี่ยน ควบคุมรัศมีการระเบิด เคารพเวลาของผู้ใช้ของคุณ โมเดลนี้เป็นของใหม่ ฝีมือไม่เป็น..