Semantic Caching และ Live Internet Search: เมื่อไร AI ควรจำคำตอบ และเมื่อไรควรค้นหาใหม่?

---

ผมขอเริ่มจากตัวอย่างคำถามในระบบแชตก่อนครับ สมมติว่าเราเห็นข้อความแบบนี้เข้ามาทั้งวัน

“เปลี่ยนรหัสผ่านยังไง” “ลืมรหัสผ่าน ต้องทำไงครับ” “รีเซ็ตพาสเวิร์ดตรงไหน”

ทั้งสามประโยค มีความหมายเดียวกัน แต่ระบบส่งไปให้ AI คิดคำตอบใหม่ทั้งสามรอบ และจ่ายค่า token ทั้งสามรอบ และถ้ามีผู้ใช้หลักพันหลักหมื่น จะทำให้เราต้องคิดวิธีแก้ปัญหาแล้วครับ

ถ้าคำถามคือ “ราคาทองวันนี้เท่าไร” หรือ “วันนี้ฝนจะตกไหม” การใช้คำตอบเก่าจะอาจกลายเป็นปัญหาแน่นอนครับ เพราะข้อมูลจะไม่ทันสมัยแล้ว

• Semantic Caching: เก็บคำตอบไว้ใช้กับคำถามใหม่ที่ความหมายใกล้กัน โดยไม่ต้องให้ AI ตอบใหม่ทุกครั้ง
• Live Internet Search: ให้ AI ค้นข้อมูลจากเว็บเมื่อคำถามต้องการข้อมูลล่าสุด

---

เปรียบเทียบเหมือน AI เราเป็นพนักงานคอลเซ็นเตอร์ที่มีสมุดโน้ต

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

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

---

Cache คืออะไร และถ้าใช้กับ AI จะคุ้มเป็นพิเศษ

Cache คือที่ผลลัพธ์ที่เคยคำทำแล้ว แล้วเราเก็บไว้ใช้ ครั้งหน้าหยิบมาใช้ได้เลยไม่ต้องทำใหม่ เป็นเทคนิคที่เว็บและแอปใช้กันมานาน

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

Cache ในโลกของ AI มีประมาณสามแบบดังนี้ครับ

1. Exact-match cache: ใช้คำถามทั้งประโยคเป็น key ต้องตรงทุกตัวถึงจะเจอ “เปลี่ยนรหัสผ่านยังไง” กับ “เปลี่ยนรหัสผ่านยังไงครับ” ถือเป็นคนละคำถาม
2. Prompt caching ของผู้ให้บริการโมเดล: ผู้ให้บริการอย่าง Anthropic และ OpenAI จะจำส่วนเนื้อหาต้นๆของ prompt ที่ส่งซ้ำ เช่น system prompt ยาวๆ หรือเอกสารชุดเดิม แล้วคิดราคาส่วนนั้นถูกลง ในหลายโมเดล ส่วนที่อ่านจาก cache คิดประมาณ 0.1 เท่าของราคา input ปกติ แต่มีเงื่อนไขว่าต้องตรงกันทุกตัวอักษรตั้งแต่ต้น และโมเดลยังต้องคิดคำตอบใหม่ทุกครั้ง ค่า output จึงจ่ายเต็มจำนวน
3. Semantic cache: เก็บคู่ “คำถาม-คำตอบ” ไว้ฝั่งแอปของเราเอง แล้วเทียบคำถามด้วยความหมาย ถ้าความหมายใกล้กันพอ ก็ส่งคำตอบเดิมกลับเลย ไม่เรียกโมเดลซ้ำ

ถ้าเทียบกับพนักงานคอลเซ็นเตอร์ Prompt caching คล้ายการเตรียมคู่มือไว้พร้อมอ่าน ส่วน Semantic caching คือมีคำตอบจดไว้อยู่แล้ว แต่ก็ยังต้องดูว่าเนื้อหาเหมาะกับคำถามหรือไม่

---

Semantic Caching ทำงานยังไง

ส่วนใหญ่มีสี่ขั้นตอน

1. แปลงคำถามเป็นตัวเลขที่แทนความหมาย (embedding): วิธีเดียวกับ vector search สามารถอ่านบทความย้อนหลังเรื่อง Hybrid Search ได้ครับ
2. หาใน cache: หาคำถามเก่าที่ความหมายใกล้ที่สุด
3. เทียบกับเกณฑ์ความใกล้ (similarity threshold): ถ้าใกล้เกินเกณฑ์ ถือว่า cache hit ส่งคำตอบเดิมกลับทันที
4. ถ้าไม่ถึงเกณฑ์ ถือว่า miss: ส่งคำถามไปให้ AI ตอบตามปกติ แล้วเก็บคู่คำถาม-คำตอบใหม่ลง cache ไว้ใช้ครั้งหน้า

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

---

คำถามที่คล้ายกันแต่ใช้ใช้ cache ไม่ได้

1. คล้ายกัน แต่เป็นคนละเรื่อง

“ยกเลิกบัตรเครดิตยังไง” “ยกเลิกบัตรเดบิตยังไง”

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

2. ตอบข้อมูลเก่า (stale answer)

ข้อมูลบางอบ่างเปลี่ยนไปแล้วเช่นโปรโมชัน แต่ cache ยังใช้คำตอบเดิม วิธีแก้คือการกำหนดอายุของคำตอบ (TTL) ให้เป็นไปตามความถี่ที่ข้อมูลต้นทางเปลี่ยน เช่น Redis ยกตัวอย่างว่า ข้อมูลแบบเรียลไทม์อย่างราคาหุ้นหรือสภาพอากาศควรหมดอายุใน 15–30 นาที ส่วน FAQ ที่ไม่ค่อยเปลี่ยนเก็บได้เป็นวันหรือสัปดาห์ และควรล้าง cache ที่เกี่ยวข้องทันทีเมื่อเอกสารต้นทางถูกแก้ไข

3. คำถามเหมือนกัน แต่เป็นข้อมูลของคนอื่น

ลูกค้าถามว่า “ยอดค้างชำระของผมเท่าไร” แล้วคำตอบดันไป save ลง cache ที่ shared กัน ลูกค้าคนถัดไปที่ถามประโยคคล้ายกันอาจได้ คำตอบของคนแรก ซึ่งหนักทีเดียว และ Redis ยกตัวอย่างในระบบหลายองค์กรว่า นโยบายของบริษัท A อาจหลุดไปตอบบริษัท B ได้ถ้าไม่แยก cache

วิธีแก้คือ แยก cache ตาม User องค์กร หรือระดับสิทธิ์ และไม่ cache คำตอบที่มาจากข้อมูลส่วนตัวเลย ถ้าไม่จำเป็น

4. ผู้ใช้ต้องการคำตอบใหม่ ไม่ใช่คำตอบเดิมที่เร็วขึ้น

เช่น “ช่วยคิดแคปชัน” หรือ “ขอไอเดียชื่อร้าน” มักต้องการความหลากหลาย แบบนี้ไม่ควร cache คำตอบ ควรให้โมเดลคิดใหม่แทนครับ

---

คำถามเดียวกัน ต้องอยู่ในบริบทเดียวกันด้วย

คำถามเดียวกัน แต่ถามคนละช่วงเวลาหรือคนละบริบท ก็อาจต้องได้คำตอบต่างกัน key ของ cache จึงควรผูกกับบริบทด้วย เช่น

• รุ่นของโมเดล
• รุ่นของ system prompt
• ภาษา
• สิทธิ์ของผู้ถาม
• รุ่นของเอกสารที่ใช้ตอบ (ถ้าเป็นระบบ RAG)

---

Live Internet Search ที่ใช้ทั่วไปคือ การค้นหาข้อมูลใน internet จริงๆ

โดยทั่วไปต้องวิเคราะห์จากสิ่งเหล่านี้ครับ

1. ตัดสินว่าคำถามนี้ต้องค้นไหม
2. แปลงคำถามเป็นคำค้นหา แล้วเรียก search
3. อ่านผลค้นหรือเนื้อหาจากหน้าเว็บที่เกี่ยวข้อง
4. เลือกท่อนที่ตอบคำถามได้
5. ตอบพร้อมแหล่งอ้างอิง

ข้อจำกัดของ Live Search

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

---

สรุป

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

Live Internet Search ทำให้ AI สามารถค้นหาเพื่อหาคำตอบเรื่องล่าสุดได้ แต่ต้องแลกมาด้วยการเสียทั้งเงินและเวลา และสิ่งสำคัญคือเนื้อหาที่มาจากเว็บนั้นเราควบคุมอะไรไม่ได้ จึงต้องมีกลไกจัดการเรื่องนี้ด้วย

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

---

ข้อมูลอ้างอิง เพิ่มเติม

• GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching: อ่านผลทดลองเรื่อง cache hit และการลดจำนวนครั้งที่เรียกโมเดล ตัวเลขเป็นผลของงานวิจัย ไม่ใช่ผลรับประกัน
• Redis LangCache concepts: อธิบายว่าการจับคู่ด้วยความหมายต่างจากการจับคู่ตรงตัวอย่างไร และทำไม threshold จึงเป็นการแลกระหว่าง hit rate กับความเสี่ยงตอบผิด
• OpenAI: Prompt caching: ดูกลไกการใช้ส่วนต้นของ prompt ซ้ำ และเงื่อนไขที่ต่างจากการเก็บคำตอบสำเร็จรูป
• Anthropic: Web search tool: ตัวอย่างเครื่องมือค้นเว็บที่มีแหล่งอ้างอิง การจำกัดโดเมน และการจำกัดจำนวนครั้งที่ค้น