Claude กับ Self-Service Analytics: ทำไม AI ตอบตัวเลขไม่ได้ ถ้าไม่มี Semantic Layer

หลายทีมเริ่มอยากทำ AI Analytics แบบง่าย ๆ:

ให้เจ้าของกิจการถามว่า “ยอดขายเดือนนี้เป็นยังไง” แล้ว AI ตอบออกมาเลย

ให้ผู้บริหารถามว่า “lead หลุดตรงไหน” แล้ว AI ไป query database ให้

ให้ทีม operation ถามว่า “สาขาไหนมีปัญหา” แล้ว AI สรุป dashboard กลับมา

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

บทความล่าสุดของ Anthropic เรื่อง “How Anthropic enables self-service data analytics with Claude” จึงน่าสนใจมาก เพราะเขาไม่ได้บอกแค่ว่า Claude เขียน SQL ได้

เขาบอกว่า analytics agent ที่เชื่อถือได้ ต้องสร้างบน data foundation, source of truth, skills, validation และ correction loop

Anthropic ระบุว่า 95% ของ business analytics queries ภายในบริษัทถูก automate ด้วย Claude และมี accuracy รวมประมาณ 95%

แต่ตัวเลขนี้ไม่ใช่ประเด็นหลัก

ประเด็นหลักคือเขาบอกชัดว่า:

Analytics accuracy ไม่ใช่ปัญหา code generation มันคือปัญหา context และ verification

1) ทำไม AI Analytics ถึงยากกว่า AI เขียนโค้ด

เวลาพูดถึง coding agent เรามักพูดเรื่อง model เขียน code, run test, fix error, open PR

ถ้า code ผิด ยังมี test, compiler, linter, review, runtime error ช่วยจับ

แต่ analytics ไม่เหมือนกัน

คำถามธุรกิจจำนวนมากมีคำตอบที่ถูกต้องได้แค่ชุดเดียว และมักต้องใช้ source ที่ถูกต้องเพียงหนึ่งชุด

ปัญหาคือ AI อาจเขียน SQL ที่ดูดีมาก แต่ใช้ table ผิด หรือ metric definition ผิด

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

“active users เดือนนี้เป็นยังไง”

คำถามนี้ดูธรรมดา แต่ในบริษัทจริงต้องตอบก่อนว่า:

• active แปลว่า login หรือทำ action สำคัญ
• นับ user, account, workspace หรือ organization
• รวม free user ไหม
• exclude fraud หรือ internal test account ไหม
• ใช้ lookback window กี่วัน
• ใช้ timezone ไหน
• metric นี้มี dashboard หลักอยู่แล้วไหม

ถ้า AI เดา definition เอง คำตอบจะดูเหมือนถูก แต่จริง ๆ อาจผิดตั้งแต่ชั้นความหมาย

นี่คือสิ่งที่ Anthropic เรียกว่า concept-to-entity ambiguity

ผู้ใช้ถามเป็นภาษาธุรกิจ แต่ระบบต้อง map ไปยัง table, field, metric, filter และ grain ที่ถูกต้อง

2) สาม failure modes ที่ทำให้ analytics agent ตอบผิด

Anthropic แบ่งสาเหตุหลักของคำตอบผิดไว้ 3 แบบ

หนึ่ง: concept-to-entity ambiguity

ธุรกิจมีคำที่คนใช้เหมือนกัน แต่ data model มีหลาย implementation

คำว่า revenue อาจมีหลาย table คำว่า customer อาจมีหลาย grain คำว่า active อาจมีหลาย filter คำว่า churn อาจแปลต่างกันใน sales, product และ finance

ถ้า agent เลือกผิดตั้งแต่ source คำตอบที่เหลือจะผิดหมด

สอง: data staleness

Data source, schema, business definition, dashboard และ documentation เปลี่ยนตลอด

ถ้า agent จำ doc เก่า หรือ reference file ไม่ถูก update คำตอบจะเริ่มผิดแบบเงียบ ๆ

อันนี้อันตรายกว่าผิดชัด ๆ เพราะตัวเลขยังดูสมเหตุสมผล

สาม: retrieval failure

บางทีข้อมูลที่ถูกต้องมีอยู่แล้ว แต่ search space ใหญ่เกินไป agent หา reference doc, metric, lineage หรือ query pattern ที่ถูกไม่เจอ

หลายทีมแก้ผิดทางโดยให้ AI access ทุกอย่างมากขึ้น แต่ Anthropic เจอว่าให้ agent grep/query corpus จำนวนมากไม่ได้ช่วย accuracy เท่าไร

สิ่งที่ช่วยคือจัด structure ให้ agent หาทางถูกตั้งแต่แรก

3) Stack ที่ Anthropic ใช้: ไม่ใช่ raw database + AI

Anthropic วาง stack ของ self-service analytics ไว้ 4 ชั้น

Data foundations

ชั้นแรกคือพื้นฐาน data engineering แบบเดิมที่ยังสำคัญมาก:

• canonical datasets
• dimensional modeling
• freshness checks
• completeness checks
• data tests
• metadata
• ownership
• model tiering

สิ่งที่เปลี่ยนคือ user ของ data model ไม่ได้เป็น data scientist เสมอไปแล้ว

ตอนนี้ agent อาจ query แทนคนที่ไม่รู้ schema และไม่รู้ว่า output ผิดตรงไหน

ดังนั้น data foundation ต้องทำให้ agent เจอคำตอบที่ถูกได้ง่าย และเจอคำตอบผิดได้ยาก

ผมชอบประโยคหนึ่งในบทความ:

เป้าหมายคือเมื่อ agent search concept หนึ่ง มันควรเจอ single governed answer

ไม่ใช่เจอ 40 candidate tables แล้วเดาเอง

Sources of truth

ชั้นที่สองคือ reference surfaces ที่ agent ใช้นำทาง data model

Anthropic เรียงความน่าเชื่อถือประมาณนี้:

1. semantic layer
2. lineage และ transformation graph
3. curated query knowledge / reference docs
4. business context เช่น docs, roadmap, decision logs, org structure

ประเด็นสำคัญคือ semantic layer ต้องมาก่อน raw SQL

ถ้าคำถาม map ไปยัง metric ที่ถูก define แล้ว agent ควรเรียก metric นั้น ไม่ควร hand-roll SQL เองทุกครั้ง

เพราะตัวเลขต้องตรงกับ dashboard, BI tool และ source of truth อื่นในบริษัท

Skills

ชั้นที่สามคือ skills

ในบริบทนี้ skill ไม่ใช่แค่ prompt สวย ๆ แต่คือ procedural knowledge ที่บอกว่า agent ควรทำงานอย่างไร

เช่น:

• ถาม clarification เรื่อง time period, segment, business decision ก่อน query
• ใช้ semantic layer ก่อน raw SQL
• ถ้า semantic layer ไม่ครอบคลุม ค่อยอ่าน reference docs ของ domain นั้น
• ต้องใช้ hygiene filter อะไรเสมอ
• ต้องระวัง gotcha อะไร
• ต้องทำ adversarial review ก่อนตอบ
• ต้องรายงาน source, freshness, owner และ confidence

Anthropic บอกว่าไม่มี skills แล้ว Claude ตอบ analytics questions ใน eval ได้ไม่เกิน 21% แต่เมื่อเพิ่ม skills แล้ว accuracy รวมขึ้นไปมากกว่า 95% และบาง domain ใกล้ 99%

ตัวเลขนี้เป็น internal eval ของ Anthropic แต่ pattern น่าสนใจมาก

เพราะมันยืนยันว่า “ให้ AI ฉลาดขึ้น” ไม่พอ ต้องทำให้ขั้นตอนการใช้ความฉลาดนั้นเป็นระบบด้วย

Validation

ชั้นสุดท้ายคือ validation

Anthropic ใช้หลายวิธี:

• offline evals จาก question / answer pairs
• dashboard-based evals
• long-tail evals ที่สร้างจาก business context
• ablation เพื่อดูว่า skill/reference/source ไหนช่วยจริง
• adversarial review
• provenance footer
• passive monitoring
• correction harvesting จาก thread ที่ stakeholder แก้คำตอบของ agent

สิ่งที่ผมชอบคือเขาไม่ได้มอง eval เป็น test log แต่มองเป็น telemetry

ทุก run ควรเก็บ skill version, git SHA, model ID, pass/fail, token count และ latency

แบบนี้ทีมจะตอบได้จริงว่า doc edit ล่าสุดช่วยให้ agent แม่นขึ้นไหม หรือทำให้แย่ลง

4) บทเรียนที่สำคัญ: prior SQL ไม่ใช่ source of truth ที่ดีเสมอไป

หลายทีมคิดว่า ถ้าให้ AI อ่าน query เก่า ๆ หลายพันไฟล์ มันน่าจะตอบดีขึ้น

Anthropic ทดลองแล้วพบว่า direct access ไปยัง dashboard SQL, transformation SQL และ analyst notebook SQL หลายพันไฟล์ ทำให้ accuracy ขยับน้อยกว่า 1 จุด

และสำหรับคำถามที่ตอบผิด ประมาณ 80% ของกรณี จริง ๆ แล้วคำตอบมีอยู่ใน corpus

แปลว่า information มีอยู่ agent เห็น information แล้ว แต่ยังไม่ใช้ให้ถูก

นี่คือ insight ที่สำคัญมากสำหรับทีม data

ปัญหาไม่ใช่แค่ access ปัญหาคือ structure

AI ไม่ต้องการ file เยอะที่สุด AI ต้องการทางเดินที่ชัดที่สุดจากคำถาม ไปยัง entity ที่ถูกต้อง

5) ใช้กับธุรกิจไทยยังไง

ถ้าแปลเป็นบริบท SME ไทย ผมจะไม่เริ่มจาก “ทำ chatbot ถามยอดขายได้”

ผมจะเริ่มจากคำถามเหล่านี้ก่อน:

1. ยอดขายที่บริษัทใช้ตัดสินใจจริง อยู่ที่ table ไหน
2. metric นี้นิยามยังไง รวม VAT ไหม รวม refund ไหม
3. lead, customer, order, branch, admin, product มี grain ยังไง
4. dashboard ไหนคือ source of truth
5. ข้อมูลสดถึงวันไหน
6. ใครเป็นเจ้าของ metric นี้
7. ถ้า AI ตอบผิด ใครเห็นและแก้กลับเข้าระบบอย่างไร

ถ้าตอบไม่ได้ การต่อ AI เข้าฐานข้อมูลตรง ๆ คือการเพิ่มความเร็วให้ความมั่ว

สำหรับ Data-Espresso ผมเห็น pattern นี้ใช้ได้กับหลาย product

CustomerOS

เจ้าของถามว่า:

“วันนี้ lead หลุดตรงไหน”

AI ไม่ควร query raw conversations มั่ว ๆ แล้วสรุปเอง

ควรมี semantic layer ของ CRM เช่น:

• lead stage
• response SLA
• unanswered conversation
• quote sent
• follow-up due
• won/lost reason
• source channel

แล้วตอบพร้อม proof ว่า conversation ไหน, admin คนไหน, stage ไหน, freshness ถึงเมื่อไร

TimeFlow

ผู้บริหารถามว่า:

“ทีมไหน overtime ผิดปกติ”

AI ต้องรู้ว่า overtime definition คืออะไร นับ leave ยังไง รวม weekend ไหม ใช้ approved timesheet เท่านั้นไหม ตัด contractor หรือ intern ไหม

ไม่อย่างนั้นตัวเลข HR จะผิด และกลายเป็นเรื่อง sensitive ทันที

Learn / AI Mentor

ผู้เรียนถามว่า:

“นักเรียนติดตรงไหนในคอร์ส n8n”

ระบบต้องนิยาม learning progress ให้ชัดก่อน:

• watched lesson
• quiz attempt
• mentor question
• lab completion
• inactive days
• course entitlement

AI Mentor Analytics ต้องตอบจาก learning semantic layer ไม่ใช่ไล่อ่าน event log แล้วเดาเอง

OPB Stack / Business OS

นี่คือจุดที่ผมคิดว่า Anthropic article ต่อกับ Business OS ชัดมาก

Business OS ไม่ใช่แค่มี AI agent แต่ต้องมี source of truth, procedures, approval, proof, memory และ evals

ถ้า owner ถาม business question แล้ว AI ตอบด้วย number ที่ไม่มี provenance ธุรกิจไม่ควรเอาไปตัดสินใจ

6) Pattern ที่ควรเริ่ม ถ้าจะทำ AI Analytics จริง

ถ้าบริษัทไทยอยากเริ่ม ผมจะแนะนำแบบ practical มาก:

เริ่มจาก metric สำคัญ 5 ตัว

ไม่ต้องทำทุกอย่าง เลือก 5 metric ที่ owner ถามบ่อยและใช้ตัดสินใจจริง เช่น:

• revenue
• lead conversion
• response time
• gross margin
• repeat customer

ทำ definition ให้จบก่อน

ทำ canonical dataset

อย่าให้มี revenue 7 เวอร์ชันใน 7 sheet

ให้มี source of truth หนึ่งชุด แล้ว dataset อื่น derive จากมัน

เขียน reference docs ให้ AI อ่าน

ไม่ใช่เขียน docs ให้คนอ่านอย่างเดียว

ต้องมี grain, scope, exclusions, gotchas, join keys, required filters, owner, freshness และตัวอย่างคำถาม

ทำ skill สำหรับ analytics workflow

skill ควรบอก agent ว่า:

• ต้อง clarify อะไรก่อน
• ต้องใช้ semantic layer ก่อน
• raw SQL ใช้เมื่อไร
• ห้ามตอบเกิน data อย่างไร
• ต้องให้ provenance footer ทุกครั้ง

ทำ eval เล็ก ๆ ก่อน launch

เริ่มจาก 20 ถึง 30 คำถามที่ owner หรือ manager ถามจริง

อย่าปล่อย AI Analytics ให้คนทั้งบริษัทใช้ ถ้ายังไม่รู้ว่าคำถามพื้นฐานตอบถูกแค่ไหน

เก็บ correction กลับเข้าระบบ

ถ้าคนบอกว่า “นี่ใช้ table ผิด” หรือ “ต้อง exclude fraud” อย่าให้ correction หายไปใน chat

ให้มันกลายเป็น reference doc update และ eval case ใหม่

นี่คือ loop ที่ทำให้ agent ดีขึ้นจริง

7) มุมมองของผม

บทความนี้ดี เพราะมันลดความ romantic ของ AI Analytics ลงเยอะ

AI ไม่ได้เก่งเพราะมันเขียน SQL ได้ AI เก่งเมื่อองค์กรจัดทางให้มันใช้ข้อมูลถูก

และนี่คือสิ่งที่หลายธุรกิจมักมองข้าม

เราอยากได้ chatbot ที่ถามยอดขายได้ แต่ยังไม่มี definition ยอดขายที่ทุกคนยอมรับ

เราอยากได้ dashboard อัตโนมัติ แต่ยังมี Google Sheet 12 ชุดที่ตัวเลขไม่ตรงกัน

เราอยากให้ AI วิเคราะห์ลูกค้า แต่ยังไม่รู้ว่า customer หนึ่งคน map กับ LINE user, phone, order และ CRM record ยังไง

ถ้าพื้นฐานพวกนี้ไม่ชัด AI จะไม่แก้ปัญหา มันจะทำให้ปัญหาดูน่าเชื่อขึ้น

สำหรับผม บทเรียนสั้น ๆ คือ:

Self-service analytics ไม่ได้เริ่มจาก AI มันเริ่มจาก source of truth

AI เป็นคนถาม คนค้น คนสรุป และคนเปิดหน้าจอให้เราเห็น แต่ semantic layer, skills, evals และ provenance คือสิ่งที่ทำให้เรากล้าเชื่อคำตอบนั้น

ถ้าจะเอา AI มาใช้กับตัวเลขธุรกิจจริง อย่าถามแค่ว่า model ไหนเก่ง ให้ถามว่า:

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

คำถามพวกนี้อาจไม่ sexy แต่เป็นคำถามที่ทำให้ AI Analytics ใช้กับธุรกิจจริงได้