05 ปิดวงจรการปรับปรุง

เอกสารประกอบสำหรับวิทยากรคู่กับ 05 ปิดวงจรการปรับปรุง

เวลา

รวม ~25 นาที

• 5 นาที — สร้างและส่งเสริมบันทึกทั้งสามรายการที่ได้จากการใช้งานจริงขึ้นเป็นข้อมูลอ้างอิง
• 5 นาที — เริ่มการทดลอง policy-v1 และ policy-v2 ที่จับคู่กัน
• 5 นาที — เปรียบเทียบความถูกต้องและสอบเทียบ business-policy-adherence
• 5 นาที — เปิดใช้งานกฎการสังเกต (observation rule) ที่มีการป้องกัน และเล่นซ้ำเมตริกสี่ประเภท
• 5 นาที — ตรวจสอบหลักฐาน อภิปรายเรื่องการย้อนกลับ (rollback) ต้นทุน และวงรอบฟีดแบ็กถัดไป

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

การตรวจสอบเตรียมความพร้อมของผู้สอน

รันคำสั่งตรวจสอบที่ไม่ก่อผลกระทบเหล่านี้จากรูทของแล็บ และยืนยันว่ามีการกำหนดค่าที่เลือกไว้ ก่อนเริ่มเซสชัน:

cd ClickHouse_Demos/workshops/agent_arena
.venv/bin/python -m scripts.promote_to_golden --help
.venv/bin/python -m scripts.provision_online_evaluators --help
.venv/bin/python -m eval.harness --help
.venv/bin/python -m scripts.verify_online_scores --help

จากนั้นยืนยันว่า:

• โมดูล 03 มี chat_turn รูทที่เชื่อถือได้เพียงหนึ่งรายการ พร้อมด้วย sql-execution-success=true และ Boolean user-thumbs=false;
• งานคำอธิบายประกอบแบบ UI-only production-investigation-<session> ของโมดูล 04 เสร็จสมบูรณ์แล้ว SQL ที่แก้ไขแล้วถูกดำเนินการจริง Trace ID จริงพร้อมใช้งานแบบเป็นการภายใน และรหัสงานคำอธิบายประกอบถูกบันทึกไว้เมื่อ Langfuse เปิดเผยรหัสนั้น;
• reviewed.json จะถูกสร้างขึ้นจากการทบทวนจริงนั้น และไม่ใช่ fixture สังเคราะห์ที่ถูกเก็บไว้ใน repository;
• WINNER_MODEL, WINNER_PROMPT, และ WINNER_CONFIG_ID ทั้งหมดล้วนบรรยายถึงผู้ชนะห้องเดียวกัน;
• การเชื่อมต่อ LLM ของ Langfuse ที่ชื่อ agent-arena-openrouter เข้าถึงโมเดลผู้พิพากษาที่กำหนดค่าไว้ได้ และมีข้อมูลรับรองที่ใช้งานได้;
• เอาต์พุตหมวดหมู่แบบมีโครงสร้างของผู้พิพากษายอมรับค่าได้เพียง PASS, FAIL, และ NOT_APPLICABLE พร้อมด้วยคำอธิบายเหตุผล; และ
• ตัวจัดสรรงานของผู้ประเมิน (evaluator dispatcher) ทำงานปกติ และห้องสามารถรับคะแนนแบบอะซิงโครนัสได้

สำหรับการซักซ้อมทุกครั้ง ให้สร้างส่วนต่อท้าย (suffix) ที่ไม่ซ้ำกันหนึ่งชุด และเก็บคู่ baseline/candidate ไว้ด้วยกัน:

export LOOP_RUN_SUFFIX="$(date +%Y%m%d-%H%M%S)"
export BASELINE_RUN_ID="online-loop-baseline-${LOOP_RUN_SUFFIX}"
export CANDIDATE_RUN_ID="online-loop-candidate-${LOOP_RUN_SUFFIX}"

อย่านำ run ID จากเซสชันก่อนหน้ามาใช้ซ้ำ harness จะต่อท้าย policy version และ configuration เข้ากับ ID ฐาน และ ID ฐานที่ไม่ซ้ำกันจะช่วยป้องกันไม่ให้ผู้เรียนเปรียบเทียบหลักฐาน ที่ไม่เกี่ยวข้องกันหรือถูกเขียนทับไปบางส่วน

ขอบเขตของคำอธิบายประกอบแบบมนุษย์

คำอธิบายประกอบโดยมนุษย์ในโมดูล 04 ถูกออกแบบให้เป็นขั้นตอนที่ต้องทำด้วยตนเอง สคริปต์รันไทม์จะไม่สร้างคิว ไม่กรอกคำตัดสินของมนุษย์ ไม่ป้อนเอาต์พุตที่แก้ไขแล้ว ไม่อนุมัติรายการ และไม่ปิดงานให้เสร็จ ผู้สอนอาจใช้ฟิกซ์เจอร์สังเคราะห์ที่ติดตามไว้ ในระบบควบคุมเวอร์ชันเพื่อซักซ้อมเมื่อยังไม่มีผลการทบทวนจริง แต่ฟิกซ์เจอร์นี้จะยังระบุ source=synthetic-reviewed-fixture จึงไม่ใช่หลักฐานว่าวงรอบคำอธิบายประกอบโดยมนุษย์ เสร็จสมบูรณ์แล้ว

สำหรับเส้นทางของผู้เรียน ให้ใช้ reviewed.json ที่ถูก ignore ไว้ของแท้จริง ถ้อยคำดั้งเดิม เป็นคำถามฟีดแบ็กจากผู้ใช้จริงหนึ่งข้อ ส่วนอินพุตที่แน่นอนอีกสองข้อเป็นถ้อยคำที่ผู้ตรวจทานเขียน ขึ้นใหม่ (paraphrase) โดยอ้างอิงจากเหตุการณ์ที่ถูกทบทวนนั้น:

How many active customers do we have?
What is our active customer count right now?
How many customers qualify as active under our business definition?

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

ความน่าเชื่อถือของการส่งเสริมขึ้นเป็นข้อมูลอ้างอิงและที่มาของข้อมูล (provenance)

ก่อนให้ห้องรันการส่งเสริม (promotion) ให้ตรวจสอบ reviewed.json โดยไม่ต้อง project ข้อมูล มันต้องมี SQL แบบอ่านอย่างเดียว (read-only) ที่แก้ไขถูกต้องตรงตามที่กำหนด มีที่มาการใช้งานจริง (production provenance) ตามที่จำเป็น และมี ID ที่ปลอดภัยไม่ซ้ำกันสามรายการ การส่งเสริมจะตรวจสอบ ความถูกต้องของ batch ท้องถิ่นทั้งหมดก่อน จากนั้นจึงทำการอ่าน metadata แบบยืนยันตัวตนก่อนที่จะ รัน ClickHouse หรือ upsert dataset การส่งเสริมจะ fail closed เมื่อไม่สามารถอ่าน metadata ได้ และจะปฏิเสธ ID ที่ชนกันหากมีที่มาการใช้งานจริงของแท้ที่แตกต่างกัน

การส่งเสริมของแท้ที่เหมือนกันทุกประการเป็น idempotent ส่วน fixture สังเคราะห์ต้องใช้ flag --synthetic-fixture อย่างชัดแจ้ง ไม่สามารถส่งเป็น path ตรงหรือใช้ร่วมกับ reviewed.json ได้ อย่ารันมันหลังจากการส่งเสริมของแท้แล้ว หากมีการรายงานว่าเกิดการชนกัน ให้เก็บรักษาแหล่งข้อมูลทั้งสองไว้ ตรวจสอบรายการ dataset ที่มีอยู่แล้ว และเลือก ID ใหม่ที่ผ่าน การตรวจสอบแล้วเท่านั้นเมื่อรายการทั้งสองเป็นตัวแทนของกรณีที่ถูกทบทวนซึ่งแตกต่างกันอย่างแท้จริง

กฎของ Experiment เทียบกับกฎของ Observation

ให้ทั้งสองบริบทนี้มองเห็นได้บนสไลด์หรือไวท์บอร์ด:

ตัว provisioner จะติดตั้งตัวประเมิน (evaluator) ที่ขับเคลื่อนด้วย catalog ทั่วไปเพียงตัวเดียว ไม่ใช่ตัวประเมินที่รองรับเฉพาะจำนวนลูกค้าเท่านั้น catalog policy-v2 ของมันครอบคลุมลูกค้าที่ active อยู่ รายได้ conversion จากการดูสู่การซื้อ และ gross margin คำถามที่ไม่เกี่ยวข้องควรได้ NOT_APPLICABLE

เฟส --business-policy-experiments ต้องรายงาน online rule enabled=False ให้ตรวจสอบใน Langfuse rule UI เป็นการป้องกันชั้นที่สอง คำสั่ง enable ในขั้นถัดไปพิสูจน์ได้เพียงว่ามีคะแนน business-policy-adherence ที่ผูกกับ dataset อยู่อย่างน้อยหนึ่งรายการ แต่ไม่สามารถทดแทนการทบทวนสอบเทียบแบบเต็มรูปแบบของผู้สอนได้

ประตูการสอบเทียบ

เปรียบเทียบ baseline และ candidate บน item ID โมเดล และ prompt เดียวกัน repo มีคำถาม YAML 20 ข้อ แต่ q019 และ q020 เป็น few-shot holdout ดังนั้นโปรเจกต์ที่สะอาดเริ่มด้วย Experiment item 18 รายการ และเป็น 21 หลังโปรโมตสามรายการ โปรเจกต์ร่วมที่ใช้ยืนยันมี 22 รายการเพียงเพราะยังเก็บ approved item เก่าที่ไม่เกี่ยวข้องหนึ่งรายการไว้; การรันคู่ล่าสุด เปลี่ยนจาก 16/22 เป็น 19/22 ให้ถือว่านี่เป็นหลักฐานที่มีเงื่อนไข ไม่ใช่จำนวน item ที่ learner ต้องได้หรือคำสัญญาว่าผู้ให้บริการที่มีความสุ่ม (stochastic) จะได้ผลรวมเดิมทุกครั้ง

อย่าเปิดใช้งานเว้นแต่ประตูทั้งหมดต่อไปนี้ผ่าน:

• กรณี prod-active-* ทั้งสามกรณีเปลี่ยนจาก FAIL และไม่ถูกต้องภายใต้ policy-v1 เป็น PASS และถูกต้องภายใต้ policy-v2;
• รายได้ของ candidate (q005) และ conversion (q018) เป็น PASS;
• การนับแบบธรรมดา (q001) เป็น NOT_APPLICABLE;
• correctness ของทุก item ที่มีอยู่ก่อนแล้วถูกเปรียบเทียบเป็นรายการ และไม่มีการถดถอย จาก 1→0;
• ความถูกต้องโดยรวมไม่ถดถอย; และ
• ทุก Experiment item มี correctness, agent-arena-llm-judge, และคะแนน business-policy-adherence ที่ตรงตามชื่อจริง พร้อมเอาต์พุตแบบมีโครงสร้างที่ถูกต้อง

ผู้พิพากษาที่ให้ทุกการนับเป็น PASS ถือว่าล้มเหลวในการสอบเทียบ แม้ candidate จะดูดีก็ตาม ให้ใช้การทดสอบ NOT_APPLICABLE เพื่อแสดงว่าการพิจารณาความเกี่ยวข้องกับนโยบายเป็นขั้นตอนการจัด หมวดหมู่จริง ๆ

การให้คะแนนแบบอะซิงโครนัสและการแก้ปัญหาเมื่อไม่มีคะแนน

การประเมินทั้งสำหรับ Experiment และ Observation เป็นแบบอะซิงโครนัสทั้งคู่ harness จะรอ คะแนนของ Experiment ที่จำเป็นให้ครบ ในขณะที่ scripts.verify_online_scores จะ poll คะแนน ของ trace แบบสดเป็นเวลา 180 วินาทีตามค่าเริ่มต้น อย่ารีเฟรชถี่ ๆ อย่าสร้างกฎขึ้นใหม่ และ อย่า enable ก่อนกำหนดเพียงเพราะคะแนนยังอยู่ในสถานะ pending

หากคะแนนไม่ปรากฏขึ้น:

1. ยืนยันชื่อที่คาดหวังให้ตรงเป๊ะ Experiment ใช้ business-policy-adherence; observation ที่ให้บริการอยู่ใช้ agent-arena-business-policy-online
2. ยืนยันว่าตัวจัดสรรงาน/execution worker ของผู้ประเมินทำงานปกติ
3. ตรวจสอบการเชื่อมต่อ agent-arena-openrouter และความพร้อมใช้งานของโมเดลผู้พิพากษา ความล่าช้าของผู้ให้บริการ การจำกัด rate limit หรือข้อจำกัดในการ routing อาจทำให้การ ประเมิน pending หรือล้มเหลวได้ แม้ว่าการตอบกลับของ agent จะสำเร็จแล้วก็ตาม
4. ยืนยันว่ากฎของ Experiment เล็งไปที่ dataset arena-golden และกฎของ Observation เล็งไปที่ observation ราก chat_turn การ mapping ต้อง expose $.question และ $.sql
5. ตรวจสอบเอาต์พุตแบบมีโครงสร้าง หมวดหมู่ที่ขาดหายไป หมวดหมู่ที่อยู่นอกเหนือสามค่าที่ อนุญาต หรือการไม่มีคำอธิบายเหตุผล ถือเป็นความล้มเหลวในการสอบเทียบ
6. หากการ provisioning รายงานว่าพบชื่อกฎที่คลุมเครือ (ambiguous) ให้หยุด และแก้ปัญหา ชื่อกฎที่ซ้ำกันเป๊ะใน Langfuse ก่อนลองใหม่ อย่าเดาว่ากฎตัวใดที่ซ้ำถูกอัปเดตไปแล้ว

รักษา trace ที่ล้มเหลวและหลักฐานของผู้ประเมินไว้ อย่าเปลี่ยนการล่มของผู้ให้บริการให้กลายเป็น PASS ที่ปลอมขึ้น หรือข้ามประตูตรวจ "ไม่มีคะแนน" ไป

แนวทางการเล่นซ้ำ (Replay)

หลังจากเปิดใช้งานแล้ว ให้รีสตาร์ทการให้บริการอย่างชัดเจนด้วย policy-v2 และใช้คำถาม สี่ข้อที่แน่นอนของผู้เรียน:

How many active customers do we have?
What was revenue in the last 30 days?
What is our view-to-purchase conversion rate for the last 7 days?
How many products are there?

ต้องได้ความสำเร็จเชิงปฏิบัติการ (operational success) สำหรับทุก trace ลูกค้าที่ active รายได้ และ conversion ต้องมี agent-arena-business-policy-online=PASS; ส่วนจำนวนสินค้า ต้องเป็น NOT_APPLICABLE

คำขอ conversion มีขอบเขตความสุ่ม (stochastic boundary) ที่ได้รับการยืนยันแล้ว อนุญาตให้ลองใหม่ ได้อย่างมากหนึ่งครั้งโดยใช้ config เดียวกัน เก็บรักษา trace ID และผลลัพธ์ของทั้งสองครั้งไว้ และ หยุดหากไม่มีครั้งใดผ่านเลย ความล้มเหลวซ้ำ ๆ คือหลักฐานการใช้งานจริงชิ้นใหม่ที่ต้องสืบสวน ไม่ใช่เหตุผลให้วนลูปจนกว่าจะได้ผลผ่าน

การสุ่มตัวอย่าง ต้นทุน และความน่าเชื่อถือ

กฎของเวิร์กช็อปใช้การสุ่มตัวอย่าง (sampling) ที่ 1 เพื่อให้ทุก trace ที่เข้าเกณฑ์สร้างหลักฐาน ที่มองเห็นได้ ในปริมาณการใช้งานจริง การให้ LLM ผู้พิพากษาตัดสินทุกคำขอจะเพิ่มต้นทุนของผู้ให้ บริการ ใช้ rate limit และอาจสร้างคะแนนหลังจากที่ตอบกลับผู้ใช้ไปแล้ว ให้เลือก sampling โดยพิจารณาจากปริมาณการใช้งาน ความเสี่ยงของเหตุการณ์ ต้นทุน/latency ของผู้ประเมิน และความ ครอบคลุมที่จำเป็น คงการตรวจสอบเชิงปฏิบัติการแบบ deterministic ให้ครอบคลุมกว้าง ๆ และสำรอง การตัดสินเชิงความหมาย (semantic judgment) ที่มีราคาแพงไว้สำหรับ traffic และเมตริกที่คุ้มค่า ต้นทุนนั้นจริง ๆ

ตัวประเมินทำหน้าที่เฝ้าติดตาม (monitoring) ไม่ใช่การอนุมัติในเส้นทางคำขอ (request-path authorization) ผู้พิพากษาที่ล่าช้าต้องไม่ปิดกั้นการตอบกลับของการให้บริการโดยไม่รู้ตัว ให้ส่งคะแนนที่ขาดหายไป การเลื่อนของหมวดหมู่ (category drift) และสัญญาณที่ไม่สอดคล้องกันไป ยังการแจ้งเตือนเชิงปฏิบัติการหรือ backlog สำหรับการทบทวน ตามวัตถุประสงค์ระดับการให้บริการ (service-level objectives) ของระบบ

การย้อนกลับและการรีเซ็ต

หากผู้พิพากษาของ observation สร้าง false pass, false fail, เอาต์พุตที่ผิดรูปแบบ หรือ ต้นทุน/latency ที่รับไม่ได้หลังการเปิดใช้งาน:

1. เปิด Langfuse Evaluations ค้นหากฎของ observation ที่ตรงเป๊ะคือ agent-arena-business-policy-online แล้วสลับเป็น disabled
2. ยืนยันว่า observation chat_turn ใหม่ ๆ ไม่ได้รับคะแนนจากกฎออนไลน์นั้นอีกต่อไป
3. คง policy-v2, sql-execution-success, และ 👍/👎 ให้ทำงานต่อไป เว้นแต่หลักฐานของ ตัวมันเองจะบอกเป็นอย่างอื่น การปิดใช้งานผู้พิพากษาที่บกพร่องไม่ควรทำให้ต้องกลับไปใช้ นโยบายเก่าที่รู้อยู่แล้วว่าล้าสมัย
4. เพิ่ม trace ที่ได้รับผลกระทบเข้าไปในคิวคำอธิบายประกอบโดยมนุษย์ที่มี suffix ปรับปรุง catalog/prompt ของผู้ประเมินและข้อมูล golden จากนั้นทำการสอบเทียบ experiment แบบจับคู่ซ้ำก่อนที่จะเปิดใช้งานอีกครั้ง

หากต้องการหยุด service ในเครื่องโดยไม่ลบหลักฐานที่อยู่บนระบบระยะไกล:

scripts/arena.sh stop

scripts/arena.sh down จะลบฐานข้อมูล ClickHouse ของเวิร์กช็อปและผู้ใช้แบบอ่านอย่างเดียว ไปด้วย แต่จะไม่ลบ dataset, การรัน Experiment, คิวคำอธิบายประกอบ หรือคะแนนของ Langfuse อย่าใช้คำสั่งนี้เป็นวิธีการย้อนกลับของผู้ประเมิน

แนวทางการพูดคุย: วงรอบยังคงเปิดอยู่

• ตัวประเมินเดิมผ่านเพราะสัญญา (contract) ของมันคือ "SQL ถูก execute" เท่านั้น การกด 👎 ของผู้ใช้เผยให้เห็นความล้มเหลวด้านค่าที่อยู่นอกเหนือสัญญานั้น
• การทบทวนโดยมนุษย์แปลงสัญญาณที่ไม่แน่นอนให้กลายเป็นการวินิจฉัยและการแก้ไขที่ผ่านการทดสอบแล้ว
• ที่มาจากการใช้งานจริง (production provenance) ทำให้เหตุการณ์นี้ตรวจสอบได้เมื่อถูกนำเข้า golden set; การเขียนถ้อยคำใหม่ (paraphrase) ช่วยเพิ่มความครอบคลุมด้านการใช้ถ้อยคำโดยไม่ แต่ง trace ผู้ใช้เพิ่มขึ้นมาลอย ๆ
• Experiment ที่จับคู่กันช่วยแยกการเปลี่ยนแปลงด้านนโยบายออกจากการเปลี่ยนแปลงด้านโมเดล/prompt และทดสอบผู้พิพากษาทั่วไปก่อนนำไปใช้งานจริง
• การได้ PASS แบบออนไลน์ไม่ได้ทำให้ฟีดแบ็กของผู้ใช้ล้าสมัยไป ในอนาคตหากพบ agent-arena-business-policy-online=PASS ร่วมกับ user-thumbs=false นั่นคือความไม่ สอดคล้องกันประเภทที่ควรเริ่มการสืบสวนใหม่พอดี

ประตูความสมบูรณ์ของงาน

อย่าปิดโมดูลนี้จนกว่าห้องจะสามารถแสดงหลักฐานทั้งหกชิ้นได้:

1. trace การใช้งานจริงที่มีผลผ่านเชิงปฏิบัติการและสัญญาณลบจากผู้ใช้;
2. คำอธิบายประกอบโดยมนุษย์ที่เสร็จสมบูรณ์ และ SQL ที่แก้ไขแล้วซึ่งได้รับการยืนยัน;
3. golden item สามรายการที่มีที่มาจากการใช้งานจริงของแท้;
4. หลักฐาน baseline/candidate บน dataset เดียวกันโดยไม่มีการถดถอยของ correctness ที่มีอยู่แล้ว;
5. หลักฐาน Experiment ที่สอบเทียบแล้วสำหรับ FAIL, PASS, และ NOT_APPLICABLE; และ
6. คะแนนแบบสดที่เปิดใช้งานครอบคลุมลูกค้าที่ active อยู่ รายได้ conversion และการนับแบบ ธรรมดา ในขณะที่ 👍/👎 ยังคงใช้งานได้อย่างต่อเนื่องสำหรับวงรอบถัดไป