- OpenAI สร้าง เอเจนต์ข้อมูล AI แบบปรับแต่งเฉพาะ ขึ้นใช้เอง เพื่อวิเคราะห์ข้อมูลอย่างมีประสิทธิภาพสำหรับ ผู้ใช้ภายในมากกว่า 3,500 คน และ ข้อมูลขนาด 600PB
- รองรับการทำงานวิเคราะห์แบบ end-to-end ตั้งแต่สำรวจตาราง รัน SQL ไปจนถึงเผยแพร่โน้ตบุ๊กและรายงาน ได้โดยอัตโนมัติผ่านการถามด้วยภาษาธรรมชาติ
- ผสานคอนเท็กซ์ 6 ชั้น ได้แก่ การใช้งานตาราง, คำอธิบายจากมนุษย์, การวิเคราะห์โค้ดด้วย Codex, องค์ความรู้ขององค์กร, เมมโมรี และ runtime context เพื่อให้ได้ความแม่นยำ
- ทำงานด้วยโครงสร้าง วงจรปิดการเรียนรู้ด้วยตนเอง ที่สามารถตรวจหาสาเหตุและปรับแนวทางเองเมื่อผลลัพธ์ระหว่างทางผิดพลาด
- ใช้ระบบประเมินอย่างเป็นระบบบน Evals API เพื่อ ตรวจจับคุณภาพถดถอยได้ตั้งแต่เนิ่นๆ พร้อมคงความน่าเชื่อถือด้วยการสืบทอดโมเดลความปลอดภัยและสิทธิ์เดิม
เหตุใดจึงต้องมีเอเจนต์ข้อมูลแบบปรับแต่งเฉพาะ
- แพลตฟอร์มข้อมูลของ OpenAI มี ผู้ใช้ภายในมากกว่า 3,500 คน, ข้อมูลขนาด 600 เพตะไบต์ และ ชุดข้อมูลมากกว่า 70,000 ชุด โดยแม้แต่การหาตารางที่ถูกต้องก็ยังเป็นงานที่ใช้เวลามากที่สุดในการวิเคราะห์
- มีตารางที่คล้ายกันจำนวนมาก ทำให้ ยากต่อการแยกความแตกต่างระหว่างตาราง เช่น รวมผู้ใช้ที่ออกจากระบบไว้หรือไม่ หรือมีฟิลด์ซ้ำกันหรือไม่
- แม้จะเลือกตารางถูกแล้ว ปัญหาอย่าง many-to-many join, ข้อผิดพลาดในการ filter pushdown หรือการ ไม่จัดการค่า
null ก็อาจทำให้ผลลัพธ์ใช้การไม่ได้
- นักวิเคราะห์ควรโฟกัสกับ การนิยามเมตริก การตรวจสอบสมมติฐาน และการตัดสินใจบนฐานข้อมูล มากกว่าการดีบัก SQL
เอเจนต์ทำงานอย่างไร
- ขับเคลื่อนด้วย GPT-5.2
- เข้าถึงได้จากสภาพแวดล้อมที่พนักงานใช้อยู่แล้ว เช่น Slack agent, เว็บอินเทอร์เฟซ, IDE, Codex CLI (เชื่อมต่อ MCP) และแอป ChatGPT ภายใน
- รองรับคำถามที่ซับซ้อนและเปิดกว้างได้
- ทำความเข้าใจคำถาม
- สำรวจข้อมูล
- รัน SQL
- วิเคราะห์และสรุปผลแบบ end-to-end
- ตัวอย่าง: วิเคราะห์ชุดข้อมูลแท็กซี่ NYC เพื่อหาคู่ ZIP ต้นทาง-ปลายทางที่มี ความผันผวนของเวลาเดินทางสูงที่สุด
- ไม่ได้ทำตามสคริปต์ตายตัว แต่จะ ประเมินความคืบหน้าของตัวเอง และหากผลลัพธ์ระหว่างทางผิดพลาด (เช่น ได้ผลลัพธ์ 0 แถวจาก join หรือ filter ที่ผิด) ก็จะตรวจหาสาเหตุ ปรับแนวทาง และลองใหม่
- ครอบคลุมเวิร์กโฟลว์การวิเคราะห์ทั้งหมด: การค้นหาข้อมูล, การรัน SQL, การ เผยแพร่โน้ตบุ๊กและรายงาน, การอ้างอิงองค์ความรู้ภายใน, การค้นเว็บ และการเรียนรู้จากเมมโมรี
โครงสร้างชั้นของคอนเท็กซ์
-
Layer 1: การใช้งานตาราง (Table Usage)
- การยึดโยงกับเมทาดาทา: ใช้เมทาดาทาของสคีมา (ชื่อคอลัมน์, ชนิดข้อมูล) ในการเขียน SQL และใช้ table lineage (ความสัมพันธ์ระหว่างตารางต้นน้ำ-ปลายน้ำ) เพื่อเข้าใจความสัมพันธ์ระหว่างตาราง
- การอนุมานจากคิวรี: รวบรวมคิวรีในอดีตเพื่อให้เอเจนต์เรียนรู้รูปแบบการเขียนคิวรีของตัวเองและ ชุดตารางที่มักถูก join เข้าด้วยกัน
-
Layer 2: คำอธิบายจากมนุษย์ (Human Annotations)
- ผู้เชี่ยวชาญโดเมนจะเขียน คำอธิบายที่ผ่านการคัดสรร ให้กับตารางและคอลัมน์ เพื่อเก็บข้อมูลที่ยากจะอนุมานจากสคีมาหรือคิวรีเดิม เช่น เจตนา ความหมายเชิง semantics บริบทธุรกิจ และข้อควรระวังที่ทราบอยู่แล้ว
- เพราะเมทาดาทาอย่างเดียวไม่พอจะแยกตารางได้ จึงจำเป็นต้อง เข้าใจวิธีสร้างและที่มาของตาราง
-
Layer 3: การวิเคราะห์โค้ดด้วย Codex (Codex Enrichment)
- ดึง นิยามในระดับโค้ด ของตารางออกมาเพื่อทำความเข้าใจเนื้อหาจริงของข้อมูลอย่างลึกซึ้ง
- ให้รายละเอียดเชิงนัยจากเหตุการณ์การวิเคราะห์ เช่น ความเป็นเอกลักษณ์ของค่า ความถี่ในการอัปเดตข้อมูล และขอบเขตของข้อมูล (เช่น มีการยกเว้นบางฟิลด์หรือมีระดับการแบ่งย่อยแค่ไหน)
- เข้าใจบริบทการใช้งานใน ระบบข้อมูลที่หลากหลาย เช่น Spark, Python นอกเหนือจาก SQL
- แยกความต่างของตารางที่ดูคล้ายกันแต่สำคัญต่างกันได้ (เช่น ตารางที่รวมเฉพาะทราฟฟิก ChatGPT แบบ 1st-party หรือไม่)
- คอนเท็กซ์นี้ อัปเดตอัตโนมัติ จึงไม่ต้องดูแลรักษาแบบแมนนวล
-
Layer 4: องค์ความรู้ขององค์กร (Institutional Knowledge)
- รวบรวมบริบทของบริษัทจาก Slack, Google Docs, Notion ฯลฯ เช่น การเปิดตัวฟีเจอร์ เหตุขัดข้อง โค้ดเนมภายใน และ นิยามมาตรฐานกับตรรกะการคำนวณ ของเมตริกสำคัญ
- มีบริการค้นคืนข้อมูลที่เก็บเอกสาร ทำ embedding และบันทึกพร้อมเมทาดาทาและสิทธิ์ รวมถึงจัดการ การควบคุมการเข้าถึงและแคช ระหว่างรันงาน
-
Layer 5: เมมโมรี (Memory)
- เมื่อเอเจนต์ได้รับการแก้ไขหรือพบความละเอียดอ่อนของคำถามด้านข้อมูล ก็จะบันทึกไว้เพื่อให้ เริ่มวิเคราะห์ครั้งถัดไปจาก baseline ที่แม่นยำกว่าเดิม
- เป้าหมายของเมมโมรีคือการเก็บและนำกลับมาใช้ซ้ำซึ่ง การแก้ไข ฟิลเตอร์ และข้อจำกัดที่ไม่ชัดเจนในตัวเอง และยากจะอนุมานจากชั้นอื่น
- ตัวอย่าง: เมื่อกรองการทดลองวิเคราะห์บางอย่าง จำเป็นต้องทำ string matching แบบเฉพาะที่นิยามไว้ใน experiment gate แต่หากไม่มีเมมโมรี เอเจนต์อาจพยายามใช้ fuzzy string matching จนเกิดข้อผิดพลาด
- เมื่อมีการแก้ไขหรือพบสิ่งที่เรียนรู้ใหม่ เอเจนต์จะกระตุ้นให้บันทึกเมมโมรี และผู้ใช้ก็สามารถ สร้างหรือแก้ไขเองด้วยตนเอง ได้
- แยกขอบเขตเมมโมรีเป็น ระดับส่วนกลางและระดับบุคคล
-
Layer 6: Runtime Context
- หากไม่มีคอนเท็กซ์ล่วงหน้าของตารางหรือข้อมูลเก่าไปแล้ว ก็จะส่ง live query ไปยัง data warehouse เพื่อยืนยันสคีมาและตรวจสอบข้อมูลแบบเรียลไทม์
- ยังสื่อสารกับ ระบบอื่นใน Data Platform เช่น บริการเมทาดาทา, Airflow, Spark เพื่อรับคอนเท็กซ์ข้อมูลจากนอก warehouse
-
ไปป์ไลน์ออฟไลน์รายวันและ RAG
- มี ไปป์ไลน์ออฟไลน์รายวัน สำหรับรวมข้อมูลการใช้งานตาราง คำอธิบายจากมนุษย์ และข้อมูลเสริมจาก Codex ให้อยู่ในรูปแบบมาตรฐานเดียวกัน
- แปลงคอนเท็กซ์ที่เสริมแล้วเป็น embedding ด้วย OpenAI Embeddings API แล้วจัดเก็บไว้ จากนั้นใช้ RAG (Retrieval-Augmented Generation) เพื่อค้นเฉพาะคอนเท็กซ์ที่เกี่ยวข้องในเวลาคิวรี
- ช่วยให้การทำความเข้าใจตารางในระดับหลายหมื่นตารางยังคง รวดเร็วและขยายขนาดได้ พร้อมรักษา runtime latency ให้ต่ำและคาดการณ์ได้
ออกแบบให้คิดและทำงานร่วมกันเหมือนเพื่อนร่วมทีม
- รองรับ การสำรวจแบบโต้ตอบและวนซ้ำ ไม่ใช่คำตอบแบบ one-shot โดยคงคอนเท็กซ์ครบถ้วนข้ามแต่ละเทิร์น ทำให้ไม่ต้องอธิบายใหม่ตั้งแต่ต้นเมื่อมีคำถามต่อหรือเปลี่ยนทิศทาง
- หากเอเจนต์กำลังไปผิดทาง ผู้ใช้สามารถ แทรกแซงระหว่างการวิเคราะห์เพื่อเปลี่ยนทิศทาง ได้
- หากคำสั่งไม่ชัดเจน จะ ถามเพื่อความชัดเจนเชิงรุก และหากไม่ได้รับคำตอบก็จะใช้ค่าเริ่มต้นที่สมเหตุสมผล (เช่น 7 วันล่าสุดหรือ 30 วันล่าสุด) เพื่อดำเนินการต่อ
- เมื่อสังเกตรูปแบบที่มีการวิเคราะห์แบบเดิมซ้ำๆ ก็จะนำการวิเคราะห์นั้นมาจัดแพ็กเป็น เวิร์กโฟลว์ (instruction set) ที่นำกลับมาใช้ซ้ำได้
- ตัวอย่างเช่น รายงานธุรกิจประจำสัปดาห์ หรือการตรวจสอบตาราง
- เข้ารหัสคอนเท็กซ์และแนวปฏิบัติที่ดีเพียงครั้งเดียวเพื่อรับประกัน ผลลัพธ์ที่สอดคล้องกันระหว่างผู้ใช้
ระบบประเมินผลเพื่อปรับปรุงได้เร็วโดยยังคงความน่าเชื่อถือ
- เนื่องจากเอเจนต์มีการพัฒนาเปลี่ยนแปลงอยู่เสมอ จึงอาจเกิด quality drift ได้ง่าย และหากไม่มีการประเมินอย่างเป็นระบบ การถดถอยอาจเกิดขึ้นโดยไม่ทันสังเกต
- สร้างชุดคำถาม-คำตอบที่ผ่านการคัดสรรบนพื้นฐานของ OpenAI Evals API โดยจับคู่แต่ละคำถามกับ คิวรี SQL "golden" ที่เขียนด้วยมือ
- ส่งคำถามภาษาธรรมชาติไปยัง endpoint สำหรับสร้างคิวรี จากนั้นรัน SQL ที่สร้างขึ้นและเปรียบเทียบกับผลลัพธ์ SQL ที่คาดหวัง
- ไม่ได้เทียบแค่สตริง แต่เปรียบเทียบทั้ง SQL และข้อมูลผลลัพธ์ แล้วป้อนเข้า Evals grader เพื่อสร้างคะแนนและคำอธิบายสุดท้ายที่สะท้อนทั้ง ความแม่นยำและความคลาดเคลื่อนที่ยอมรับได้
- การประเมินนี้ทำหน้าที่เป็น unit test ที่รันต่อเนื่องระหว่างการพัฒนา และยังเป็น canary ในโปรดักชันเพื่อ ตรวจจับ regression ได้ตั้งแต่เนิ่นๆ
ความปลอดภัยของเอเจนต์
- เชื่อมตรงกับโมเดลความปลอดภัยและการควบคุมการเข้าถึงเดิมของ OpenAI และ สืบทอดพร้อมบังคับใช้ สิทธิ์และ guardrails เดียวกันในชั้นอินเทอร์เฟซ
- ทุกการเข้าถึงเป็นแบบ pass-through โดยผู้ใช้จะคิวรีได้เฉพาะตารางที่ตนมีสิทธิ์อยู่แล้วเท่านั้น และหากไม่มีสิทธิ์ เอเจนต์จะแจ้งให้ทราบหรือ fallback ไปใช้ชุดข้อมูลทางเลือก
- เพื่อความโปร่งใส มีการ เปิดเผยกระบวนการให้เหตุผล โดยสรุปสมมติฐานและขั้นตอนที่ดำเนินการไปพร้อมกับคำตอบ และลิงก์ตรงไปยังผลลัพธ์ดิบของคิวรีที่รันจริง เพื่อให้ผู้ใช้ตรวจสอบทุกขั้นตอนของการวิเคราะห์ได้
บทเรียนที่ได้จากการสร้างระบบ
-
Lesson 1: น้อยกว่าคือดีกว่า (Less is More)
- ในช่วงแรกได้เปิดเผยชุดเครื่องมือทั้งหมดให้เอเจนต์ใช้ แต่กลับเกิด ความสับสนจากความสามารถที่ซ้ำซ้อน
- ความสามารถซ้ำซ้อนที่มีประโยชน์เมื่อมนุษย์เรียกใช้เอง กลับทำให้เอเจนต์กำกวม จึงปรับโดย จำกัดและรวม การเรียกใช้เครื่องมือบางประเภทเพื่อเพิ่มความน่าเชื่อถือ
-
Lesson 2: ชี้เป้า ไม่ใช่ชี้เส้นทาง (Guide the Goal, Not the Path)
- การพรอมป์แบบสั่งละเอียดมากเกินไปกลับทำให้ผลลัพธ์แย่ลง
- เพราะแต่ละคำถามมีรายละเอียดต่างกัน คำสั่งที่แข็งทื่ออาจพาเอเจนต์ไปผิดทาง ดังนั้นการให้ แนวทางระดับสูง แล้วมอบหมายให้การให้เหตุผลของ GPT-5 เลือกเส้นทางดำเนินการเองจึงให้ผลดีกว่า
-
Lesson 3: ความหมายอยู่ในโค้ด (Meaning Lives in Code)
- สคีมาและประวัติคิวรีอธิบายได้เพียงรูปแบบและวิธีการใช้งานของตาราง แต่ ความหมายที่แท้จริงอยู่ในโค้ดที่สร้างตารางนั้น
- ตรรกะในไปป์ไลน์จับสมมติฐาน การรับประกันความสดใหม่ และเจตนาทางธุรกิจ ซึ่งไม่ปรากฏชัดใน SQL หรือเมทาดาทา
- ด้วยการให้ Codex คลานโค้ดเบสเพื่อเข้าใจว่าชุดข้อมูลถูกสร้างขึ้นจริงอย่างไร จึงสามารถตอบได้อย่างแม่นยำว่า "มีอะไรอยู่ข้างใน" และ "ใช้ได้เมื่อไร" ซึ่งทำไม่ได้หากดูจากสัญญาณใน warehouse เพียงอย่างเดียว
ทิศทางต่อจากนี้
- กำลังผลักดันอย่างต่อเนื่องทั้งการรับมือกับคำถามกำกวมให้ดีขึ้น, ยกระดับความน่าเชื่อถือและความแม่นยำด้วยการตรวจสอบที่แข็งแรงขึ้น, และการผสานรวมเวิร์กโฟลว์ให้ลึกยิ่งขึ้น
- มุ่งไปสู่รูปแบบที่ กลมกลืนไปกับวิธีการทำงานที่ผู้คนใช้อยู่แล้ว มากกว่าจะเป็นเครื่องมือแยกต่างหาก
- ระบบจะพัฒนาอย่างต่อเนื่องตามเทคโนโลยีพื้นฐานด้านการให้เหตุผล การตรวจสอบ และการแก้ไขตัวเองของเอเจนต์ที่ดีขึ้น โดย
ภารกิจของทีมคือการทำให้ การวิเคราะห์ข้อมูลที่รวดเร็วและเชื่อถือได้ พร้อมใช้ได้อย่างลื่นไหลทั่วทั้งระบบนิเวศข้อมูลของ OpenAI
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ปัญหาใหญ่ที่สุดคือ ความน่าเชื่อถือ และ ความสามารถในการอธิบาย
พวกเราพัฒนา natural language analytics ที่ Veezoo มา 10 ปีแล้ว และแนวทาง Text-to-SQL แบบตรงไปตรงมานั้นขยายระบบได้ไม่ดี
ตอนที่ CFO ถามเรื่องรายได้ ตัวเลขที่ถูกแค่ 99% ก็ไม่มีความหมาย และ CFO ก็ไม่สามารถตรวจสอบ SQL เองได้
ดังนั้นเราจึงใส่ชั้น abstraction ที่เรียกว่า Knowledge Graph ไว้ เพื่อให้ AI แปลงภาษาธรรมชาติเป็นภาษาคิวรีเชิงความหมาย แล้วคอมไพล์เป็น SQL แบบกำหนดแน่นอน
ในทางกลับกัน ก็สามารถแปลง semantic query นี้กลับเป็นคำอธิบายภาษาธรรมชาติ เพื่อให้ผู้ใช้ตรวจสอบได้ง่ายว่าผลลัพธ์ตรงกับเจตนาหรือไม่
business logic อยู่ใน Knowledge Graph และคอมไพเลอร์รับประกันว่าทุกคิวรีจะปฏิบัติตามสิ่งนี้ 100%
โครงสร้างโดยละเอียดสรุปไว้ใน เอกสาร Veezoo Architecture
สิ่งที่สงสัยคือจัดการกับ cardinality explosion อย่างไร และรับมือกับคำขอแบบหลายคิวรีที่ต้องพึ่งผลลัพธ์จากคิวรีก่อนหน้าอย่างไร
ควรต้องติดตามได้ว่าในวันไหนใช้คิวรีใด และตรวจสอบมันอย่างไร
(แน่นอนว่า prompt ก็ควรอยู่ภายใต้ version control ด้วย)
แปลกใจที่ตัวอย่างแรก ไม่สมเหตุสมผลเลย
ถ้าสิ่งนี้ผ่านการตรวจโดยมนุษย์ได้ ก็น่าจะเป็นไปได้ว่ามันถูกเขียนโดย AI และถ้าเป็นแบบนั้นก็ทำให้ตั้งคำถามกับความน่าเชื่อถือของระบบ
ลิงก์รูปภาพที่มีปัญหา
เดสก์ท็อปเป็น prompt ที่ถูกต้อง,
ส่วนมือถือเป็น prompt ที่ผิด
จากประสบการณ์ที่ใช้ระบบ BI มาหลายตัว ฉันคิดว่า AI agent แบบนี้เป็น use case ที่เหมาะมาก
โดยธรรมชาติแล้ว BI มีข้อผิดพลาดได้หลายชั้น — ตัวคิวรีเองอาจผิด หรือวิธีตีความข้อมูลอาจผิด
เมื่อสองอย่างนี้รวมกัน คุณก็เข้าไปอยู่ใน “โลกสมมติ” แล้ว ดังนั้นให้ AI มารับหน้าที่ขั้นแรกแทนยังจะดีกว่า
เคยหวังว่า OpenAI จะแก้ปัญหาเรื่องความน่าเชื่อถือได้ แต่เสียดายที่ยังไม่ใช่
ขั้นที่ 0: จัดเก็บข้อมูลผิด
ขั้นที่ -1: เข้าใจโมเดลผิดตั้งแต่แรก
ขั้นที่ -2: กระบวนการทางธุรกิจผิดมาตั้งแต่ต้น
เพราะอย่างนั้นฉันเลยเรียกมันว่า “single source of falsehood” แทน “single source of truth”
ส่วนที่ยากที่สุดคือการขยายความไว้วางใจ
พวกเราก็กำลังสร้างอะไรคล้าย ๆ กันอยู่ และไม่ว่า agent loop จะดีแค่ไหน สุดท้ายก็ยังต้องมี canonical metrics ที่มนุษย์ curate ไว้
ไม่อย่างนั้นผู้ใช้ที่ไม่ใช่สายเทคนิคก็จะตัดสินใจเรื่องเสี่ยง ๆ จาก SQL ที่ตรวจสอบไม่ได้
แนวทางของเราคือ
เมื่อเวลาผ่านไป คิวรีส่วนใหญ่ก็จะหันไปใช้ metric มาตรฐาน และ agent ก็จะกลายเป็น smart router จาก intent → metric ที่ผ่านการตรวจสอบ ไม่ใช่แค่ตัวสร้าง SQL ธรรมดา
ระบบประเมิน golden SQL ในส่วน “เคลื่อนที่เร็วโดยไม่ทำลายความเชื่อมั่น” ก็สะท้อนแนวคิดเดียวกัน
มีสรุปไว้ใน บล็อกโพสต์นี้
ถ้ามีหลายเส้นทางไปยังคำตอบ ก็จะได้ผลลัพธ์ต่างกัน
LLM มักสร้าง metric ที่ไร้ความหมายอย่างพวก
xyz_indexขึ้นมา แล้วผู้ใช้ก็มักเชื่อว่าใช้ได้เพราะมันดูเหมือนจริงผมคิดว่าผลกระทบที่แท้จริงของ AI ต่ออาชีพนักพัฒนาคือ คุณภาพของข้อมูลและเอกสาร
การนำ AI ไปใช้ได้มีประสิทธิภาพแค่ไหนขึ้นอยู่กับว่าข้อมูลในบริษัทจัดระเบียบมาดีเพียงใด
ข้อมูลสาธารณะถูกใช้ไปจนแทบหมดแล้ว และทรัพยากรถัดไปก็คือเอกสารภายใน, code repository และ data lake
บริษัทที่มีรากฐานพวกนี้ดีจะสามารถสร้างและดูแลบริการใหม่ด้วย AI ได้เร็วและถูกกว่า
ตรงกันข้าม บริษัทที่จัดการเอกสารและโค้ดได้เละเทะจะทำให้ AI ทำงานได้ไม่ดี
สุดท้ายก็จะเสียตลาดให้คู่แข่ง
เพราะงั้นเวลาหางานครั้งต่อไป ผมตั้งใจว่าจะถามให้ชัดเรื่อง ระดับการจัดการเอกสาร ข้อมูล และ repository
ที่ Amplitude ก็สร้างระบบคล้ายกันชื่อ Moda
เมื่อหลายเดือนก่อน Wade เคยให้ Claire Vo ดู วิดีโอเดโม ซึ่งยอดเยี่ยมมาก
ตอนนี้ผมก็ใช้อยู่ทุกวันเพื่อถามคำถามหลากหลายแบบ
พวกเราก็มีฟีเจอร์คล้ายกันใน Definite.app ที่ ให้ได้ภายใน 5 นาที
ไม่ต้องใช้ Spark หรือ Snowflake
เรามีทั้ง data lake, pipeline, semantic layer และ data agent ในแอปเดียว
จริง ๆ แล้วสิ่งที่ยากกว่า agent เองมากคือ การสร้าง data infrastructure
ถ้า agent เขียนได้แค่ SQL อย่างเดียว ข้อจำกัดจะเยอะมาก แต่เราเปิดให้มันจัดการ infrastructure เองได้ จึงกลายเป็นจุดเปลี่ยนใหญ่
เนื้อหาดีมากจริง ๆ
แต่ดูเหมือนจะขาดส่วนที่อธิบายว่า ผลลัพธ์ถูกคำนวณมาอย่างไร
ถ้าเป็นเครื่องมือใช้ภายใน OpenAI การสมมติว่าผู้ใช้อ่าน SQL ได้ก็พอเข้าใจได้ แต่สำหรับผู้ใช้ที่ไม่ใช่สายเทคนิค นี่เป็นโจทย์ด้านการออกแบบที่ใหญ่มาก
ถ้าเคยทำงานกับระบบข้อมูล จะรู้ได้เร็วว่า “คำตอบ” สำคัญพอ ๆ กับ “คำตอบนั้นได้มาอย่างไร”
ส่วนตัวแล้วคิดว่า In-House Data Agent ของ Kimi น่าสนใจกว่า
ปัญหาด้านข้อมูลไม่ใช่ปัญหาทางเทคนิค แต่เป็น ปัญหาเชิงองค์กร
จากประสบการณ์ของผม สาเหตุของปัญหาด้านข้อมูลไม่ใช่ “การเลือกเทคโนโลยีผิด” แต่คือ การตัดสินใจเรื่อง governance และ ownership
สุดท้ายแล้วทุกอย่างก็กลับไปจบที่ กฎของ Conway