ฉันเขียนคู่มือนี้ขึ้นมา เพราะหวังว่าจะมีใครสักคนเขียนแบบนี้ให้ฉันอ่านก่อนที่จะก้าวเข้าสู่วงการวิศวกรรม AI ประยุกต์ (Applied AI Engineering)
บทบาทนี้โดยรวมแล้วทับซ้อนกับวิศวกรรมซอฟต์แวร์แบบดั้งเดิม แต่ก็เพิ่มแนวคิดสำคัญบางอย่างที่วิศวกรซอฟต์แวร์ส่วนใหญ่ต้องเรียนรู้ระหว่างการเปลี่ยนผ่าน ฉันแนะนำให้คุณใช้บทความนี้เป็นโครงร่างของหัวข้อหลักที่ต้องทำความเข้าใจ แล้วค่อยติดตามแหล่งข้อมูลที่เชื่อมโยงไว้ตลอดทั้งบทความเมื่อคุณต้องการเจาะลึกมากขึ้น
เมื่ออ่านจบ คุณควรจะมีความเข้าใจที่ชัดเจนขึ้นมากว่าวิศวกรรม AI ประยุกต์คืออะไร งานนี้ต้องการอะไรจริงๆ และมันขยายขอบเขตออกไปไกลกว่าวิศวกรรมซอฟต์แวร์แบบดั้งเดิมอย่างไร
ถ้าคุณสนใจที่จะทำงานในปัญหาที่น่าสนใจที่สุดบางอย่างในด้าน AI ประยุกต์ร่วมกับทีมวิศวกรที่มีความสามารถมาก เรากำลังรับสมัครงานอยู่เสมอ สมัครได้ที่เว็บไซต์ของเรา varickagents.com หรือแนะนำผู้สมัครเพื่อรับค่าตอบแทนแนะนำ 20,000 ดอลลาร์
อย่างไรก็ตาม วิธีที่ดีที่สุดในการทำความเข้าใจวิศวกรรม AI ประยุกต์คือการเริ่มต้นที่การเปลี่ยนแปลงวิธีคิดของคุณเกี่ยวกับการสร้างซอฟต์แวร์
วิศวกรรมซอฟต์แวร์ vs วิศวกรรม AI
ความแตกต่างที่ใหญ่ที่สุดระหว่างการเป็นวิศวกรซอฟต์แวร์ (SWE) และวิศวกร AI คือ วิศวกรรมซอฟต์แวร์แบบดั้งเดิมฝึกให้คุณคิดแบบกำหนดตายตัว (deterministic) ในขณะที่ AI ประยุกต์บังคับให้คุณคิดแบบความน่าจะเป็น (probabilistic)
ในซอฟต์แวร์ทั่วไป คุณเขียนลอจิก ทำให้มันรันได้ และเมื่อมีอะไรพัง คุณมักจะสามารถตามรอยมันได้ – อินพุตที่มีโครงสร้างจะให้เอาต์พุตที่มีโครงสร้างอย่างแน่นอน
AI ประยุกต์ไม่ได้ทำงานแบบนั้น คุณกำลังสร้างระบบรอบๆ การเรียก API ที่ไม่สามารถกำหนดตายตัวได้ไปยังระบบปัญญาประดิษฐ์ ซึ่งหมายความว่าอินพุตเดียวกันสามารถให้ผลลัพธ์ที่แตกต่างกันได้ทุกครั้ง ด้วยเหตุนี้ งานจึงไม่ได้หยุดอยู่แค่การสร้างซอฟต์แวร์ แต่กลับกลายเป็นการวัดว่าระบบทำงานอย่างที่ควรจะเป็นหรือไม่
วิธีที่เราทำสิ่งนั้นคือผ่านการประเมินผล (evals) ดังนั้นฉันจะอธิบายวิธีสร้างชุดการประเมินผลที่รับประกันว่าเอเจนต์ที่คุณพัฒนาจะไม่ทำผิดพลาด ฉันได้เรียนรู้ว่านี่เป็นหนึ่งในทักษะที่สำคัญที่สุดของนักพัฒนา AI ประยุกต์ เนื่องจากลักษณะงานของเราที่ไม่สามารถกำหนดตายตัวได้
ส่วนถัดไปของบทความจะครอบคลุมถึงการพัฒนาแต่ละส่วนของเอเจนต์ AI (ยกเว้นตัวโมเดลเองแน่นอน) เพราะคุณสามารถเรียก API ไปยังโมเดลได้ แต่คุณต้องสร้างทุกอย่างอื่นด้วยตัวเอง สิ่งนี้เรียกว่าวิศวกรรมสายรัด (Harness Engineering)
และสุดท้าย ฉันจะครอบคลุมถึงวิธีการเปลี่ยนจากเอเจนต์หนึ่งตัวในระบบผลิตจริงไปเป็นหลายตัว – และทำไมมันถึงเป็นปัญหาของระบบกระจาย (distributed systems problem) ถ้าคุณอ่านบทความนี้จนจบ ก็ไม่มีเหตุผลใดที่คุณจะไม่สามารถเปลี่ยนผ่านไปเป็นวิศวกร AI ประยุกต์ได้
การประเมินผล (Evals)
วิศวกร AI ประยุกต์เปลี่ยนความไม่แน่นอนให้เป็นความมั่นใจที่วัดได้โดยใช้การประเมินผล ในการพัฒนาซอฟต์แวร์แบบดั้งเดิม คุณเชื่อถือระบบเพราะคุณเขียนลอจิกและทดสอบโค้ดแล้ว ใน AI ประยุกต์ คุณไม่สามารถเชื่อถือระบบแบบนั้นได้ เพราะโมเดลสามารถทำงานแตกต่างกันไปในแต่ละรอบการทำงาน ดังนั้นวิศวกร AI จึงต้องสร้างชั้นการวัดผลรอบๆ เอเจนต์
การประเมินผลคือกระบวนการมอบหมายงานให้เอเจนต์ ปล่อยให้มันทำงาน และให้คะแนนสิ่งที่มันทำ เป้าหมายคือการพิสูจน์สองสิ่ง: เอเจนต์ทำงานเสร็จสมบูรณ์อย่างถูกต้อง และเอเจนต์ทำงานอยู่ภายในขอบเขตที่กำหนดให้
ขั้นตอนแรกคือ การให้คะแนนผลลัพธ์ (grade the outcome) นี่เป็นขั้นตอนที่ง่ายที่สุดของกระบวนการประเมินผล สำหรับเอเจนต์ใบแจ้งหนี้ ซึ่งเป็นประเภทที่ฉันมักจะทำงานด้วย นั่นหมายถึงการตรวจสอบให้แน่ใจว่าใบแจ้งหนี้ไปอยู่ในที่ที่ถูกต้อง หรือรายการซ้ำถูกแจ้งเตือน คุณแค่เปรียบเทียบผลลัพธ์สุดท้ายกับสิ่งที่ควรจะเกิดขึ้น
ขั้นตอนที่สองคือ การให้คะแนนเส้นทาง (grade the trajectory) นี่คือเส้นทางที่เอเจนต์ใช้เพื่อไปถึงผลลัพธ์นั้น: เครื่องมือที่มันเรียกใช้ ฟิลด์ที่มันแตะต้อง อาร์กิวเมนต์ที่มันส่งผ่าน และการกระทำที่มันพยายามทำระหว่างทาง สิ่งนี้สำคัญเพราะเอเจนต์สามารถไปถึงคำตอบสุดท้ายที่ถูกต้องได้ในขณะที่ยังทำสิ่งที่อันตรายในกระบวนการ มันสามารถจัดประเภทใบแจ้งหนี้ได้อย่างถูกต้องในขณะที่เปลี่ยนรายละเอียดธนาคาร หรือส่งการชำระเงินก่อนได้รับการอนุมัติ
เส้นทางนั้นเป็นเพียงบันทึก (log): รายการตามลำดับของทุกเครื่องมือที่เอเจนต์เรียกใช้และอาร์กิวเมนต์ที่มันส่งผ่าน – การให้คะแนนมันก็แค่เขียนเช็คกับบันทึกนั้น
เช็คบางอย่างเป็นแบบ กำหนดตายตัว (deterministic) – ตรวจสอบให้แน่ใจว่า send_payment ไม่เคยปรากฏก่อนการเรียก approval ตรวจสอบว่าฟิลด์เดียวที่ถูกเขียนคือฟิลด์ที่เอเจนต์ได้รับอนุญาตให้เขียน เช็คอื่นๆ เป็นการ ตัดสิน (judgment) – เช่น การยกระดับปัญหาเหมาะสมหรือไม่ เหตุผลสมควรกับการกระทำหรือไม่ สิ่งเหล่านี้จะถูกส่งไปยังโมเดลที่สองพร้อมเกณฑ์การให้คะแนน (rubric)
หลักการทั่วไปที่ควรปฏิบัติตามคือ เช็คแบบกำหนดตายตัวมักจะจับการละเมิดด้านความปลอดภัย ในขณะที่โมเดลผู้ตัดสิน (judge model) จะให้คะแนนคุณภาพ
ผลลัพธ์คือคะแนนสองคะแนนต่อกรณีทดสอบหนึ่งกรณี: เอเจนต์ได้คำตอบที่ถูกต้องหรือไม่ และมันมีพฤติกรรมที่ถูกต้องระหว่างทางหรือไม่ สิ่งเหล่านี้ต้องรายงานแยกจากกัน เพราะเอเจนต์ที่จัดประเภทใบแจ้งหนี้ได้ถูกต้อง 95% ของเวลา แต่แตะต้องฟิลด์ต้องห้ามใน 4% ของรอบการทำงาน จะดูดีมากในคะแนนรวม แต่ก่อให้เกิดปัญหาทางธุรกิจครั้งใหญ่ในระบบผลิตจริง
บทความนี้ทำหน้าที่เป็นบทนำเกี่ยวกับการประเมินผลและหัวข้ออื่นๆ ที่ครอบคลุม ดังนั้นฉันจึงได้เชื่อมโยงแหล่งข้อมูลอื่นๆ เพื่อช่วยให้คุณเจาะลึกมากขึ้น นี่คือบางส่วนที่ช่วยให้ฉันเข้าใจวิธีสร้างการประเมินผลที่มีประสิทธิภาพ –
- คอร์สการประเมินผลของ Anthropic
- คู่มือการประเมินผลฉบับสมบูรณ์ของ Lenny
- คำถามที่พบบ่อยเกี่ยวกับการประเมินผลของ Hamel
ฉันแนะนำให้อ่านแต่ละอัน แต่เริ่มต้นด้วยของ Lenny และ Hamel ก่อน แล้วค่อยไปเรียนคอร์สการประเมินผล (ซึ่งจะลงมือปฏิบัติมากกว่าเล็กน้อย)
แต่การประเมินผลยังคงต้องมีเอเจนต์ให้ทดสอบ และทุกอย่างรอบๆ โมเดลต้องถูกสร้างโดยคุณ ระบบรอบข้างนั้นเรียกว่าสายรัด (harness) – ส่วนถัดไปจะครอบคลุมถึงวิธีคิดเกี่ยวกับแต่ละส่วนของกระบวนการวิศวกรรมสายรัด ตั้งแต่การเรียกใช้เครื่องมือไปจนถึงการปรับแต่งหน้าต่างบริบท (context window)
วิศวกรรมสายรัด (Harness Engineering)
โมเดลเพียงอย่างเดียวไม่ใช่เอเจนต์ โมเดลสามารถให้เหตุผล จัดประเภท เขียน และตัดสินใจได้ แต่มันไม่สามารถทำงานภายในบริษัทได้ด้วยตัวเอง มันสามารถบอกได้ว่าควรดำเนินการอะไร แต่ไม่สามารถดำเนินการนั้นอย่างปลอดภัยได้เว้นแต่คุณจะสร้างระบบรอบๆ มัน – และระบบนั้นคือสายรัด
สายรัดคือทุกสิ่งที่อยู่รอบๆ โมเดลที่เปลี่ยนการเรียก API ให้เป็นเอเจนต์ที่ทำงานได้: เครื่องมือที่มันใช้ได้ บริบทที่มันเห็น สถานะที่มันจดจำ ราวกั้นที่จำกัดมัน และลูปที่ปล่อยให้มันทำงานต่อไปจนกว่างานจะเสร็จ
ส่วนแรกของสายรัดคือการดำเนินการเครื่องมือ (tool execution)
โมเดลอ่านและเขียนได้เฉพาะข้อความ ดังนั้นเมื่อโมเดลตัดสินใจจะทำอะไรบางอย่าง มันไม่ได้ดำเนินการจริงๆ มันจะปล่อยคำขอที่มีโครงสร้าง (สตริง JSON) เพื่ออัปเดตเรกคอร์ด หรือส่งอีเมล หรือค้นหาฐานข้อมูล
สายรัดรับคำขอนั้น ตรวจสอบความถูกต้อง ดำเนินการจริง และส่งผลลัพธ์กลับไปยังโมเดลเป็นข้อความ
ส่วนที่สองคือการจัดการบริบท (context management) ทุกคำสั่ง เมนูเครื่องมือ ผลลัพธ์ของเครื่องมือ และข้อความก่อนหน้า ล้วนกินพื้นที่ในหน้าต่างบริบทของโมเดล สายรัดต้องตัดสินใจว่าโมเดลจำเป็นต้องเห็นอะไรในตอนนี้ สิ่งใดควรถูกสรุป และสิ่งใดควรถูกลบออก หากไม่มีสิ่งนี้ เอเจนต์จะหลงทางในประวัติศาสตร์ที่ไม่เกี่ยวข้อง
ฉันจะเขียนบทความที่ครอบคลุมมากขึ้นซึ่งเจาะลึกในแต่ละส่วนของกระบวนการพัฒนาสายรัด แต่สำหรับตอนนี้ ฉันแนะนำให้ฟังการบรรยายนี้โดยวิศวกรจาก Arize ซึ่งเป็นแพลตฟอร์มการเรียนรู้อย่างต่อเนื่องสำหรับเอเจนต์ ที่เจาะลึกกระบวนการคิดของพวกเขาเกี่ยวกับ การจัดการบริบท
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการประยุกต์ใช้การจัดการบริบทที่มีประสิทธิภาพกับเอเจนต์ของคุณในทางปฏิบัติ ให้อ่านบล็อกเหล่านี้:
ส่วนที่สามในวิศวกรรมสายรัดคือสถานะและความจำ (state and memory) โมเดลไม่มีสถานะ (stateless) ระหว่างการเรียก ดังนั้นทุกสิ่งที่เอเจนต์ต้องจำต้องอยู่ภายนอกโมเดล (โดยปกติอยู่ในฐานข้อมูล ที่เก็บไฟล์ หรือเรกคอร์ดงาน) บริบทคือสิ่งที่โมเดลกำลังมองอยู่ในขณะนี้ สถานะคือทุกสิ่งที่เอเจนต์รู้แต่ไม่ได้กำลังมองอยู่ในขณะนี้
ส่วนที่สี่คือราวกั้น (guardrails) เนื่องจากโมเดลสามารถขอการกระทำที่ผิดด้วยความมั่นใจเท่ากับการกระทำที่ถูก สายรัดจึงต้องตรวจสอบสิทธิ์ ตรวจสอบความถูกต้องของอินพุต ป้องกันการกระทำที่ไม่ปลอดภัย และส่งต่อขั้นตอนที่มีความเสี่ยงสูงไปยังมนุษย์
สุดท้าย ทั้งหมดนี้ถูกผูกเข้าด้วยกันในลูปของเอเจนต์: สร้างบริบท เรียกโมเดล ตรวจสอบการตอบสนอง ดำเนินการเครื่องมือหากได้รับอนุญาต เก็บผลลัพธ์ อัปเดตบริบท และทำซ้ำจนกว่างานจะเสร็จ
วิศวกรรมสายรัดเป็นส่วนใหญ่ของสิ่งที่คุณจะทำในฐานะวิศวกร AI ประยุกต์ ดังนั้นใช้เวลากับส่วนนี้ให้มาก ในฐานะวิศวกร AI ประยุกต์ งานทั้งหมดของคุณคือการสร้างสภาพแวดล้อมการทำงานที่ทำให้ระบบความน่าจะเป็นสามารถทำงานภายในซอฟต์แวร์ที่กำหนดตายตัวได้
แต่โดยปกติแล้วระบบผลิตจริงไม่ได้หยุดอยู่ที่เอเจนต์ตัวเดียว
เมื่อเวิร์กโฟลว์ใหญ่ขึ้น สัญชาตญาณตามธรรมชาติคือการแบ่งงาน แต่เมื่อคุณเพิ่มเอเจนต์ตัวที่สอง การออกแบบระบบจะเปลี่ยนไป
ด้วยเอเจนต์ตัวเดียว ความซับซ้อนส่วนใหญ่อยู่ภายในลูปเดียว ด้วยเอเจนต์หลายตัว ตอนนี้คุณมีหลายลูปที่ทำงานในสภาพแวดล้อมเดียวกัน แต่ละเอเจนต์อาจอ่านสถานะที่เอเจนต์อื่นเพิ่งเปลี่ยนไป เขียนไปยังหน่วยความจำที่เอเจนต์อื่นต้องพึ่งพา หรือเรียกใช้เครื่องมือซึ่งผลลัพธ์ส่งผลกระทบต่อเวิร์กโฟลว์ทั้งหมด
ณ จุดนี้ ส่วนที่ยากไม่ใช่แค่การเขียน prompt การประเมินผล หรือการออกแบบสายรัดอีกต่อไป มันกลายเป็นปัญหาของระบบกระจาย: ใครเป็นเจ้าของสถานะใด ใครสามารถเขียนไปยังหน่วยความจำได้ เครื่องมือใดที่ปลอดภัยที่จะลองใหม่ และจะเกิดอะไรขึ้นเมื่อเอเจนต์ที่สมเหตุสมผลสองตัวดำเนินการในลำดับที่ผิด
การปรับใช้หลายเอเจนต์คือปัญหาของระบบกระจาย
เมื่อเอเจนต์ตัวแรกทำงานได้และเวิร์กโฟลว์ใหญ่ขึ้น วิศวกร AI ประยุกต์มือใหม่มักจะมีสัญชาตญาณในการแบ่งงานออกเป็นบทบาท: เอเจนต์หนึ่งค้นคว้า หนึ่งวางแผน หนึ่งดำเนินการ หนึ่งตรวจสอบ
แต่เอเจนต์ตัวที่สองเปลี่ยนหน่วยการออกแบบจากเอเจนต์เป็นระบบ ตอนนี้หลายลูปทำงานในสภาพแวดล้อมเดียวกัน – เอเจนต์หนึ่งสามารถอัปเดตสถานะลูกค้าในขณะที่อีกตัวกำลังเขียนแผนโดยอิงจากสถานะที่ล้าสมัย ทั้งคู่ตัดสินใจอย่างสมเหตุสมผล แต่ระบบปล่อยให้การตัดสินใจเหล่านั้นมีปฏิสัมพันธ์ในลำดับที่ผิด
นี่คือปัญหาของระบบกระจาย ข่าวดีคือวิศวกรระบบกระจายได้แก้ไขความล้มเหลวเหล่านี้มานานหลายทศวรรษแล้ว งานของคุณคือการนำไปประยุกต์ใช้กับลูปที่บังเอิญมี LLM อยู่ข้างใน ด้านล่างนี้คือรายการวิธีแก้ปัญหาจากระบบกระจายที่นำไปใช้กับวิศวกรรม AI:
หลักการเขียนโดยผู้เดียว (Single-writer principle) ทุกสถานะที่สำคัญจะมีเอเจนต์เพียงตัวเดียวที่สามารถเขียนลงไปได้ – เอเจนต์อื่นๆ อ่านจากมันหรือส่งคำขอเปลี่ยนแปลง บังคับใช้สิ่งนี้ในระดับเครื่องมือ: ถ้าเอเจนต์ดำเนินการเป็นตัวเดียวที่สามารถเขียนไปยัง CRM ได้ เอเจนต์ค้นคว้าก็จะไม่สามารถทำให้ CRM เสียหายได้ไม่ว่ามันจะให้เหตุผลได้แย่แค่ไหนก็ตาม
คีย์ความเท่าเทียม (Idempotency keys) เอเจนต์จะลองเรียกเครื่องมือใหม่เมื่อมีบางอย่างล้มเหลวหรือหมดเวลา แต่การลองใหม่อาจเป็นอันตรายเมื่อเครื่องมือเปลี่ยนแปลงบางอย่างในโลกแห่งความเป็นจริง คุณไม่ต้องการให้เอเจนต์ส่งการชำระเงินเดียวกันสองครั้งเพียงเพราะคำขอแรกดูเหมือนว่าจะล้มเหลว วิธีแก้ไขคือการแนบคีย์ที่ไม่ซ้ำกันกับการเรียกเครื่องมือทุกครั้งที่เปลี่ยนแปลงข้อมูล (mutating tool call) ซึ่งหมายถึงการกระทำใดๆ ที่เปลี่ยนแปลงข้อมูลในระบบภายนอก หากเครื่องมือเห็นคีย์เดียวกันอีกครั้ง มันควรส่งคืนผลลัพธ์เดิมแทนที่จะดำเนินการอีกครั้ง API ของ Stripe ทำงานแบบนี้ – และมันนำไปใช้กับการพัฒนาเอเจนต์เมื่อต้องจัดการกับการชำระเงิน อีเมล ฯลฯ
เงื่อนไขเบื้องต้นในการเขียน (Preconditions on writes) เอเจนต์มักจะดำเนินการตามมุมมองโลกที่เก่า อาจมีบางอย่างเปลี่ยนแปลงไประหว่างเวลาที่เอเจนต์วางแผนกับเวลาที่มันพยายามอัปเดตระบบภายนอก เพื่อป้องกันการเขียนที่ล้าสมัย เครื่องมือที่เปลี่ยนแปลงข้อมูลควรกำหนดเงื่อนไขก่อนที่จะทำการเปลี่ยนแปลง ตัวอย่างเช่น: "ตั้งค่าสถานะเป็น 'อนุมัติแล้ว' ก็ต่อเมื่อยังเป็น 'รอดำเนินการ' อยู่" หากสถานะเปลี่ยนแปลงไปแล้ว เครื่องมือควรล้มเหลวอย่างชัดเจนแทนที่จะเขียนทับสถานะที่ใหม่กว่าอย่างเงียบๆ
การส่งมอบงานอย่างชัดเจน (Explicit hand-offs) ส่งงานเป็นข้อความที่มีโครงสร้างที่กำหนดไว้ (schema) โดยเรียงลำดับโดยผู้ประสานงาน (orchestrator) เอเจนต์ควรได้รับงานของมัน ไม่ใช่ค้นพบมันเอง
สรุปโดยย่อ (TLDR)
บทความนี้ทำหน้าที่เป็นภาพรวมของหัวข้อที่สำคัญที่สุดที่ฉันได้เรียนรู้ในฐานะวิศวกร AI ประยุกต์: การประเมินผล วิศวกรรมสายรัด และการออกแบบระบบหลายเอเจนต์
ถ้าคุณจะจำอะไรได้จากบทความนี้ ก็ขอให้เป็นสิ่งนี้ – โมเดลให้ความฉลาด แต่ทุกสิ่งที่ทำให้มันเชื่อถือได้ (ชั้นการวัดผล สภาพแวดล้อมการทำงาน กฎการประสานงาน) ล้วนถูกออกแบบโดยคุณ เข้าใจสิ่งเหล่านี้ แล้วการเปลี่ยนผ่านจากวิศวกรรมซอฟต์แวร์จะกลายเป็นเพียงการต่อยอดทักษะที่คุณมีอยู่แล้ว
ถ้าคุณสนใจงานประเภทนี้และต้องการร่วมทีมเพื่อจัดการกับปัญหาที่น่าสนใจที่สุดบางอย่างในด้าน AI ประยุกต์ร่วมกับทีมวิศวกรที่มีความสามารถมาก เรากำลังรับสมัครงานอยู่เสมอ สมัครได้ที่เว็บไซต์ของเรา varickagents.com และเราอาจให้คุณเริ่มงานได้เร็วที่สุดเท่าที่จะเป็นไปได้ ในทางกลับกัน ถ้าคุณแนะนำผู้สมัครที่ผ่านการคัดเลือก เราจะให้ค่าตอบแทนแนะนำ 20,000 ดอลลาร์
