03 ปล่อยใช้งานและตรวจจับ

คู่มือประกอบสำหรับวิทยากร คู่กับ 03 ปล่อยใช้งานและตรวจจับ

เวลาที่ใช้

รวม ~15 นาที

• 3 นาที — อธิบายความแตกต่างระหว่างการประเมินเชิงปฏิบัติการกับมูลค่าที่ผู้ใช้ได้รับ
• 4 นาที — แสดงการตรวจสอบก่อนใช้งาน (preflight) และปล่อยการกำหนดค่าที่ห้องเลือกไว้บน policy-v1
• 4 นาที — ถามคำถามที่อยู่ภายใต้นโยบายในหน้า Chat และรับ 👎 จากคำตอบนั้น
• 4 นาที — ค้นหาการติดตาม (trace) ของ Chat ดังกล่าว ตรวจสอบคะแนนทั้งสองค่า และทำซ้ำเหตุการณ์ด้วย curl

ตรวจสอบก่อนใช้งาน (Preflight) วันก่อนงาน

รันคำสั่งนี้ด้วยผู้ชนะที่คุณคาดว่าห้องจะเลือก ตัวเลือกสำรองที่ยืนยันแล้วคือ qwen3.7-flash__P2_fewshot:

cd ClickHouse_Demos/workshops/agent_arena
source .env
export WINNER_CONFIG_ID="${WINNER_CONFIG_ID:-qwen3.7-flash__P2_fewshot}"
.venv/bin/python -m schema.gen_schema_context
.venv/bin/python -m scripts.check_online_eval_scenario \
  --config-id "$WINNER_CONFIG_ID"
.venv/bin/python -m scripts.provision_online_evaluators --operational

การตรวจสอบ preflight จะลองซ้ำแบบมีขอบเขตเพียงหนึ่งครั้ง เฉพาะเมื่อผลลัพธ์แรกของคำถาม รูปแบบหนึ่งเป็น ok/unknown และจะลองซ้ำเฉพาะคำถามรูปแบบเดิมกับคอนฟิกเดิมเท่านั้น ความล้มเหลวอื่นทั้งหมดถือเป็นผลสุดท้าย และจะไม่มีคำถามรูปแบบใดถูกลองซ้ำเกินหนึ่งครั้ง

อย่าดำเนินการต่อจากความจำ ให้ยืนยันทุกข้อต่อไปนี้ในสภาพแวดล้อมจริงของห้อง:

• stale_count และ current_count ปรากฏทั้งคู่และมีค่าต่างกัน;
• การจัดประเภททั้งสามอย่างเป็น policy-v1 ทั้งหมด;
• บรรทัดสุดท้ายระบุว่าเหตุการณ์นี้สามารถทำซ้ำได้;
• ผู้ประเมิน (evaluator) sql-execution-success มีอยู่จริง; และ
• กฎ agent-arena-sql-execution-online ถูกเปิดใช้งาน

สำหรับ Qwen ต้องปิดการใช้งาน OpenRouter Settings → Privacy → Data Policies → Zero Data Retention → Non-frontier เพื่อให้เส้นทาง Alibaba มีสิทธิ์ใช้งานได้ ทำการเปลี่ยนแปลงนี้ เฉพาะหลังจากตรวจสอบข้อกำหนดเรื่องการจัดการข้อมูลสำหรับงานนี้แล้วเท่านั้น ผู้เรียนต้องได้รับ คีย์รันไทม์แบบจำกัดสิทธิ์ ไม่ใช่คีย์การจัดเตรียมของผู้สอน

แนวทางการบรรยาย

• เริ่มด้วยผู้ชนะจากโมดูล 02 จริงของห้อง แล้วเขียน WINNER_CONFIG_ID ไว้ในที่ที่ ทุกคนเห็นได้ แกนหลักของ agent และการกำหนดค่าที่เลือกไว้ไม่มีการเปลี่ยนแปลง มีเพียง บริบทนโยบายทางธุรกิจที่นำไปใช้งานจริงเท่านั้นที่จงใจให้ล้าหลังไปหนึ่งเวอร์ชัน

• ระบุขอบเขตของผู้ประเมินให้ชัดก่อนแสดงผลลัพธ์: sql-execution-success พิสูจน์ได้เพียงว่า ClickHouse รับ SQL นั้นได้ ไม่ได้พิสูจน์ว่า SQL นั้นตรงตาม ความหมายปัจจุบันของตัวชี้วัดที่อยู่ภายใต้นโยบาย

• ถามคำถามใน Chat แสดง SQL ที่สร้างขึ้น ผลลัพธ์ และ policy_version=policy-v1 จากนั้น คลิก 👎 และรอจนเห็น feedback sent การติดตามราก (root trace) ของ Chat นี้คือ เหตุการณ์เดียวที่ถือเป็นหลักฐานอย่างเป็นทางการ

• แสดงคำจำกัดความปัจจุบันให้ผู้ชมดูเทียบกัน:

  SELECT uniqExact(customer_id) FROM v_orders
  WHERE order_ts >= now() - INTERVAL 30 DAY
  AND status NOT IN ('cancelled', 'returned')

• พูดให้ชัดเจนว่า SQL ที่สร้างขึ้นโดยอิงตามการสมัครสมาชิก (signup-based) นั้นถูกต้องภายใต้ policy-v1 ที่ล้าสมัยซึ่งถูกส่งให้โมเดล นี่คือความล้มเหลวในการปล่อยใช้งาน/กระบวนการ และ จุดบอดของผู้ประเมิน ไม่ใช่การอ้างว่าโมเดลเพิกเฉยต่อคำสั่งที่ชัดเจน

• ใน Langfuse กรองด้วย user-thumbs = false เปิด chat_turn ของ Chat ที่ตรงเงื่อนไข ล่าสุด แล้วแสดง sql-execution-success=true คู่กับ user-thumbs=false สัญญาณนี้ ทำหน้าที่จัดลำดับความสำคัญของการสอบสวน แต่ไม่ได้ให้การวินิจฉัยหรือกลายเป็น ความจริงพื้นฐาน (ground truth) ด้วยตัวมันเอง

• รันการทำซ้ำด้วย curl ที่บังคับไว้หลังจากนั้น ในลักษณะเป็นการวินิจฉัยที่ไม่ให้คะแนน ตั้งชื่อตัวระบุของมันว่า CURL_TRACE_ID ตรวจสอบเฉพาะ sql-execution-success=true และห้ามส่ง feedback ให้กับมันหรือใช้มันเป็นข้อมูลส่งต่อไปยังโมดูล 04

• บันทึก ID/URL ของการติดตามราก และจำนวนทั้งสองค่าไว้สำหรับโมดูล 04 เก็บตัวระบุ ที่เป็นข้อมูลจริงไว้ภายในโครงการ Langfuse และเวิร์กชีทของเวิร์กช็อปเท่านั้น

หลักฐานการติดตามที่ควรพบ

เปิดการสังเกต (observation) ราก chat_turn ไม่ใช่แค่ llm_call ที่เป็นลูกของมัน สิ่งที่ควรพบมีดังนี้:

ฝั่ง serving ตั้งชื่อฟิลด์นี้ว่า policy_version แต่ตัวปรับ (adapter) ของ OpenTelemetry จะทำความสะอาดคีย์ของ metadata ให้เหลือแต่อักขระตัวอักษรและตัวเลข ดังนั้น Langfuse จึงแสดงคีย์ ที่ถูกส่งออกมาเป็น policyversion

ผู้ประเมินเชิงปฏิบัติการทำงานแบบอะซิงโครนัส (asynchronous) ให้ใช้ตัวตรวจสอบแทนการถือว่า คะแนนที่ยังไม่ปรากฏคือความล้มเหลว:

.venv/bin/python -m scripts.verify_online_scores "$CHAT_TRACE_ID" \
  sql-execution-success=true user-thumbs=false

ความล้มเหลวที่พบได้บ่อย

• ผู้ให้บริการถูกบล็อกโดย ZDR — Qwen จะล้มเหลวก่อนสร้าง SQL เมื่อข้อกำหนด Zero Data Retention แบบ non-frontier ของ OpenRouter ถูกเปิดใช้งานและเส้นทาง Alibaba ที่มีสิทธิ์ไม่ได้รับอนุญาต ให้ปิดข้อจำกัด ZDR นั้นสำหรับเวิร์กช็อปนี้ หรือใช้ ตัวเลือกสำรองที่เปิดเผยไว้หลังจากตรวจสอบข้อกำหนดด้านความเป็นส่วนตัวแล้ว
• ตัวจัดส่งงานของผู้ประเมิน (evaluator dispatcher) ไม่ทำงาน — trace มาถึงแล้ว แต่ sql-execution-success ไม่ปรากฏขึ้นเลย ให้ยืนยันว่าบริการ/ตัวจัดส่งงาน การประมวลผลผู้ประเมินของ Langfuse ทำงานปกติ และกฎ agent-arena-sql-execution-online ถูกเปิดใช้งาน การจัดเตรียมกฎไว้เพียงอย่างเดียวไม่ได้ทำให้คะแนนถูกประมวลผลหาก worker ของการประเมินไม่พร้อมใช้งาน
• ขาด dependency ของ OpenTelemetry — ไม่มี trace ปรากฏเลยแม้ /ask ตอบกลับมาแล้วก็ตาม ให้ติดตั้ง requirements ของแล็บที่ปักเวอร์ชันไว้ใหม่ด้วย .venv/bin/python -m pip install -r requirements.txt เนื่องจาก runtime ใช้เส้นทาง OpenTelemetry ของ Langfuse v4 และต้องการแพ็กเกจ OTel ที่รองรับกัน
• โปรเซสเซิร์ฟเวอร์เก่ายังทำงานอยู่ — คำตอบรายงาน policy-v2 ทั้งที่คำสั่ง ในเชลล์ระบุ policy-v1 เป็นเพราะโปรเซสเก่ายังครองพอร์ต 8100 อยู่ ให้หยุดมันให้หมด ก่อนเริ่มการปล่อยใช้งานแบบ seeded
• พอร์ตผิด — Chat UI ค่าเริ่มต้นใช้ http://localhost:8100 ถ้า serving ใช้ พอร์ตอื่น ให้ตั้งค่า VITE_SERVING_BASE ให้เป็นแอดเดรสเดียวกัน หรือใช้ curl ดิบเทียบกับพอร์ตจริง
• feedback ซ้ำ — feedback ใช้ score ID แบบกำหนดได้ล่วงหน้า user-thumbs-<trace_id> ให้ส่งการให้คะแนนเพียงหนึ่งครั้งต่อ trace การใช้ trace เดิม ซ้ำสำหรับการให้คะแนนที่ขัดแย้งกันอาจทำให้เกิดข้อผิดพลาดจาก feedback service หรือ ทำให้การสาธิตดูคลุมเครือ ให้สร้างเซสชัน/trace ใหม่แทน
• คะแนนยังรอดำเนินการ — การประเมินเป็นแบบอะซิงโครนัส ให้ปล่อยให้ scripts.verify_online_scores polling รอคะแนนก่อนที่จะเปลี่ยนการกำหนดค่า
• จำนวนอ้างอิงตรงกัน — แสดงว่าความแตกต่างที่ seed ไว้ไม่มีอยู่ในสแนปช็อตข้อมูลนี้ ห้ามสร้างความล้มเหลวขึ้นมาเอง ให้ทำการ reseed หรือวิเคราะห์ข้อมูลก่อนเริ่มเซสชัน

ขั้นตอนการรีเซ็ต

หยุดเซิร์ฟเวอร์ที่กำลังทำงานอยู่ แล้วเริ่มโปรเซส policy-v1 ใหม่แบบสะอาด:

scripts/arena.sh stop
scripts/arena.sh serve
source .env
.venv/bin/python -m schema.gen_schema_context
AGENT_ARENA_POLICY_VERSION=policy-v1 \
  .venv/bin/uvicorn serving.api:app --port 8100

scripts/arena.sh serve จะกู้คืนแดชบอร์ดและเว็บ UI ให้ทำงานในพื้นหลังก่อนที่ serving API จะเข้าครองเทอร์มินัล รีเฟรชหน้า Chat เพื่อสร้างเซสชันใหม่ ถ้าคุณใช้ API แบบดิบโดยตรง ให้ส่ง session ID ใหม่หรือละเว้นไว้เพื่อให้ /ask สร้างให้เอง โดยอัตโนมัติ รันการตรวจสอบก่อนใช้งาน (preflight) และตัวจัดเตรียมอีกครั้งในเทอร์มินัลที่สอง ทั้งสองคำสั่งปลอดภัยที่จะรันซ้ำได้

นโยบายสำรอง

ใช้การกำหนดค่า qwen3.7-flash__P2_fewshot ที่ผู้สอนทราบว่าใช้งานได้แน่นอน เฉพาะกรณีที่ ผู้ชนะของห้องไม่ตรงตามนโยบายที่ล้าสมัยอย่างชัดเจนในสามคำถามของการตรวจสอบก่อนใช้งานอีกต่อไป ให้ประกาศการสับเปลี่ยนนี้ออกเสียงดังๆ: ตัวเลือกสำรองรักษาไว้ซึ่งเหตุการณ์การสอนที่กำหนดผลได้แน่นอน ในขณะที่ผู้ชนะบนลีดเดอร์บอร์ดยังคงเป็นผลลัพธ์ที่วัดได้จริงของห้อง อย่าสลับโมเดลอย่างเงียบๆ และอย่าใช้ตัวเลือกสำรองเพื่อปิดบังความล้มเหลวจากจำนวนที่เท่ากัน ปัญหาข้อมูลรับรอง (credential) การกำหนดเส้นทางผู้ให้บริการ หรือโครงสร้างพื้นฐานของผู้ประเมิน

ส่งต่อไปยังโมดูล 04

ก่อนดำเนินการต่อ ให้ยืนยันว่าเวิร์กชีทมีข้อมูล ID/URL ของ Chat root trace ที่เป็นหลักฐาน อย่างเป็นทางการ, stale count, current count, sql-execution-success=true, และ Boolean user-thumbs=false ครบถ้วน โมดูล 04 จะเริ่มต้นจากความขัดแย้งที่แท้จริงนี้และเพิ่มการตัดสิน ของมนุษย์เข้าไป ต้องไม่เริ่มต้นด้วยการวินิจฉัยที่เขียนไว้ล่วงหน้าซึ่งแยกขาดจาก trace ที่เกิดขึ้นจริงในการใช้งานจริง