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

จุดเริ่มต้น

โมดูล 04 ปิดท้ายด้วยการตรวจสอบโดยมนุษย์ (human annotation) ที่เสร็จสมบูรณ์แล้วสำหรับ chat_turn ของโมดูล 03 ที่เป็นแหล่งอ้างอิงหลัก เก็บ SQL ที่แก้ไขแล้วและ worksheet แหล่งที่มาไว้ให้พร้อมใช้งาน:

source=production-feedback
source_trace_id=<authoritative Chat trace ID>
failure_category=stale-business-policy
source_policy_version=policy-v1
annotation_id=<completed task ID when available>

trace ของโปรดักชันดั้งเดิมมี sql-execution-success=true และ user-thumbs=false การกดโหวตลง (thumbs-down) เป็นตัวชี้ให้พบ trace ที่ควรค่าแก่การตรวจสอบ ส่วนการตรวจสอบที่เสร็จสมบูรณ์แล้วคือสิ่งที่ให้การวินิจฉัยและความจริงพื้นฐาน (ground truth) ที่แก้ไขแล้ว

วงจรการประเมินและการปรับปรุงอย่างต่อเนื่อง

โมดูลนี้ปิดวงจรหนึ่งรอบ ดังนี้:

1. คำติชมของผู้ใช้เผยให้เห็นจุดบอดของผู้ประเมินออนไลน์ที่ใช้อยู่ในปัจจุบัน
2. มนุษย์ตรวจสอบและอนุมัติการแก้ไข
3. เหตุการณ์ที่ผ่านการตรวจสอบนั้นขยายชุดข้อมูลโกลเดน (golden dataset)
4. รุ่นเบสไลน์ (baseline) และรุ่นตัวเลือก (candidate) รันทับชุดข้อมูลที่ขยายแล้วชุดเดียวกัน
5. ผู้ประเมินทั่วไป (general evaluator) ผ่านการปรับเทียบแบบออฟไลน์ก่อนที่จะเปิดใช้งานออนไลน์ และ
6. ทราฟฟิกในอนาคตยังคงเก็บทั้งคะแนนของผู้ประเมินและคำติชมของผู้ใช้ต่อไป

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

เป้าหมาย

ผ่านหลักฐาน 5 ประตู (evidence gate): promote, baseline, candidate, calibrate จากนั้น enable และ replay ใช้ผู้ชนะจากโมดูล 02 สำหรับการทดลองทั้งสองรอบ เพื่อให้เวอร์ชันของนโยบายเป็นตัวแปรเดียว ที่เปลี่ยนแปลงโดยตั้งใจ

รันคำสั่งทั้งหมดด้านล่างจาก ClickHouse_Demos/workshops/agent_arena:

cd ClickHouse_Demos/workshops/agent_arena
source .env
export WINNER_MODEL="${WINNER_MODEL:-qwen3.7-flash}"
export WINNER_PROMPT="${WINNER_PROMPT:-P2_fewshot}"
export WINNER_CONFIG_ID="${WINNER_CONFIG_ID:-qwen3.7-flash__P2_fewshot}"

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

ประตูหลักฐานที่ 1 — โปรโมตเหตุการณ์ที่ผ่านการตรวจสอบแล้ว

สร้าง reviewed.json ไว้ที่รูทของแล็บ ด้วยเรคคอร์ดสามรายการต่อไปนี้ แทนที่ ค่าตัวยึด (placeholder) ทั้งสองแบบในทุกที่ที่ปรากฏ ก่อนรันการโปรโมต หาก Langfuse ไม่ได้ เปิดให้เห็น ID ของ annotation task ให้ลบ annotation_id ออกจากทั้งสามเรคคอร์ดแทน การปล่อยเป็นค่าตัวยึดไว้ ฟิลด์นี้เป็นฟิลด์ที่ไม่จำเป็น ในขณะที่ฟิลด์แหล่งที่มาจากโปรดักชันอื่น ๆ เป็นฟิลด์ที่ต้องมี

[
  {
    "id": "prod-active-001",
    "question": "How many active customers do we have?",
    "golden_sql": "SELECT uniqExact(customer_id) FROM v_orders WHERE order_ts >= now() - INTERVAL 30 DAY AND status NOT IN ('cancelled', 'returned')",
    "tier": 2,
    "ordered": false,
    "source": "production-feedback",
    "source_trace_id": "<paste the Module 03 Chat trace ID>",
    "failure_category": "stale-business-policy",
    "source_policy_version": "policy-v1",
    "annotation_id": "<paste the completed task ID>"
  },
  {
    "id": "prod-active-002",
    "question": "What is our active customer count right now?",
    "golden_sql": "SELECT uniqExact(customer_id) FROM v_orders WHERE order_ts >= now() - INTERVAL 30 DAY AND status NOT IN ('cancelled', 'returned')",
    "tier": 2,
    "ordered": false,
    "source": "production-feedback",
    "source_trace_id": "<paste the Module 03 Chat trace ID>",
    "failure_category": "stale-business-policy",
    "source_policy_version": "policy-v1",
    "annotation_id": "<paste the completed task ID>"
  },
  {
    "id": "prod-active-003",
    "question": "How many customers qualify as active under our business definition?",
    "golden_sql": "SELECT uniqExact(customer_id) FROM v_orders WHERE order_ts >= now() - INTERVAL 30 DAY AND status NOT IN ('cancelled', 'returned')",
    "tier": 2,
    "ordered": false,
    "source": "production-feedback",
    "source_trace_id": "<paste the Module 03 Chat trace ID>",
    "failure_category": "stale-business-policy",
    "source_policy_version": "policy-v1",
    "annotation_id": "<paste the completed task ID>"
  }
]

มีเพียง prod-active-001 เท่านั้นที่เป็นคำถามฉบับเดียวกันเป๊ะกับ trace คำติชมของผู้ใช้ ส่วน prod-active-002 และ prod-active-003 เป็นการเขียนถ้อยคำใหม่ (paraphrase) โดยผู้ตรวจสอบ ซึ่งได้มา จากเหตุการณ์ที่ตรวจสอบเดียวกันนั้น ทั้งสองรายการใช้ source trace เดียวกันและ annotation ที่เสร็จสมบูรณ์เดียวกันเพื่อให้ตรวจสอบย้อนกลับ (auditability) ได้ ทั้งสองรายการไม่ใช่ trace คำติชมจากโปรดักชันเพิ่มเติมอีกสองรายการ อินพุตทั้งสามรายการถูกออกแบบให้เรียกใช้เมตริกลูกค้าที่ยังใช้งานอยู่ (active-customer) ภายใต้การกำกับดูแลเหมือนกันโดยตั้งใจ ดังนั้น เบสไลน์จึงไม่สามารถแสดงผลว่าดูปกติได้ด้วยการทดสอบจำนวนนับที่ไม่เกี่ยวข้อง

โปรโมตชุดที่ผ่านการตรวจสอบแล้ว:

source .env
.venv/bin/python -m scripts.promote_to_golden reviewed.json

คาดว่าจะได้บรรทัด prepared prod-active-* สามบรรทัด ตามด้วย:

promoted 3 question(s) into the 'arena-golden' dataset

เปิด Langfuse → Datasets → arena-golden และตรวจสอบเมทาดาต้าของแต่ละไอเทมใหม่ ตรวจให้แน่ใจว่า source=production-feedback, source_trace_id เดียวกันซึ่งเป็นค่าจริง, failure_category=stale-business-policy และ source_policy_version=policy-v1

คลังต้นทางใน repo มีคำถาม YAML 20 ข้อ โดย q019 และ q020 กันไว้เป็น few-shot prompt holdout ดังนั้นโปรเจกต์ที่สะอาดจึงเริ่มด้วย Experiment item 18 รายการใน arena-golden การโปรโมตสามรายการนี้ทำให้ dataset ที่สะอาดมี 21 รายการ โปรเจกต์ที่ใช้ซ้ำ อาจมี approved item เพิ่มเติม ให้บันทึก provenance นั้นแทนการลบเพื่อบังคับจำนวน และกำหนดให้ baseline กับ candidate ใช้ item ID ชุดเดียวกัน

การโปรโมตจะตรวจสอบความถูกต้องของชุดงานทั้งหมด, SQL แบบอ่านอย่างเดียว (read-only) และแหล่งที่มาที่จำเป็น ก่อนที่จะสอบถาม ClickHouse หรือเขียนไอเทมลงชุดข้อมูล จากนั้นจะอ่านเมทาดาต้าของชุดข้อมูลที่มีอยู่ และปฏิเสธ ID ที่ชนกันแต่มีแหล่งที่มาจากโปรดักชันแตกต่างกัน หากขั้นตอนตรวจสอบล่วงหน้า (preflight) ที่ผ่านการยืนยันตัวตนแล้ว ไม่สามารถยืนยันแหล่งที่มาได้อย่างปลอดภัย มันจะหยุดโดยไม่มีการเขียนข้อมูล การโปรโมตของแท้ซ้ำจะปลอดภัย ก็ต่อเมื่อแหล่งที่มาจากโปรดักชันที่ชนกันนั้นเหมือนกันเป๊ะเท่านั้น

ประตูหลักฐานที่ 2 — รันเบสไลน์ policy-v1

ก่อนอื่น ให้จัดเตรียม (provision) judge ที่ขับเคลื่อนด้วยแคตตาล็อกสำหรับการทดลอง ขั้นตอนนี้จะสร้าง กฎการสังเกต (observation rule) ออนไลน์ของมันในสถานะปิดใช้งาน:

source .env
.venv/bin/python -m scripts.provision_online_evaluators \
  --business-policy-experiments

คาดว่าจะได้ experiment rule enabled=True; online rule enabled=False ยืนยันว่ากฎ ออนไลน์ยังปิดใช้งานอยู่ใน Langfuse ก่อนดำเนินการต่อ

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

export LOOP_RUN_SUFFIX="${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}"

.venv/bin/python -m eval.harness --run-id "$BASELINE_RUN_ID" \
  --policy-version policy-v1 --models "$WINNER_MODEL" --prompts "$WINNER_PROMPT" \
  --wait-for-score business-policy-adherence

harness จะต่อท้าย --policy-v1 เข้ากับ release ID มันจะรอชื่อคะแนนของ Experiment ที่ตรงเป๊ะสามชื่อในทุก ๆ trace ได้แก่ correctness, agent-arena-llm-judge, และ business-policy-adherence อย่าดำเนินการต่อหากการรันหมดเวลา (timeout) หรือคะแนนใดคะแนนหนึ่ง ขาดหายไป

ใน Langfuse Experiments ให้บันทึกจำนวนไอเทมของชุดข้อมูลของเบสไลน์และค่าความถูกต้อง (correctness) โดยรวม หลังการโปรโมต ให้คาดหวัง 21 รายการในโปรเจกต์ที่สะอาด โปรเจกต์ที่ใช้ซ้ำอาจมี approved item มากกว่านั้น และคำตอบของ provider อาจแตกต่างกันได้ ดังนั้นประตูสำหรับการปล่อยรุ่น จึงคือการเปรียบเทียบแบบจับคู่ด้านล่าง ไม่ใช่คะแนนรวมที่ hard-code ไว้

ประตูหลักฐานที่ 3 — รันตัวเลือก (candidate) policy-v2

โดยไม่เปลี่ยนชุดข้อมูล โมเดล พรอมป์ หรือคำต่อท้ายของการรัน ให้รันตัวเลือก:

.venv/bin/python -m eval.harness --run-id "$CANDIDATE_RUN_ID" \
  --policy-version policy-v2 --models "$WINNER_MODEL" --prompts "$WINNER_PROMPT" \
  --wait-for-score business-policy-adherence

บันทึกค่ารวมจริงของ candidate แล้วเปรียบเทียบทั้งสองการรันใน Langfuse และต้องตรวจสอบให้ได้ว่า:

• ID ของไอเทมในชุดข้อมูลและจำนวนไอเทมเหมือนกันเป๊ะ;
• ไอเทม prod-active-* ทั้งสามรายการเปลี่ยนจาก correctness=0 ภายใต้ policy-v1 ไปเป็น correctness=1 ภายใต้ policy-v2;
• ไอเทมทุกรายการที่มีอยู่ก่อน prod-active-* ถูกเปรียบเทียบทีละไอเทม โดยไม่มี การถดถอย (regression) จาก correctness=1 ไปเป็น correctness=0; และ
• ค่าความถูกต้องโดยรวมของตัวเลือกไม่ต่ำกว่าค่าความถูกต้องของเบสไลน์

หยุดทันทีหากไอเทมที่มีอยู่ก่อนแล้วเกิดการถดถอย ตัวเลือกที่แก้ไขเหตุการณ์ได้แต่ทำให้ พฤติกรรมที่รู้จักแล้วพังลง ถือว่ายังไม่ผ่านประตูสำหรับการปล่อยรุ่น

ประตูหลักฐานที่ 4 — ปรับเทียบ (calibrate) judge นโยบายทั่วไปหนึ่งตัว

business-policy-adherence ไม่ใช่ “ผู้ประเมินลูกค้าที่ใช้งานอยู่ (active-customer evaluator)” มันรับคำถาม, SQL ที่ถูกสร้างขึ้น, และแคตตาล็อกเมตริกของ policy-v2 ทั้งหมด มันจะตัดสินว่า เมตริกที่อยู่ภายใต้การกำกับดูแลตัวไหนที่ใช้ได้ แล้วส่งคืน PASS, FAIL, หรือ NOT_APPLICABLE การออกแบบแบบเดียวกันนี้สามารถตรวจสอบลูกค้าที่ใช้งานอยู่ รายได้ การแปลง (conversion) และอัตรากำไรขั้นต้นได้โดยไม่ต้อง สร้างผู้ประเมินหนึ่งตัวต่อคำถามหนึ่งรูปแบบถ้อยคำ

ก่อนที่จะเปิดใช้งานสำหรับการสังเกตในโปรดักชัน ให้ตรวจสอบไอเทมของ Experiment ต่อไปนี้:

ทำการตรวจสอบลูกค้าที่ใช้งานอยู่แบบเดียวกันซ้ำอีกครั้งสำหรับ prod-active-002 และ prod-active-003 อ่าน คำอธิบายเหตุผล (reasoning) ของ judge ควบคู่ไปกับหมวดหมู่ผลลัพธ์ด้วย โดยมันควรระบุชื่อนโยบายในแคตตาล็อกที่ใช้ได้ และประเมิน SQL ที่ถูกสร้างขึ้นเทียบกับนโยบายนั้น คำถามนับจำนวนแบบธรรมดาต้องยังคงได้ผลลัพธ์เป็น NOT_APPLICABLE เพื่อแสดงให้เห็นว่า judge ไม่ได้ยัดคำถามนับจำนวนทุกข้อ ให้เข้ากับนโยบายลูกค้าที่ใช้งานอยู่

ให้กฎออนไลน์ยังคงปิดใช้งานอยู่หากหมวดหมู่ผลลัพธ์ผิดแม้แต่ข้อเดียว, คะแนนที่จำเป็นขาดหายไป, เอาต์พุตที่มีโครงสร้าง (structured output) มีรูปแบบผิด หรือการเปรียบเทียบค่าความถูกต้องเกิดการถดถอย การปรับเทียบด้วย experiment แบบออฟไลน์ต้องมาก่อนเสมอ เพราะมันเปิดให้คุณตรวจสอบผลบวกลวง (false pass) และผลลบลวง (false failure) เทียบกับตัวอย่างที่รู้ผลลัพธ์อยู่แล้ว ก่อนที่ผู้ประเมินจะเข้าไปมีผลต่อการมอนิเตอร์ ในโปรดักชันจริง

ประตูหลักฐานที่ 5 — เปิดใช้งาน (enable) และ replay บน policy-v2

หลังจากประตูการปรับเทียบทั้งหมดผ่านแล้วเท่านั้น จึงเปิดใช้งานกฎการสังเกต:

source .env
.venv/bin/python -m scripts.provision_online_evaluators \
  --enable-business-policy-online

คาดว่าจะได้ชื่อกฎที่ตรงเป๊ะคือ agent-arena-business-policy-online พร้อม enabled=True คำสั่งนี้จะ fail closed (ล้มเหลวแบบปิดกั้น) เมื่อหาคะแนนของ Experiment ที่กำหนดขอบเขตด้วยชุดข้อมูล (dataset-scoped) ในชื่อ business-policy-adherence ไม่พบ; การตรวจสอบการปรับเทียบด้วยมือของคุณข้างต้นยังคงเป็นประตู คุณภาพหลักอยู่เสมอ

หยุดเซิร์ฟเวอร์ policy-v1 ในเทอร์มินัลแรก ให้เริ่มตัวเลือก (candidate) และปล่อยให้มันรัน ต่อไป:

source .env
AGENT_ARENA_POLICY_VERSION=policy-v2 \
  .venv/bin/uvicorn serving.api:app --port 8100

ในเทอร์มินัลที่สอง ให้กำหนด helper ที่รับคำถามหนึ่งข้อ และคืนค่า trace ID กลับมาก็ต่อเมื่อยืนยันแล้วว่าได้รับการตอบกลับที่สำเร็จจาก policy-v2:

source .env
export WINNER_CONFIG_ID="${WINNER_CONFIG_ID:-qwen3.7-flash__P2_fewshot}"
ask_trace() {
  local question="$1"
  local body
  body=$(.venv/bin/python -c \
    'import json,sys; print(json.dumps({"question": sys.argv[1], "config_id": sys.argv[2]}))' \
    "$question" "$WINNER_CONFIG_ID")
  curl -fsS http://localhost:8100/ask \
    -H 'content-type: application/json' -d "$body" | \
    .venv/bin/python -c \
    'import json,sys; data=json.load(sys.stdin); assert data["policy_version"] == "policy-v2" and data["outcome"] == "ok"; print(data["trace_id"])'
}

ถามคำถามเกี่ยวกับลูกค้าที่ใช้งานอยู่และรายได้อย่างละครั้ง คะแนนจากการสังเกตออนไลน์ใช้ ชื่อกฎ agent-arena-business-policy-online ไม่ใช่ชื่อคะแนนของ Experiment:

ACTIVE_TRACE=$(ask_trace "How many active customers do we have?")
.venv/bin/python -m scripts.verify_online_scores "$ACTIVE_TRACE" \
  sql-execution-success=true agent-arena-business-policy-online=PASS

REVENUE_TRACE=$(ask_trace "What was revenue in the last 30 days?")
.venv/bin/python -m scripts.verify_online_scores "$REVENUE_TRACE" \
  sql-execution-success=true agent-arena-business-policy-online=PASS

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

ask_conversion() {
  local body
  body=$(.venv/bin/python -c \
    'import json,sys; print(json.dumps({"question": sys.argv[1], "config_id": sys.argv[2]}))' \
    "What is our view-to-purchase conversion rate for the last 7 days?" \
    "$WINNER_CONFIG_ID")
  curl -fsS http://localhost:8100/ask \
    -H 'content-type: application/json' -d "$body" | \
    .venv/bin/python -c \
    'import json,sys; data=json.load(sys.stdin); assert data["policy_version"] == "policy-v2"; print("\t".join((data["trace_id"], data["outcome"])))'
}

IFS=$'\t' read -r CONVERSION_TRACE_1 CONVERSION_OUTCOME_1 <<< \
  "$(ask_conversion)"
if .venv/bin/python -m scripts.verify_online_scores "$CONVERSION_TRACE_1" \
  sql-execution-success=true agent-arena-business-policy-online=PASS; then
  CONVERSION_SCORES_1=pass
else
  CONVERSION_SCORES_1=fail
fi
if [ "$CONVERSION_OUTCOME_1" = ok ] && [ "$CONVERSION_SCORES_1" = pass ]; then
  CONVERSION_RESULT_1=pass
else
  CONVERSION_RESULT_1=fail
fi
printf 'conversion_attempt=1 trace_id=%s outcome=%s exact_scores=%s result=%s\n' \
  "$CONVERSION_TRACE_1" "$CONVERSION_OUTCOME_1" \
  "$CONVERSION_SCORES_1" "$CONVERSION_RESULT_1"

CONVERSION_TRACE_2=not-run
CONVERSION_OUTCOME_2=not-run
CONVERSION_SCORES_2=not-run
CONVERSION_RESULT_2=not-run
if [ "$CONVERSION_RESULT_1" != pass ]; then
  IFS=$'\t' read -r CONVERSION_TRACE_2 CONVERSION_OUTCOME_2 <<< \
    "$(ask_conversion)"
  if .venv/bin/python -m scripts.verify_online_scores "$CONVERSION_TRACE_2" \
    sql-execution-success=true agent-arena-business-policy-online=PASS; then
    CONVERSION_SCORES_2=pass
  else
    CONVERSION_SCORES_2=fail
  fi
  if [ "$CONVERSION_OUTCOME_2" = ok ] && [ "$CONVERSION_SCORES_2" = pass ]; then
    CONVERSION_RESULT_2=pass
  else
    CONVERSION_RESULT_2=fail
  fi
fi
printf 'conversion_attempt=2 trace_id=%s outcome=%s exact_scores=%s result=%s\n' \
  "$CONVERSION_TRACE_2" "$CONVERSION_OUTCOME_2" \
  "$CONVERSION_SCORES_2" "$CONVERSION_RESULT_2"

if [ "$CONVERSION_RESULT_1" != pass ] && \
   [ "$CONVERSION_RESULT_2" != pass ]; then
  printf '%s\n' \
    'STOP: conversion failed twice; preserve both traces and investigate.' >&2
  false
fi

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

หลังจากที่ conversion ผ่านแล้วเท่านั้น จึงถามคำถามนับจำนวนแบบธรรมดาหนึ่งครั้ง:

PRODUCT_TRACE=$(ask_trace "How many products are there?")
.venv/bin/python -m scripts.verify_online_scores "$PRODUCT_TRACE" \
  sql-execution-success=true agent-arena-business-policy-online=NOT_APPLICABLE

ผู้ประเมินออนไลน์ทำงานแบบอะซิงโครนัส (asynchronously) ตัวตรวจสอบ (verifier) จะ poll เป็นเวลาสูงสุด 180 วินาที ตามค่าเริ่มต้น คะแนนที่ยังอยู่ในสถานะรอ (pending) ไม่ถือว่าเหมือนกับคะแนนที่ล้มเหลว

ให้วงจรทำงานต่อไป

เปิดใช้งาน 👍/👎 ต่อไปหลังจาก rollout เฝ้าดูความไม่สอดคล้องกัน เช่น agent-arena-business-policy-online=PASS คู่กับ user-thumbs=false กรณีเหล่านี้เป็น ตัวเลือกที่มีค่าสูงสำหรับคิว annotation รอบถัดไป การตรวจสอบโดยมนุษย์จะเป็นผู้ตัดสินว่าควรแก้ไข นโยบาย พรอมป์ ข้อมูล หรือตัวผู้ประเมินเอง กรณีที่ได้รับการอนุมัติจะถูกส่งกลับไปยัง arena-golden แล้วตัวเลือกรอบถัดไปก็จะทำตามลำดับ baseline → candidate → calibration → guarded enablement ซ้ำอีกครั้ง

กฎของเวิร์กช็อปนี้สุ่มตัวอย่าง trace ที่มีสิทธิ์ 100% เพื่อให้ผู้เรียนทุกคนได้เห็นหลักฐาน นั่นคือการตั้งค่าเพื่อการสอน ไม่ใช่ค่าเริ่มต้นสำหรับโปรดักชัน การสุ่มตัวอย่างจริงควรสะท้อน ทราฟฟิก ต้นทุนของผู้ประเมิน ความหน่วง (latency) ความเสี่ยง และการครอบคลุมเหตุการณ์ที่คุณต้องการ

หลักฐานความสำเร็จ

• root trace ของโปรดักชันยังคงแสดง sql-execution-success=true และค่า Boolean user-thumbs=false
• task การตรวจสอบโดยมนุษย์ production-investigation-<session> เสร็จสมบูรณ์ด้วย การแก้ไขที่ผ่านการยืนยันแล้วและ approved-for-golden=true
• ไอเทมโกลเดนทั้งสามรายการมีแหล่งที่มาจาก production-feedback ของแท้ คุณสามารถ แยกแยะได้ว่าไอเทมใดคือคำถามจากผู้ใช้จริงหนึ่งข้อ และไอเทมใดคือการเขียนถ้อยคำใหม่โดยผู้ตรวจสอบอีกสองข้อ
• เบสไลน์และตัวเลือกใช้ชุดข้อมูลที่ขยายแล้ว โมเดล และพรอมป์ชุดเดียวกัน ตัวเลือกแก้ไขไอเทมที่โปรโมตทั้งสามรายการได้สำเร็จ และไม่ทำให้เกิดการถดถอยของค่าความถูกต้อง ที่มีอยู่เดิม
• การปรับเทียบด้วย Experiment ให้ผลลัพธ์ FAIL, PASS, และ NOT_APPLICABLE ด้วยชื่อคะแนน ที่ตรงเป๊ะคือ business-policy-adherence
• กฎการสังเกตถูกปิดใช้งานระหว่างการปรับเทียบ และเปิดใช้งานก็ต่อเมื่อ ผ่านทุกประตูแล้วเท่านั้น
• trace ของลูกค้าที่ใช้งานอยู่ รายได้ และการแปลง (conversion) มีค่า agent-arena-business-policy-online=PASS; ส่วนการนับจำนวนสินค้าแบบธรรมดามีค่า agent-arena-business-policy-online=NOT_APPLICABLE
• คุณสามารถอธิบายได้ว่าเหตุใดการประเมินออนไลน์และคำติชมของผู้ใช้จึงยังคงปรับปรุงกันและกัน ต่อไปได้แม้หลังจากการปรับใช้งานจริงแล้ว