“The Ontology is the system at the heart of Palantir’s architecture.” ประโยคนี้สำคัญไม่ใช่เพราะ Palantir เท่านั้น แต่เพราะมันชี้ไปยังปัญหาที่ใหญ่กว่าในยุค Enterprise AI: องค์กรจำนวนมากมีข้อมูลมากขึ้น มีระบบมากขึ้น และมี AI มากขึ้น แต่ยังไม่มี “โครงสร้างความหมาย” ที่ทำให้ระบบทั้งหมดเข้าใจโลกธุรกิจเดียวกัน

ที่ผ่านมา Digital Transformation มักถูกอธิบายผ่านการย้ายข้อมูลขึ้น Cloud การสร้าง Data Lake การทำ Dashboard หรือการใช้ LLM กับเอกสารภายใน แต่ปัญหาที่ลึกกว่านั้นคือข้อมูลในองค์กรไม่ได้ล้มเหลวเพราะไม่มีที่เก็บ ข้อมูลล้มเหลวเพราะแต่ละระบบเข้าใจสิ่งเดียวกันไม่เหมือนกัน ลูกค้าในระบบ CRM อาจไม่ใช่ลูกค้าในระบบบัญชี รายได้ใน Dashboard อาจไม่ใช่รายได้ในระบบการเงิน ความเสี่ยงในระบบ Compliance อาจไม่ใช่ความเสี่ยงในมุมของฝ่ายสินเชื่อ และ entity เดียวกันอาจปรากฏอยู่ในหลายระบบภายใต้ชื่อ รหัส และบทบาทที่แตกต่างกัน

Ontology จึงไม่ใช่เพียง data model หรือ taxonomy แต่เป็นการกำหนดว่าในโลกขององค์กรมีสิ่งใดอยู่ สิ่งเหล่านั้นหมายถึงอะไร สัมพันธ์กันอย่างไร และมีกฎใดใช้ควบคุมการตีความหรือการดำเนินการของระบบ แนวคิดนี้สอดคล้องกับนิยามในเชิง Computer Science ที่มอง ontology เป็นการระบุแนวคิดร่วมอย่างเป็นทางการ ชัดแจ้ง และเครื่องจักรอ่านได้

ในยุค Agentic AI ความสำคัญของ ontology จะเพิ่มขึ้น เพราะ AI ไม่ได้ถูกคาดหวังให้เพียง “ค้นหาและตอบ” แต่ต้องสามารถ “เข้าใจ เชื่อมโยง ตัดสินใจ และลงมือทำ” ภายใต้บริบทขององค์กร หากไม่มี ontology หรือ semantic layer ที่ชัดเจน AI agent จะมีภาษา แต่ไม่มีแผนที่ของโลกธุรกิจที่มันกำลังทำงานอยู่

1. The Real Problem Is Not Data Integration, but Semantic Fragmentation

องค์กรจำนวนมากเข้าใจปัญหาข้อมูลผิดระดับ เมื่อข้อมูลกระจายอยู่หลายระบบ คำตอบทั่วไปคือการทำ data integration: ดึงข้อมูลจาก ERP, CRM, Core System, Spreadsheet, Data Warehouse และเอกสารภายในมาไว้ในที่เดียวกัน แต่การรวมข้อมูลเชิงเทคนิคไม่ได้แก้ปัญหาเชิงความหมาย ปัญหาที่แท้จริงคือ semantic fragmentation หรือการที่ระบบต่าง ๆ ใช้คำเดียวกันต่างความหมาย และใช้คนละคำกับสิ่งที่อาจเป็น entity เดียวกัน

ตัวอย่างในภาคการเงินชัดมาก คำว่า customer อาจหมายถึงผู้ใช้บริการในระบบ CRM, account holder ในระบบธนาคาร, counterparty ในระบบความเสี่ยง, borrower ในระบบสินเชื่อ หรือ beneficial owner ในระบบ KYC แต่ละคำไม่ได้ผิด เพียงแต่เป็นการมอง entity เดียวกันจากมุมของระบบที่ต่างกัน ซึ่งถ้าองค์กรไม่มี ontology ระบบ AI จะต้องเดาเองว่า entity เหล่านี้เกี่ยวข้องกันอย่างไร การเดานี้อาจพอใช้ได้เมื่อคำถามเป็นการสรุปเอกสารทั่วไป แต่จะอันตรายมากเมื่อคำถามเกี่ยวข้องกับความเสี่ยง การอนุมัติ การเงิน หรือการดำเนินการจริง

Ontology จึงทำหน้าที่เป็น semantic contract ระหว่างระบบต่าง ๆ

• Customer ไม่ได้เป็นเพียง field ใน CRM แต่เป็น business entity ที่อาจมีหลาย role

• Account ไม่ได้เป็นเพียงเลขบัญชี แต่เป็น object ที่มี owner, transaction, risk profile และ permission

• Transaction ไม่ได้เป็นเพียง record แต่เป็น event ที่อาจ trigger rule, alert หรือ investigation

นี่คือเหตุผลที่ ontology แตกต่างจาก taxonomy หรือ database schema อย่างมีนัยสำคัญ Taxonomy บอกว่าสิ่งหนึ่งอยู่ในหมวดใด Database schema บอกว่าข้อมูลถูกเก็บในรูปแบบใด แต่ ontology บอกว่าสิ่งนั้นหมายถึงอะไร สัมพันธ์กับสิ่งอื่นอย่างไร และมีกฎอะไรใช้กับมัน

ดังนั้น ถ้า data warehouse คือสถานที่เก็บข้อมูล ontology คือชั้นที่ทำให้ข้อมูลเหล่านั้นกลายเป็นโลกธุรกิจที่ระบบเข้าใจได้

2. Ontology Turns Enterprise Data into an Operating Context

สิ่งที่ทำให้ ontology สำคัญต่อ Enterprise AI ไม่ใช่เพียงการนิยามคำศัพท์ แต่คือการเปลี่ยนข้อมูลให้กลายเป็น operating context ระบบข้อมูลแบบดั้งเดิมมักตอบคำถามว่า “ข้อมูลอยู่ที่ไหน” หรือ “ตัวเลขคืออะไร” แต่ AI ที่ใช้ในองค์กรต้องตอบคำถามที่ซับซ้อนกว่า เช่น: สิ่งนี้คือ entity ประเภทใด?, เกี่ยวข้องกับ entity อื่นอย่างไร?, ความสัมพันธ์นี้มีผลต่อความเสี่ยงหรือไม่?, ผู้ใช้คนนี้มีสิทธิ์เห็นข้อมูลนี้หรือไม่?, ระบบควรดำเนินการอะไรต่อ?, Action ใดต้องมี approval?, ถ้า action นี้เกิดขึ้น จะกระทบ process ใด?

สิ่งที่ทำให้ ontology เริ่มต่างจาก knowledge graph ทั่วไป คือ Knowledge Graph จะบันทึกข้อเท็จจริงว่า entity ใดเชื่อมกับ entity ใด แต่ ontology กำหนดกรอบว่า entity และความสัมพันธ์เหล่านั้นควรถูกเข้าใจอย่างไร รายงานที่ส่งมาสรุปไว้ชัดว่า ontology คือ schema หรือกฎของโดเมน ส่วน knowledge graph คือข้อมูลจริงที่ถูกบันทึกตามแบบแปลนนั้น

ทั้งนี้ ในบริบทขององค์กรยุคใหม่ ontology ต้องไปไกลกว่านั้นอีกขั้น มันไม่ควรหยุดที่ “สิ่งต่าง ๆ เชื่อมกันอย่างไร” แต่ต้องเชื่อมไปถึง “องค์กรสามารถทำอะไรกับสิ่งเหล่านั้นได้บ้าง”

เมื่อ ontology เชื่อม entity, relationship, rule และ action เข้าด้วยกัน มันจะกลายเป็น operating context ที่ AI สามารถใช้วางแผนและดำเนินงานได้ ไม่ใช่แค่ค้นข้อมูล และนี่คือจุดเปลี่ยนสำคัญของ Enterprise AI เพราะ LLM อย่างเดียวเก่งเรื่องภาษา แต่ไม่รู้ operating model ขององค์กร Document RAG ช่วยให้ LLM หาเอกสารที่เกี่ยวข้องได้ แต่ยังอ่อนแอเมื่อต้องเชื่อมข้อมูลหลายระบบหรือ reasoning หลายขั้น จากการศึกษาชี้ให้เห็นว่า ontology ไม่ได้ทำให้ตัว LLM ฉลาดขึ้นโดยตรง แต่ทำให้ retrieval, reasoning และ validation รอบตัวโมเดลมีความแม่นยำและตรวจสอบได้มากขึ้น

กล่าวอีกแบบคือ LLM ทำให้ AI “พูดได้” แต่ ontology ทำให้ AI “รู้ว่ากำลังพูดถึงโลกแบบไหน”

3. Agentic AI Makes Ontology a Strategic Requirement, Not a Technical Luxury

ในยุค chatbot องค์กรอาจยังพออยู่ได้โดยไม่มี ontology ที่ชัดเจน เพราะระบบส่วนใหญ่ทำหน้าที่ตอบคำถามหรือสรุปเอกสาร หากตอบผิด มนุษย์ยังเป็นคนตรวจสอบก่อนนำไปใช้ แต่ Agentic AI เปลี่ยนสมการนี้ Agent ไม่ได้เพียงตอบว่า “ควรทำอะไร” แต่สามารถเรียกใช้เครื่องมือ เปิด workflow ส่งคำขออนุมัติ แก้ไขข้อมูล หรือสั่งให้ระบบอื่นทำงานต่อได้ เมื่อ AI เริ่มมีอำนาจในการดำเนินการ ความเข้าใจผิดในระดับความหมายจะไม่ใช่แค่คำตอบที่คลาดเคลื่อน แต่กลายเป็น operational risk

ตัวอย่างเช่น หาก AI agent ได้รับคำสั่งว่า: “ตรวจสอบลูกค้ากลุ่ม high risk และเริ่มกระบวนการ review”

ระบบต้องรู้ทันทีว่า:

• high risk นิยามจากเกณฑ์ใด

• customer หมายถึง role ไหน

• review เป็น process ประเภทใด

• ต้องดึงข้อมูลจากระบบใด

• ใครมีสิทธิ์เห็นข้อมูล

• action ใดทำได้อัตโนมัติ

• action ใดต้องรอมนุษย์อนุมัติ

• ผลลัพธ์ต้องเขียนกลับไปที่ระบบใด

หากไม่มี ontology agent จะต้องอาศัย prompt, document retrieval หรือ hard-coded workflow แบบแยกส่วน ซึ่งทำให้ระบบขยายยากและควบคุมยาก นี่คือเหตุผลที่ ontology จะถูกพูดถึงมากขึ้นในยุค agentic AI แม้หลายองค์กรอาจไม่ใช้คำว่า ontology โดยตรง บางแห่งอาจเรียกว่า semantic layer, business context layer, enterprise knowledge graph หรือ digital twin แต่แก่นของปัญหาเดียวกันคือ องค์กรต้องมีชั้นกลางที่อธิบายความหมาย ความสัมพันธ์ กฎ และสิทธิ์ของโลกธุรกิจให้ AI ใช้งานได้

ในมุมนี้ ontology ไม่ใช่ project ด้าน data management อย่างเดียว แต่เป็น infrastructure สำหรับ automation เพราะ automated analytics หรือ AI-driven workflow จะทำงานได้ดีต่อเมื่อระบบรู้ว่า metric ใดมาจาก entity ใด entity ใดเชื่อมกับ process ใด และ action ใดได้รับอนุญาตภายใต้ policy ใด

ตัวอย่างในอุตสาหกรรมต่าง ๆ:

• ในธนาคาร ontology อาจใช้เชื่อมลูกค้า บัญชี ธุรกรรม ความเสี่ยง KYC และ workflow การตรวจสอบ

• ในโรงงาน ontology อาจเชื่อม machine, component, supplier, production order, defect, inventory และ maintenance action

• ในธุรกิจพลังงาน ontology อาจเชื่อม asset, sensor, grid, outage, demand forecast, maintenance plan และ safety rule

• ในประกันภัย ontology อาจเชื่อม policyholder, claim, coverage, medical record, fraud signal และ approval workflow

ประเด็นไม่ใช่ว่า ontology เหมาะกับอุตสาหกรรมใดอุตสาหกรรมหนึ่ง แต่เหมาะกับทุกบริบทที่ข้อมูล ความสัมพันธ์ และการดำเนินการมีความซับซ้อนพอที่จะทำให้ AI เดาผิดไม่ได้

Strategic Implication

Ontology ควรถูกมองเป็น capability เชิงกลยุทธ์ ไม่ใช่เอกสาร data dictionary ที่ทีม IT ทำไว้ประกอบระบบ องค์กรที่ต้องการใช้ AI ในระดับ operational ควรถามคำถามที่ลึกกว่า “เราจะใช้โมเดลอะไร” หรือ “เราจะทำ RAG กับเอกสารชุดไหน” ซึ่งคำถามที่สำคัญกว่าคือ

• องค์กรของเรามี business entities ที่ตกลงร่วมกันแล้วหรือยัง?

• คำว่า customer, product, revenue, risk, contract มีนิยามเดียวกันหรือไม่?

• ระบบรู้หรือไม่ว่า entity เหล่านี้สัมพันธ์กันอย่างไร?

• กฎทางธุรกิจถูกเก็บอยู่ในระบบหรืออยู่ในหัวพนักงาน?

• AI มีขอบเขต action และ permission ที่ชัดเจนหรือไม่?

• เราสามารถ audit ได้หรือไม่ว่า AI ตัดสินใจจาก entity, rule และ data ใด?

ถ้าคำตอบคือยังไม่มี การเริ่มใช้ agentic AI ในระดับองค์กรจะยังติดอยู่กับข้อจำกัดเดิม คือระบบพูดเก่งขึ้น แต่ยังไม่เข้าใจองค์กรจริง อย่างไรก็ตาม ontology ไม่ควรถูกสร้างแบบบนลงล่างทั้งองค์กรตั้งแต่วันแรก เพราะจะมีต้นทุนสูงและเสี่ยงกลายเป็นโครงการเชิงสถาปัตยกรรมที่ไม่มีผลลัพธ์ทางธุรกิจ จากศึกษาชี้ให้เห็นว่า เส้นทางพัฒนาที่เหมาะสมควรเริ่มจาก document search, metadata, taxonomy และ entity extraction ก่อนพัฒนาไปสู่ lightweight ontology, knowledge graph และ enterprise semantic layer ตามความจำเป็นของ use case

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

Conclusion

Ontology สำคัญขึ้นไม่ใช่เพราะเป็นคำใหม่ในวงการ AI แต่เพราะ AI กำลังเดินทางจากระบบที่ใช้ภาษาไปสู่ระบบที่ต้องทำงานกับองค์กรจริง เมื่อ AI เพียงตอบคำถาม context อาจเป็นเพียงข้อมูลประกอบ แต่เมื่อ AI ต้องวิเคราะห์ ตัดสินใจ และดำเนินการ context จะกลายเป็น infrastructure ที่สำคัญ ดังนั้น Ontology ซึ่งคือชั้นที่ทำให้ context เหล่านั้นอยู่ในรูปแบบที่ระบบสามารถใช้งานได้ เพราะ มันสามารถกำหนดได้ว่าโลกขององค์กรประกอบด้วย entity ใดบ้าง และ entity เหล่านั้นมีความสัมพันธ์กันอย่างไร กฎใดใช้ควบคุม และ action ใดสามารถเกิดขึ้นได้

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

โดยสรุป องค์กรที่ไม่มี ontology อาจมี AI ที่อ่านข้อมูลได้ แต่องค์กรที่มี ontology จะเริ่มมี AI ที่เข้าใจบริบทของการทำงานจริง ซึ่ง ในปี 2026 Palantir ยังเพิ่ม Ontology MCP ซึ่งเปิดให้ external AI agents เชื่อมกับ ontology ผ่าน Model Context Protocol ได้ โดยองค์กรสามารถจำกัดว่า agent ใดอ่าน object ใดหรือดำเนิน action ใดได้ นี่สะท้อนว่า Ontology กำลังถูกวางตำแหน่งไม่เพียงเป็น backend ของแอป Palantir แต่เป็น governed interface ระหว่างโลกการทำงานจริงกับระบบ AI ภายนอกด้วย