การสร้าง Custom Harness ด้วย Pi และ Jev

AI agent คือ language model ที่ทำงานเป็นลูป โดยมันจะอ่านคำสั่ง เลือกใช้เครื่องมือ เช่น "อ่านไฟล์นี้" หรือ "ลบไฟล์นั้น" ดูผลลัพธ์ที่ได้ แล้วทำวนไปเรื่อยๆ จนกว่างานจะเสร็จ ทุกครั้งที่โมเดลร้องขอใช้งานเครื่องมือ เราจะเรียกคำขอนั้นว่า tool call

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

harness ที่ดีจะต้องตัดสินใจเรื่องเล็กๆ น้อยๆ ตลอดทาง เช่น คำขอนี้ควรให้โมเดลไหนจัดการ? tool call นี้ปลอดภัยพอที่จะรันไหม? คำตอบนี้ดีพอที่จะส่งกลับหรือยัง? harness ส่วนใหญ่หาคำตอบเหล่านี้ด้วยการถาม chat model แล้วรออ่านคำตอบ ซึ่งต้องเสียค่าใช้จ่ายในการเรียกโมเดลเต็มๆ ทุกครั้ง ในทางปฏิบัติจึงมักข้ามการตรวจสอบหลายๆ อย่างไป

Jev จาก TypeSafe AI เป็นโมเดลขนาดเล็กที่สร้างมาเพื่อการตัดสินใจเหล่านี้โดยเฉพาะ คุณแค่บอกรายละเอียดสถานการณ์แล้วตั้งคำถามไม่กี่ข้อ มันก็จะตอบกลับมาเป็นตัวเลขทีละข้อ โดยไม่มีการเขียนข้อความใดๆ ออกมาเลย

เรื่องนี้สำคัญมากเมื่อคุณต้องการสร้าง custom harness หรือก็คือลูป agent ของตัวเองแทนการใช้ agent สำเร็จรูป เพราะ custom harness ช่วยให้คุณเลือกได้ว่าจะใช้โมเดลไหน อนุญาตให้ agent เข้าถึงอะไรได้บ้าง และแค่ไหนถึงจะถือว่างานเสร็จ Jev ทำให้ต้นทุนของการตรวจสอบเบื้องหลังตัวเลือกเหล่านั้นถูกลงจนสามารถรันได้ในทุกขั้นตอน

ในบทเรียนนี้ คุณจะสร้าง harness ด้วย Pi SDK ซึ่งเป็น TypeScript toolkit สำหรับสร้าง agent และใช้งาน Jev ใน 3 จุด เมื่อจบแล้ว คุณจะได้ลองรัน harness ที่เสร็จสมบูรณ์ใน sandbox จริง พร้อมปรับแต่งค่าต่างๆ ด้วยตัวเอง

เข้าถึงบทเรียนแบบอินเทอร์แอกทีฟฉบับเต็มและ playground ได้ที่นี่:

https://academy.dair.ai/resources/jev-decisions-in-a-pi-sdk-harness

ไกด์นี้ได้แรงบันดาลใจมาจากบทความ Building a Harness with Jev ของ Sydney Runkle บนบล็อกของ LangChain ซึ่งแสดงการทำ model routing และ tool gating ในรูปแบบ middleware สำเร็จรูปของ LangChain แต่ในบทความนี้ คุณจะลงมือสร้างแนวคิดเดียวกันด้วยตัวเองบน Pi SDK แล้วเพิ่มอีก 2 แพทเทิร์นสำหรับการจัดการข้อผิดพลาดและการตรวจสอบคำตอบ

สิ่งที่คุณจะได้สร้าง

harness นี้ประกอบด้วย 3 ส่วน แต่ละส่วนจะถามคำถาม Jev ในช่วงเวลาที่ต่างกัน และเราจะเรียกแต่ละส่วนด้วยชื่อเหล่านี้ตลอดทั้งบทความ

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

Jev คืออะไร

TypeSafe เรียก Jev ว่าเป็น System One model ชื่อนี้มาจาก Daniel Kahneman นักจิตวิทยาที่อธิบายโหมดการคิดของมนุษย์ไว้สองแบบ System One คือการคิดที่รวดเร็วและเป็นอัตโนมัติ เหมือนเวลาเรารู้ทันทีว่ากระทะร้อน ส่วน System Two คือการคิดที่ช้าและต้องใช้ความตั้งใจ เหมือนเวลาคิดเลขหารยาว

ใน harness นี้ language model ทั่วไปจะทำหน้าที่หนักอย่างการอ่านไฟล์และเขียนคำตอบ ส่วน Jev จะคอยตัดสินใจเรื่องเล็กๆ รอบๆ อย่างรวดเร็ว Jev ถูกและเร็วพอที่จะใช้ถามได้ทุก tool call ไม่ใช่แค่เฉพาะจุดที่คุณคาดเดาไว้ล่วงหน้าว่าอาจมีความเสี่ยง

ตัวเลขแต่ละตัวคือความน่าจะเป็นระหว่าง 0 ถึง 1 ค่า 0.83 แปลว่า Jev ค่อนข้างมั่นใจว่าคำตอบคือใช่ ส่วน 0.03 แปลว่ามันค่อนข้างมั่นใจว่าคำตอบคือไม่ใช่

ประเภทคำถาม 3 แบบ

ทุก request ที่ส่งไปหา Jev จะมีสองส่วน state คือสถานการณ์ที่คุณต้องการให้ประเมิน เช่น tool call หรือคำสั่งของผู้ใช้ ส่วน questions คือสิ่งที่คุณอยากรู้เกี่ยวกับสถานการณ์นั้น Jev จะตอบทุกคำถามพร้อมกันในครั้งเดียว ดังนั้นการถามสามคำถามจึงใช้เวลาพอๆ กับการถามคำถามเดียว

Jev รองรับคำถาม 3 ประเภท ประเภทแรกซึ่ง Jev เรียกว่า noul คือคำถามแบบใช่หรือไม่ใช่

Jev รู้เฉพาะสิ่งที่คุณบอกเท่านั้น ดังนั้นจงอธิบายทุกตัวเลือกและทุกระดับด้วยภาษาที่เข้าใจง่าย คำอธิบายเหล่านี้แหละคือ prompt

การตั้งค่า

คุณสามารถใช้งาน Jev ได้ผ่าน OpenRouter บริการที่ให้ AI models หลายตัวภายใต้ API key เดียว คีย์นี้จะครอบคลุมทั้ง language model และ Jev ให้ติดตั้งแพ็กเกจ Pi ทั้งสองตัวแล้วตั้งค่าคีย์ของคุณ

1npm install @earendil-works/pi-agent-core @earendil-works/pi-ai

1OPENROUTER_API_KEY=...

Jev มี URL ของตัวเอง แยกจาก URL ของแชทปกติ ควรระบุเวอร์ชันที่ชัดเจนเสมอ เช่น typesafe/jev-1.13 โค้ดไคลเอนต์ทั้งหมดของ Jev ใช้ fetch เพียงครั้งเดียว

1const JEV = "typesafe/jev-1.13";
2
3async function ask(state: unknown, questions: unknown) {
4  const response = await fetch("https://openrouter.ai/api/alpha/decisions", {
5    method: "POST",
6    headers: {
7      "Content-Type": "application/json",
8      Authorization: `Bearer ${process.env.OPENROUTER_API_KEY}`,
9    },
10    body: JSON.stringify({ model: JEV, state, questions }),
11    signal: AbortSignal.timeout(2_000),
12  });
13  if (!response.ok) throw new Error(await response.text());
14  return response.json();
15}

agent จะต้องหยุดรอจนกว่า Jev จะตอบ การเรียกใช้งานจึงถูกตัดจบหากเกินสองวินาที โดยปกติคำตอบจะกลับมาภายใน 200 ถึง 400 มิลลิวินาที

ตำแหน่งที่ Jev เข้ามาทำงาน

คลาส Agent ของ Pi จะรันลูปให้คุณ โดยเปิดโอกาสให้โค้ดของคุณเข้าไปทำงานในช่วงเวลาที่กำหนดไว้ในลูปนั้น จุดเหล่านี้เรียกว่า hooks ซึ่ง harness ของเราจะใช้ hook หนึ่งตัวสำหรับแต่ละส่วนจากทั้งสามส่วน

gate เวอร์ชันแรก

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

1import { Agent } from "@earendil-works/pi-agent-core";
2
3const agent = new Agent({
4  initialState: { systemPrompt, model, tools },
5  streamFn: models.streamSimple.bind(models),
6
7  beforeToolCall: async ({ toolCall, args }) => {
8    const { answers } = await ask(
9      { tool: toolCall.name, arguments: args },
10      {
11        destructive: {
12          type: "noul",
13          instructions: "This tool call destroys or overwrites data that was not created by this run.",
14          criteria: {
15            true: "Deletes files, truncates or overwrites existing content, drops data, or force-pushes over history.",
16            false: "Reads, lists, creates a new file, or appends to a file this run already created.",
17          },
18        },
19      },
20    );
21
22    if (answers.destructive.noul >= 0.65) {
23      return { block: true, reason: "Blocked: this looks destructive.", terminate: true };
24    }
25  },
26});

ค่า 0.65 คือ threshold หรือจุดตัดที่ harness จะเลิกเชื่อถือการเรียกใช้นั้นๆ อะไรก็ตามที่ Jev ให้คะแนนเท่ากับหรือสูงกว่านี้จะถูกบล็อก

ตอนนี้ถ้า agent พยายามจะลบบันทึกของคุณ มันจะถูกหยุดก่อนที่การลบจะเกิดขึ้นจริง การลบบันทึกจะได้คะแนนประมาณ 0.83 ส่วนการอ่านจะได้ 0.01 แต่ gate นี้ยังทำงานแบบหยาบๆ อยู่ เพราะการสร้างไฟล์ใหม่เอี่ยมก็ได้คะแนนประมาณ 0.70 จึงโดนบล็อกไปด้วย

การถามนี้มีต้นทุนต่ำมาก Jev คิดค่าบริการ $0.042 ต่อ input tokens หนึ่งล้านตัว ซึ่งไม่ถึงหนึ่งในสามของราคารับข้อมูลเข้าของ GLM 5.3 Flash ที่เป็นโมเดลราคาถูกกว่าในสองโมเดลที่ harness นี้ใช้งานอยู่

จาก gate แรกสู่ harness ฉบับสมบูรณ์

gate แรกนั้นใช้งานได้ แต่ยังทิ้งช่องโหว่ไว้อีก 4 จุด

1. threshold ถูกฝังอยู่ใน hook ทำให้ปรับแก้หรือทดสอบได้ยาก
2. ทุก request รันบนโมเดลเดียวกันหมด ไม่ว่างานจะง่ายหรือยาก
3. ไม่มีระบบรองรับกรณีที่ติดต่อ Jev ไม่ได้
4. ไม่มีการตรวจสอบว่าคำตอบสุดท้ายดีพอหรือไม่

แต่ละหัวข้อด้านล่างนี้จะช่วยอุดช่องโหว่เหล่านี้ทีละจุด

1. รวม threshold ไว้ในที่เดียว

หัวข้อนี้จะปรับปรุง gate ให้ดีขึ้น

threshold เป็นตัวกำหนดว่า agent ทำอะไรได้บ้าง และคุณจะต้องปรับมันบ่อยๆ เมื่อเห็นผลลัพธ์จริง ดังนั้นให้ย้ายมันออกจาก hook มาไว้ในฟังก์ชันธรรมดาชื่อ decideGate() ฟังก์ชันนี้จะรับตัวเลขจาก Jev แล้วคืนค่าเป็น verdict ซึ่งคือการตัดสินใจขั้นสุดท้ายของ harness เกี่ยวกับการเรียกใช้นั้น การรวมกฎเหล่านี้ไว้ในที่เดียวเรียกว่า policy

policy ยังเพิ่มตัวเลือกตรงกลางเข้ามาด้วย เพราะ threshold เดียวบอกได้แค่อนุญาตหรือบล็อก แต่ถ้ามีสอง threshold จะได้ verdict ถึงสามแบบ

• เท่ากับหรือสูงกว่า blockAt การเรียกใช้จะถูกบล็อก
• ต่ำกว่า askAt การเรียกใช้จะทำงานต่อ
• ถ้าอยู่ระหว่างกลาง การเรียกใช้จะหยุดรอให้คนอนุมัติ

ช่วงตรงกลางนี้จะดักจับการเรียกใช้ที่ Jev ยังไม่แน่ใจ ซึ่งถ้าใช้จุดตัดเดียวอาจตัดสินพลาดไปในทางใดทางหนึ่ง

1export function decideGate(signals: GateSignals, policy = DEFAULT_GATE_POLICY): GateVerdict {
2  const worst = Math.max(
3    signals.destructive.noul,
4    signals.irreversible.noul,
5    signals.outsideWorkspace.noul,
6  );
7  if (worst >= policy.blockAt) return { action: "block", ... };
8  if (worst >= policy.askAt) return { action: "ask", ... };
9  return { action: "allow", ... };
10}

เนื่องจากมันเป็นแค่ฟังก์ชันธรรมดา คุณจึงทดสอบมันได้โดยป้อนตัวเลขแบบด้านบนเข้าไปเลย โดยไม่ต้องพึ่งโมเดลจริง

2. เลือกโมเดลตาม request

หัวข้อนี้จะเพิ่ม router เข้ามา

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

ก่อนที่ request จะเริ่มทำงาน router จะถาม Jev สองคำถามในครั้งเดียว โดย choice จะเลือก tier และ score จะประเมินความซับซ้อนของ request

1const ROUTER_QUESTIONS = {
2  tier: choice("Which model tier should handle this request?", {
3    fast: "Reading one file, pulling a fact out of it, or a small edit in a single place.",
4    powerful: "Work that spans several files, or a failure with no obvious cause.",
5  }),
6  complexity: score("How much reasoning does this request need?", [
7    "Mechanical. One step, no judgement.",
8    "Localized. A few steps inside one area.",
9    "Architectural. Many moving parts or an unknown root cause.",
10  ]),
11};

policy ของ router จะนำคำตอบทั้งสองมาใช้แบบนี้

• หากคะแนน complexity สูง ให้ใช้โมเดลที่ทรงพลัง แม้ว่า Jev จะเลือก fast ไว้ก็ตาม
• หาก Jev ไม่มั่นใจในตัวเลือกของตัวเอง ให้ใช้โมเดลที่ทรงพลังเพื่อความปลอดภัย
• นอกเหนือจากนี้ ให้ใช้โมเดลที่ Jev เลือก

1if (complexity.score >= policy.escalateAtComplexity) return powerful;
2if (tierAnswer.confidence < policy.minConfidence) return policy.fallbackTier;
3return tierAnswer.choice;

นี่เป็นเพียงตัวอย่าง policy หนึ่งเท่านั้น policy ของคุณอาจให้น้ำหนักกับคำตอบต่างออกไปเพื่อให้เหมาะกับงานของคุณ เช่น เน้นใช้ของถูกสำหรับ batch job ปริมาณมาก หรือ escalate ทุกอย่างที่แตะระบบ production เสมอ Jev มีหน้าที่แค่หาคำตอบ โค้ดของคุณจะเป็นคนตัดสินใจว่าจะเอาคำตอบนั้นไปทำอะไรต่อ

ทำไมถึงเลือกแค่ครั้งเดียว

router จะเลือกโมเดลเพียงครั้งเดียวตอนเริ่ม request และใช้โมเดลนั้นไปจนกว่างานจะเสร็จ สาเหตุมาจาก prompt caching

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

ผู้ก่อตั้ง Jev ได้อธิบายการคำนวณตัวเลขนี้ไว้ใน เอกสารออกแบบ coding agents ในการใช้งานเซสชันยาวๆ เซสชันหนึ่ง การสลับจาก Claude Opus ไปใช้ Sonnet ที่ถูกกว่าแล้วสลับกลับมา มีค่าใช้จ่ายมากกว่าการใช้ Opus ตัวเดียวตลอดถึงประมาณ 50% ดังนั้นควรเลือกโมเดลตั้งแต่ต้นตอนที่บทสนทนายังสั้นๆ แล้วใช้ตัวเดิมไปจนจบ

3. เตรียมแผนรับมือเมื่อ Jev ล่ม

หัวข้อนี้จะปรับเปลี่ยนทั้ง gate และ router

เมื่อ harness ถาม Jev เกี่ยวกับทุก tool call แล้ว agent ก็จะพึ่งพา Jev อย่างหลีกเลี่ยงไม่ได้ และเช่นเดียวกับบริการออนไลน์อื่นๆ Jev อาจทำงานช้าหรือล่มได้ คุณจึงต้องตัดสินใจล่วงหน้าว่าแต่ละส่วนจะทำอย่างไรเมื่อไม่ได้รับคำตอบ ซึ่งทางเลือกที่เหมาะสมจะต่างกันไปในแต่ละส่วน

gate จะบล็อกการเรียกใช้ ถ้า gate ถาม Jev ไม่ได้ มันจะไม่รู้เลยว่าคำขอนั้นปลอดภัยหรือไม่ การปล่อยผ่านไปอาจทำให้ไฟล์ถูกลบได้ gate จึงปฏิเสธการทำงาน วิศวกรเรียกสิ่งนี้ว่า failing closed เหมือนประตูที่ล็อกเองเมื่อไฟดับ

router จะใช้โมเดลที่ทรงพลัง ถ้า router ถาม Jev ไม่ได้ มันจะไม่รู้ว่า request นั้นยากแค่ไหน แต่โมเดลที่ทรงพลังจัดการได้ทุกเรื่อง request จึงยังได้คำตอบที่ดี เพียงแต่คุณต้องจ่ายแพงขึ้นนิดหน่อย นี่เรียกว่า failing open คือปล่อยให้งานดำเนินต่อไป

4. ตรวจสอบคำตอบ

หัวข้อนี้จะเพิ่ม verifier เข้ามา ใน agent harness นั้น verifier คือขั้นตอนที่ตรวจสอบผลงานของ agent ก่อนจะถือว่างานเสร็จสมบูรณ์

agent อาจจบงานด้วยคำตอบที่ตกหล่นบางอย่างไป หรืออ้างถึงสิ่งที่มันไม่เคยตรวจสอบในไฟล์จริงๆ คนที่อ่านมักจะดูไม่ออก การตรวจสอบคำตอบก่อนส่งกลับจะช่วยจับปัญหานี้ได้ในขณะที่ agent ยังมีโอกาสลองใหม่

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

1const VERIFY_QUESTIONS = {
2  quality: score("How well does the answer satisfy the request?", [
3    "Does not answer the request.",
4    "Partly answers it, with a gap the reader would notice.",
5    "Fully answers the request.",
6  ]),
7  grounded: noul("Every factual claim is supported by the files or tool results in the transcript."),
8};

มีกฎสองข้อที่ป้องกันไม่ให้ agent ลองใหม่ไม่รู้จบ คือจำกัดให้ลองได้สูงสุดสองครั้ง และเมื่อ Jev ไม่มั่นใจในคะแนนที่ตัวเองให้ harness จะยอมรับคำตอบนั้นแทนที่จะจ่ายเงินเพื่อลองใหม่อีกรอบ

ความปลอดภัยและการเก็บ log

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

gate จะมองแค่ตัว tool call เอง นั่นคือชื่อเครื่องมือและข้อมูลนำเข้า วิธีนี้ช่วยรับมือกับ prompt injection ที่ข้อความซ่อนอยู่ในไฟล์หรือหน้าเว็บหลอกให้โมเดลทำสิ่งที่เป็นอันตราย แม้ gate จะไม่เห็นกลลวงนั้น แต่มันก็ยังเห็นการเรียกใช้ที่เป็นอันตรายที่เกิดขึ้นตามมา

ควรบันทึก log ทุกการตัดสินใจพร้อมกับตัวเลขที่อยู่เบื้องหลัง log จะอธิบายว่าทำไมบางอย่างถึงถูกบล็อก และแสดงตัวเลขจริงเพื่อนำไปใช้ตั้ง threshold โดย harness จะเขียน log หนึ่งบรรทัดต่อการตัดสินใจหนึ่งครั้งลงในไฟล์ชื่อ decisions.jsonl เนื่องจาก gate เห็นทุกสิ่งที่ agent พยายามทำ log จึงซ่อนอีเมลและคีย์ต่างๆ พร้อมทั้งย่อข้อมูลนำเข้าที่ยาวเกินไปให้สั้นลง

ลองใช้งานดู

sandbox ด้านล่างจะรัน harness ฉบับสมบูรณ์จากบทเรียนนี้ โดยเชื่อมต่อกับ Jev จริงๆ มันทำงานกับโฟลเดอร์บันทึกข้อมูลสำรวจเส้นทางเดินป่า และเครื่องมือ delete_path ของมันก็สามารถลบไฟล์เหล่านั้นได้จริง

ลองเล่นได้ที่นี่: https://academy.dair.ai/resources/jev-decisions-in-a-pi-sdk-harness

ทำไมต้องสร้าง harness ของตัวเอง

agent สำเร็จรูปจะตัดสินใจเรื่องเหล่านี้ด้วยกฎที่ฝังมาในตัวมันเอง แต่ custom harness จะย้ายกฎเหล่านั้นมาไว้ในโค้ดของคุณ คุณเป็นคนเลือกโมเดล ตั้ง threshold กำหนดว่าเมื่อไหร่ที่คนต้องเข้ามาแทรกแซง และอ่าน log เพื่อดูเหตุผลที่แท้จริงของการเรียกใช้แต่ละครั้ง

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

การนำไปประยุกต์ใช้ด้านอื่น

สามส่วนนี้สามารถนำไปใช้นอกเหนือจาก coding agents ได้

• บอทตรวจทานโค้ด ให้คะแนนการแก้ไขที่แนะนำแต่ละจุด แล้วแสดงให้คนดูเฉพาะจุดที่คุ้มค่าแก่การอ่าน
• การทำความสะอาดข้อมูล ถามก่อนรวมข้อมูลสองรายการว่าพูดถึงสิ่งเดียวกันหรือไม่ แล้วทิ้งคู่ที่ไม่แน่ใจไว้ให้คนจัดการ
• Document pipelines ให้คะแนนแต่ละหน้าที่ดึงข้อมูลออกมา แล้วรันใหม่เฉพาะหน้าที่ได้คะแนนต่ำ
• คิวรออนุมัติ เฉพาะการเรียกใช้ที่อยู่ในช่วง "ถามคน" เท่านั้นที่จะไปถึงผู้ตรวจสอบที่เป็นมนุษย์

ในทุกกรณี language model จะทำหน้าที่ที่ต้องใช้ความคิดแบบปลายเปิด ส่วน Jev จะคอยตอบคำถามย่อยๆ ที่อยู่รอบๆ งานนั้น

คำถาม threshold และ policy ในบทเรียนนี้เป็นเพียงตัวอย่างเพื่อการเรียนรู้ ไม่ใช่ค่าที่ตั้งมาสำหรับระบบ production เรากำลังทำการ benchmark ว่าการเปลี่ยนแปลง harness เหล่านี้ส่งผลต่อต้นทุนและคุณภาพของคำตอบอย่างไร และจะมีไกด์ติดตามผลพร้อมข้อมูลเหล่านั้นตามมาเร็วๆ นี้

ผมใช้เวลาหนึ่งเย็นนั่งทำไกด์และ sandbox นี้ร่วมกับ Opus 5.5 หากพบปัญหาใดๆ ทัก DM มาบอกได้เลย สามารถคัดลอกบทความนี้ไปป้อนให้ agent ของคุณเพื่อทดลองไอเดียเหล่านี้ต่อได้เลย