Databricks: Agent ขาดระบบที่เชื่อถือได้ ไม่ใช่ขาดความฉลาด

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

ปลายเดือนตุลาคมมีหัวข้อเรื่อง Databricks ขึ้น trending ใน X ด้วยประเด็นใกล้ ๆ กันนี้ ผมเลยตามไปหาว่า Databricks พูดอะไรไว้จริง ๆ

โพสต์นี้อยู่ในซีรีส์ Critical Thinking ต่อจากCursor Agent SDK ครับ

แหล่งต้นทาง: อะไรที่ผมยืนยันได้ และอะไรที่ยืนยันไม่ได้

ขอแยกให้ชัดก่อนครับ

ยืนยันไม่ได้: หน้า trending ของ X ผมเปิดอ่านไม่ได้ เลยไม่รู้ว่าสรุปในหน้านั้นเขียนว่าอะไร และจะไม่อ้างถึงเนื้อหาในนั้น ผมยังหาประกาศหรือบล็อกของ Databricks เองที่ออกช่วงวันเดียวกันไม่เจอด้วย

ยืนยันได้: หนึ่งวันก่อนหน้านั้น คือ 27 ตุลาคม 2026 Ben Horowitz โพสต์บทความใน X ซึ่งเป็นบทความเดียวกับ "Databricks & the Future of the Firm" ใน a16z News ที่เขาเขียนร่วมกับ Michael McGuiness ช่วงเวลาตรงกัน ผมเลยเดาว่าเป็นต้นเรื่องของ trending แต่ขอย้ำว่าเป็นการเดาจากเวลาที่ใกล้กันเท่านั้น

ในบทความนั้นมีคำพูดของ Ali Ghodsi ซีอีโอของ Databricks ที่ตรงกับหัวข้อนี้ที่สุดครับ

AI does not have an intelligence problem… It has a context problem.

ประเด็นหลักที่ผมสรุปจากบทความได้มีสามข้อ

• SORA Ghodsi บอกว่า "The lakehouse has become the system of record nowadays" และเรียกไอเดียนี้ว่า "SORA – the System of Record for Agents"
• ความรู้ที่อยู่ในหัวคน บทความบอกว่าถ้าจะให้ agent ทำงานเองได้ "much of the ontology, authority, and evaluation that currently lives in people's heads" ต้องย้ายเข้าไปอยู่ใน system of record ขององค์กร และ "authority and evaluation are just as unwritten as ontology"
• สิทธิ์ Ghodsi บอกว่า "You can't grant access to each proprietary, siloed database to your agents" ส่วนบทความเล่าว่า Unity Gateway ให้ agent แต่ละตัวมี "an identity, a budget, and guardrails" และมี trace เก็บทุก action

บทความยังสรุปคำถามที่ system of record ต้องตอบได้ไว้สี่ข้อ คืออะไรคือความจริง มันหมายความว่าอะไร อะไรที่ทำได้ และ "Did it work?"

ข้อควรระวังสองข้อครับ ข้อแรก a16z เป็นนักลงทุนใน Databricks มาตั้งแต่รอบ Series A ปี 2013 และ Fortune รายงานว่า Horowitz นั่งในบอร์ดของ Databricks ด้วย บทความนี้จึงมีมุมที่ช่วยขายบริษัทอยู่ด้วย ข้อสอง ตัวบทความไม่ได้พูดตรง ๆ ว่า "agent ล้มเหลวใน production เพราะขาดระบบที่เชื่อถือได้" หัวข้อโพสต์นี้เป็นการตีความของผมจากประโยค context problem กับคำถามสี่ข้อข้างบน ไม่ใช่คำพูดของ Databricks

ทำไมผมว่าประเด็นนี้ถูก แม้จะมาจากคนขาย

ถ้าตัดชื่อผลิตภัณฑ์ออก สิ่งที่เหลือคือคำถามที่ทีมทำซอฟต์แวร์ต้องตอบอยู่แล้วครับ

ลองเทียบกับพนักงานใหม่ดู คนเก่งมากที่เพิ่งเข้าบริษัทวันแรกก็ยังทำงานพลาดได้ เพราะไม่รู้ว่าลูกค้า VIP คือใคร ไม่รู้ว่าส่วนลดเกินกี่เปอร์เซ็นต์ต้องขออนุมัติ และไม่รู้ว่างานแบบไหนที่หัวหน้าถือว่า "เสร็จ" ความรู้เหล่านี้ไม่มีอยู่ในเอกสาร แต่อยู่ในหัวคน ซึ่งตรงกับที่บทความเรียกว่า ontology, authority และ evaluation

agent ก็เหมือนกันครับ เปลี่ยนไปใช้โมเดลที่ฉลาดขึ้น ก็ไม่ได้ทำให้มันรู้กฎที่ไม่เคยมีใครเขียนลงไป

สิ่งที่ผมไม่ซื้อทั้งหมดคือข้อสรุปว่าคำตอบต้องเป็น lakehouse ตัวเดียว สำหรับโปรเจกต์ลูกค้าขนาดกลางที่ผมทำ system of record อาจเป็นฐานข้อมูลของแอปเอง ระบบ ERP ของลูกค้า หรือแม้แต่ไฟล์ policy ที่มี version ก็ได้ หลักการสำคัญกว่าตัวผลิตภัณฑ์

ต้องสร้างอะไรรอบโมเดล

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

คำถาม	สิ่งที่ต้องสร้าง	ถ้าไม่มีจะเป็นยังไง
อะไรคือความจริง	แหล่งข้อมูลหลักที่ตกลงกันแล้วว่าเชื่อได้ พร้อมเวลาอัปเดตล่าสุด	agent ตอบจากข้อมูลเก่าหรือจากสำเนาที่ไม่ตรงกัน
มันหมายความว่าอะไร	นิยามคำในธุรกิจ เช่น "ลูกค้า active" หรือ "ยอดขาย" นับยังไง	agent คำนวณถูกตามสูตร แต่ผิดตามความหมายที่ธุรกิจใช้
อะไรที่ทำได้	identity ของ agent สิทธิ์ที่จำกัด และจุดที่ต้องให้คนอนุมัติ	agent ทำสิ่งที่ผู้ใช้คนนั้นเองไม่มีสิทธิ์ทำ
มันได้ผลไหม	ชุดทดสอบ (eval) trace และ log ที่ย้อนดูได้	รู้ว่าพังตอนลูกค้าโทรมาแจ้ง

เรื่องสิทธิ์ ผมว่าเอกสารของ Databricks เองอธิบายทางเลือกได้ดีครับ ในหน้า agent authentication มีให้เลือกระหว่างให้ agent ใช้ identity ของตัวเอง กับ "user authorization" ที่ agent ใช้ identity ของผู้ใช้ที่ส่งคำขอมา (เดิมเรียกว่า On-Behalf-Of) โดยแนะนำแบบหลังเมื่อต้องการสิทธิ์รายคน audit trail หรือการควบคุมสิทธิ์แบบละเอียด หลักนี้ใช้ได้กับทุกแพลตฟอร์มครับ agent ไม่ควรมีสิทธิ์มากกว่าคนที่สั่งมัน

ส่วนเรื่อง eval หน้า Evaluate and improve ของ Databricks ตั้งคำถามไว้ว่า response "correct, grounded, safe, and complete" หรือเปล่า ซึ่งเป็นเกณฑ์ที่ผมว่าหยิบไปเขียนเป็น acceptance criteria ได้เลย แบบเดียวกับที่ผมเขียนไว้ในยุค agent = คุณต้องเขียน AC เหมือน PO

สมมติว่าลูกค้าขอ agent ตอบคำถามเรื่องคำสั่งซื้อ

ขอยกตัวอย่างสมมตินะครับ ไม่ใช่โปรเจกต์จริง

สมมติว่าลูกค้าค้าปลีกรายหนึ่งอยากได้ agent ที่ตอบแอดมินว่า "ออเดอร์นี้ส่งถึงไหนแล้ว" และ "คืนเงินได้ไหม" ถ้าทีมผมเริ่มจากเลือกโมเดลแล้วต่อ API ฐานข้อมูลเลย เดโมจะดูดีภายในไม่กี่วัน แต่พอจะขึ้นจริง คำถามเหล่านี้จะตามมา

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

ไม่มีข้อไหนเลยที่โมเดลฉลาดขึ้นแล้วจะตอบแทนเราได้ครับ ทุกข้อต้องเป็นการตัดสินใจของลูกค้า แล้วเขียนลงไปเป็นข้อมูล สิทธิ์ หรือเทสต์ งานส่วนนี้คืองานของ PO และ PM ไม่ใช่งานของ prompt

Checklist ก่อนให้ agent แตะข้อมูลจริง

นี่คือรายการที่ผมจะใช้คุยกับลูกค้าและทีมก่อนเปิด agent ให้ใช้กับข้อมูล production ครับ

ข้อมูลและความหมาย

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

สิทธิ์และการควบคุม

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

การตรวจสอบ

• มีชุดคำถามทดสอบจากเคสจริงของลูกค้า รวมเคสที่ agent ควรปฏิเสธ
• เก็บ trace ว่า agent อ่านอะไร เรียก tool อะไร และตอบอะไร
• รันชุดทดสอบซ้ำทุกครั้งที่เปลี่ยนโมเดล prompt หรือ tool
• มีคนรับผิดชอบดู log และตัดสินว่าผลลัพธ์แบบไหนถือว่า "ใช้ได้"

ถ้าข้อไหนตอบไม่ได้ ผมว่ายังไม่ควรขยับไปข้อถัดไปครับ โดยเฉพาะหมวดสิทธิ์ เพราะความผิดพลาดตรงนั้นแก้ย้อนหลังยากที่สุด

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

ท้ายที่สุด

ผมว่าประโยค "AI does not have an intelligence problem… It has a context problem" มีประโยชน์ ถึงจะมาจากบทความของนักลงทุนที่มีส่วนได้เสียก็ตาม เพราะมันเปลี่ยนคำถามจาก "ใช้โมเดลไหน" เป็น "องค์กรเขียนความจริง กฎ และเกณฑ์ความสำเร็จของตัวเองลงไปแล้วหรือยัง"

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

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