SharePoint Agent ทำงานได้ตอน Demo แต่ข้อมูลจริงหลายร้อย GB ทำไมถึงตอบไม่ได้
คำตอบสั้น
SharePoint agent ที่ตอบเก่งตอน demo กับ 20 ไฟล์ มักตอบพลาดเมื่อเจอ knowledge base หลายร้อย GB เพราะปัญหาไม่ได้อยู่ที่ตัว AI model แต่อยู่ที่ retrieval architecture ซึ่งก็คือวิธีที่ระบบค้นและดึงข้อมูลที่ถูกต้องส่งให้ model การแก้ที่ยั่งยืนคือเลือกระหว่าง Microsoft 365 index กับ Azure AI Search ให้เหมาะกับปริมาณและชนิดไฟล์ จัดเตรียมเอกสารให้ AI อ่านได้ และวัดผลด้วย latency และ answer quality ไม่ใช่แค่เพิ่มไฟล์เข้าไปเรื่อย ๆ
ทำไม agent ถึงทำงานได้ตอน demo แต่พังตอนใช้จริง
เพราะ demo ใช้เอกสารจำนวนน้อยที่คัดมาแล้วและมีโครงสร้างชัดเจน ทำให้ระบบหาคำตอบเจอเกือบทุกครั้ง แต่เมื่อ corpus โตเป็นหลายร้อย GB โอกาสที่ระบบจะดึงเอกสารผิดชิ้นมาให้ model เพิ่มขึ้นอย่างรวดเร็ว
สถานการณ์นี้เกิดขึ้นซ้ำ ๆ ในโครงการ AI Agent ขององค์กรไทย ทีม IT สร้าง agent เชื่อมกับ SharePoint site หนึ่ง ทดสอบกับเอกสารนโยบาย 20 ไฟล์ ผลลัพธ์ออกมาดีมาก ผู้บริหารอนุมัติให้ขยายทั้งองค์กร พอเชื่อมกับ document library จริงที่มีข้อมูลสะสมมาสิบปี คำตอบกลับเริ่มคลาดเคลื่อน ช้าลง และบางครั้งอ้างอิงเอกสารที่ถูกยกเลิกไปแล้ว
ความเข้าใจผิดที่พบบ่อยที่สุดคือคิดว่าการเชื่อม Copilot เข้ากับ SharePoint เท่ากับการออกแบบ enterprise search บน SharePoint ซึ่งเป็นคนละเรื่องกัน อย่างแรกคือการต่อท่อ อย่างที่สองคือการออกแบบสถาปัตยกรรม
ปัญหาซ่อนอยู่ที่ชั้น retrieval ไม่ใช่ชั้น model
เมื่อผู้ใช้ถามคำถาม ระบบจะไม่ได้ส่งเอกสารทั้งหมดให้ model อ่าน แต่จะค้นหาชิ้นส่วนข้อความที่เกี่ยวข้องที่สุดจำนวนจำกัดส่งไปให้ ถ้าชั้นค้นหานี้ดึงชิ้นส่วนผิดมา model ที่เก่งแค่ไหนก็ตอบถูกไม่ได้ เพราะมันไม่เคยเห็นข้อมูลที่ถูกต้องเลย
Small curated knowledge set ต่างจาก Enterprise corpus อย่างไร
Small curated knowledge set คือชุดเอกสารจำนวนจำกัดที่จัดระเบียบมาแล้ว ใช้ native Copilot knowledge ก็เพียงพอ ส่วน Enterprise corpus คือข้อมูลหลายร้อย GB หลายชนิดไฟล์ที่ต้องออกแบบ retrieval อย่างจงใจ
Native Copilot knowledge เพียงพอ
- ทำงานได้ดีกับเอกสารจำนวนจำกัดที่มีโครงสร้างชัดเจน
- จัดการและดูแลรักษาง่าย ไม่ต้องมีทีมเฉพาะ
- เหมาะกับ pilot, demo และ use case ที่ขอบเขตแคบ
- ต้นทุนต่ำ เริ่มได้เร็วภายในไม่กี่วัน
ต้องออกแบบ retrieval อย่างจงใจ
- ปริมาณข้อมูลระดับหลายร้อย GB
- ชนิดไฟล์หลากหลาย ทั้ง PDF, Excel, รูปภาพ
- คำถามของผู้ใช้กว้างและซับซ้อนกว่ามาก
- ความคาดหวังสูงขึ้นทั้งด้านความแม่นยำ ความเร็ว และ governance
เส้นแบ่งไม่ได้อยู่ที่ขนาดไฟล์อย่างเดียว แต่อยู่ที่ว่าคำถามของผู้ใช้กว้างแค่ไหน ถ้าผู้ใช้ถามได้เฉพาะเรื่องนโยบาย HR การใช้ native knowledge ก็เพียงพอแม้จะมีไฟล์เยอะ แต่ถ้าผู้ใช้ถามข้ามแผนกได้ทุกเรื่อง ต่อให้ไฟล์ไม่มากก็ต้องคิดเรื่อง retrieval ตั้งแต่แรก
4 คำถามที่ต้องตอบให้ได้ก่อนเลือก retrieval approach
ก่อนตัดสินใจเรื่องสถาปัตยกรรม ต้องตอบให้ชัดว่าจะ index อย่างไร ไฟล์เป็นมิตรกับ AI หรือไม่ รับ response time ได้เท่าไร และจะวัดคุณภาพคำตอบด้วยอะไร
จะ index อย่างไร
จะใช้ Microsoft 365 index ที่มีอยู่แล้ว หรือจะสร้าง search index แยกต่างหาก คำตอบข้อนี้กำหนดต้นทุนและความซับซ้อนทั้งโครงการ
ไฟล์เป็นมิตรกับ AI หรือไม่
PDF ที่สแกนมา ไฟล์ Excel ที่มีสูตรซับซ้อน และรูปภาพ ล้วนต้องผ่านการเตรียมก่อน ไม่ใช่โยนเข้าไปแล้วใช้ได้ทันที
รับ response time ได้เท่าไร
ต้องหาสมดุลระหว่างความคาดหวังของผู้ใช้กับการออกแบบ retrieval และ infrastructure ที่ลงทุนไหว
จะวัดคุณภาพด้วยอะไร
ต้องนิยามให้ได้ว่าคำตอบที่ดีสำหรับองค์กรของคุณหน้าตาเป็นอย่างไร ไม่ใช่ปล่อยให้เป็นความรู้สึก
ยังไม่แน่ใจว่าองค์กรของคุณอยู่ตรงไหนของ 4 คำถามนี้
ทำ Copilot Readiness Assessment ฟรีMicrosoft รองรับอะไรอยู่ตอนนี้
Copilot Studio รองรับ knowledge source ได้สูงสุด 500 แหล่งต่อ agent ขณะที่ SharePoint knowledge มีข้อจำกัดด้านจำนวนแหล่งและไฟล์ ส่วน Azure AI Search ถูกวางตำแหน่งสำหรับชุดเอกสารขนาดใหญ่โดยเฉพาะ
| ความสามารถ | สิ่งที่ต้องรู้ |
|---|---|
| Copilot Studio knowledge sources | รองรับได้สูงสุด 500 knowledge sources ต่อหนึ่ง agent ซึ่งฟังดูเยอะ แต่ในทางปฏิบัติจำนวนแหล่งไม่ใช่ตัวชี้วัดคุณภาพ |
| SharePoint knowledge | มีข้อจำกัดเชิงปฏิบัติทั้งด้านจำนวนแหล่งและจำนวนไฟล์ ต้องตรวจสอบก่อนออกแบบขอบเขต |
| ไฟล์ XLSX | เพิ่มเข้าไปได้ แต่คำตอบเชิงวิเคราะห์อาจไม่เหมาะสมนัก เพราะ agent ไม่ได้รันโค้ดคำนวณบนข้อมูลตารางแบบอิสระ |
| Azure AI Search | ถูกวางตำแหน่งอย่างชัดเจนว่าเหมาะกับชุดเอกสารขนาดใหญ่ที่ต้องการ enterprise search |
| Microsoft 365 Copilot Retrieval API | คืนชิ้นส่วนข้อความที่เกี่ยวข้องและผ่านการตัดสิทธิ์ตาม permission แล้ว จาก SharePoint, OneDrive และ Copilot connectors โดยไม่ต้องสร้าง index แยก |
เลือก Microsoft 365 index หรือ Azure AI Search ดี
เลือก Microsoft 365 index เมื่อต้องการความเรียบง่ายและอยู่ใกล้กับ permission และความสดของข้อมูลเดิม เลือก Azure AI Search เมื่อต้องการควบคุมการ index เอง จูนการค้นหาได้ และรองรับข้อมูลหลายรูปแบบขนาดใหญ่
| ประเด็น | Microsoft 365 / SharePoint index | Azure AI Search |
|---|---|---|
| สถาปัตยกรรม | เรียบง่ายกว่า ไม่ต้องสร้างระบบแยก | ต้องมี search และ indexing architecture แยกต่างหาก |
| Permission | ใช้ permission ของ Microsoft 365 โดยตรง ตัดสิทธิ์อัตโนมัติ | ต้องออกแบบการจัดการสิทธิ์เพิ่มเติมเอง |
| ความสดของข้อมูล | ใกล้เคียงกับเนื้อหาต้นทางมากที่สุด | ขึ้นกับรอบการ index ที่ออกแบบไว้ |
| การควบคุมและจูน | ปรับแต่งได้จำกัด | ควบคุม custom indexing, search tuning และ observability ได้มากกว่า |
| ข้อมูลหลายรูปแบบ | เหมาะกับเนื้อหาใน Microsoft 365 เป็นหลัก | รองรับ scenario ที่ซับซ้อน ขนาดใหญ่ และหลายรูปแบบ |
| เหมาะกับใคร | องค์กรที่ข้อมูลอยู่ใน Microsoft 365 เป็นหลักและต้องการเริ่มเร็ว | องค์กรที่มี corpus ขนาดใหญ่และต้องการ performance ที่ออกแบบได้ |
ข้อควรระวัง retrieval ที่เร็วขึ้นไม่ได้แปลว่าคำตอบดีขึ้นอัตโนมัติ
การเปลี่ยนสถาปัตยกรรม retrieval ช่วยลด latency ได้จริง แต่คุณภาพคำตอบยังขึ้นอยู่กับว่า index อะไรไว้ แบ่งชิ้นข้อมูลและดึงออกมาอย่างไร และเนื้อหาที่ถูกต้องได้ไปถึง model หรือไม่ องค์กรจำนวนมากลงทุนย้ายไป Azure AI Search แล้วพบว่าคำตอบยังผิดเหมือนเดิม เพราะไม่ได้แก้ที่คุณภาพเอกสารต้นทาง
6 trade-off ที่ต้องชั่งน้ำหนัก
ทุกการตัดสินใจเรื่อง retrieval จะกระทบ 6 ด้านเสมอ ได้แก่ Permissions, Freshness, Quality, Latency, Cost และ Observability ไม่มีทางเลือกไหนชนะทุกด้านพร้อมกัน
| Trade-off | คำถามที่ต้องตอบ |
|---|---|
| Permissions | ผู้ใช้จะเห็นเฉพาะข้อมูลที่ตัวเองมีสิทธิ์เห็นหรือไม่ และใครเป็นคนรับผิดชอบเมื่อมีข้อมูลรั่ว |
| Freshness | เมื่อมีเอกสารใหม่หรือมีการแก้ไข agent จะรู้ภายในกี่นาทีหรือกี่ชั่วโมง |
| Quality | คำตอบที่ได้ตรงกับเจตนาของคำถามแค่ไหน และอ้างอิงแหล่งที่ถูกต้องหรือไม่ |
| Latency | ผู้ใช้รอได้กี่วินาที และเวลาตอบสนองนี้ยอมรับได้ในกระบวนการทำงานจริงหรือไม่ |
| Cost | ต้นทุน index, storage และ compute ต่อเดือนเป็นเท่าไร และโตตามปริมาณข้อมูลอย่างไร |
| Observability | เมื่อคำตอบผิด เราสืบย้อนได้หรือไม่ว่าระบบดึงเอกสารชิ้นไหนมาให้ model |
ข้อที่องค์กรไทยมักมองข้ามที่สุดคือ Observability เพราะตอน pilot ทุกคนอยู่ในห้องเดียวกันและรู้ว่าคำตอบผิดตรงไหน แต่เมื่อขยายไปหลายร้อยผู้ใช้ ถ้าไม่มีระบบสืบย้อนว่า retrieval ดึงอะไรมา ทีมจะแก้ปัญหาไม่ถูกจุดและจบลงด้วยการโทษ model
ทำไมไฟล์ Excel 30 sheet ถึงเป็นปัญหาใหญ่
ไฟล์ Excel ที่มี 30 sheet และข้อมูลแบบมีโครงสร้าง มักต้องผ่านการจัดโครงสร้างใหม่ แยกตารางให้ชัด แบ่งไฟล์ หรือใช้ retrieval approach ที่ต่างออกไป เพราะ agent ไม่ได้รันการคำนวณบนตารางแบบอิสระ
นี่คือจุดที่ความคาดหวังกับความจริงห่างกันมากที่สุด ทีมการเงินมักคาดหวังว่า agent จะตอบได้ว่ายอดขายไตรมาสสามโตกี่เปอร์เซ็นต์จากไฟล์งบที่อัปโหลดเข้าไป แต่ระบบดึงข้อความจากตารางมาเป็นชิ้น ๆ แล้วให้ model อ่าน ซึ่งไม่เหมือนการเปิด Excel แล้วคำนวณ
แนวทางแก้ที่ใช้ได้จริง
- แยกไฟล์ที่มีหลาย sheet ออกเป็นไฟล์ย่อยตามหัวข้อ เพื่อให้แต่ละชิ้นมีบริบทครบในตัวเอง
- ทำตารางให้เป็น flat table มี header ชัดเจน ไม่มี merged cell และไม่มีแถวว่างคั่น
- สร้างเอกสารสรุปเป็นข้อความประกอบไฟล์ตัวเลข เพื่อให้ agent มีบริบทเชิงคำอธิบาย
- ถ้าต้องการการคำนวณจริง ให้แยกไปใช้ Power BI หรือเครื่องมือวิเคราะห์ แล้วให้ agent อ้างอิงผลลัพธ์แทน
5 ขั้นตอนจาก demo สู่ enterprise-ready
เส้นทางที่ใช้ได้จริงมี 5 ขั้นตามลำดับ ได้แก่ Scope, Prepare, Retrieve, Measure และ Govern การข้ามขั้นใดขั้นหนึ่งมักทำให้ต้องย้อนกลับมาแก้ในภายหลัง
Scope กำหนดขอบเขต
นิยามให้ชัดว่า corpus ครอบคลุมอะไรบ้าง และผู้ใช้จะถามคำถามประเภทไหน เขียนตัวอย่างคำถามจริงอย่างน้อย 30 ข้อจากผู้ใช้จริง ไม่ใช่จากจินตนาการของทีม IT
Prepare จัดเตรียมเอกสาร
ทำความสะอาดรูปแบบไฟล์ จัดโครงสร้างใหม่ และใส่ metadata ขั้นตอนนี้กินเวลามากที่สุดแต่ให้ผลตอบแทนสูงที่สุด
Retrieve เลือกวิธีดึงข้อมูล
ตัดสินใจระหว่าง Microsoft 365 retrieval กับ purpose-built search index โดยอิงจากคำตอบของ 4 คำถามและ 6 trade-off ข้างต้น
Measure วัดผล
ทดสอบ latency, relevance และ answer quality ด้วยชุดคำถามมาตรฐาน วัดซ้ำทุกครั้งที่มีการเปลี่ยนแปลง ไม่ใช่วัดครั้งเดียวตอนเปิดตัว
Govern กำกับดูแล
ตรวจสอบ permission ความสดของข้อมูล ต้นทุน และการ monitoring อย่างต่อเนื่อง กำหนดผู้รับผิดชอบที่ชัดเจนในแต่ละด้าน
สรุปประเด็นสำคัญ
- การเชื่อม Copilot กับ SharePoint ไม่เท่ากับการออกแบบ enterprise search บน SharePoint อย่างแรกคือการต่อท่อ อย่างที่สองคือการออกแบบสถาปัตยกรรม
- เมื่อ knowledge base โตขึ้น retrieval architecture สำคัญไม่แพ้ตัว model เพราะ model ตอบได้เฉพาะจากข้อมูลที่ระบบดึงมาให้เท่านั้น
- ไฟล์เยอะไม่ใช่กลยุทธ์ สิ่งที่ต้องออกแบบคือวิธีดึงข้อมูล ไม่ใช่ปริมาณข้อมูลที่ใส่เข้าไป
- retrieval ที่เร็วขึ้นไม่ได้แปลว่าคำตอบถูกต้องขึ้น คุณภาพยังขึ้นกับสิ่งที่ index และวิธีแบ่งชิ้นข้อมูล
- ไฟล์ Excel หลาย sheet ต้องจัดการเป็นพิเศษ เพราะ agent ไม่ได้รันการคำนวณบนตารางแบบอิสระ
คำถามที่พบบ่อย
Copilot Studio รองรับ knowledge source ได้กี่แหล่งต่อ agent
รองรับได้สูงสุด 500 knowledge sources ต่อหนึ่ง agent อย่างไรก็ตามจำนวนแหล่งไม่ใช่ตัวชี้วัดคุณภาพคำตอบ องค์กรที่ใส่ครบ 500 แหล่งโดยไม่จัดเตรียมเอกสาร มักได้คำตอบแย่กว่าองค์กรที่ใช้ 20 แหล่งที่คัดมาอย่างดี
ต้องสร้าง search index แยกเสมอไหมถ้าข้อมูลเยอะ
ไม่เสมอไป Microsoft 365 Copilot Retrieval API สามารถคืนชิ้นส่วนข้อความที่ผ่านการตัดสิทธิ์ตาม permission แล้วจาก SharePoint, OneDrive และ Copilot connectors โดยไม่ต้องสร้าง index แยก ควรทดสอบแนวทางนี้ก่อนเสมอ แล้วค่อยพิจารณา Azure AI Search เมื่อพบข้อจำกัดที่ชัดเจน
ใส่ไฟล์ Excel ให้ agent ได้ไหม
ใส่ได้ แต่คำตอบเชิงวิเคราะห์อาจไม่เหมาะสมนัก เพราะ agent ไม่ได้รันโค้ดคำนวณบนข้อมูลตารางแบบอิสระ ไฟล์ที่มี 30 sheet หรือข้อมูลโครงสร้างซับซ้อน ควรจัดโครงสร้างใหม่ แยกตารางให้ชัด หรือแบ่งไฟล์ก่อน
Azure AI Search เหมาะกับองค์กรแบบไหน
เหมาะกับองค์กรที่มีชุดเอกสารขนาดใหญ่และต้องการ enterprise search จริงจัง โดยให้การควบคุมเรื่อง custom indexing, search tuning และ observability มากกว่า แต่แลกมาด้วยความซับซ้อนของสถาปัตยกรรมและต้นทุนที่สูงขึ้น
จะรู้ได้อย่างไรว่าถึงเวลาต้องเปลี่ยน retrieval architecture
สัญญาณที่ชัดที่สุดมีสามข้อ หนึ่งคือ latency สูงจนผู้ใช้เลิกใช้ สองคือคำตอบอ้างอิงเอกสารผิดบ่อยแม้เอกสารที่ถูกต้องจะอยู่ในระบบ และสามคือทีมสืบย้อนไม่ได้ว่าระบบดึงอะไรมา ถ้าเจอข้อใดข้อหนึ่งเป็นประจำควรทบทวนสถาปัตยกรรม
เริ่มต้นโครงการ AI Agent ควรใช้เวลาเท่าไรถึงจะพร้อมใช้จริง
ขึ้นอยู่กับความพร้อมของเอกสารเป็นหลัก องค์กรที่มีเอกสารจัดระเบียบดีอยู่แล้วสามารถทำ pilot ที่ใช้งานจริงได้ภายใน 4 ถึง 6 สัปดาห์ ส่วนองค์กรที่ต้องทำความสะอาดข้อมูลก่อน ขั้นตอน Prepare มักใช้เวลามากกว่าขั้นตอนอื่นรวมกัน
แหล่งอ้างอิง
MISO Digital, MFEC Group
Microsoft Solutions Partner with Copilot Specialization