คู่มือเบื้องต้นเกี่ยวกับการทำ Tracing สำหรับแอปพลิเคชัน LLM

นี่เป็นส่วนหนึ่งของซีรีส์ที่เรากำลังเผยแพร่ใน Langfuse Academy ซึ่งเราจะพาคุณผ่านวงจรชีวิตวิศวกรรม AI อย่างครบถ้วน หากคุณยังใหม่กับซีรีส์นี้ The AI Engineering Loop คือจุดเริ่มต้นที่ดีที่สุด

สรุปสั้นๆ เกี่ยวกับ AI Engineering Loop

AI Engineering Loop คือวิธีที่ทีมงานปรับปรุงระบบ AI อย่างต่อเนื่อง มันเชื่อมโยงสิ่งที่เกิดขึ้นในระบบจริง (การติดตาม, การตรวจสอบ) เข้ากับการทำซ้ำอย่างมีโครงสร้างระหว่างการพัฒนา (ชุดข้อมูล, การทดลอง, การประเมินผล) การปรับปรุงแต่ละครั้งที่เผยแพร่จะสร้างข้อมูลใหม่ และทีมงานจะวนซ้ำกระบวนการนี้อย่างต่อเนื่อง

คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ที่นี่

การติดตาม (tracing) เข้ากับวงจรได้อย่างไร

ซอฟต์แวร์แบบดั้งเดิมส่วนใหญ่เป็นแบบกำหนดได้ การทำงานจะเป็นไปตามรูปแบบที่กำหนดไว้ล่วงหน้า แต่สำหรับแอปพลิเคชัน LLM นั้นไม่ใช่แบบนั้น การทำงานของเอเจนต์อาจยุ่งเหยิง เรากำลังจัดการกับพฤติกรรมที่เกิดขึ้นใหม่ซึ่งมีอินพุตและเอาต์พุตที่หลากหลายและไม่คาดคิด รวมถึงลำดับการทำงาน คุณจำเป็นต้องมีสิ่งอื่นเพื่อติดตามพฤติกรรมของเอเจนต์ของคุณ: traces

การติดตาม (tracing) เป็นศูนย์กลางของวงจรการปรับปรุงทั้งหมด ทุกขั้นตอนอื่นๆ (การตรวจสอบ, การสร้างชุดข้อมูล, การทดลอง, การประเมินผล) ดำเนินการบน traces

หากคุณคุ้นเคยกับแนวคิดการสังเกตการณ์แบบดั้งเดิมอยู่แล้ว บางส่วนต่อไปนี้อาจรู้สึกซ้ำซาก คุณสามารถอ่านผ่านๆ หรือข้ามไปก่อนได้

กายวิภาคของ trace

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

observation คือขั้นตอนเดียวในกระบวนการ มันมีอินพุต, เอาต์พุต, เวลาเริ่มต้น/สิ้นสุด, และข้อมูลเมตาเกี่ยวกับสิ่งที่เกิดขึ้นในขั้นตอนนั้น

ลำดับชั้น

trace มีโครงสร้างแบบต้นไม้ตามลำดับชั้น ภายในประกอบด้วย observations ที่สามารถบรรจุ observations อื่นๆ เกิดเป็นโครงสร้างแม่-ลูกที่สะท้อนการทำงานจริงของแอปพลิเคชัน AI ของคุณ

คุณสามารถเห็นสิ่งที่เกิดขึ้นตามลำดับ และขั้นตอนใดเป็นส่วนหนึ่งของขั้นตอนใหญ่ใด

ข้อมูล observation

อินพุตและเอาต์พุต ทุก observation สามารถมีอินพุตและเอาต์พุตได้ โดยส่วนใหญ่แล้วจะมีทั้งสองอย่าง ในบางกรณีเฉพาะอาจมีเพียงอย่างใดอย่างหนึ่ง สิ่งสำคัญสำหรับการตีความคือคุณต้องตั้งค่าอินพุตและ/หรือเอาต์พุตที่เหมาะสมกับประเภทของการกระทำที่เกิดขึ้นใน observation นั้น

ประเภทของ observation เพื่อให้แยกแยะการดำเนินการต่างๆ ได้ง่าย คุณจะเห็น observation หลายประเภท แต่ละประเภทใช้เพื่อบันทึกปฏิสัมพันธ์ต่างๆ ของเอเจนต์

ประเภทของ observation ทำให้อ่าน traces และกรองได้ง่ายขึ้น ใน trace ที่มี 20 observation การสามารถระบุการเรียก LLM ได้อย่างรวดเร็วช่วยประหยัดเวลา

ต้นทุน, ความหน่วง, การใช้โทเค็น

นอกเหนือจากอินพุตและเอาต์พุตแล้ว ยังมีคุณลักษณะบางอย่างบน observations ที่เป็นพื้นฐานในแอปพลิเคชัน LLM ทุกตัว: ต้นทุน, ความหน่วง, และการใช้โทเค็น สิ่งเหล่านี้จะถูกบันทึกต่อ observation และรวมที่ระดับ trace

Traces กับ sessions

โดยส่วนใหญ่คุณจะไม่เห็นการทำงานตลอดวงจรชีวิตของเอเจนต์ทั้งหมดใน trace เดียว traces สามารถจัดกลุ่มเป็น sessions ได้ แต่คุณจะแบ่งเส้นแบ่งระหว่าง trace กับ session ตรงไหน?

กฎทั่วไปคือ: หนึ่ง trace สอดคล้องกับการเรียกใช้ระบบหนึ่งครั้ง โดยทั่วไปคือหนึ่งการเรียก API หรือการทำงานของเอเจนต์หนึ่งครั้ง จากนั้น session จะรวมหลาย traces เข้าด้วยกัน เช่น ทุกเทิร์นในการสนทนาหลายเทิร์น

จะเริ่มต้นที่ไหน

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

1. ตั้งค่า tracing สำหรับเส้นทางคำขอสำคัญหนึ่งเส้นทางในแอปพลิเคชันของคุณ
2. ตรวจสอบให้แน่ใจว่าแต่ละ observation บันทึกอินพุต, เอาต์พุต, และข้อมูลเมตาที่มีประโยชน์สำหรับขั้นตอนที่มันแสดง
3. ตรวจสอบ traces จริงสองสามรายการด้วยตนเองเพื่อยืนยันว่าโครงสร้างเข้าใจง่ายและมีประโยชน์สำหรับการดีบัก

ขั้นตอนถัดไป

เมื่อคุณเห็น traces แล้ว คุณสามารถไปยังขั้นตอนถัดไป: การตรวจสอบ (monitoring) การตรวจสอบคือสิ่งที่เชื่อมต่อ traces เข้ากับวงจรของการปรับปรุงและทำซ้ำบนเอเจนต์ของคุณ