Semantic Caching และ Live Internet Search: เครื่องมือให้ AI cache คำตอบเพื่อประหยัดเงิน และดึงข้อมูลจากเว็บเมื่อจำเป็น

สมมติว่าถ้า log ของระบบ chat เรามีคำถามแบบนี้เต็มไปหมด

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

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

ในขณะเดียวกันก็มีคำถามอีกแบบที่ AI ตอบจากความจำไม่ได้ เช่น “ราคาทองวันนี้เท่าไร” "วันนี้ฝนจะตกไหม" หรือ “โปรโมชันเดือนนี้มีอะไรบ้าง” ตอบพวกนี้เปลี่ยนทุกวัน และข้อมูลที่โมเดลถูกเทรนมามีวันตัดรอบ (knowledge cutoff) นั่นหมายความว่าข้อมูลใหม่หลังจากวันนั้น model ก็จะไม่รู้เรื่องแล้ว

บทความนี้จะเล่าสองเทคนิคที่ตอบโจทย์สองฝั่งนี้ครับ Semantic Caching ให้ AI จำคำตอบของคำถามที่ความหมายซ้ำๆ จะได้ไม่ต้องจ่ายซ้ำ และ Live Internet Search ให้ AI ไปดึงข้อมูลสดๆ จากเว็บเมื่อคำถามต้องการ หรือใช้ search engine และการตัดสินยังไงว่าคำถามไหนควร “จำ” คำถามไหนควร “ค้นใหม่”

สรุปก่อนอ่าน

• Semantic Caching คือเก็บคำตอบเดิมไว้ เมื่อมีคำถามใหม่ที่ความหมายใกล้เคียงพอ ก็ส่งคำตอบเดิมกลับไปเลย ไม่ต้องเรียก AI หลายๆรอบ
• ถ้าเราสามารถตอบคำถามจาก cache ได้ประมาณ 90% ขึ้นไป อาจจะประหยัดค่า token ได้ 10 เท่า งานวิจัยบางส่วนที่ผมเจอทำได้ประมาณ 60–70% ซึ่งอาจจะถูกลงประมาณ 3 เท่า
• ความเสี่ยงของ cache มีสามเรื่อง คือ ตอบผิดเพราะคิดว่าเป็นคำถามเดียวกัน ตอบข้อมูลเก่า และตอบข้อมูลของคนอื่น
• Live Internet Search เป็นเครื่องมือที่ ทำให้ AI สามารถค้นหาและตอบเรื่องล่าสุดได้ พร้อมกับแหล่งอ้างอิง แต่มีค่าใช้จ่ายต่อครั้งที่สูงกว่าเพราะ มีค่าใช้จ่ายจาก API Search และคำตอบที่ได้ช้ากว่าเพราะต้องค้นหา และสรุปคำตอบก่อน รวมถึงหน้าเว็บที่ค้นหาอาจมีคำสั่งที่อันตรายได้
• Caching และ Live Internet Search สองเทคนิคนี้ใช้คู่กันได้ ถ้ามีขั้นตอนการคัดแยกคำถามก่อนว่า แบบไหน ใช้ใช้ cache ได้ แบบไหนต้องค้นใหม่ และแบบไหนห้ามใช้คำตอบร่วมกับคนอื่น

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

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

ตัวอย่าง

ลูกค้าถาม	พนักงานที่ดีจะทำ	ในระบบ AI
“บัตรหายต้องทำยังไง”	เปิดสมุดโน้ต ตอบได้เลย	Semantic cache
“อัตราแลกเปลี่ยนวันนี้เท่าไร”	สมุดโน้ตมีเขียนของวันนี้ไหม ถ้าไม่ เปิดดูหน้าจอข้อมูลล่าสุด แล้ว note ไว้อีกที	Live Internet Search + cache (per day)
“ยอดค้างชำระของผมเท่าไร”	ไม่มีทางตอบจากโน้ตของลูกค้าคนอื่น ต้องเปิดดูบัญชีของคนนี้	ดึงจากระบบจริงตามสิทธิ์ ไม่ใช้ cache ร่วมกับ user คนอื่น
“บัตรเครดิตหายต้องทำยังไง” กับ “บัตรเดบิตหาย...”	ฟังให้ดีก่อน เพราะขั้นตอนอาจต่างกัน	ระวังการจับคู่ผิด (false hit)

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

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

กับ AI จะคุ้มเป็นพิเศษ เพราะการให้โมเดลคิดคำตอบแล้ว ทั้งเสียเงินตามจำนวน 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: เก็บคู่ “คำถาม-คำตอบ” ไว้ฝั่งแอปของเราเอง แล้วเทียบคำถามด้วยความหมาย ถ้าความหมายใกล้กันพอ ก็ส่งคำตอบเดิมกลับเลย ไม่เรียกโมเดลซ้ำ

แบบ	เทียบด้วยอะไร	ประหยัดอะไร	ข้อจำกัด
Exact-match cache	ข้อความตรงตัว	ข้ามการเรียก AI ไปเลย	คนพิมพ์ต่างกันนิดเดียวก็ไม่ cache
Prompt caching	ส่วนต้นของ prompt ตรงตัว	ค่า input ส่วนที่ซ้ำ และเวลาประมวลผล input	ยังจ่ายค่า output และยังรอโมเดลตอบ
Semantic cache	ความหมายใกล้กัน	ข้ามการเรียก AI ไปเลย	อาจจะตอบผิด context และต้องดูเรื่องข้อมูลเก่า และสิทธิ์ของข้อมูล

ส่วนใหญ่ที่ระบุ “ถูกลง 10 เท่า” ส่วนหนึ่งมาจากราคา 0.1 เท่าของ prompt caching นี่แหล่ะครับ แต่จะเป็นส่วนลดเฉพาะ input ที่ซ้ำ ไม่ใช่ 10เท่า ทั้งบิล

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

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

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

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

แล้วประหยัดได้ประมาณเท่าไหร่

เพื่อให้เห็นภาพ ลองคิดเลขง่ายๆ ดูครับ ถ้าเราไม่นับค่า embedding และค่าที่ระบบ cache ต้นทุนค่า AI จะเหลือแค่คำถามที่ miss

สัดส่วนคำถามที่ hit	ยังต้องเรียก AI	ต้นทุนถูกลงประมาณ
30%	70%	1.4 เท่า
50%	50%	2 เท่า
69%	31%	3.2 เท่า
90%	10%	10 เท่า

การจะได้ 10 เท่า ต้อง hit ประมาณ 90% ซึ่งหมายความว่าคำถามเกือบทั้งหมดต้องซ้ำความหมายกับที่เคยถาม เช่น บอตตอบ FAQ

งานวิจัย GPT Semantic Cache (Regmi และ Pun, 2024) ทดลองกับคำถามที่ซ้ำบ่อยแบบงานบริการลูกค้า ได้ cache hit ประมาณ 61.6–68.8% ลดการเรียก API ได้สูงสุด 68.8% และคำตอบที่ได้จาก cache ถูกต้องเกิน 97% ตามการวัดของผู้วิจัย ถ้าแปลงเป็นต้นทุนตามตารางข้างบน คือถูกลงประมาณ 3 เท่า (ดูเพิ่มเติมจาก link อ้างอิงท้ายบทความ)

แค่ 3 เท่าก็ถือว่าคุ้มมากแล้วนะครับ

ความเสี่ยงของ Semantic Cache

1. ตอบผิดเพราะคิดว่าเป็นคำถามเดียวกัน (false hit)

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

เอกสารของ Redis เขียนไว้ตรงๆ ว่า semantic caching ไม่ได้รับประกันว่า hit แล้วจะถูกเสมอ และในงาน vCache (Schroeder และคณะ, 2025) ก็ชี้ว่าการใช้เกณฑ์เดียว ในการเทียบความใกล้เคียงของความหมายกับทุกคำถาม ก็ไม่ได้รับประกันความถูกต้อง

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

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

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

3. ตอบข้อมูลของคนอื่น

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

นอกจากนี้ยังมีงานวิจัย (Song และคณะ, 2024) ที่แสดงว่า การที่ดูเวลาที่ระบบตอบเร็วผิดปกติ เพราะว่า hit cache ฉะนั้นอาจใดาได้ว่าคนอื่นเคยถามอะไร ดังนั้น cache ที่ใช้รวมกันหลาย user จึงเป็นเรื่องความเป็นส่วนตัวด้วย ไม่ใช่แค่เรื่องความถูกต้องเพียงอย่างเดียว

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

4. คำถามที่ผู้ใช้อยากได้คำตอบใหม่

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

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

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

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

ถ้าข้อใดข้อหนึ่งเปลี่ยน แสดงว่าคำตอบเก่าอาจไม่เป็นข้อมูลล่าสุดแล้ว

Live Internet Search: การ Search หาข้อมูลจริง

ถึงจะมีระบบ RAG ที่ค้นเอกสารในองค์กรได้ (ผมได้เขียนบทความอธิบายเรื่อง RAG ไว้ สามารถเข้าไปย้อนดีได้ครับ) ก็ยังมีคำถามที่ต้องใช้ข้อมูลล่าสุด เช่น ข่าว ราคา กฎระเบียบที่เพิ่งออก หรือ version ของซอฟต์แวร์ ซึ่งไม่มีข้อมูลทั้งในตัวโมเดลและเอกสารภายในเอง

Live Internet Search ที่ใช้ในขั้นตอนโดยทั่วไปคือ

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

ส่วนใหญ่มีสองวิธีคือ 1. ใช้เครื่องมือค้นเว็บที่ผู้ให้บริการโมเดลมีให้ในตัว และ 2. คือบริการ search API แยกต่างหาก แล้วเรามาประกอบขั้นตอนเอง

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

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

ซึ่งต้องลดความเสี่ยงโดยอาจจะ จำกัดโดเมนสำหรับเรื่องที่ต้องการความแม่นยำ เช่น ให้ค้นเฉพาะเว็บหน่วยงานที่เป็นทางการ whitelist ที่น่าเชื่อถือ และแสดงแหล่งอ้างอิงให้ตรวจสอบได้ จำกัดจำนวนครั้งที่ค้นหาต่อคำถาม และไม่ให้ AI ที่อ่านเว็บ มีสิทธิ์ทำเรื่องที่สำคัญพร้อมกัน เพราะอาจะ run หรือ ทำสิ่งที่ไม่ปลอดภัยได้

ใช้ condition หรือกลไลเพื่อคัดกรองก่อนว่าจะ cache หรือ ค้นหาใหม่

ถ้ามี (router) แยกคำถาม คั่นก่อน

ประเภทคำถาม	ตัวอย่าง	แนวทางที่เหมาะสม	อายุของคำตอบ (TTL)
ข้อมูลที่ไม่ค่อยเปลี่ยน	“RAG คืออะไร”, “เปลี่ยนรหัสผ่านยังไง”	Semantic cache	ยาว เป็นวันหรือสัปดาห์ และ clear เมื่อเอกสารเปลี่ยนแปลง
ข้อมูลที่เปลี่ยนตามเวลา	“ราคาทองวันนี้”, “ข่าวล่าสุดเรื่อง...”	Live search แล้ว cache ผลค้นหาแบบสั้นๆ	เป็นนาที พร้อมบอกเวลาของข้อมูล
ข้อมูลส่วนตัวหรือตามสิทธิ์ของ user	“ยอดค้างชำระของผม”	ดึงจากระบบจริงตามสิทธิ์	ไม่ใช้ cache ร่วมกัน หรือแยก cache per user
งานออกแบบ หรือแนวความคิดสร้างสรรค์	“ช่วยคิดแคปชัน”	ให้ AI ตอบใหม่เสมอ	ไม่ cache

สรุป: cache ในข้อมูลที่เปลี่ยนไม่บ่อยหรือแทบไม่เปลี่ยนเลย ใช้การค้นหากับสิ่งที่มีการ update อยู่เสมอ และต้องระวังการ cache ที่ share ระหว่าง user

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

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

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

ข้อมูลอ้างอิง

• GPTCache (Zilliz) บน GitHub
• Regmi และ Pun: GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching
• Schroeder และคณะ: vCache: Verified Semantic Prompt Caching
• Song และคณะ: The Early Bird Catches the Leak: Unveiling Timing Side Channels in LLM Serving Systems
• Redis: LangCache concepts
• Redis: 10 techniques for semantic cache optimization
• Anthropic: Prompt caching
• OpenAI: Prompt caching
• Anthropic: Web search tool
• Microsoft: Bing Search API retirement