เราปรับปรุงระบบคัดกรองเรซูเม่ใหม่ด้วยเวิร์กโฟลว์ AI-Native ได้อย่างไร

โพสต์นี้เป็นเรื่องเกี่ยวกับการทดลองเล็กๆ อย่างหนึ่ง คือการเชื่อมต่อฐานข้อมูลการรับสมัครงานของเราใน Notion เข้ากับ Claude Code แล้วรัน dynamic workflow ที่กระจายงานให้ AI agent มากกว่า 100 ตัวทำงานแบบพร้อมกัน เพื่ออ่านเรซูเม่ ให้คะแนนตามเกณฑ์ที่สอดคล้องกัน และตรวจสอบข้ามการตัดสินของกันและกัน จนได้รายชื่อผู้สมัครที่จัดอันดับแล้วซึ่งเราสามารถนำไปใช้ปฏิบัติได้ทันที

ทั้งหมดนี้มีค่าใช้จ่าย $65 และใช้เวลาประมาณ 13 นาทีในการประมวลผลผู้สมัคร 115 คน แต่สิ่งที่น่าสนใจกว่าค่าใช้จ่ายคือคำถามด้านวิธีการที่มันเผยออกมา — เมื่อไหร่ควรใช้กองทัพ agent แทนการใช้เพียงตัวเดียว จะป้องกันไม่ให้ AI ให้คะแนนเฟ้ออย่างไร และการเข้ารหัส "ความยอดเยี่ยม" ให้เป็นสิ่งที่เครื่องจักรสามารถปฏิบัติได้จริงหมายความว่าอย่างไร

1. Dynamic Workflow คืออะไร

เริ่มจากแนวคิดกันก่อน เพราะนี่คือพื้นฐานที่ทุกอย่างที่เหลือตั้งอยู่บนนั้น

การใช้ AI ส่วนใหญ่ในปัจจุบันเป็นไปตามรูปแบบ prompt-and-reply คือส่งข้อความ รับคำตอบ แล้วทำซ้ำ วิธีนี้ใช้ได้ดีกับงานที่ทำครั้งเดียว แต่จะเริ่มยุ่งยากเมื่อคุณต้องทำสิ่งเดียวกันกับวัตถุ 115 ชิ้น — คุณต้องคัดลอกและวางซ้ำ 115 ครั้ง หรือให้บทสนทนาเดียวประมวลผลทีละรายการตามลำดับ ซึ่งจะช้าลงและสับสนมากขึ้นเรื่อยๆ

Dynamic workflow คือโมเดลที่ต่างออกไป: โค้ดที่จัดระเบียบกองทัพ AI agent คุณสมบัติที่กำหนดของมันคือ

• แยก deterministic control flow กับการตัดสินของ AI ออกจากกันอย่างชัดเจน ลูป การกระจายงาน การรวบรวมผลลัพธ์ และการบังคับใช้โควตา ถูกจัดการโดยโค้ด (ทำซ้ำได้ ตรวจสอบได้) ส่วนการตัดสินใจแบบอัตวิสัย (เรซูเม่นี้แข็งแรงพอหรือไม่?) ถูกมอบหมายให้ AI agent
• Fan-out parallelism การเรียก parallel(...) เพียงครั้งเดียวสามารถสร้าง agent อิสระจำนวนหลายสิบหรือหลายร้อยตัวให้ทำงานพร้อมกัน โดยแต่ละตัวทำงานในส่วนของตัวเองโดยไม่ปนเปื้อนซึ่งกันและกัน
• Multi-stage pipelines ผลลัพธ์ของขั้นตอนหนึ่งจะป้อนเข้าสู่ขั้นตอนต่อไป โค้ดจะจัดการการกรอง การจัดอันดับ และการลบข้อมูลซ้ำระหว่างขั้นตอน
• Structured output agent แต่ละตัวจะส่งคืนผลลัพธ์เป็น JSON ที่สอดคล้องกับ schema — ไม่ใช่ข้อความแชทแบบอิสระ — เพื่อให้โค้ดขั้นต่อไปสามารถนำไปใช้ได้โดยตรง

ลองเปรียบเทียบ: บทสนทนาเดียวก็เหมือนกับ การปรึกษาผู้เชี่ยวชาญคนเดียวเป็นเวลาบ่ายวันหนึ่ง ส่วน dynamic workflow ก็เหมือนกับ การรวบรวมคณะกรรมการพิจารณา 125 คน มอบเกณฑ์และไฟล์ผู้สมัครหนึ่งคนให้แต่ละคน รันการพิจารณาทั้งหมดพร้อมกัน ตรวจสอบผลลัพธ์อันดับต้นๆ ข้ามกัน และรวบรวมเป็นรายชื่อที่จัดอันดับแล้ว — โดยตรรกะการรวบรวม การกระจายงาน และการสรุปผลถูกฝังไว้ในสคริปต์

การคัดกรองเรซูเม่เป็นรูปแบบที่เหมาะสมโดยธรรมชาติสำหรับแพทเทิร์นนี้: ปริมาณสูง เกณฑ์ที่สม่ำเสมอ การตัดสินแบบอัตวิสัย ข้อกำหนดด้านความเป็นธรรม

สำหรับการแนะนำเชิงเทคนิคที่ลึกซึ้งกว่านี้: A harness for every task: dynamic workflows in Claude Code

2. Hiring Workflow: เป้าหมายและการออกแบบ

ปัญหา

เรามีจุดปวดหัวที่เป็นรูปธรรม: มีผู้สมัครมากกว่าร้อยคนที่อยู่ในสถานะ "initial review" ในฐานข้อมูลการรับสมัครงานของเราใน Notion โดยไม่มีวิธีที่เป็นไปได้จริงในการประมวลผลด้วยมือโดยไม่เกิด standard drift — มาตรฐานที่คุณใช้กับเรซูเม่ที่ 80 นั้นแทบจะไม่เคยเหมือนกับมาตรฐานที่ใช้ในเรซูเม่ที่ 5

ฉันต้องการทดสอบไอเดียเฉพาะอย่างหนึ่ง: เราสามารถสรุป "สิ่งที่ยอดเยี่ยมมีลักษณะอย่างไรในยุคของ AI agent" ให้เป็นเกณฑ์ที่เครื่องจักรสามารถปฏิบัติได้และมนุษย์อ่านเข้าใจได้ แล้วรันผู้สมัครทั้ง 115 คนผ่านการปรับเทียบมาตรฐานเดียวกันได้หรือไม่?

เป้าหมายไม่ใช่การให้ AI ตัดสินใจจ้างงานอย่างชัดเจน แต่เป้าหมายคือ

1. บีบอัดผู้สมัคร 115 คนให้เหลือ รายชื่อที่จัดอันดับและมีเหตุผลสนับสนุน เพื่อให้ความสนใจของมนุษย์มุ่งไปที่คนที่สมควรได้รับความสนใจนั้นจริงๆ
2. ทำให้เกณฑ์มีความโปร่งใสและปรับแก้ได้ — ถ้าผลลัพธ์ผิด คุณเปลี่ยนไฟล์ Markdown ไม่ใช่แก้โค้ดหรือใช้สัญชาตญาณ

การตัดสินใจด้านการออกแบบสามข้อ

การตัดสินใจที่ 1: เกณฑ์และโค้ดแยกออกจากกันโดยสิ้นเชิง

เกณฑ์การประเมินอยู่ในไฟล์ Markdown แยกต่างหาก (criteria/) ไม่ได้ฝังอยู่ในโค้ด workflow ใครก็ตาม — รวมถึงเพื่อนร่วมทีมที่ไม่ใช่ฝ่ายเทคนิค — ก็สามารถเปลี่ยนพฤติกรรมการคัดกรองได้โดยการแก้ไขไฟล์เหล่านี้

criteria/
├── 00-philosophy.md          Overall philosophy: what we're hiring for + the "raise the bar" rule
├── 01-pedigree.md            Strong academic / early foundation    (weight 20%)
├── 02-ai-agent-fluency.md    AI-native capability                  (weight 35%)
├── 03-grit-problem-solving.md  Problem-solving & overcoming difficulty  (weight 30%)
├── 04-talent-lens.md         Top-talent signal                     (weight 15%)
└── scoring.md                Scoring formula + grade bands + 5% quota rule

มิติทั้งสี่นี้คือ "มาตรฐานความยอดเยี่ยมสำหรับยุคของ AI agent, v0.1" ของเรา ความคิดที่อยู่เบื้องหลังแต่ละข้อคือ

• AI-native capability มีน้ำหนักสูงที่สุด (35%) ในปี 2026 การที่คนหนึ่งใช้เครื่องมือ agentic อย่าง Claude Code เป็นส่วนสำคัญของการทำงานอย่างแท้จริงหรือไม่นั้นเป็นตัวแบ่งประสิทธิภาพการทำงานที่สำคัญ เราลงโทษการใส่คีย์เวิร์ดโดยเฉพาะ — การระบุ "Claude Code" โดยไม่มีหลักฐานโครงการที่ตรวจสอบได้ถือเป็นสัญญาณที่อ่อนแอ
• หลักฐานที่จับต้องได้ของการแก้ปัญหา (30%) เรามองหา "scar tissue" — สิ่งที่สร้างขึ้นเองตั้งแต่ต้นโดยอิสระ เรื่องเล่าของการเอาชนะอุปสรรคที่แท้จริง — ไม่ใช่การทำซ้ำระดับ tutorial
• พื้นฐานที่แข็งแรง (20%) พื้นฐานทางวิชาการทำหน้าที่เป็นตัวแทนของศักยภาพดิบ — เป็นสัญญาณ ไม่ใช่ข้อกำหนด ปริญญาจากมหาวิทยาลัยที่คัดเลือกเข้มงวดแต่มีผลงานปานกลางจะถูกลงโทษ ในขณะที่นักสร้างที่เรียนรู้ด้วยตัวเองโดยไม่มีวุฒิที่มีชื่อเสียงแต่มีผลงานจริงที่ปล่อยใช้งานแล้วจะได้รับคะแนนเสริม
• สัญญาณของบุคคลที่มีความสามารถระดับสูง (15%) มิตินี้ตั้งใจให้เป็นอัตวิสัย โดย prompt จะถามว่า ทีมอย่าง Anthropic หรือผู้ก่อตั้งอย่าง Musk จะต้องการติดต่อคนนี้ทันทีหรือไม่ มันจับความคิดริเริ่ม รสนิยม และความเร็วซึ่งอีกสามมิติจับไม่ได้

การตัดสินใจที่ 2: เข้ารหัส "raise the bar" เป็นข้อบังคับที่แข็ง ไม่ใช่สโลแกน

scoring.md มีกฎที่เข้มงวด: ผู้สมัครที่ไปถึงระดับสูงสุด (S) ต้องมีจำนวนไม่เกิน 5% ของกลุ่มผู้สมัครทั้งหมด หลังจากการให้คะแนนเสร็จสมบูรณ์ทั้งหมด โค้ดจะใช้เพดานทั่วโลก: แม้ว่าผู้สมัครหลายคนจะได้คะแนนอยู่ในช่วง S ตามหลักเทคนิค แต่จะให้ผ่านได้เพียง 5% อันดับต้นเท่านั้น สิ่งนี้ต่อสู้โดยตรงกับความล้มเหลวที่รู้จักกันดี — การให้คะแนนของ AI มักจะผ่อนปรนโดยธรรมชาติ หากไม่มีข้อบังคับที่แข็ง มันจะให้เกรดครึ่งหนึ่งของกลุ่มว่า "ยอดเยี่ยม"

การตัดสินใจที่ 3: เพิ่มการทบทวนแบบ adversarial เพื่อจับคะแนนที่เฟ้อ

การให้คะแนนอย่างเดียวไม่เพียงพอ agent ให้คะแนนตัวเดียวสามารถถูกดึงดูดโดยคำพูดที่ดูน่าประทับใจ เช่น "ตีพิมพ์ในวารสารระดับท็อป" "สร้าง framework ของตัวเอง" ดังนั้นผู้สมัครที่ได้คะแนนอันดับต้นจะผ่านการรอบที่สอง: คณะของ agent "devil's advocate" ซึ่งมีหน้าที่โดยตรงคือ โต้แย้งว่า "คนนี้ไม่สมควรได้รับการจัดอันดับสูงสุด" และดึงคะแนนลงในทุกที่ที่หลักฐานไม่สนับสนุนอย่างเต็มที่

Workflow

Setup 📋 ฐานข้อมูลการรับสมัครงานใน Notion — ดึงข้อมูลด้วย Notion CLI → ไฟล์ข้อมูลที่มีโครงสร้างหนึ่งไฟล์ต่อผู้สมัครหนึ่งคน

AI เฟส 1: การให้คะแนน (115 agent ทำงานพร้อมกัน)

• อ่านไฟล์เกณฑ์ MD ทั้ง 6 ไฟล์ + ไฟล์ข้อมูลของผู้สมัครคนนั้น
• เข้าเยี่ยมชม GitHub / portfolio links อย่างจริงจังเพื่อตรวจสอบหลักฐาน
• ส่งคืน JSON ที่มีโครงสร้าง: คะแนน 4 มิติ + เหตุผล + จุดเด่น + สัญญาณเสี่ยง

Code Deterministic Synthesis

• คำนวณคะแนนรวมแบบถ่วงน้ำหนัก
• จัดเรียงอันดับทั่วโลก คำนวณโควตา 5%
• เลือกผู้สมัครอันดับต้นสำหรับคิวการทบทวนแบบ adversarial

AI เฟส 2: Adversarial Review (Agent ทำงานพร้อมกัน)

• บุคลิก "devil's advocate" ทบทวนผู้สมัครอันดับต้นแต่ละคน
• โต้แย้งการกำหนดระดับสูงสุด
• ดึงคะแนนลงในที่ที่หลักฐานไม่เพียงพอ

Code Deterministic Verdict

• จัดเรียงใหม่โดยใช้คะแนนที่ปรับเทียบแล้ว
• บังคับใช้เพดานแข็ง 5%
• กำหนดระดับเกรดสุดท้าย: S / A / B / C / D

ผลลัพธ์: รายงานที่จัดอันดับ Markdown ที่มีโครงสร้าง พร้อมคะแนนต่อผู้สมัคร เหตุผล และคำตัดสินการทบทวนแบบ adversarial

ขั้นตอนสีน้ำเงิน (การให้คะแนน / การทบทวน) เป็น AI ขั้นตอนสีเทา (การสังเคราะห์ / คำตัดสิน) เป็นโค้ด การแบ่งนี้ตั้งใจ: สิ่งที่เป็นคณิตศาสตร์ — การถ่วงน้ำหนัก การจัดอันดับ การบังคับใช้โควตา — ไปที่โค้ดเพื่อความสามารถในการทำซ้ำได้ สิ่งที่ต้องการการตัดสิน — คนนี้แข็งแรงพอหรือไม่? — ไปที่ AI

3. สิ่งที่เราเห็น: ผลลัพธ์และข้อคิดเห็น

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

สิ่งที่เรารัน

การกระจายตัว

โควตา 5% (5 ที่) ไม่ถูกใช้เลยแม้แต่นิดเดียว — ไม่ใช่โควตาที่ปิดกั้นใคร แต่เป็นเกณฑ์คะแนนขั้นต่ำที่ปิดกั้น ไม่มีใครผ่านเกณฑ์พื้น A-band ได้ด้วยตัวเอง ด้านล่างจะอธิบายว่าเหตุใดสิ่งนี้จึงเป็นสัญญาณที่มีประโยชน์จริงๆ

หน้าตาของอันดับต้นๆ (ไม่ระบุตัวตน)

โดยไม่มีข้อยกเว้น ผู้สมัครที่มีอันดับสูงสุดคือคนที่ สร้าง agent ขึ้นมาจริงๆ — ไม่ใช่คนที่เคยได้ยินเกี่ยวกับ AI:

• #1: นักศึกษาบัณฑิตศึกษาที่สร้าง multi-agent workbench แบบ Claude-Code ขึ้นมาเองตั้งแต่ต้น — รวมถึง agent main loop, tool call parsing, context compression, การสร้าง sub-agent, และ safety gates โค้ดทั้งหมดตรวจสอบได้ ไม่ใช่แค่คำบรรยาย
• #2: นักศึกษาบัณฑิตศึกษาอีกคนที่ deploy ระบบ multi-agent จริงที่เข้าถึงได้สาธารณะ (แอปพลิเคชันในโดเมนเฉพาะ) พร้อมผลงานทางวิชาการที่เพิ่มเข้ามา
• ลึกลงไปอีก: มีคนที่เขียน agent orchestration engine ด้วย Go จากศูนย์ มีคนที่ปล่อย coding agent แบบเบาโดยศึกษาสถาปัตยกรรมของ Claude Code มีคนที่สร้างเกมด้วย local LLM เองภายในเจ็ดวันโดยใช้เครื่องมือ AI ตลอดทั้งกระบวนการ

สิ่งที่พวกเขามีเหมือนกัน: สัญญาณที่แข็งแรงของพวกเขาแทบจะไม่ปรากฏในตัวเรซูเม่เลย — มันอยู่ใน GitHub repos และ portfolio นี่คือเหตุผลว่าทำไม agent ให้คะแนนแต่ละตัวจึงถูกสั่งให้ เข้าเยี่ยมชม link อย่างจริงจังและตรวจสอบหลักฐาน แทนที่จะอ่านแค่ข้อความในเรซูเม่

ข้อคิดเห็นสามข้อ

ข้อคิดเห็นที่ 1: Adversarial review จับคะแนนที่เฟ้อได้จริงๆ

ตัวอย่างที่ชัดเจนที่สุดคือผู้สมัครสองคนแรก หลังจากเฟสการให้คะแนน ทั้งคู่มีคะแนนรวมถ่วงน้ำหนักประมาณ 82 คะแนน — พอที่จะเข้า A band และเฉียดเกณฑ์ S หลังจากการทบทวนแบบ adversarial ทั้งคู่ลงมาอยู่ที่ประมาณ 75 คะแนน พร้อมเหตุผลที่เฉพาะเจาะจงมาก:

"สร้าง multi-agent workbench ที่ตรวจสอบได้ — AI-native capability เป็นสัญญาณที่แข็ง แต่โครงการมีอายุ ~3 สัปดาห์ ผู้ร่วมพัฒนาคนเดียว 0 stars ไม่มี test ในเชิงแนวคิดเป็นการนำมาสร้างซ้ำ ไม่ใช่การแก้ปัญหาที่เป็นต้นฉบับ แทบไม่มีหลักฐานสนับสนุนเพิ่มเติมนอกจากบรรทัดวุฒิการศึกษา: เป็นผู้สมัครที่มีศักยภาพสูงและมั่นคง แต่ไม่ใช่ระดับยอดเยี่ยม"

"เป็นนักสร้าง AI-native ที่แท้จริงและตรวจสอบได้ แต่การอ้างว่าตีพิมพ์ในวารสารระดับท็อป ปรากฏเพียงในบันทึกของ recruiter โดยไม่มีแหล่งที่มาที่ตรวจสอบได้อย่างอิสระ backend หลักของระบบเป็นแบบ private ไม่สามารถยืนยันการมีส่วนร่วมของแต่ละบุคคลได้ การใช้วุฒิทางวิชาการที่ไม่ได้ตรวจสอบเพื่อเอื้อมไปสู่ระดับสูงสุดคือคะแนนที่เฟ้อจากการขับเคลื่อนด้วยคีย์เวิร์ด"

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

ข้อคิดเห็นที่ 2: S:0 / A:0 ไม่ใช่บั๊ก — มันคือกระจกสะท้อน

สัญชาตญาณแรกคือการถามว่ามาตรฐานถูกกำหนดผิดหรือไม่ แต่มองกลุ่มผู้สมัครอย่างตรงไปตรงมา:

• ผู้สมัครส่วนใหญ่มีเรซูเม่ที่บางมาก — มิติสำคัญ (ประสบการณ์ AI ผลงานที่ตรวจสอบได้) หายไปโดยสิ้นเชิง
• ผู้สมัครหลายคนสำหรับบทบาท Agent Engineer ไม่มีหลักฐานการใช้เครื่องมือ agentic เลยและไม่มี link GitHub
• กลุ่มผู้สมัครยังมีอีเมลธุรกิจของ recruiter และการแจ้งเตือนระบบของ LinkedIn — สิ่งเหล่านี้ถูกระบุอย่างถูกต้องว่าไม่เกี่ยวข้องและได้คะแนน 0 ซึ่งบังเอิญเผยให้เห็นว่าฐานข้อมูลการรับสมัครงานของเราต้องการการทำความสะอาด

พูดอีกอย่างคือ เกณฑ์ที่เข้มงวดแยกสัญญาณออกจากเสียงรบกวนได้อย่างชัดเจน ผู้สร้างที่แท้จริง (อันดับต้น 6 คน) และ "ผู้มีความสามารถทั่วไปที่มีผลงาน" (ระดับกลาง) จบลงในตำแหน่งที่แยกจากกันอย่างชัดเจน นั่นคือประเด็น — พลาดไปบ้างดีกว่าให้คะแนนเฟ้อทุกคน

สิ่งนี้ยังเผยคำถามที่เปิดกว้างซึ่งควรค่าแก่การพูดถึง: เกณฑ์ A-band ปัจจุบัน (78 คะแนน) เข้มงวดเกินไปสำหรับผู้สมัครที่เป็นนักศึกษาซึ่งมีประวัติ GitHub ที่แข็งแรงแต่ยังไม่มีประวัติการทำงานอาชีพหรือไม่? ที่น่าสนใจคือ agent ทบทวนแบบ adversarial เองก็อธิบายว่าสองคนแรกเป็น "ผู้สมัครที่มีศักยภาพสูง" — แต่คะแนนถ่วงน้ำหนักยังคงให้พวกเขาอยู่ใน B band การจะผ่อนปรนเกณฑ์นั้นสำหรับผู้สมัครที่มีศักยภาพสูงในช่วงต้นอาชีพหรือไม่นั้นเป็นการตัดสินใจที่ควรทำหลังจากที่เราเห็นคุณภาพการสัมภาษณ์จริงจากกลุ่ม B แล้ว ข่าวดีคือ การเปลี่ยนแปลงนั้นเป็นแค่ตัวเลขหนึ่งตัวในไฟล์ Markdown หนึ่งไฟล์ ไม่ต้องแก้โค้ดเลย

ข้อคิดเห็นที่ 3: "Criteria as code" ทำให้ความเห็นต่างมีประสิทธิผล

บทสนทนาเกี่ยวกับมาตรฐานการรับสมัครงานมักจะคลุมเครือ — "เราต้องการคนที่มีความมุ่งมั่น" "คนที่หาทางแก้ปัญหาได้" เพราะเกณฑ์นี้ถูกเขียนลงพร้อมน้ำหนักและตัวอย่างอ้างอิง บทสนทนากลายเป็นรูปธรรมทันที: "ความสามารถด้าน AI ควรเป็น 35% หรือ 40%?" "นักสร้างที่โดดเด่นโดยไม่มีวุฒิการศึกษาที่มีชื่อเสียงได้ประโยชน์มากแค่ไหนจริงๆ?" "โควตาควรเป็น 5% หรือ 8%?" — ความเห็นต่างทุกข้อสอดคล้องกับบรรทัดที่เฉพาะเจาะจงในไฟล์ Markdown ซึ่งสามารถเปลี่ยนแปลง ควบคุมเวอร์ชัน และถกเถียงได้ มาตรฐานจึงกลายเป็นสินทรัพย์ที่คุณดูแลรักษา ไม่ใช่ความเห็นพ้องที่ต้องพูดซ้ำในทุกที่ประชุม

4. ค่าใช้จ่ายและ ROI

ค่าใช้จ่ายที่แน่นอน

เราใช้ Claude Opus 4.8 (ระดับสูงสุด) รายละเอียดที่แม่นยำตามหมวดหมู่ token:

นั่นคือเฉลี่ยประมาณ $0.57 ต่อผู้สมัครหนึ่งคน

ข้อค้นพบที่ขัดกับสัญชาตญาณ: การเขียน cache เป็นค่าใช้จ่ายรายการที่มากที่สุด

สมมติฐานธรรมดาคือเพราะ agent ทั้ง 115 ตัวกำลังอ่านไฟล์เกณฑ์ทั้ง 6 ไฟล์เดียวกัน prompt caching ควรจะช่วยได้มาก แต่มันไม่ช่วยในแบบที่คุณคิด

Prompt caching ทำงานบนการจับคู่ prefix ที่ตรงกันทุกตัวอักษร และแต่ละ agent session เป็นอิสระจากกัน agent 125 ตัวหมายถึง 125 session ที่เป็นอิสระ — แต่ละตัวมีคำอธิบายงานที่ต่างกัน (ข้อมูลผู้สมัครที่ต่างกัน) — ดังนั้น cache ที่เขียนโดย agent A ไม่สามารถถูก hit โดย agent B ได้ การ cache ช่วยได้เฉพาะภายในการทำงานแบบหลายรอบของ agent ตัวเดียวเอง (อ่านเกณฑ์ → เข้าดู GitHub → เข้าดู portfolio → ส่งผลลัพธ์ อ่านเนื้อหาก่อนหน้าซ้ำในแต่ละรอบ)

นี่เผยให้เห็นข้อแลกเปลี่ยนด้านสถาปัตยกรรม: fan-out parallelism ทวีค่าใช้จ่ายในการเขียน cache (แต่ละ agent สร้าง cache ของตัวเอง) แต่แลกมาด้วยการตัดสินที่เป็นอิสระ ไม่ปนเปื้อนกัน และกำจัดการสะสม context แบบ quadratic ของการประมวลผลตามลำดับ สำหรับงานที่คุณภาพการตัดสินสำคัญ ข้อแลกเปลี่ยนนั้นคุ้มค่า

วิธีคิดเรื่อง ROI

เปรียบเทียบตรงกับการทบทวนด้วยมือ: hiring manager อ่านเรซูเม่หนึ่งฉบับอย่างละเอียด ตรวจดู GitHub และเขียนบันทึก — อย่างระมัดระวังคือ 5 ถึง 10 นาทีต่อผู้สมัครหนึ่งคน สำหรับ 115 คน นั่นคือ 10 ถึง 19 ชั่วโมงของงานที่ต้องจดจ่อ โดยมาตรฐานจะเปลี่ยนแปลงไปตลอดทาง

Workflow นี้ให้ผลลัพธ์:

แต่ ROI ที่สำคัญกว่านั้นคือด้านความสนใจ: มัน เปลี่ยนทิศทางความสนใจของมนุษย์จากผู้สมัคร 83 คนที่ไม่เหมาะสมอย่างชัดเจน ไปสู่ผู้สร้างที่แท้จริง 6 คน ที่อยู่ในอันดับต้น นั่นคือสิ่งที่มีค่าสูงสุดที่การคัดกรองขั้นแรกทำได้

จะทำให้ถูกกว่านี้ได้หรือไม่?

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

• ใช้ Sonnet สำหรับเฟสการให้คะแนน และใช้ Opus เฉพาะสำหรับ adversarial review — น่าจะลดค่าใช้จ่ายได้ 70 ถึง 80% โดยสูญเสียคุณภาพน้อยที่สุด
• หรือใช้โมเดลที่ถูกกว่าสำหรับการตรวจสอบแรกแบบหยาบๆ แล้วใช้ Opus สำหรับการประเมินอย่างละเอียดของกลุ่มอันดับต้น

แต่การรับสมัครงานเป็นสิ่งที่ มีความถี่ต่ำ มีความเสี่ยงสูง และยากที่จะย้อนกลับ ด้วยค่าใช้จ่าย $65 ในการประมวลผล pipeline ทั้งหมดพร้อมความสามารถในการตรวจสอบได้เต็มที่และเกณฑ์ที่ปรับแก้ได้ ข้อสรุปชัดเจน: ใช้โมเดลที่ดีที่สุด อย่าแลกคุณภาพการตัดสินกับการประหยัดค่าใช้จ่ายเพียงเล็กน้อย

ภาพรวมที่ใหญ่กว่า

สิ่งที่น่าตื่นเต้นจริงๆ ในการทดลองนี้ไม่ใช่ "AI สามารถคัดกรองเรซูเม่ได้" — นั่นไม่ใช่ไอเดียใหม่ แต่คือ โมเดล dynamic workflow — โค้ดที่จัดระเบียบกองทัพ AI agent — ทำให้งานบางประเภทมีโครงสร้าง ทำซ้ำได้ และปรับแก้ได้เป็นครั้งแรก

การรับสมัครงานเป็นเพียงจุดเริ่มต้น แพทเทิร์นเดียวกัน — เกณฑ์ในรูปแบบไฟล์ที่อ่านได้ + การประเมินแบบ fan-out parallel + การทบทวนแบบ adversarial + การรวบรวมแบบ deterministic — สามารถถ่ายโอนไปยังโดเมนใดก็ได้ที่คุณต้องทำการตัดสินแบบอัตวิสัยที่สอดคล้องและมีปริมาณสูง เช่น การกลั่นกรองเนื้อหา การรีวิวโค้ด การจัดลำดับความสำคัญของ feedback ผู้ใช้ การวิเคราะห์คู่แข่ง การตรวจสอบความถูกต้อง (due diligence)

เกณฑ์นี้เป็น v0.1 มันไม่สมบูรณ์แบบ แต่ตอนนี้มันเป็น สินทรัพย์ที่มีเวอร์ชัน ถกเถียงได้ และปรับปรุงได้ — ไม่ใช่ข้อตกลงโดยปริยายที่อยู่ในหัวของใครคนหนึ่ง การเปลี่ยนแปลงนั้น มากกว่าผลลัพธ์เฉพาะใดๆ คือสิ่งที่การทดลองนี้ต้องการสื่อจริงๆ