สรุปจากคลิป ดูคลิปต้นฉบับ
Agentic Search for Context Engineering ทำไม AI เก่งไม่พอถ้าหาข้อมูลผิด
ปัญหาของ AI agent ในโลกธุรกิจไม่ได้อยู่แค่ว่า model ฉลาดพอไหม แต่อยู่ที่มัน “หยิบข้อมูลอะไรเข้ามาคิด” ต่างหาก ถ้าหยิบผิด ต่อให้ใช้ model แพงแค่ไหน คำตอบก็ยังผิด หลุดประเด็น หรือชวนให้ตัดสินใจพลาดได้อยู่ดี
นี่คือประเด็นแกนกลางจากคลิป Agentic Search for Context Engineering บนช่อง AI Engineer ที่ Leonie Monigatti จาก Elastic อธิบายไว้น่าสนใจมากว่า งานที่หลายทีมเรียกรวมๆ ว่า retrieval หรือ RAG จริงๆ แล้วมีส่วนที่สำคัญกว่านั้น คือ “search” หรือวิธีที่ agent ตัดสินใจว่าจะไปค้นอะไร จากไหน และค้นยังไง
มุมนี้สำคัญกับเจ้าของธุรกิจและคนทำงานมาก เพราะเวลาจะเอา AI ไปใช้จริง เราไม่ได้ต้องการแค่ chatbot ตอบได้ แต่ต้องการระบบที่หาเอกสารภายใน, ข้อมูลลูกค้า, policy, ไฟล์งาน, หรือข้อมูลบนเว็บได้ถูกที่ถูกเวลา ถ้าจุดนี้ออกแบบไม่ดี AI จะดูฉลาดแค่ตอนเดโม แต่พอใช้จริงจะเริ่มตอบมั่วทันที
สารบัญ
- Step 1: เข้าใจก่อนว่า Context Engineering ไม่ใช่แค่ยัดข้อมูลเข้า model
- Step 2: เห็นวิวัฒนาการจาก RAG แบบตายตัว ไปสู่ Agentic RAG
- Step 3: เลิกหาค้อนอันเดียว แล้วมอง search tools เป็นชุดเครื่องมือ
- Step 4: รู้ failure mode ก่อนสร้าง agent จริง
- Step 5: เริ่มจาก semantic search แบบง่าย แล้วสังเกตว่ามันพังตรงไหน
- Step 6: ให้ agent เขียน query เอง เมื่อโจทย์เริ่มซับซ้อน
- Step 7: ใช้ Agent Skills เพื่อสอนงานยากแบบเป็นชั้นๆ
- Step 8: อย่ามองข้าม Shell Tool เพราะมันสารพัดประโยชน์
- Step 9: เสริม Shell Tool ด้วย CLI ที่เก่งเรื่อง semantic search โดยตรง
- Step 10: ออกแบบ tool stack แบบ Low Floor, High Ceiling
- Step 11: มองข้อจำกัดเรื่อง model, latency และความน่าเชื่อถือให้ครบ
- Step 12: Actionable Insights สำหรับเจ้าของธุรกิจและคนทำงาน
- Step 13: Troubleshooting ปัญหาที่มักเจอเมื่อเริ่มทำ Agentic Search
- Step 14: การต่อยอดที่น่าทำต่อ
- Step 15: สรุป Checklist ทั้งหมด
Step 1: เข้าใจก่อนว่า Context Engineering ไม่ใช่แค่ยัดข้อมูลเข้า model
Leonie เสนอภาพที่คมมากว่า context engineering คือศิลปะของการเลือกว่าจากแหล่งข้อมูลทั้งหมด อะไรควรถูกส่งเข้า context window ของ LLM ประโยคนี้ฟังเหมือนเรื่องเทคนิค แต่ถ้าแปลเป็นภาษาธุรกิจ มันคือการออกแบบว่า AI จะ “ใช้ข้อมูลอะไรในการตอบ”
หลายทีมมักโฟกัสที่ prompt หรือ model เป็นหลัก แต่ช่องว่างสำคัญจริงๆ คือกลไกระหว่าง แหล่งข้อมูล กับ สิ่งที่ถูกส่งเข้าไปให้ model อ่าน ตรงนี้เองที่ search tools เข้ามามีบทบาท
แหล่งข้อมูลที่ AI agent อาจต้องใช้มีหลายแบบ เช่น
- ไฟล์ในเครื่อง หรือไฟล์โปรเจกต์
- ฐานข้อมูลบริษัท
- ข้อมูลบนเว็บ
- memory ระยะยาว
- เอกสารความรู้หรือ skill ของ agent
ถ้ามองในมุมธุรกิจไทย ภาพนี้ชัดมาก เช่น agent ที่ช่วยฝ่ายขายอาจต้องดึงข้อมูลจาก CRM, Google Drive, ราคาโปรโมชันล่าสุด, FAQ ภายใน, และประวัติการคุยกับลูกค้า ถ้าไม่มีระบบ search ที่ดี AI จะไม่รู้ว่าควรไปเปิดอะไร อะไรควรข้าม และอะไรควรดึงเข้ามาก่อน
Leonie ถึงกับออกความเห็นว่า context engineering ประมาณ 80% คือ agentic search ซึ่งอาจฟังแรง แต่ถ้ามองจากงานใช้งานจริง ถือว่าเข้าเป้า เพราะปัญหาส่วนใหญ่ไม่ได้มาจากการ “ตอบ” แต่มาจากการ “หาไม่เจอ” หรือ “หาเจอแต่ดึงผิด”
Step 2: เห็นวิวัฒนาการจาก RAG แบบตายตัว ไปสู่ Agentic RAG
RAG รุ่นแรกๆ ทำงานแบบตรงไปตรงมา ผู้ใช้ถามอะไร ระบบก็เอาคำถามนั้นไปค้นในฐานข้อมูล แล้วดึง chunk กลับมาให้ model อ่าน จากนั้นค่อยตอบ
ข้อดีคือเรียบง่าย แต่ข้อเสียก็ชัดมาก
- บางคำถามไม่จำเป็นต้องค้นอะไรเพิ่ม แต่ระบบก็ยังค้น
- ถ้าค้นได้ข้อมูลไม่ตรง อาจยิ่งทำให้ model สับสน
- คำถามซับซ้อนที่ต้องค้นหลายรอบ มักไปไม่ถึงคำตอบ
- ถ้ารอบแรกค้นเจอ hint สำหรับรอบถัดไป ระบบแบบตายตัวก็ตามต่อไม่เป็น
ตรงนี้เองที่ Agentic RAG เข้ามาแทน โดยเปลี่ยนจาก pipeline คงที่ เป็นการให้ agent “ตัดสินใจเอง” ว่าจะเรียกใช้ search tool หรือไม่ และจะค้นกี่รอบ
สำหรับธุรกิจ นี่แปลว่า AI เริ่มทำงานเหมือนพนักงานมากขึ้น คือไม่ได้หยิบเอกสารทุกชิ้นมาดูพร้อมกัน แต่จะคิดก่อนว่า คำถามนี้ต้องเปิดฐานข้อมูลไหม ต้องเปิดไฟล์ในเครื่องไหม หรือแค่ตอบจากความรู้ทั่วไปก็พอ
อย่างไรก็ดี จุดที่ควรระวังคือ agentic ไม่ได้แปลว่าแม่นเสมอ มันแปลว่า “มีอิสระมากขึ้น” และอิสระนั้นก็มาพร้อมความเสี่ยง ถ้า tool design ไม่ดี AI จะใช้ tool ผิดตัวหรือไม่ใช้เลย
Step 3: เลิกหาค้อนอันเดียว แล้วมอง search tools เป็นชุดเครื่องมือ
หนึ่งในแก่นสำคัญของคลิปนี้คือ ไม่มี search tool ตัวเดียวที่ชนะทุกโจทย์ Leonie ย้ำชัดว่า การทำ search ให้ดีเป็นเรื่องยากมาก และนั่นคือเหตุผลที่เรามีทั้ง vector search, keyword search, dense embeddings, sparse embeddings, multi-vector embeddings รวมถึงวิธี indexing ที่ต่างกันไป
สรุปง่ายๆ คือ AI agent ที่จะใช้งานจริง ควรมี tool stack ไม่ใช่ tool เดียว
ตัวอย่าง search tools ที่ถูกพูดถึง มีทั้ง
- Semantic search tool สำหรับค้นตามความหมาย
- Database query tool สำหรับให้ agent เขียน query เอง
- Web search tool สำหรับข้อมูลภายนอก
- Memory tool สำหรับดึงความจำเดิม
- Shell/Bash tool สำหรับให้ agent ใช้คำสั่ง terminal เพื่อสำรวจไฟล์หรือเรียก CLI ต่างๆ
ประเด็นนี้เอามาใช้กับองค์กรไทยได้ตรงมาก เช่น ถ้าเรามี AI ช่วยทีม operation เราอาจไม่ควรบังคับให้มันใช้ semantic search อย่างเดียว เพราะบางคำถามต้องการ exact match เช่น เลข invoice, รหัสลูกค้า, SKU สินค้า, หรือเลขสัญญา ซึ่ง keyword หรือ query ตรงๆ จะเหมาะกว่า
Step 4: รู้ failure mode ก่อนสร้าง agent จริง
ส่วนที่มีประโยชน์มากคือ Leonie แยกให้เห็นว่า agentic search พังได้หลายแบบ และ 3 แบบแรกที่เจอบ่อยคือ
- agent ไม่เรียก tool เลย
- agent เรียก tool ผิดตัว
- agent สร้าง parameter ผิด
สามข้อนี้ฟังดูเป็นเรื่องเทคนิค แต่จริงๆ ส่งผลกับธุรกิจโดยตรง เช่น
- ไม่เรียก tool เลย หมายถึง AI ตอบจากความจำตัวเอง ซึ่งเสี่ยง hallucination
- เรียก tool ผิดตัว หมายถึงควรค้นในฐานข้อมูลลูกค้า แต่ดันไปค้นเว็บ
- ใส่ parameter ผิด หมายถึงไปดึงข้อมูลคนละชุด แล้วตอบผิดแบบดูเหมือนมั่นใจ
Leonie ชี้ว่าต้นเหตุสำคัญมักอยู่ที่ tool description ถ้าอธิบายสั้นเกินไป agent จะเลือกใช้ไม่ถูก โดยเฉพาะเมื่อมีหลาย tools พร้อมกัน คำอธิบายควรระบุให้ชัดว่า
- tool นี้มีไว้ทำอะไร
- ควรใช้เมื่อไร
- ไม่ควรใช้เมื่อไร
- ควรใช้ก่อนหรือหลัง tool อื่นหรือไม่
มุมนี้น่าสนใจมากสำหรับคนทำงาน เพราะสะท้อนความจริงแบบเดียวกับการบริหารทีม ถ้าคำสั่งงานคลุมเครือ ต่อให้ลูกทีมเก่งก็ยังทำผิดได้ AI ก็เหมือนกัน
Step 5: เริ่มจาก semantic search แบบง่าย แล้วสังเกตว่ามันพังตรงไหน
ในเดโมแรก Leonie ใช้ข้อมูล session ของงาน conference เก็บใน Elasticsearch แล้วสร้าง semantic search tool แบบพื้นฐาน Agent สามารถรับคำถาม เช่น “มี session ไหนพูดถึง regulatory constraints บ้าง” แล้วเรียก semantic search เพื่อหาคำตอบได้
ช่วงนี้เป็นเดโมคลาสสิกของ agentic search ที่หลายทีมใช้สาธิต และตรงนี้เองที่หลายคนอาจเข้าใจผิดว่า “ระบบพร้อมแล้ว” ทั้งที่จริงมันยังเปราะมาก
เพราะพอเปลี่ยนคำถามเป็น “ควรไป session ไหนเพื่อเรียนรู้เรื่อง GEPA” ระบบ semantic search กลับดึงผลลัพธ์ผิด เช่น ไปเจอ session เกี่ยวกับ Gemma หรือเรื่องอื่นที่คล้ายกันทาง token แต่ไม่ใช่สิ่งที่ถาม
นี่คือข้อจำกัดสำคัญของ semantic search มันเก่งกับความหมายกว้างๆ แต่ไม่ได้แปลว่าจะเก่งกับคำเฉพาะ, ชื่อเฉพาะ, ตัวย่อ, รหัสสินค้า หรือคำที่ต้อง exact match เสมอไป
ถ้าเอามาเทียบกับธุรกิจไทย ปัญหานี้เจอบ่อยมาก เช่น
- ถามหารหัสสินค้าเฉพาะ แต่ระบบดึงสินค้าที่คล้ายกัน
- ถามชื่อ policy ภายใน แต่ AI หยิบเอกสารอีกฉบับที่มีความหมายใกล้กัน
- ถามชื่อลูกค้าองค์กรที่สะกดคล้ายกัน แล้วสรุปผิดบัญชี
ตรงนี้คือเหตุผลว่าทำไม “มี RAG” ไม่ได้แปลว่า “พร้อมใช้กับงานจริง”
Step 6: ให้ agent เขียน query เอง เมื่อโจทย์เริ่มซับซ้อน
เมื่อ semantic search ไม่พอ Leonie ขยับไปใช้ general-purpose database tool ที่เปิดให้ agent เขียน query ทั้งก้อนเอง ด้วย Elasticsearch Query Language หรือ ESQL
ข้อดีคือ agent ไม่ได้จำกัดอยู่แค่การค้นตามหัวข้อ แต่สามารถ
- กรองตาม metadata ได้
- นับจำนวนได้
- ทำ aggregation ได้
- จัดรูปข้อมูลก่อนส่งกลับได้
นี่เป็นก้าวสำคัญในเชิงความสามารถ แต่ก็เพิ่มความเสี่ยงทันที เพราะการเขียน query เต็มรูปแบบยากกว่าแค่ส่งข้อความค้นหา
ในเดโม agent พยายามค้นคำว่า GEPA ด้วย wildcard แต่ใช้เครื่องหมายแบบ SQL ผิด ทำให้ผลลัพธ์ออกมาเป็นศูนย์ ทั้งที่ข้อมูลจริงมีอยู่
จุดนี้มีบทเรียนสำคัญ 2 ข้อ
- ผลลัพธ์ว่าง ไม่ได้แปลว่าไม่มีข้อมูลเสมอไป บางครั้งแปลว่า query ผิด
- ยิ่ง tool ยืดหยุ่นมาก agent ยิ่งมีโอกาสพลาดมาก
Leonie จึงเพิ่ม error handling เพื่อให้ agent เห็นข้อความ error และพยายาม self-correct ได้ แทนที่ระบบจะล้มไปเลย ตรงนี้เป็นแนวคิดที่ดีมากสำหรับงานธุรกิจ เพราะของจริงระบบย่อมเจอ edge case ตลอด
Step 7: ใช้ Agent Skills เพื่อสอนงานยากแบบเป็นชั้นๆ
เมื่อ agent เขียน query ผิด วิธีแก้ไม่จำเป็นต้องยัด documentation ทั้งหมดลง system prompt Leonie เสนอทางเลือกที่ฉลาดกว่า คือใช้ agent skills
แนวคิดของ skills คือเก็บคำอธิบายหรือคู่มือไว้แยกต่างหาก โดยใน system prompt จะใส่แค่ชื่อ skill กับคำอธิบายสั้นๆ พอ agent ต้องใช้จริง ค่อยโหลดรายละเอียดเข้ามาใน context แบบ progressive disclosure
ในตัวอย่างนี้ skill ถูกใช้เพื่อบอก syntax พื้นฐานของ ESQL และย้ำเรื่อง wildcard ที่ถูกต้อง จากนั้นยังเพิ่มความสัมพันธ์ระหว่าง tools ด้วย เช่น “ให้โหลด Elasticsearch ESQL skill ก่อน แล้วค่อยใช้ execute query tool”
ผลคือ agent เรียก skill ก่อน แล้วค่อยสร้าง query ที่ถูกต้องจนหา session ที่เกี่ยวกับ GEPA เจอ
มุมนี้มีคุณค่ามากสำหรับองค์กร เพราะมันสะท้อนหลักการจัดการความรู้ที่ดี เราไม่จำเป็นต้องใส่ทุกอย่างไว้ในหัว AI ตลอดเวลา แต่ควรทำให้มัน “หยิบคู่มือที่ใช่ในเวลาที่ใช่” เหมือน onboarding พนักงานใหม่
ข้อสังเกตของเราคือ แนวคิด skills เหมาะกับองค์กรที่มี policy, SOP, ขั้นตอนอนุมัติ, กฎ compliance หรือ workflow ที่ซับซ้อน เพราะช่วยแยก “ความรู้เฉพาะทาง” ออกจาก prompt หลัก ทำให้ดูแลง่ายกว่า
Step 8: อย่ามองข้าม Shell Tool เพราะมันสารพัดประโยชน์
อีกช่วงที่น่าสนใจมากคือการสลับจากฐานข้อมูลไปสู่ local file system แล้วใช้ shell tool หรือ bash tool ให้ agent รันคำสั่ง terminal เอง เช่น ls, grep, cat หรือแม้แต่เรียก CLI อื่นๆ
Leonie ชี้ว่า shell tool มีความยืดหยุ่นสูงมาก เพราะมันสามารถใช้สำรวจไฟล์, ค้นข้อความ, เรียก API ผ่าน curl, หรือเขียนสคริปต์ต่อเองได้
ในเดโม ข้อมูล session ถูกเก็บเป็นไฟล์ในโฟลเดอร์ย่อยตามประเภท Agent ใช้ shell tool เพื่อไล่ดูโครงสร้างโฟลเดอร์ จากนั้นใช้ grep เพื่อหาคำว่า GEPA และอ่านไฟล์ที่เกี่ยวข้องจนตอบได้ว่าควรไป session ไหน
สิ่งที่น่าสนใจคือ agent เก่งกับ bash มากกว่าที่หลายคนคิด เช่นเวลาถามเรื่อง regulatory constraints มันไม่ได้ค้นแค่คำเดียว แต่พยายามแตกเป็นคำพ้องหรือคำใกล้เคียง เช่น compliance, GDPR, governance แล้วค่อยๆ ไล่หา
แม้มันจะทำงานได้ แต่ Leonie ก็ชวนตั้งคำถามตรงๆ ว่า แบบนี้ดีที่สุดหรือยัง คำตอบคือ ไม่เสมอไป เพราะการไล่ synonym ทีละคำอาจกินรอบ, ช้า, และสิ้นเปลือง token
นี่เป็นจุดที่ควรเห็นต่างแบบสร้างสรรค์กับกระแส “all you need is a shell tool” ได้เลย เพราะในโลกจริง shell tool ใช้ได้กว้าง แต่ไม่ได้หมายความว่าเหมาะที่สุดกับทุกโจทย์ โดยเฉพาะเมื่อองค์กรต้องการความเร็ว, ความสม่ำเสมอ, และการกำกับสิทธิ์ใช้งาน
Step 9: เสริม Shell Tool ด้วย CLI ที่เก่งเรื่อง semantic search โดยตรง
เพื่อแก้ข้อจำกัดของ grep ที่เก่งเรื่อง exact match มากกว่า semantic Leonie ยกตัวอย่างการเพิ่ม CLI เฉพาะทางอย่าง JinaGrep เข้าไปใน workflow ผ่าน shell tool
แทนที่ agent จะต้องเดาคำพ้องเองหลายรอบ เราสามารถบอกมันว่า
- ถ้าต้อง exact match ให้ใช้ grep
- ถ้าต้อง semantic search หรือ fuzzy query ให้ใช้ JinaGrep
ผลลัพธ์คือคำถามเดิมเรื่อง regulatory constraints ถูกตอบได้ตรงตั้งแต่ครั้งแรก Agent สำรวจโครงสร้างไฟล์ก่อน แล้วเรียก JinaGrep เพื่อค้นเชิงความหมายจนเจอ session ที่เกี่ยวข้องทันที
บทเรียนสำคัญจากช่วงนี้คือ shell tool ไม่จำเป็นต้องทำทุกอย่างด้วยคำสั่งพื้นฐานเสมอไป เราสามารถ “ขยายความสามารถ” ของมันด้วย CLI เฉพาะทางได้ ซึ่งเหมาะมากกับองค์กรที่มีข้อมูลกระจัดกระจายอยู่บนไฟล์เซิร์ฟเวอร์หรือ shared drive
Step 10: ออกแบบ tool stack แบบ Low Floor, High Ceiling
สรุปเชิงกลยุทธ์ที่ดีที่สุดจากคลิปนี้คือ Leonie แนะนำให้สร้างชุดเครื่องมือที่มีทั้ง low floor และ high ceiling
Low floor คือ tools ที่ใช้ง่าย พารามิเตอร์ไม่ซับซ้อน Agent ใช้แล้วผิดน้อย เช่น
- ค้นลูกค้าด้วย customer ID
- semantic search แบบพื้นฐาน
- ดึงเอกสารตามชื่อไฟล์
High ceiling คือ tools ที่ยืดหยุ่น รับมือคำถามแปลกหรือซับซ้อนได้ เช่น
- query execution tool
- shell tool
- เครื่องมือที่ให้เขียนคำสั่งหรือสคริปต์เอง
มุมมองนี้ใช้กับธุรกิจได้ดีมาก ถ้าเราเพิ่งเริ่มและยังไม่รู้พฤติกรรมการถามของผู้ใช้จริง Leonie แนะนำให้เริ่มจาก general-purpose tool ก่อน จากนั้น log พฤติกรรมของ agent ดูว่ามันถามอะไรบ่อย พลาดตรงไหน ใช้กี่รอบ แล้วค่อยแตกออกมาเป็น tool เฉพาะทางภายหลัง
นี่เป็นคำแนะนำที่มีเหตุผลมาก เพราะหลายองค์กรชอบเริ่มด้วยการออกแบบระบบละเอียดเกินไปตั้งแต่วันแรก แต่พอใช้งานจริง รูปแบบคำถามของทีมขาย, ฝ่ายบริการลูกค้า, ฝ่ายบัญชี หรือผู้บริหารกลับต่างกันมาก การเริ่มแบบยืดหยุ่นก่อนแล้วค่อยเฉพาะทางทีหลังจึงมักคุ้มกว่า
Step 11: มองข้อจำกัดเรื่อง model, latency และความน่าเชื่อถือให้ครบ
ช่วงถามตอบมีหลายประเด็นที่คนทำธุรกิจควรรู้
ข้อแรกคือ model ที่เก่งขึ้นช่วยลด error ได้จริง โดยเฉพาะเวลาต้องสร้างพารามิเตอร์ซับซ้อนหรือเขียน query เอง แต่ model ที่เก่งไม่ได้แปลว่าจะไม่มี error ดังนั้นการหวังพึ่ง model อย่างเดียวไม่พอ
ข้อสองคือ agentic RAG แลกมากับ latency เพราะมีการคิดและเรียก tool หลายรอบ RAG แบบธรรมดายังเหมาะกับหลาย use case ที่ตรงไปตรงมา ตรงนี้เรามองว่าธุรกิจไม่ควรรีบเปลี่ยนทุกอย่างเป็น agentic workflow ถ้าโจทย์เดิมยังใช้ RAG ธรรมดาแล้วตอบได้ดีพอ
ข้อสามคือ hybrid approach มักชนะ มีการพูดถึงการใช้หลาย tools ร่วมกัน เช่น database tool กับ shell tool เพื่อให้เครื่องมือหนึ่งหา อีกเครื่องมือหนึ่งช่วยตรวจสอบ ผลลัพธ์ที่ได้อาจแม่นกว่าการใช้ทางเดียว
ข้อสี่คือ irrelevant results บางส่วนไม่ได้น่ากลัวเสมอไป เพราะ agent รุ่นใหม่พอจะคัดแยกสิ่งที่ไม่เกี่ยวได้ แต่ถ้าสะสมข้อมูลรกใน context มากเกินไปก็ยังเสี่ยงทำให้คุณภาพคำตอบตกในระยะยาว
และข้อสุดท้ายคือเรื่อง skills management ถ้าโหลด skill มากเกินไป context จะบวม ทางออกที่ถูกเสนอคือเก็บ skill ไว้ใน file store แล้วโหลดแบบ on-demand และค่อย offload ออกเมื่อไม่จำเป็นแล้ว แนวคิดนี้สำคัญมากกับระบบองค์กรที่คุยกันยาวหลายรอบ
Step 12: Actionable Insights สำหรับเจ้าของธุรกิจและคนทำงาน
- เลิกถามแค่ว่าใช้ model อะไร แล้วเริ่มถามว่า AI ของเราค้นข้อมูลจากไหน และเลือกแหล่งข้อมูลยังไง
- แยกคำถามเป็น 2 แบบ คือคำถามที่ต้อง exact match กับคำถามที่ต้องค้นตามความหมาย แล้วเลือก tool ให้ตรง
- ถ้าเริ่มต้นยังไม่รู้ pattern การใช้งาน ให้เริ่มด้วย tool ที่ยืดหยุ่นก่อน แล้ว log พฤติกรรมจริง
- อย่าโยนทุกอย่างใส่ prompt เดียว ถ้ามีความรู้เฉพาะทางเยอะ ให้ทำเป็น skills หรือคู่มือที่โหลดเมื่อจำเป็น
- วัดต้นทุนต่อคำตอบ ไม่ใช่แค่ว่าตอบได้หรือไม่ แต่ดูด้วยว่าใช้กี่รอบ ช้าแค่ไหน และมีโอกาสพลาดตรงไหน
Step 13: Troubleshooting ปัญหาที่มักเจอเมื่อเริ่มทำ Agentic Search
ปัญหา: AI ตอบจากความจำ ไม่ยอมค้นข้อมูลภายใน
สาเหตุ: คำอธิบาย tool ไม่ชัด หรือ system prompt ไม่ย้ำว่าควรค้นเมื่อไร
วิธีแก้: ระบุ trigger condition ของแต่ละ tool ให้ชัด และทดสอบด้วยคำถามหลายรูปแบบ
ปัญหา: AI ค้นเจอข้อมูลคล้ายๆ แต่ไม่ตรงเรื่อง
สาเหตุ: ใช้ semantic search กับโจทย์ที่ต้อง exact match เช่น รหัสหรือชื่อเฉพาะ
วิธีแก้: เพิ่ม keyword search, filter หรือ query ตรงๆ สำหรับข้อมูลประเภทนี้
ปัญหา: AI เขียน query ผิด แล้วสรุปว่าไม่มีข้อมูล
สาเหตุ: tool มีพารามิเตอร์ซับซ้อนเกินไป หรือ syntax เฉพาะทางไม่ได้ถูกสอนชัดพอ
วิธีแก้: เพิ่ม error handling, ใส่ skill สำหรับ syntax, และบันทึก query ที่พลาดบ่อยเพื่อนำมาปรับปรุง
ปัญหา: คำตอบช้าเกินใช้งานจริง
สาเหตุ: agent ต้องเรียก tool หลายรอบเพราะเครื่องมือกว้างเกินไป
วิธีแก้: ดู log แล้วแยก use case ที่พบบ่อยออกมาเป็น specialized tools
ปัญหา: ระบบคุยนานๆ แล้วเริ่มตอบเพี้ยน
สาเหตุ: context window เต็มไปด้วยผลค้นหาเก่าและ skills ที่ไม่จำเป็นแล้ว
วิธีแก้: ใช้การโหลดข้อมูลแบบ on-demand และย้ายข้อมูลเก่าไปเก็บใน file store หรือ memory ภายนอก
Step 14: การต่อยอดที่น่าทำต่อ
- ทดลองทำ AI agent ที่สลับระหว่าง RAG ธรรมดากับ agentic search ตามประเภทคำถาม เพื่อคุมทั้งความเร็วและความแม่น
- สร้าง dashboard สำหรับดู log การใช้ tools ของ agent เพื่อหาโอกาสทำ tool เฉพาะทางเพิ่ม
- ออกแบบ skill library สำหรับความรู้ในองค์กร เช่น SOP, pricing rules, compliance, และขั้นตอนอนุมัติต่างๆ
Step 15: สรุป Checklist ทั้งหมด
- ☐ กำหนดให้ชัดว่า AI ต้องเข้าถึงข้อมูลจากแหล่งไหนบ้าง
- ☐ แยกประเภทคำถามที่ต้อง exact match ออกจากคำถามเชิงความหมาย
- ☐ เริ่มจาก search tools ที่จำเป็นจริง ไม่ต้องยัดทุกอย่างตั้งแต่ต้น
- ☐ เขียน tool description ให้ชัดว่าควรใช้เมื่อไรและไม่ควรใช้เมื่อไร
- ☐ ระวัง 3 failure mode หลัก: ไม่เรียก tool, เรียกผิด tool, ใส่ parameter ผิด
- ☐ ถ้าใช้ query execution tool ให้มี error handling เสมอ
- ☐ ใช้ skills สำหรับความรู้เฉพาะทาง แทนการยัดทั้งหมดลง prompt
- ☐ ถ้าใช้ shell tool ให้แยกสภาพแวดล้อมและคุมสิทธิ์ให้ดี
- ☐ พิจารณาใช้ hybrid tool stack เช่น database tool ร่วมกับ shell tool
- ☐ log พฤติกรรม agent แล้วค่อยแตก specialized tools ตามการใช้งานจริง
- ☐ วัดทั้งความแม่น, ความเร็ว, จำนวนรอบการค้น และต้นทุน token
ถ้าจะสรุปคลิปนี้ให้สั้นที่สุด ประเด็นคือ ปัญหาใหญ่ของ AI agent ไม่ใช่แค่การคิด แต่คือการหา และการหาที่ดีไม่ได้มาจาก model อย่างเดียว แต่มาจากการออกแบบ search tools, skills, และ workflow ให้ตรงกับลักษณะงานจริง
สำหรับองค์กรไทย นี่คือจุดที่ควรลงทุนเวลาให้มากกว่าการไล่เปลี่ยน model รุ่นล่าสุด เพราะถ้า AI ยังหาข้อมูลผิด ต่อให้ตอบลื่นแค่ไหนก็ยังไว้ใจไม่ได้ แต่ถ้าออกแบบ agentic search ดีพอ เราจะเริ่มเห็น AI ที่ช่วยงานได้จริงมากกว่าระบบเดโมสวยๆ
แหล่งอ้างอิงเพิ่มเติม: Elastic, LangChain, Jina AI, Anthropic: Building Effective Agents