Databricks Genie: ก่อนให้ AI Agent ลงมือ ต้องมี Context Layer ที่ไว้ใจได้

Databricks เปิดตัว Genie One, Genie Agents และ Genie Ontology เมื่อวันที่ 16 มิถุนายน 2026

ถ้าอ่านเร็ว ๆ นี่อาจดูเป็นข่าว enterprise AI อีกชิ้นหนึ่งครับ มี AI coworker, มี agent, มี ontology, มี integration กับ Slack, Microsoft Teams, mobile app และ MCP-based assistant experiences

แต่ประเด็นที่ผมว่าสำคัญไม่ใช่ชื่อ product ประเด็นคือวิธีคิดที่อยู่ข้างหลังมัน

Databricks กำลังชี้ไปที่ปัญหาใหญ่ของ AI Agent ในองค์กร:

Agent ไม่ได้ต้องการแค่โมเดลที่เก่งขึ้น แต่ต้องการบริบทที่ถูกต้องก่อนลงมือ

1) ปัญหาจริงของ AI ในธุรกิจไม่ใช่แค่ “ตอบได้ไหม”

ใน demo ส่วนใหญ่ AI ดูเก่งมากครับ ถามอะไรตอบได้ สรุปเอกสารได้ เขียนข้อความได้ สร้าง code ได้

แต่พอเข้าไปในธุรกิจจริง ปัญหาจะเริ่มเปลี่ยนจาก “โมเดลฉลาดไหม” เป็น “โมเดลรู้บริบทจริงไหม”

เช่น ถ้าถามว่า “ยอดขายเดือนนี้ดีขึ้นไหม” AI ต้องรู้มากกว่าเลขยอดขาย

มันควรรู้ว่า:

• dashboard ไหนคือ source of truth
• นิยามคำว่า “ยอดขาย” ในบริษัทนี้นับจาก invoice, payment หรือ order
• refund ถูกหักแล้วหรือยัง
• channel ไหนถูกจัดกลุ่มอย่างไร
• ลูกค้าประเภทไหนควรถูกแยกดู
• ตัวเลขนี้ใช้สำหรับ decision แบบไหน

ถ้า AI ไม่รู้สิ่งเหล่านี้ มันอาจตอบได้ครับ แต่คำตอบอาจเป็นคำตอบที่ “ดูดีแต่ใช้ผิด”

นี่คือจุดที่ธุรกิจต้องระวังมากกว่า hallucination แบบตลก ๆ เพราะคำตอบผิดในรายงาน, CRM, support, finance หรือ operation อาจทำให้ทีมตัดสินใจผิดจริง

2) Genie Ontology คือ signal ว่า agent ต้องมีชั้นบริบท

จากบทความของ Databricks, Genie Ontology ถูกวางเป็น unified context layer หน้าที่คือดึงและจัดระเบียบความรู้จาก data assets และ connected tools เพื่อให้ Genie รู้ว่าอะไรควรเชื่อและควรตอบอย่างไรในบริบทของบริษัท

พูดง่าย ๆ คือไม่ปล่อยให้ agent ไปเดาเอาเองว่า:

• metric นี้คืออะไร
• table ไหนสำคัญ
• dashboard ไหนเชื่อได้
• document ไหนเกี่ยวข้อง
• workflow ไหนเป็นของทีมไหน
• action นี้ควรทำต่อหรือแค่เสนอให้คนตรวจ

สำหรับองค์กรใหญ่ นี่อาจเป็น ontology เต็มระบบ

สำหรับ SME หรือทีมเล็ก ผมไม่คิดว่าต้องเริ่มด้วยระบบใหญ่ขนาดนั้นครับ แต่หลักคิดเดียวกันใช้ได้ทันที

ก่อนสร้าง agent ให้ถามว่า:

AI ตัวนี้ใช้ context จากไหน และเราพิสูจน์ได้ไหมว่า context นั้นถูกต้องพอสำหรับงานนี้

ถ้ายังตอบไม่ได้ แปลว่า agent อาจยังไม่ควรถูกให้ลงมือเอง

3) จาก Chatbot ไปเป็น Agent จุดเสี่ยงเปลี่ยนทันที

Chatbot ตอบผิด เรายังมีโอกาสอ่านก่อนเชื่อ

แต่ Agent ต่างออกไป เพราะมันอาจทำงานต่อจากคำตอบ เช่น:

• สร้าง task ใน project management
• ส่ง email follow-up
• เขียน proposal
• แก้ไฟล์
• เปิด ticket
• เปลี่ยนข้อมูลใน CRM
• สรุปตัวเลขให้ผู้บริหาร
• เรียก tool หรือ API ต่อ

ถ้า context ผิด การลงมือก็ผิดตาม

นี่คือเหตุผลที่ผมมองว่า agent stack ควรมี 4 ชั้น ไม่ใช่แค่ prompt กับ model

1) Context layer บอกว่า agent ควรรู้อะไร และควรเชื่อ source ไหน

2) Permission layer บอกว่า agent มีสิทธิ์อ่านหรือทำอะไรได้บ้าง

3) Approval layer บอกว่างานไหนทำเองได้ งานไหนต้องให้คนตรวจ

4) Proof layer บอกว่า agent ใช้ข้อมูลอะไร คิดอย่างไร ทำอะไรไปแล้ว และย้อนกลับไปตรวจได้ไหม

Databricks signal วันนี้เน้น context layer Teleport Beams signal ในวันเดียวกันก็เน้น identity, LLM Proxy และ audit สำหรับ agent ที่แตะ production infrastructure

สองเรื่องนี้ประกบกันพอดีครับ ด้านหนึ่งบอกว่า agent ต้องรู้บริบท อีกด้านหนึ่งบอกว่า agent ต้องมีตัวตน สิทธิ์ และ log

4) บทเรียนสำหรับธุรกิจไทย: อย่ารีบทำ agent ก่อนทำแผนที่บริบท

หลายทีมเริ่มจากคำถามว่า “จะให้ AI Agent ทำอะไรดี”

คำถามนี้ไม่ผิดครับ แต่ยังไม่พอ

ผมแนะนำให้เพิ่มอีก 5 คำถามก่อนเสมอ:

1) งานนี้ใช้ข้อมูลจาก source ไหน 2) ถ้า source ขัดกัน จะเชื่ออันไหน 3) คำศัพท์ธุรกิจที่สำคัญนิยามไว้อย่างไร 4) Action ไหนให้ AI ทำเองได้ และ action ไหนต้องรอ approval 5) ถ้าผลลัพธ์ผิด จะตรวจย้อนหลังจาก log อะไร

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

ตัวอย่างง่าย ๆ:

ถ้าจะทำ agent ช่วยตอบลูกค้าจาก CRM และ knowledge base อย่าเริ่มจาก prompt ว่า “ตอบลูกค้าให้ดี”

ให้เริ่มจากแผนที่บริบทก่อน:

• ข้อมูลลูกค้ามาจาก CRM ตัวไหน
• product facts มาจากหน้าไหน
• ราคาและ promotion มาจาก source ไหน
• ถ้าลูกค้าถามเรื่อง refund ต้องส่งต่อใคร
• ถ้าคำตอบไม่มั่นใจ ต้องตอบอย่างไร
• มี log conversation และ source citation หรือไม่

นี่คือสิ่งที่ทำให้ agent ใช้ได้จริงในธุรกิจ ไม่ใช่แค่ดูฉลาดใน demo

5) ทำไม open-weight model ก็ยิ่งทำให้เรื่องนี้สำคัญ

ในกรอบข่าวเดียวกัน Z.ai เปิดตัว GLM-5.2 เป็น open-weight model สำหรับ long-horizon tasks พร้อม 1M-token context และ MIT license

นี่เป็น signal อีกด้านหนึ่งว่า model ฝั่งเปิดกำลังเก่งขึ้นมาก โดยเฉพาะงาน coding agent และงานยาวหลาย step

แต่ยิ่ง model เก่งขึ้น ยิ่งต้องมี context และ control ชัดขึ้นครับ

เพราะโมเดลที่ทำงานได้ยาวขึ้น อาจช่วยทำงานได้ลึกขึ้น แต่ถ้า context ผิด มันก็จะพา workflow ผิดไปไกลขึ้นเช่นกัน

ดังนั้นคำถามสำหรับ operator ไม่ใช่แค่ “ควรใช้ model ไหน” แต่คือ:

เรามีระบบให้ model ใช้ข้อมูลที่ถูกต้อง, จำกัดสิทธิ์ถูกจุด, และตรวจ proof ได้หรือยัง

Operator Kit: Agent Context Map ก่อนปล่อย Agent ลงงานจริง

ใช้ checklist นี้ก่อนสร้าง agent ที่แตะข้อมูลธุรกิจ, ลูกค้า, code, finance หรือระบบหลังบ้านครับ

Step 1: ระบุงานให้แคบ

เขียนให้ชัดว่า agent ทำงานอะไร 1 งาน

ตัวอย่างที่ดี:

• สรุป lead ใหม่และเสนอ next action ให้ sales ตรวจ
• ตรวจ ticket support แล้วแนะนำ macro reply
• สรุปรายงานยอดขายรายวันจาก dashboard ที่กำหนด

ตัวอย่างที่กว้างเกินไป:

• ช่วยดูแลลูกค้า
• เป็นผู้ช่วยฝ่ายขาย
• ทำ operation ให้ทีม

Step 2: ระบุ source of truth

ตอบให้ได้ว่า agent ต้องอ้างอิงข้อมูลจากไหน

• CRM: customer profile, deal stage, owner
• Knowledge base: product facts, FAQ, policy
• Data dashboard: metric, revenue, lead, conversion
• Document repo: SOP, contract template, internal policy
• Chat or ticket system: customer conversation history

ถ้ามีหลาย source ให้เขียน rule ว่า source ไหนชนะเมื่อข้อมูลขัดกัน

Step 3: นิยามคำศัพท์ธุรกิจ

เลือกคำสำคัญ 5 ถึง 10 คำที่ agent ห้ามตีความเอง

ตัวอย่าง:

• lead qualified หมายถึงอะไร
• active customer นับจากอะไร
• revenue นับก่อนหรือหลัง refund
• urgent ticket คืออะไร
• VIP customer คือกลุ่มไหน

นี่คือ mini ontology ของทีมเล็กครับ ไม่ต้องเริ่มใหญ่ แต่ต้องเริ่มจากคำที่ทำให้คนตัดสินใจผิดได้

Step 4: แยก read, suggest, act

แบ่งสิทธิ์ agent เป็น 3 ระดับ

Read อ่านข้อมูลและสรุปได้

Suggest เสนอ action ได้ แต่คนต้องตรวจ

Act ลงมือในระบบได้เอง เฉพาะงานที่ความเสี่ยงต่ำและ rollback ง่าย

ถ้างานเกี่ยวกับเงิน, สัญญา, customer data, production system หรือ public posting ควรเริ่มจาก read และ suggest ก่อน

Step 5: ตั้ง approval gate

เขียน rule ง่าย ๆ ว่าอะไรต้องให้คนกด approve

ตัวอย่าง:

• ส่งข้อความหาลูกค้าจริง ต้อง approve
• เปลี่ยนข้อมูล CRM สำคัญ ต้อง approve
• สรุปรายงานให้ผู้บริหาร ส่ง draft ให้คนตรวจ
• ลบไฟล์, deploy, refund, discount ต้องห้ามทำเอง

Step 6: เก็บ proof ให้ตรวจย้อนหลังได้

อย่างน้อยควรเก็บ:

• input ที่ agent เห็น
• source ที่ agent อ้าง
• output ที่ agent สร้าง
• tool หรือ API ที่ถูกเรียก
• คนที่ approve
• เวลาและผลลัพธ์สุดท้าย

ถ้าไม่มี proof อย่าเรียกว่า automation ที่พร้อมใช้งานครับ ให้เรียกว่า experiment ที่ยังต้องมีคนเฝ้า

สรุป

ในความเห็นของผม Databricks Genie รอบนี้ไม่ใช่แค่ข่าว product launch

มันเป็นสัญญาณว่า phase ต่อไปของ AI Agent จะไม่ได้วัดกันที่ model อย่างเดียว แต่จะวัดกันที่ว่าใครทำ context, permission, approval และ proof ได้ดีกว่า

สำหรับธุรกิจไทย บทเรียนคืออย่ารีบสร้าง agent ที่ลงมือได้เองเพียงเพราะ model เก่งขึ้น

เริ่มจาก Agent Context Map ก่อน: รู้แหล่งข้อมูล, รู้คำศัพท์ธุรกิจ, จำกัดสิทธิ์, ตั้ง approval gate, และเก็บ proof

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