การทำให้การประเมินผล AI Agent เป็นระบบอัตโนมัติ: Eval Engineering Skill จาก LangChain

วันนี้เรากำลังเปิดตัว Eval Engineering Skill ซึ่งเป็นทักษะที่ช่วยให้ coding agents สร้าง evals โดยใช้บริบทจาก repository และ traces ของ agent

ทักษะนี้จะตรวจสอบว่า agent ถูกสร้างขึ้นมาอย่างไร ขุดรูปแบบจาก traces (ถ้ามี) และเสนอความสามารถที่ควรทดสอบ

ทักษะนี้ถูกออกแบบมาเพื่อสัมภาษณ์ผู้ใช้ ซึ่งสามารถให้ข้อเสนอแนะเกี่ยวกับข้อเสนอแนะและอนุมัติแต่ละ eval อย่างค่อยเป็นค่อยไป ผลลัพธ์ที่ได้คือชุดของ evals ที่สามารถทำงานได้ในรูปแบบ Harbor

การสร้างสภาพแวดล้อมและงาน (Task)

ทักษะจะอ่าน repository ก่อนและทำแผนที่พื้นผิวของ agent รวมถึง prompts, models, tools, skills, hooks ฯลฯ นอกจากนี้ยังระบุข้อมูลและบริการที่สนับสนุนพฤติกรรมเหล่านั้น เช่น การเรียก API

ผู้ใช้ยังสามารถชี้ agent ไปยัง traces ซึ่งสามารถดึงมาได้โดยใช้เครื่องมือเช่น langsmith-cli Traces แสดงให้เห็นว่า tools ทำงานอย่างไรในทางปฏิบัติ เช่น อาร์กิวเมนต์ ผลลัพธ์ และข้อผิดพลาด สัญญาที่สังเกตได้เหล่านี้ช่วยให้ทักษะสามารถจำลองพฤติกรรมการผลิตที่เกี่ยวข้องในสภาพแวดล้อมที่ควบคุมได้

การคลานไปทั่ว repo และ traces ทำให้ agent มีความรู้ว่าความสามารถใดที่สำคัญสำหรับ agent ขณะที่มันเสนอ eval tasks เราพบว่า การสัมภาษณ์ผู้ใช้ นำไปสู่การยอมรับ eval ที่ดีกว่าการสร้างแบบครั้งเดียว (one-shot generation) ผู้ใช้เลือกจากทิศทางของ eval ที่เสนอ และให้คำแนะนำเกี่ยวกับคำถาม เช่น ควรใช้ tools และ dependencies ใดแบบสด หรือต้องจำลอง ตัวอย่างเช่น การเรียก tool ที่มีค่าใช้จ่ายหรือต้องเขียนลงใน production สามารถจำลองแทนที่จะรันทุกครั้งที่มีการเรียก eval

เราทดสอบโฟลว์นี้กับ agent ตอบคำถามเอกสารของเรา chat-langchain สำหรับ agent นี้ สภาพแวดล้อมต้องการคลังข้อมูลที่เปิดเผยผ่านเครื่องมือค้นหาของ agent ซึ่งจำลองตาม agent ที่ใช้งานจริง งานต่างๆ รวมถึงคำถามเอกสารที่สมจริงซึ่งดึงมาจาก traces จริง และตัวตรวจสอบที่ตรวจสอบคำตอบโดยใช้สตริงคำตอบทองคำและเอกสารที่อ้างอิง

การออกแบบ Eval เป็นแบบวนซ้ำ

เราพบว่าในขณะที่ agent บางครั้งสามารถสร้าง evals แบบครั้งเดียวได้ แต่ evals ที่ดีที่สุดมาจากผู้ใช้ที่ให้ข้อเสนอแนะและระบุว่าความสามารถใดที่ควรวัดใน agent Coding agents และทักษะเป็นอินเทอร์เฟซที่เป็นธรรมชาติซึ่งความรู้เกี่ยวกับวิธีการสร้าง eval ที่ดีถูกเข้ารหัส และผู้ใช้สามารถวนซ้ำได้เรื่อยๆ

ตัวอย่างเช่น เราพบว่าเมื่อสร้างตัวตรวจสอบ ตัวตรวจสอบแรกแทบจะไม่ใช่ตัวสุดท้าย วิธีที่มีประโยชน์ในการปรับปรุงคือการรัน eval และตรวจสอบทั้งสองด้านของผลลัพธ์:

เส้นทางของ agent รวมถึงข้อความ การเรียก tool และการกระทำ
เส้นทางของตัวตรวจสอบ หลักฐาน การให้เหตุผล และคะแนนสุดท้าย

สิ่งนี้ช่วยเปิดเผยว่างานหรือการออกแบบตัวตรวจสอบวัดสิ่งที่เราใส่ใจหรือไม่ หรืออาจถูก reward hacked ซึ่ง agent สามารถใช้ทางลัดได้ ทางลัดเหล่านี้อาจรวมถึงการอ้างอิงแหล่งที่มาที่ไม่เกี่ยวข้องมากเกินไปเพื่อรับคะแนนเต็มใน eval การอ้างว่าทำสิ่งที่ไม่ได้ทำ การใช้ประโยชน์จากเนื้อหาคำตอบที่ถูกเปิดเผย หรือการทำให้ proxy พอใจโดยไม่ต้องทำงานให้เสร็จ การสังเกต traces ว่า agent แก้ปัญหาอย่างไร มักจะเผยให้เห็นที่มาของความล้มเหลวเหล่านี้ จากนั้นสามารถแก้ไขงาน สภาพแวดล้อม และตัวตรวจสอบ และรันอีกครั้งได้

Evals อยู่ในรูปแบบ Harbor

ทักษะสร้าง evals เป็น Harbor tasks:

คำสั่ง (Instruction): ข้อความที่มอบให้กับ agent ในตอนเริ่มต้นที่อธิบายงาน
สภาพแวดล้อม (Environment): กำหนดเป็น Dockerfile ที่ประกอบด้วยการตั้งค่าสำหรับงาน เช่น เครื่องมือที่จะติดตั้งหรือข้อมูลที่จะใส่ใน filesystem
ตัวตรวจสอบ (Verifier) ที่ให้คะแนนว่า agent ทำงานเสร็จสมบูรณ์อย่างถูกต้องหรือไม่

ทักษะสร้างส่วนประกอบเหล่านี้ร่วมกันเป็น Harbor task:

markdown

1evals/<task-id>/
2├── task.toml
3├── instruction.md
4├── environment/
5└── tests/

Harbor รัน agent ในสภาพแวดล้อมและบันทึกเส้นทาง สิ่งประดิษฐ์ (artifacts) รางวัล และข้อผิดพลาด eval เดียวกันสามารถรันกับ models, prompts, tools และ agent versions ที่แตกต่างกันได้

เหตุใดสิ่งนี้จึงสำคัญ

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

Evals คือข้อมูลการฝึกอบรมสำหรับ agent ทีมงานสามารถปรับพฤติกรรมของ agent ให้เข้ากับ evals ผ่านวิศวกรรม harness เช่น การเปลี่ยน prompts และ tools หรือการ fine-tuning eval เป็นเป้าหมายที่คงที่สำหรับการตัดสินใจว่าการเปลี่ยนแปลงเหล่านั้นปรับปรุงความสามารถที่ตั้งใจไว้หรือไม่

Evals ในรูปแบบ containerized ทำให้กระบวนการนี้เร็วขึ้น งานและสภาพแวดล้อมยังคงที่ในขณะที่การกำหนดค่า agent เปลี่ยนแปลง ดังนั้นผู้สร้างสามารถสลับ models, tools, prompts หรือ agent versions ทั้งหมดและเปรียบเทียบผลลัพธ์ได้โดยตรง การกำหนดค่าหลายอย่างสามารถทำงานพร้อมกันได้

สภาพแวดล้อมที่ทำซ้ำได้มีความสำคัญต่อสัญญาณนั้น เมื่อ eval สะท้อนเครื่องมือ ข้อมูล สิทธิ์ สถานะ และโหมดความล้มเหลวที่เกี่ยวข้องจากการผลิต ผู้สร้างจะได้ testbed ที่เสถียรซึ่งยังคงเป็นตัวแทนของการทำงานของ agent พวกเขาสามารถทดลองได้อย่างรวดเร็วโดยไม่ต้องพึ่งพาระบบการผลิตที่เปลี่ยนแปลงหรือเขียนลงในสถานะการผลิต

ลูปที่ได้คือ:

ขุด traces -> ระบุข้อผิดพลาด -> สร้าง eval -> ปรับปรุง agent -> รันอีกครั้ง

ลองใช้วันนี้

Eval Engineering Skill มีอยู่ใน langchain-ai/langchain-skills repository

ติดตั้งทักษะใน Codex หรือ Claude Code เปิด repository ที่มี agent ที่คุณต้องการประเมิน ชี้ agent ไปยังชุดของ traces (ถ้ามี) และเริ่มต้นด้วย prompt ง่ายๆ:

เราหวังว่าจะขยายทักษะนี้และสร้างเครื่องมือเพื่อให้การสร้าง evals โดยอัตโนมัติและการปรับ agent ให้เข้ากับ evals เหล่านั้นทำได้ง่ายขึ้น