Gemma Delegation: สถาปัตยกรรม 3 ชั้นที่ทำให้ AI Agent ทำงานจริงในงานการเงิน

ในงานสาย Model Risk Management ที่แบงก์ สิ่งที่ผมกังวลมากที่สุดเวลาจะใช้ AI ไม่ใช่ "โมเดลฉลาดพอไหม" — แต่คือ ข้อมูลลูกค้าจะหลุดออกไปไหม และ ค่า API จะพุ่งแค่ไหนถ้ารัน agent ทั้งวัน

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

ระบบที่ผมสร้างขึ้นใน lab ชื่อว่า Gemma Delegation ตอบทั้งสองโจทย์ด้วยสถาปัตยกรรม 3 ชั้น ซึ่งมีหัวใจสำคัญคือ Claude เป็นผู้ ตัดสินใจ ว่าจะส่งงานไปที่ไหน — ไม่ใช่ใครคนเดียวทำทุกอย่าง

1. ทำไมต้องมีระบบ Delegation?

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

ปัญหาที่ 1 — ค่า token สูงเกินควร: งานซ้ำๆ ที่ Claude ทำทุกวัน เช่น แปลงรูปแบบเอกสาร สรุปข้อมูล หรือเขียน log นั้นไม่จำเป็นต้องใช้โมเดลที่ทรงพลังที่สุดเสมอไป แต่ถ้าทุกงานวิ่งผ่าน Claude Sonnet token ก็หมดเร็วและค่าใช้จ่ายก็พุ่ง

ปัญหาที่ 2 — ข้อมูลลับผ่าน cloud: ถ้างานเกี่ยวกับข้อมูลลูกค้า ตัวเลขภายใน หรือบทวิเคราะห์ขององค์กร การส่งผ่าน cloud API ใดก็ตามมีความเสี่ยงด้าน data governance ที่ต้องอธิบายต่อทีม Compliance — โดยเฉพาะในภาคการเงินที่อยู่ภายใต้ข้อกำหนด PDPA และระเบียบของ BoT

ปัญหาที่ 3 — Claude ติดคอ: ถ้าทุกงานต้องรอ Claude ทำเอง งานที่รันพร้อมกันได้จะถูก serialize ให้ทำทีละงาน throughput ต่ำ และ Claude ใช้เวลาไปกับงานที่ไม่ต้องการ reasoning ระดับสูง

Delegation แก้ทั้งสามด้วยการ จับคู่งานกับโมเดลที่เหมาะสม แทนที่จะส่งทุกอย่างไปที่เดียวกัน

ทำไมมันสำคัญกับเรา: สำหรับคนสาย data/risk ในแบงก์ การ delegate ไม่ใช่แค่เรื่องประหยัดเงิน — มันคือการออกแบบระบบให้สอดคล้องกับ constraint จริง: ข้อมูลลับต้องอยู่ภายใน งบประมาณต้องควบคุมได้ และ pipeline ต้องรัน 24/7 โดยไม่ติดขัด

2. สถาปัตยกรรม 3 ชั้น: ใครทำอะไร?

ในระบบของผม โมเดล 3 ตัวรับบทบาทต่างกันอย่างชัดเจน:

ชั้นที่ 1 — Claude (สมองหลักและตัวตัดสินใจ): Claude รับผิดชอบงานที่ต้องการ reasoning ระดับสูง ได้แก่ ออกแบบ experiment วินิจฉัยปัญหาซับซ้อน code review ขั้นสุดท้าย และที่สำคัญที่สุด — ตัดสินใจว่าจะ delegate งานไหนให้ใคร Claude คือ "หัวหน้าทีม" ที่มองภาพรวม ไม่ใช่นักแสดง solo ที่ทำทุกอย่างคนเดียว

ชั้นที่ 2 — gemma local (โมเดลส่วนตัวบน LM Studio): รับงาน sensitive โดยเฉพาะ ทั้งข้อมูลลูกค้า เอกสารภายใน journal ที่มี context จากงาน หรือ content ภาษาไทยที่ต้องการความเข้าใจบริบทเฉพาะ เนื่องจาก gemma รันบนเครื่องส่วนตัว ข้อมูลจึงไม่ออกนอกบ้านเลย ตอบโจทย์ PDPA และ data governance โดยตรงโดยไม่ต้องมีข้อยกเว้นพิเศษ

ชั้นที่ 3 — gemma API (free-tier cloud): รับงานทั่วไปที่ไม่ sensitive เช่น วิเคราะห์ข้อมูลสาธารณะ ทดสอบ guard หรือ prompt ใหม่ สกัดข้อมูลจากเอกสารที่ไม่ลับ หรืองาน lab experiment Claude เลือกส่งมาที่นี่เมื่อประเมินแล้วว่าไม่มีความเสี่ยงด้านข้อมูลและไม่จำเป็นต้องใช้ความสามารถของ Claude เอง

ความสัมพันธ์ระหว่างสามชั้นนี้ไม่ใช่ hierarchy ที่แข็งตัว — มันเป็น collaboration ที่ Claude เห็นภาพรวมและจัดสรรงานตาม constraint ของแต่ละชั้น

ทำไมมันสำคัญกับเรา: คำถาม "AI ตัวไหน safe?" เปลี่ยนเป็น "Claude ตัดสินใจ route ถูกต้องไหม?" ซึ่งตรวจสอบและ audit ได้จากประวัติการ dispatch — ต่างจากการหวังว่า developer จะจำกฎ routing ทุกข้อได้เอง

3. Logic การตัดสินใจ: Claude Route อย่างไร?

ส่วนที่น่าสนใจที่สุดของระบบคือ วิธีที่ Claude ตัดสินใจ ว่าจะ delegate หรือไม่ และถ้าส่งออกจะไปที่ไหน

จากประสบการณ์สร้างและ iterate ระบบนี้มาสองเดือน ผมพบว่า Claude ต้องรู้คำตอบของคำถามหลักสองข้อก่อนทุกงาน:

คำถามที่ 1 — "งานนี้ sensitive ไหม?" ถ้าใช่ → gemma local เสมอ ไม่มีข้อยกเว้น ไม่ว่างานจะง่ายหรือซับซ้อนแค่ไหน ความ sensitive มีน้ำหนักมากกว่า criteria อื่นทั้งหมด

คำถามที่ 2 — "งานนี้จำเป็นต้องใช้ Claude เองไหม?" ถ้าใช่ (งานสำคัญที่มี decision impact สูง code review ขั้นสุดท้าย หรือ context ที่ต้องการ Claude โดยเฉพาะ) → Claude ทำเอง ถ้าไม่ → delegate

ขนาดของ output ที่คาดว่าจะได้ก็เป็นปัจจัยหนึ่งในการตัดสินใจ: งานที่มี output ยาวมากก็ delegate ออกเพื่อประหยัด token Claude ไว้ใช้กับงานที่คุ้มค่ากว่า

สิ่งที่ผมเรียนรู้จากการ iterate: กฎ routing ที่ hardcode ไว้ล่วงหน้า เช่น "ถ้า task_type == X ส่ง Y" ทำงานได้ดีในช่วงแรก แต่เปราะบางเมื่อ workflow เปลี่ยน วิธีที่ robust กว่าคือให้ Claude อนุมานจาก context ของงานแต่ละครั้ง ซึ่งต้องการ system prompt ที่ออกแบบมาดี และนั่นคือส่วนที่ซับซ้อนที่สุดของระบบทั้งหมด

ทำไมมันสำคัญกับเรา: ในงาน risk ที่ข้อมูลเปลี่ยนรูปแบบบ่อย เช่น รายงาน BoT ที่ปรับ format ทุกปี หรือข้อมูล 56-1 ที่มีหลายรูปแบบตามบริษัท การ hardcode routing ต้องอัปเดตตาม แต่ Claude ที่อนุมานจาก context ปรับตัวได้เองโดยอัตโนมัติมากกว่า

4. Speed-First Patching: เมื่อ gemma ทำงานผิดเล็กน้อย

ปัญหาในทางปฏิบัติของ delegation: ลูกน้องทำงานผิดบ้าง แล้วทำอย่างไร?

วิธีที่ผมพัฒนาขึ้นเรียกว่า Speed-First Patching — ถ้า output ของ gemma ผ่านเกณฑ์คุณภาพส่วนใหญ่ (schema ถูก ข้อมูลครบ ส่วนที่ผิดเป็นรายละเอียดเล็กน้อย) Claude จะ patch and proceed แทนที่จะส่งงานกลับให้ gemma ทำใหม่ทั้งหมด

ตัวอย่างจริงจาก lab: gemma สกัดข้อมูลจากเอกสารชุดใหญ่ ข้อมูลส่วนใหญ่ถูกต้อง แต่มีรูปแบบวันที่บางรายการที่ไม่ตรง แทนที่จะ rerun ทั้งงาน (เสียค่า API อีกรอบ + รอเวลาอีก) Claude แก้เฉพาะส่วนที่ผิดแล้วเดินหน้าต่อ ผลลัพธ์สุดท้ายเหมือนกัน แต่ใช้ทรัพยากรน้อยกว่ามาก

ความท้าทายคือ threshold ว่า "ผ่านเกณฑ์เท่าไหร่ถึง patch แทน rerun" ไม่มีสูตรตายตัว ขึ้นอยู่กับประเภทงาน ความ criticality ของข้อมูล และ context ในขณะนั้น QC loop ที่ตรวจสอบ output ก่อนตัดสินใจจึงเป็นส่วนสำคัญที่ต้องออกแบบอย่างรอบคอบ

ทำไมมันสำคัญกับเรา: ในงาน data ที่ต้องประมวลเอกสารปริมาณมาก เช่น งบการเงินหลายไฟล์หรือ 56-1 หลายบริษัทในรอบเดียว การ patch ฉลาดๆ ประหยัดต้นทุนได้มากกว่า "retry until perfect" โดยไม่ลดคุณภาพผลลัพธ์สุดท้าย

5. ผลจริงจาก Lab และข้อจำกัดที่ควรรู้

หลังจากรันระบบ delegation ใน lab มาสองเดือน ผมสังเกตเห็นผลที่ชัดเจนสองด้าน:

ด้านบวกที่เห็นได้ชัด: ข้อมูลลับไม่ออกนอกบ้านเลย เพราะ routing rule ชัดเจนตั้งแต่ต้น ค่าใช้จ่ายจาก Claude ลดลงเพราะงานซ้ำๆ ปริมาณสูงไปที่ gemma API free-tier แทน และ Claude มีเวลาเหลือมากขึ้นสำหรับงานที่ต้องการ reasoning ที่ลึกกว่า ระบบยังรัน 24 ชั่วโมงได้โดยไม่ติดขัด ซึ่งอ่านรายละเอียดเพิ่มเติมได้ที่ ระบบ runner อัตโนมัติ 24/7 และสำหรับกลยุทธ์ควบคุม token cost แบบเต็ม ดูที่ คู่มือควบคุมค่าใช้จ่าย LLM

ข้อจำกัดที่ต้องรู้ก่อนเริ่ม: ระบบ delegation ที่ดีใช้เวลา iterate กว่าจะ stable — routing logic เริ่มต้นออกแบบง่าย แต่ edge case มักปรากฏหลังจาก run จริงสักพัก gemma local ต้องการ hardware ที่รองรับได้ (GPU VRAM เพียงพอ) และ latency สูงกว่า cloud API จึงไม่เหมาะกับงานที่ต้องการ response เร็วมาก นอกจากนี้ QC loop ที่ตรวจ output ของ gemma ก่อน Claude รับต่อเป็นส่วนที่ข้ามไม่ได้ — ถ้าไม่มีจุดตรวจสอบนี้ ข้อผิดพลาดเล็กๆ จะสะสมและแก้ยากขึ้นเรื่อยๆ

ภาพรวม

Gemma Delegation ไม่ใช่แค่เรื่อง "ใช้โมเดล local ประหยัดเงิน" — มันคือการออกแบบระบบ AI ให้สอดคล้องกับ constraint จริงในงานการเงิน: ข้อมูลลับต้องอยู่ภายใน ต้นทุนต้องควบคุมได้ และคุณภาพต้องไม่ตกเมื่อ scale ขึ้น

สถาปัตยกรรม 3 ชั้น — Claude orchestrate, gemma local สำหรับ sensitive, gemma API สำหรับงานทั่วไป — เป็นแนวคิดที่ปรับใช้ได้กับ context อื่น แต่สิ่งที่ทำให้ทำงานจริงอยู่ในรายละเอียด: decision tree ที่แม่นยำ, system prompt สำหรับ gemma แต่ละ backend, QC pipeline ที่ตรวจสอบ output ก่อน patch, และ guard rules ที่อัปเดตตามผล lab

ถ้าอยากได้ ตัวเต็ม + ก็อป workspace ผมไปใช้เลย — decision tree จริง, system prompt template, QC pipeline, และไฟล์ workspace ทั้งหมดที่ใช้อยู่จริง อยู่ใน คอร์ส Claude Code