คลังความรู้ของคุณกับฐานข้อมูลของคุณไม่เคยมาเจอกัน นี่คือเหตุผลที่ต้องมี Knowledge Engineering

ลองถามคำถามจริงกับองค์กรของคุณ แล้วดูว่าคำตอบถูกประกอบขึ้นมาอย่างไร

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

ไม่มีระบบไหนตอบคำถามนี้ได้ คนต่างหากที่เป็นคนตอบ โดยเปิดทั้งสองระบบขึ้นมา แล้ว Join มันเข้าด้วยกันในหัวตัวเอง

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

Business Intelligence แก้ไปได้ครึ่งหนึ่ง และแก้ได้ดีด้วย คุณเอาเครื่องมือไปจ่อที่ฐานข้อมูล แล้วถามได้เสียทีว่าเกิดอะไรขึ้น กี่ครั้ง เท่าไร ภูมิภาคไหน ตั้งแต่เมื่อไร องค์กรส่วนใหญ่ยังเดินอยู่บนสิ่งนี้ และยังทำอยู่ต่อไป เนื่องจากทางเลือกไม่ได้มีมากนัก ที่แย่กว่านั้นคือมันไม่สามารถเข้าใจข้อความในเอกสาร มันบอกได้ว่าใช้เงินไปเท่าไร แต่บอกไม่ได้ว่านโยบายยอมให้ใช้หรือไม่

ระบบ Retrieval แก้อีกครึ่งหนึ่ง เอาโมเดลไปจ่อที่คลังเอกสาร ถามด้วยภาษาคนว่านโยบายเขียนไว้ว่าอย่างไร แล้วได้คำตอบพร้อมแหล่งอ้างอิง อันนี้ก็ของจริง ใช้งานกันแพร่หลาย แต่มันไม่เคยแตะแถวข้อมูลสักแถว มันตอบจากสิ่งที่ถูกเขียนไว้ ไม่เคยตอบจากสิ่งที่เกิดขึ้นจริง

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

เลเยอร์ Knowledge Engineering มองข้อมูลคู่นี้เป็นหน่วยเดียวกัน

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

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

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

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

ใน Orchestration ทั่วไป Agent หรือโค้ดที่เขียนขึ้น (เรียกว่า Flow) จะดึงข้อมูลจากหลายฐานข้อมูลและหลายเอกสารมารวมกันเอง แล้วส่งให้โมเดลทันที เมื่อการรวมเกิดขึ้นเองแบบนี้ ข้อมูลที่ถูกรวมจึงไม่ได้ผ่าน Gate เมื่อไม่ผ่าน Gate ก็ไม่มีการตรวจ Classification และไม่มีการปิดบังข้อมูล ผลคือแถวข้อมูลที่เป็นความลับไปถึงโมเดลที่ไม่ได้รับอนุญาตให้เห็นได้ การเขียนกฎไว้ใน Prompt ก็ป้องกันเรื่องนี้ไม่ได้ เพราะ Prompt อาจตกหล่นกฎด้าน Governance ไป และไม่มีส่วนใดตรวจว่ากฎนั้นถูกทำตามจริง

ความเสี่ยงนี้ไม่ได้เกิดครั้งเดียวแล้วจบ ทุกครั้งที่มีการเพิ่ม Flow ใหม่ที่รวมข้อมูล ถ้า Flow นั้นไม่ได้ผ่าน Gate มันก็ส่งข้อมูลให้โมเดลโดยตรงได้อีก และจะไม่มีใครรู้ เพราะไม่มีการบันทึก

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

ผลิตภัณฑ์ไหนก็ตามที่เคยรวมแหล่งข้อมูลสองอย่างนี้เข้าด้วยกัน ย่อมเคยเจอปัญหานี้ ลองถามดูว่า มีทางไหนไหมที่ Flow ซึ่งสร้างในผลิตภัณฑ์จะไปถึงโมเดลได้โดยไม่ผ่าน Gate

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

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

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

จะเข้มงวดแค่ไหนเป็นการตัดสินใจ และมีบันทึก Workspace หนึ่งสามารถตั้งให้รับเฉพาะสิ่งที่เลเยอร์ตรวจสอบเองได้ ในโหมดนั้น เนื้อหาที่ส่งไปให้โมเดลภายนอกได้ มีเพียงเนื้อหาที่เลเยอร์ดึงมาเองจากเอกสารที่มี Classification แล้ว และพกป้ายกำกับของเอกสารนั้นไปด้วย ส่วนที่เหลือทั้งหมด รวมถึงผลลัพธ์ที่ Query จากฐานข้อมูล จะอยู่บนฮาร์ดแวร์ของคุณเอง นี่คือการยอมสละขีดความสามารถของโมเดลภายนอก เพื่อแลกกับความแน่นอน การแลกนี้เหมาะกับ Workspace หนึ่ง ๆ หรือไม่ เป็นดุลยพินิจของคนที่รับผิดชอบ Workspace นั้น ไม่ใช่ของซอฟต์แวร์ และการเปลี่ยนค่านี้ถูกบันทึกไว้

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

คุณไม่ต้องเขียน Engine สำหรับรวมข้อมูล และไม่ต้องเขียนโค้ดสำหรับ Join Classification เอง Infozense Knowledge Engineering อ่านคลังเอกสารของคุณ และ Query ฐานข้อมูลของคุณ ณ ที่ที่มันอยู่ ประกอบคำตอบจากทั้งสองแหล่ง หยิบระดับความอ่อนไหวที่เข้มที่สุดเท่าที่มีอยู่ข้ามทั้งสองแหล่ง แล้วกำหนดปลายทาง ปิดบังข้อมูล ติดป้ายกำกับ และบันทึก ด้วยค่าเดียวนั้น

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