CAG (Cache-Augmented Generation) คืออะไร? เปรียบเทียบการใช้งานกับ RAG จากผลทดสอบจริงสูงสุด 6.2 แสนโทเค็น

CAG (Cache-Augmented Generation) คือวิธีการที่นำเอกสารทั้งหมดใส่ไว้ในส่วนนำของพรอมต์โดยไม่ต้องผ่านการกรองด้วยการค้นหา จากนั้นจะทำการแคชส่วนนั้นไว้เพื่อนำกลับมาใช้ใหม่ในแต่ละคำถาม วิธีนี้ช่วยขจัดปัญหาการตกหล่นจากการค้นหาที่มักเกิดขึ้นใน RAG ได้ แต่ในขณะเดียวกัน ยิ่งเอกสารมีขนาดใหญ่เท่าใด การประมวลผลในแต่ละครั้งก็จะยิ่งหนักขึ้นเท่านั้น เราได้ทดสอบโดยให้ Claude บน Amazon Bedrock ตอบคำถาม 24 ข้อจากระเบียบภายในบริษัทที่สร้างขึ้นเพื่อการทดลอง โดยแบ่งขนาดเอกสารออกเป็น 5 ระดับ ตั้งแต่ประมาณ 1 หมื่นถึง 6.2 แสนโทเค็น และเปรียบเทียบกับวิธีค้นหา 3 รูปแบบ รวมถึงวิธี Self-Route (วิธีที่ใช้การค้นหาเพื่อตอบ หากข้อมูลไม่เพียงพอจึงค่อยส่งต่อไปยังเนื้อหาทั้งหมด) ผลปรากฏว่าที่ระดับ 3.6 หมื่นโทเค็น CAG มีประสิทธิภาพทั้งในด้านความแม่นยำของคำตอบ ค่าใช้จ่าย และระยะเวลารอคอยที่เทียบเท่าหรือดีกว่าการค้นหาทั่วไป และที่ระดับ 1.08 แสนโทเค็น ค่าใช้จ่ายและระยะเวลารอคอยเริ่มใกล้เคียงกัน เมื่อเกิน 3 แสนโทเค็น แม้จะยังรักษาความแม่นยำของคำตอบไว้ได้ แต่ระยะเวลาก่อนที่ตัวอักษรแรกจะปรากฏและค่าใช้จ่ายต่อคำถามกลับพุ่งสูงขึ้นเป็น 2 ถึง 7 เท่าของการค้นหาทั่วไป

สำหรับผู้รับผิดชอบด้านระบบสารสนเทศและ DX ที่กำลังพิจารณาใช้ AI แชทเพื่อตอบคำถามเกี่ยวกับระเบียบภายในบริษัทหรือ FAQ เราได้สรุปวิธีการเลือกรูปแบบโดยอิงจากตัวเลขไว้ดังนี้

CAG คือวิธีการที่ตรงกันข้ามกับ RAG ที่เน้นการค้นหาแล้วค่อยส่งข้อมูล โดย CAG จะใช้วิธีส่งข้อมูลทั้งหมดไปให้แล้วทำการแคช (Cache) ส่วนที่ส่งไปนั้นไว้

เรามาทำความเข้าใจเกี่ยวกับกลไกการทำงานและวิธีอ่านตัวเลขจากงานวิจัยต้นฉบับที่มักถูกอ้างถึงกันก่อนครับ

RAG จะแบ่งเอกสารออกเป็นส่วนย่อยๆ (Chunk) ละไม่กี่ร้อยตัวอักษร แล้วสร้างดัชนีด้วย Embedding หรือ BM25 จากนั้นในทุกครั้งที่มีการตั้งคำถาม ระบบจะส่งเฉพาะส่วนที่เกี่ยวข้องที่สุดเพียงไม่กี่รายการไปให้โมเดล แต่ CAG จะไม่สร้างดัชนี โดยจะนำเนื้อหาทั้งหมดของเอกสารวางไว้ที่ส่วนต้นของ Prompt ตามลำดับเดิมทุกครั้ง พร้อมใส่ตัวคั่นแคชไว้ที่ส่วนท้าย แล้วจึงเพิ่มคำถามต่อท้ายเข้าไป วิธีนี้เป็นรูปแบบที่เกิดขึ้นได้เพราะ Context Window มีขนาดกว้างขึ้น ซึ่ง Claude รุ่น Sonnet และ Haiku ที่ใช้ในครั้งนี้สามารถรองรับเอกสารขนาด 620,000 Token ได้โดยตรง

ในการใช้งานครั้งแรก ระบบจะอ่านเนื้อหาทั้งหมดและเขียนลงในแคช ส่วนตั้งแต่ครั้งที่สองเป็นต้นไป ระบบจะอ่านข้อมูลจากแคชนั้นและประมวลผลเฉพาะส่วนที่เป็นคำถามใหม่เท่านั้น สิ่งที่เทียบเท่ากับการบันทึก KV Cache (ผลลัพธ์ระหว่างการคำนวณ Attention) ในงานวิจัยต้นฉบับ ก็คือ Prompt Caching ในระดับ API นั่นเอง

แคชจะทำงานได้ก็ต่อเมื่อเนื้อหาตั้งแต่ต้นจนถึงตัวคั่นไม่มีส่วนใดแตกต่างกันเลยแม้แต่ไบต์เดียว โดยค่าเริ่มต้นของอายุแคชคือ 5 นาที ซึ่งจะถูกขยายออกไปทุกครั้งที่มีการอ่านข้อมูล และยังมีตัวเลือกการตั้งค่าที่ 1 ชั่วโมงอีกด้วย ราคาของ Claude Sonnet ในภูมิภาคกรุงเทพฯ ของ Bedrock ณ เวลาที่เขียนบทความนี้ (โปรดตรวจสอบราคาล่าสุดที่หน้าเว็บไซต์ของ AWS) อยู่ที่ 2.00 USD ต่อ 1 ล้าน Token สำหรับการป้อนข้อมูลปกติ, 2.50 USD สำหรับการเขียนแคช (อายุ 5 นาที) และ 0.10 USD สำหรับการอ่านแคช เนื่องจากค่าอ่านมีราคาเพียง 1 ใน 20 ของการป้อนข้อมูลปกติ หากมีการใช้เนื้อหาเดิมซ้ำ 2 ครั้ง ก็จะสามารถคุ้มทุนส่วนต่างที่เพิ่มขึ้นจากการเขียนแคชได้ การออกแบบแคชยังมีการกล่าวถึงใน บทความเรื่อง Prompt Caching ในรูปแบบ Multi-tenant อีกด้วย

ชื่อ CAG เริ่มเป็นที่รู้จักจากบทความวิจัยเรื่อง "Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks" (arXiv:2412.15605, short paper ในงาน WWW '25) โดยใช้โมเดลแบบเปิดขนาด 8B (Llama) รวบรวมเอกสารจาก SQuAD และ HotpotQA จำนวน 20,000 ถึง 85,000 โทเค็น เพื่อเปรียบเทียบกับ RAG ที่ใช้ BM25 และการค้นหาแบบเวกเตอร์

ตัวเลข "เร็วขึ้นประมาณ 40 เท่า" ที่มักถูกอ้างถึงนั้น เป็นอัตราส่วนระหว่างการส่งข้อความเต็มโดยไม่ใช้แคชซึ่งใช้เวลา 92.08 วินาที กับการใช้ CAG ซึ่งใช้เวลา 2.26 วินาที ในการตั้งค่าสูงสุดของ HotpotQA (ประมาณ 85,000 โทเค็น) ไม่ใช่การเปรียบเทียบกับ RAG ในส่วนของความแม่นยำ (BERTScore) ภายใต้การตั้งค่าเดียวกัน CAG ทำได้ 0.7407 ซึ่งต่ำกว่า RAG ที่ดึงข้อมูล 5 อันดับแรกด้วย BM25 เล็กน้อยที่ 0.7535 ส่วนในการตั้งค่าสูงสุดของ SQuAD (ประมาณ 50,000 โทเค็น) CAG ทำได้ 0.7734 ซึ่งสูงกว่าค่าสูงสุดของ RAG ที่ 0.7658

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

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

วิธีการเปรียบเทียบเอกสารและคำถามมีดังนี้ครับ

เนื้อหาหลักของเอกสารคือระเบียบภายในของบริษัทผู้ผลิตสัญชาติญี่ปุ่นในประเทศไทยที่สมมติขึ้นเพื่อใช้ในการทดสอบ โดยประกอบด้วย 7 เอกสาร 41 มาตรา ได้แก่ ข้อบังคับเกี่ยวกับการทำงาน, ระเบียบการเบิกค่าใช้จ่ายในการเดินทางฉบับเก่าและฉบับปรับปรุง, คำถามที่พบบ่อย (FAQ) เกี่ยวกับการเบิกค่าใช้จ่าย, ระเบียบความปลอดภัยด้านสารสนเทศ, ขั้นตอนการขอลาหยุด และโครงสร้างองค์กรพร้อมข้อมูลติดต่อ ทั้งนี้ได้มีการใส่จุดที่แตกต่างกันในเรื่องของจำนวนเงินหรือกำหนดเวลาในฉบับเก่าและฉบับปรับปรุง รวมถึง FAQ ที่ยังไม่ได้แก้ไขตามฉบับปรับปรุงเข้าไปโดยเจตนา

คำถามมีทั้งหมด 24 ข้อ แบ่งออกเป็น 4 ส่วน ได้แก่ คำถามที่ตอบได้โดยการอ่านจุดเดียว 8 ข้อ, คำถามที่ต้องนำเอกสาร 2 ฉบับมาประกอบกัน 6 ข้อ, คำถามที่ฉบับเก่าหรือ FAQ ขัดแย้งกับฉบับปรับปรุง 5 ข้อ และคำถามที่ไม่มีคำตอบในเอกสาร (เช่น ระยะเวลาการลาเพื่อเลี้ยงดูบุตร, อายุเกษียณ เป็นต้น) อีก 5 ข้อ ตัวอย่างของคำถามที่ต้องนำข้อมูลมาประกอบกัน เช่น "การเบิกค่าใช้จ่ายจำนวน 60,000 บาท ใครเป็นผู้อนุมัติ และบุคคลนั้นชื่ออะไร" โดยกฎเกณฑ์เรื่องผู้อนุมัติจะระบุไว้ในคู่มือขั้นตอนการปฏิบัติงาน ส่วนชื่อจะระบุไว้ในผังองค์กรเท่านั้น

เพื่อขยายขนาดข้อมูล เราได้เพิ่มเนื้อหาของกฎหมายในสาขาที่ไม่เกี่ยวข้องกับระเบียบภายใน เช่น กฎหมายสิทธิบัตร, กฎหมายลิขสิทธิ์, กฎหมายควบคุมอาคาร ฯลฯ จาก API ของ e-Gov กฎหมายค้นหา โดยนำเอกสารระเบียบภายในทั้ง 7 ฉบับไปแทรกไว้ระหว่างตัวบทกฎหมายเหล่านั้นในระยะห่างที่เท่ากัน ปริมาณของเอกสารมี 5 ระดับ ตั้งแต่ประมาณ 11,000 โทเค็นเฉพาะระเบียบภายใน ไปจนถึง 36,000, 108,000, 310,000 และ 620,000 โทเค็น โดยคำตอบจะอยู่ในส่วนของระเบียบภายในเสมอ

การให้คะแนนดำเนินการโดยส่งคำตอบที่ถูกต้องและเนื้อหาทั้งหมดของระเบียบภายในให้ Claude (Sonnet) อีกตัวหนึ่งเป็นผู้ประเมิน โดยให้ 1 คะแนนสำหรับคำตอบที่ถูกต้อง, 0.5 คะแนนสำหรับคำตอบที่ขาดประเด็นสำคัญบางส่วน และ 0 คะแนนสำหรับคำตอบที่ผิด นอกจากนี้ยังมีการบันทึกข้อมูลการแนะนำค่าเก่าและการสร้างข้อมูลเท็จ (Hallucination) ในกรณีที่ไม่มีกฎระเบียบในเอกสารแยกไว้ต่างหาก และได้ตรวจสอบเหตุผลของการตัดสินในกรณีที่ไม่ใช่คำตอบที่ถูกต้องทีละรายการ

สำหรับการตอบกลับ เราได้เรียกใช้งาน Claude Sonnet และ Claude Haiku ผ่านโปรไฟล์การอนุมาน (inference profile) แบบ global จาก Amazon Bedrock ในภูมิภาคกรุงเทพฯ (ap-southeast-7) โดยในส่วนของกระบวนการคิด (thinking) นั้น สำหรับ Sonnet จะเปิดใช้งานเฉพาะระหว่างการใช้เครื่องมือ (ซึ่งในครั้งนี้ไม่ได้มีการใช้เครื่องมือ) ส่วน Haiku ได้ปิดการใช้งานไว้ ข้อมูลอ้างอิงถูกส่งไปในรูปแบบ search_result ของ Claude เพื่อให้ระบุแหล่งที่มา โดยคำสั่ง (instruction) ที่ใช้เหมือนกันในทุกวิธี (หากข้อมูลขัดแย้งกันให้ยึดข้อมูลล่าสุด หากไม่มีในเอกสารให้ระบุว่าไม่มีข้อมูล)

เราได้เปรียบเทียบทั้งหมด 6 วิธี ดังนี้: วิธี CAG จะส่งเนื้อหาทั้งหมดไปและใส่ตัวคั่นแคชไว้ที่ส่วนท้าย ส่วนวิธีค้นหาทั้ง 3 รูปแบบนั้น Sonnet จะเป็นผู้ตอบทั้งหมด วิธีแรกคือการค้นหาด้วยเวกเตอร์เพียงอย่างเดียว (ใช้โมเดล embedding ของ Cohere, เลือก 6 อันดับแรก) วิธีที่สองคือการผสมอันดับระหว่างการค้นหาด้วยเวกเตอร์และ BM25 หรือ ไฮบริดเสิร์ช (เลือก 6 อันดับแรก) วิธีที่สามคือ Contextual Retrieval ที่ Anthropic เผยแพร่ (ใช้วิธีเพิ่มบริบทตำแหน่งของเอกสารลงในแต่ละส่วนด้วย Claude Haiku ประมาณ 50–100 ตัวอักษรก่อนทำดัชนี) โดยนำมาใช้ร่วมกับโมเดลจัดลำดับ (reranking model) ของ Cohere เพื่อจัดลำดับใหม่จาก 30 อันดับแรก แล้วจึงส่ง 6 หรือ 12 อันดับแรกไปให้โมเดล จากการวัดผลของ Anthropic พบว่าการรวมวิธีนี้ช่วยลดอัตราการพลาดข้อมูลใน 20 อันดับแรกจาก 5.7% เหลือ 1.9% ส่วนวิธีสุดท้ายคือ Self-Route ซึ่งจะให้โมเดลตอบด้วยวิธีค้นหาแบบที่สาม และจะเปลี่ยนไปใช้ CAG เฉพาะเมื่อโมเดลตัดสินว่าข้อมูลอ้างอิงไม่เพียงพอเท่านั้น โดยการค้นหาและ Self-Route ได้ถูกวัดผลใน 2 ระดับ คือ 3.6 หมื่นโทเค็น และ 6.2 แสนโทเค็น

เวลาในการรอ (latency) วัดตั้งแต่ส่งคำถามจากเครื่องปลายทางจนถึงตัวอักษรแรกของคำตอบปรากฏขึ้น โดยวิธีค้นหาจะรวมเวลาไป-กลับของการทำ embedding (สิงคโปร์) และการจัดลำดับใหม่ (โตเกียว) สำหรับ CAG ในคำถามที่สองเป็นต้นไปจะเป็นรอบที่อ่านจากแคช นอกจากนี้ เรายังได้วัดผลโดยการเพิ่มบรรทัดที่แตกต่างกันในทุกครั้งที่ส่วนต้นของข้อความเพื่อไม่ให้แคชทำงาน โดยวัดผล 2–3 ครั้งในแต่ละขนาด ส่วนค่าใช้จ่ายเป็นการคำนวณจากจำนวนโทเค็นที่ได้รับกลับมาคูณกับราคาต่อหน่วยของ API

CAG ทำคะแนนได้ 23.5-24 คะแนน จาก 24 ข้อ ในทุกระดับขนาดทั้ง 5 ระดับ ส่วนการค้นหาทำคะแนนได้ 21.0-23.5 คะแนน

ความแตกต่างส่วนใหญ่มาจากคำถามที่ครอบคลุมหลายเอกสาร และการปนเปื้อนของค่าเก่า

3.6 หมื่นโทเค็น CAG มีค่าเท่ากับหรือดีกว่าการค้นหาในทุกด้าน ทั้งอัตราคำตอบที่ถูกต้อง เวลารอ และค่าใช้จ่าย แม้ที่ 62 หมื่นโทเค็น อัตราคำตอบที่ถูกต้องจะสูงที่สุด แต่ใช้เวลาค่ามัธยฐานถึง 15 วินาทีกว่าจะได้อักขระตัวแรก

ค่าใช้จ่ายของ CAG คือค่าเฉลี่ยของรอบที่อ่านแคช (ค่าใช้จ่ายของการเขียนครั้งแรกจะกล่าวถึงในภายหลัง)

ความแตกต่างระหว่างการค้นหา 3 รูปแบบปรากฏชัดส่วนใหญ่ในคำถามที่ข้ามเอกสาร เมื่อเพิ่มคำอธิบายบริบทและจัดเรียงใหม่ซ้อนกัน จำนวนคำถามที่ส่วนที่จำเป็นทั้งหมดอยู่ใน 6 อันดับแรกเพิ่มขึ้นจาก 16 ข้อ (เฉพาะการค้นหาแบบเวกเตอร์) เป็น 18 ข้อ จากทั้งหมด 19 ข้อที่มีคำตอบ และอัตราคำตอบที่ถูกต้องก็เพิ่มขึ้นด้วย แม้จะเพิ่มกฎหมายเข้าไปจนเป็น 62 หมื่นโทเค็น อัตราคำตอบที่ถูกต้องของการค้นหาก็แทบไม่เปลี่ยนแปลง

สิ่งที่การค้นหาทุกรูปแบบพลาดไปคือคำถามที่ว่า "การเบิกค่าใช้จ่ายจำนวน 60,000 บาท ใครเป็นผู้อนุมัติ และบุคคลนั้นชื่ออะไร" ในคู่มือขั้นตอนการปฏิบัติงานระบุว่าผู้อนุมัติคือผู้อำนวยการฝ่ายบริหาร ซึ่งการค้นหาทุกรูปแบบสามารถตอบส่วนนี้ได้อย่างถูกต้อง แต่ชื่อของบุคคลนั้นปรากฏอยู่ในแผนผังองค์กรเท่านั้น และในส่วนนั้นไม่มีคำว่า "ค่าใช้จ่าย" หรือ "การอนุมัติ" ปรากฏอยู่เลย เนื่องจากคำในคำถามไม่ตรงกับคำในเนื้อหา แม้จะเพิ่มคำอธิบายบริบทหรือจัดลำดับใหม่หลายครั้งก็ไม่สามารถติดอันดับ 1 ใน 12 ได้ คำตอบที่ได้จากการค้นหาจึงกลายเป็น "ไม่สามารถตอบชื่อบุคคลที่เป็นผู้อนุมัติได้ เนื่องจากไม่มีระบุไว้ในเอกสารที่ได้รับ" ทั้งที่ในตัวเอกสารมีคำตอบอยู่ แต่ระบบกลับตอบว่าไม่มี

ในขณะที่ CAG แม้จะมีขนาด 620,000 โทเค็น ก็ยังสามารถตอบได้ว่า "ตามข้อมูลองค์กรและข้อมูลติดต่อ (ณ วันที่ 1 เมษายน 2026) ผู้อำนวยการฝ่ายบริหารคือคุณซาโต" เนื่องจากระบบมองเห็นเนื้อหาทั้งหมด จึงสามารถใช้คำตอบแรก (ผู้อำนวยการฝ่ายบริหาร) เป็นเบาะแสในการค้นหาคำตอบที่สอง (ชื่อ) ได้ งานวิจัยเรื่อง Self-Route (Li และคณะ, EMNLP 2024) ก็ระบุว่าหนึ่งในเหตุผลหลักที่ RAG ล้มเหลวคือคำถามแบบหลายขั้นตอนที่คำตอบก่อนหน้าจะเป็นตัวกำหนดสิ่งที่ต้องค้นหาในขั้นตอนถัดไป

สำหรับคำถามเกี่ยวกับการรวมค่าเบี้ยเลี้ยงและค่าที่พัก (พนักงานทั่วไปเดินทางไปเชียงใหม่ 3 วัน 2 คืน) ทั้งการค้นหาแบบเวกเตอร์ (Vector Search) และการค้นหาแบบไฮบริด (Hybrid Search) ต่างก็พลาดส่วนเนื้อหาฉบับปรับปรุงไป คำตอบจากการค้นหาแบบเวกเตอร์คำนวณได้ 4,200 บาทโดยใช้ค่าเบี้ยเลี้ยงและค่าที่พักจากฉบับเก่า ส่วนการค้นหาแบบไฮบริดตอบว่า "ข้อ 5 (ค่าเบี้ยเลี้ยง) ฉบับปรับปรุงปี 2026 ไม่ได้รวมอยู่ในเอกสาร" ทำให้ไม่สามารถคำนวณยอดรวมหลังการปรับปรุงได้ ซึ่งคำตอบที่ถูกต้องตามฉบับปรับปรุงคือ 5,900 บาท หากการค้นหาพลาดส่วนเนื้อหาที่จำเป็นไป โมเดลก็จะสร้างคำตอบโดยใช้ข้อมูลเก่าที่มีอยู่ในมือแทน

สำหรับคำถาม 5 ข้อที่ตั้งใจใส่ข้อมูลที่ขัดแย้งกันไว้ ผลปรากฏว่าการค้นหา (Search) สามารถตอบได้อย่างถูกต้องเกือบทั้งหมด เนื่องจากหัวข้อของฉบับเก่าและฉบับปรับปรุงใหม่นั้นเหมือนกันและมีเนื้อหาที่ใกล้เคียงกันมาก ระบบจึงดึงข้อมูลทั้งสองฉบับออกมาพร้อมกัน ทำให้โมเดลสามารถเลือกข้อมูลจากฉบับใหม่ได้

ปัญหาที่เกิดขึ้นในการค้นหาคือคำถามที่ไม่เกี่ยวข้องกับข้อมูลที่ขัดแย้งกัน ตัวอย่างเช่น เมื่อถามว่า "ค่าใช้จ่ายที่สำรองจ่ายไปจะได้รับโอนคืนเมื่อไหร่" คำตอบที่ได้จากการใช้บริบทประกอบกับการจัดลำดับ (Top 6) นั้น หลังจากที่ตอบวันโอนเงินที่ถูกต้อง (ปิดยอดวันที่ 20 ของทุกเดือน โอนเงินวันที่ 25 ของเดือนนั้น) แล้ว ระบบยังได้เพิ่มข้อความว่า "ทั้งนี้ สำหรับการเบิกค่าใช้จ่ายในการเดินทาง ให้ยื่นคำร้องผ่านระบบเบิกจ่ายภายใน 14 วันหลังจากเดินทางกลับ" ซึ่งเลข 14 วันนั้นเป็นค่าเก่าที่ยังค้างอยู่ใน FAQ ในขณะที่ฉบับปรับปรุงใหม่กำหนดไว้ว่าภายใน 10 วันทำการ เนื่องจากระบบดึงมาเฉพาะส่วนของ FAQ และโมเดลไม่เห็นข้อมูลฉบับปรับปรุงใหม่ จึงทำให้ระบบแนะนำค่าเก่าว่าเป็นกฎระเบียบปัจจุบัน

การปนเปื้อนของค่าเก่าในลักษณะนี้ พบได้ 0-3 รายการต่อเงื่อนไขในการค้นหาแบบปกติ ในขณะที่ CAG ทั้งในรุ่น Sonnet และ Haiku พบ 0 รายการ แม้ว่าการลบ FAQ ฉบับเก่าทิ้งหรือแก้ไขทุกครั้งที่มีการปรับปรุงจะเป็นวิธีแก้ปัญหาที่ต้นเหตุ แต่ CAG ซึ่งสามารถมองเห็นเนื้อหาเอกสารได้ทั้งหมดนั้น เป็นวิธีที่ได้รับผลกระทบจากการตกหล่นในการแก้ไขข้อมูลน้อยกว่า

ความแม่นยำไม่ลดลงแม้จะใช้โทเค็นถึง 6.2 แสนโทเค็น แต่เวลาในการประมวลผลจนถึงตัวอักษรแรกและค่าใช้จ่ายต่อคำถามเพิ่มขึ้นตามปริมาณข้อมูล

การแคช (Cache) ช่วยลดค่าใช้จ่ายเป็นหลัก แต่ในระดับขนาดใหญ่จะไม่ช่วยลดเวลาในการรอคอยได้มากนัก

สำหรับ Sonnet ค่ามัธยฐานของเวลาในการอ่านแคชอยู่ที่น้อยกว่า 2.5 วินาทีจนถึงระดับ 10.8 หมื่นโทเค็น แต่เพิ่มขึ้นเป็น 5.2 วินาทีที่ 31 หมื่นโทเค็น และ 15.0 วินาทีที่ 62 หมื่นโทเค็น

กรณีมีแคชเป็นการทดสอบ 23 ครั้งตั้งแต่คำถามที่ 2 เป็นต้นไป ส่วนกรณีไม่มีแคชเป็นการทดสอบในช่วง 2–3 ครั้ง (สำหรับ Sonnet ที่ 1.1 หมื่นโทเค็น ได้ตัดค่าผิดปกติที่ 52.9 วินาทีออกไป 1 ครั้ง)

สำหรับ Sonnet ที่ 31 หมื่นโทเค็น เวลาที่ไม่มีแคชซึ่งอยู่ที่ 13.5–16.2 วินาทีได้ลดลงมาเหลือค่ามัธยฐานที่ 5.2 วินาที แต่ที่ 62 หมื่นโทเค็น เวลาที่เคยอยู่ที่ 19.3–22.5 วินาทีลดลงเหลือเพียง 15.0 วินาทีเท่านั้น คาดว่าเป็นเพราะถึงแม้จะลดขั้นตอนการอ่านข้อมูลไปได้ แต่กระบวนการสร้างคำตอบโดยอ้างอิงจากเนื้อหาเบื้องต้นที่ยาวเหยียดยังคงอยู่ (ยังไม่ได้รับการยืนยัน)

Haiku ใช้เวลาเป็นค่ามัธยฐานถึง 3–4 วินาทีแม้ในขนาดข้อมูลที่น้อย และไม่มีขนาดใดที่ทำงานได้เร็วกว่า Sonnet ในการทดสอบที่ 1.1 หมื่นโทเค็น แม้ความยาวของคำตอบจะไม่ต่างจาก Sonnet มากนัก แต่จำนวนโทเค็นของผลลัพธ์กลับมากกว่าประมาณ 2 เท่า ซึ่งยังไม่ได้ตรวจสอบหาสาเหตุ

ค่าใช้จ่ายในการอ่านแคช (Cache) สำหรับ Sonnet อยู่ที่ 0.007 USD ต่อคำถามเมื่อใช้ 3.6 หมื่นโทเค็น และ 0.066 USD เมื่อใช้ 6.2 แสนโทเค็น

หน่วยเป็น USD (ค่าเฉลี่ยต่อครั้งรวมเอาต์พุต) การค้นหา (พร้อมบริบท + การเรียงลำดับ, 6 รายการแรก) จะอยู่ที่ประมาณ 0.012 USD ต่อคำถาม ไม่ว่าจะเป็น 3.6 หมื่นหรือ 6.2 แสนโทเค็น ซึ่งไม่ขึ้นอยู่กับปริมาณเอกสาร สำหรับ CAG ของ Sonnet นั้นที่ 1.08 แสนโทเค็นจะมีราคาใกล้เคียงกันที่ 0.014 USD แต่จะเพิ่มขึ้นเป็นประมาณ 3 เท่าที่ 3.1 แสนโทเค็น และประมาณ 5.5 เท่าที่ 6.2 แสนโทเค็น หากมีการสอบถาม 1,000 ครั้งต่อวัน CAG ที่ 6.2 แสนโทเค็นจะมีค่าใช้จ่าย 66 USD ต่อวัน และการค้นหาจะมีค่าใช้จ่าย 12 USD

เนื่องจากอายุของแคชคือ 5 นาที หากไม่มีการสอบถามเกิน 5 นาที คำถามถัดไปจะถือเป็นการเขียนใหม่ ที่ 6.2 แสนโทเค็น การเขียนหนึ่งครั้งจะมีค่าใช้จ่าย 1.55 USD ดังนั้นในช่วงเวลาที่มีการสอบถามไม่บ่อยนัก ค่าใช้จ่ายต่อคำถามจะสูงขึ้น หากขยายอายุแคชเป็น 1 ชั่วโมง ราคาต่อหน่วยของการเขียนจะเพิ่มขึ้นจาก 2.50 USD เป็น 4.00 USD ต่อ 1 ล้านโทเค็น (สำหรับ Sonnet)

Haiku มีราคาถูกกว่าอย่างเห็นได้ชัด โดยต่ำกว่า 0.001 USD ต่อคำถามหากใช้ไม่เกิน 1 แสนโทเค็น และมีอัตราความถูกต้องอยู่ที่ 23-24 คะแนน ซึ่งไม่แตกต่างจาก Sonnet มากนัก อย่างไรก็ตาม ในกรณีที่อินพุตเกิน 1 แสนโทเค็น ราคาต่อหน่วยของอินพุต แคช และเอาต์พุตทั้งหมดจะเพิ่มขึ้นเป็น 5 เท่า ซึ่งตัวเลขตั้งแต่ 1.08 แสนโทเค็นขึ้นไปในตารางได้คำนวณโดยใช้ราคาต่อหน่วยนี้แล้ว

เมื่อส่งคำนำเดิมซ้ำอีกครั้งด้วยข้อความเต็มขนาด 108,000 โทเค็น ระบบจะอ่านข้อมูลจากแคช 107,510 โทเค็น โดยใช้เวลา 1.20 วินาทีจนถึงตัวอักษรแรก และมีค่าใช้จ่าย 0.013 USD จากนั้นเมื่อลองส่งข้อมูลเดิมโดยเพิ่มเพียงเครื่องหมายจุลภาค (、) เข้าไปในเอกสารส่วนต้น ระบบจะไม่มีการอ่านจากแคชเลย และต้องเขียนข้อมูลใหม่ทั้งหมด 107,511 โทเค็น ซึ่งใช้เวลา 3.33 วินาที และมีค่าใช้จ่าย 0.270 USD เนื่องจากแคชจะถูกใช้งานก็ต่อเมื่อคำนำทั้งหมดจนถึงจุดแบ่ง (delimiter) ตรงกันเท่านั้น หากมีจุดแบ่งเพียงจุดเดียวที่ส่วนท้าย ไม่ว่าจะแก้ไขส่วนใดของเอกสาร ก็จำเป็นต้องเขียนข้อมูลใหม่ทั้งหมด

ในการใช้งานจริง มีข้อกำหนดเบื้องต้นว่าต้องจัดลำดับเอกสารให้คงที่ และไม่ควรใส่ข้อมูลที่เปลี่ยนแปลงทุกครั้ง เช่น วันที่อัปเดตหรือชื่อผู้ใช้งาน ไว้ก่อนจุดแบ่ง หากวางระเบียบที่เปลี่ยนแปลงยากไว้ด้านหน้า และวาง FAQ หรือประกาศที่มีการอัปเดตบ่อยไว้ด้านหลัง โดยมีจุดแบ่งคั่นกลาง (สามารถใส่จุดแบ่งได้สูงสุด 4 จุดต่อการเรียกใช้งาน 1 ครั้ง) จะช่วยให้เมื่อมีการแก้ไขเอกสาร คุณจะเสียค่าใช้จ่ายในการสร้างใหม่เฉพาะส่วนที่อยู่ด้านหลังเท่านั้น

นอกจากนี้ รูปแบบ search_result ที่ให้ระบุแหล่งที่มาจะเพิ่มจำนวนโทเค็นประมาณ 110 โทเค็นต่อบล็อก ซึ่งในกรณีของระเบียบภายในที่มี 41 ส่วน จำนวน 5,721 โทเค็นจะเพิ่มขึ้นเป็น 10,386 โทเค็น ดังนั้นในการใช้งาน CAG การไม่แบ่งส่วนย่อยจนเกินไปจะช่วยประหยัดค่าใช้จ่ายได้มากกว่า

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

Self-Route เป็นวิธีการที่ให้การค้นหาตอบคำถามก่อน และจะส่งต่อไปยัง CAG แบบเต็มรูปแบบก็ต่อเมื่อโมเดลตัดสินว่าเอกสารไม่เพียงพอเท่านั้น ในงานวิจัย (Li และคณะ) รายงานว่าสามารถตอบคำถามได้ 57-82% ด้วยการค้นหาเพียงอย่างเดียว ซึ่งช่วยลดค่าใช้จ่ายลงได้ 39-65% เมื่อเทียบกับการส่งข้อมูลทั้งหมดไปประมวลผล โดยที่ยังคงความแม่นยำไว้ได้เกือบเท่าเดิม

ในครั้งนี้ มีคำถาม 5 จาก 24 ข้อที่ถูกส่งไปประมวลผลแบบเต็มรูปแบบ ซึ่งเป็นคำถาม 5 ข้อที่ไม่มีคำตอบในเอกสาร สำหรับข้อมูล 620,000 โทเค็นนั้น เนื่องจากต้องอ่านเนื้อหาทั้งหมดเพื่อยืนยันว่าไม่มีคำตอบ คำถามทั้ง 5 ข้อนี้จึงใช้เวลา 9.2-16.0 วินาทีกว่าจะเริ่มแสดงตัวอักษรแรก และค่าใช้จ่ายเฉลี่ยต่อข้อก็สูงกว่าการค้นหาเพียงอย่างเดียวประมาณ 2 เท่า (0.026 USD) ในทางกลับกัน คำถามของผู้มีอำนาจอนุมัติที่ไม่สามารถระบุชื่อได้นั้น จบลงที่ขั้นตอนการค้นหาโดยตอบว่า "ไม่มีระบุไว้ในเอกสาร" และไม่ได้ถูกส่งไปประมวลผลแบบเต็มรูปแบบ หากเอกสารที่ได้รับสามารถเขียนคำตอบได้ในระดับหนึ่ง โมเดลจะไม่ตัดสินว่าเอกสารนั้นไม่เพียงพอ

ยิ่งสัดส่วนของคำถามที่ไม่อยู่ในระเบียบข้อบังคับมีสูงเท่าใด ข้อดีของ Self-Route ก็จะยิ่งลดน้อยลงเท่านั้น เราจำเป็นต้องเสริมด้วยกลไกอื่นแทนที่จะปล่อยให้เป็นหน้าที่ของโมเดลเพียงอย่างเดียว เช่น การกำหนดกฎให้ส่งคำถามที่อาจต้องใช้เอกสารอื่นเพิ่มเติม เช่น "ผู้มีอำนาจอนุมัติ" หรือ "ผู้รับผิดชอบ" ไปประมวลผลแบบเต็มรูปแบบโดยอัตโนมัติ

จากตัวเลขในครั้งนี้ หากเอกสารมีขนาดไม่เกิน 100,000 โทเค็น วิธีที่แนะนำคือการใช้ CAG แต่หากเกินกว่านั้น ให้ใช้วิธีการค้นหาแบบไฮบริดที่มีบริบทประกอบร่วมกับการจัดลำดับใหม่

ในเอกสารชุดนี้ 100,000 โทเค็นจะเทียบเท่ากับตัวอักษรประมาณ 100,000 ตัว

จากการวัดผลในครั้งนี้ สามารถสรุปเกณฑ์ได้ว่า หากเอกสารมีปริมาณไม่เกิน 100,000 token ควรเลือกใช้ CAG แต่หากเกิน 300,000 token ขึ้นไป ควรเลือกใช้การค้นหา (Search)

เกณฑ์แบ่งดังกล่าวเป็นค่าที่ได้จากการใช้ Sonnet บน Bedrock ทั้งนี้ Anthropic ได้ระบุไว้ในบทความเรื่อง Contextual Retrieval ว่าหากเอกสารมีปริมาณไม่ถึง 200,000 token สามารถใส่เนื้อหาทั้งหมดลงใน Prompt ได้ อย่างไรก็ตาม สำหรับการใช้งานที่ต้องการให้เวลาจนถึงอักษรตัวแรก (Time to First Token) อยู่ภายใน 3 วินาที (ค่ามัธยฐาน) ผลการวัดในครั้งนี้แสดงให้เห็นว่าขีดจำกัดจะอยู่ที่ประมาณ 100,000 token

ความถี่ในการอัปเดตและขอบเขตของข้อมูลที่อนุญาตให้เข้าถึงได้ก็เป็นปัจจัยในการตัดสินใจเช่นกัน เอกสารที่มีการอัปเดตทุกวันจำเป็นต้องเขียนข้อมูลใหม่ทุกครั้ง และหากแต่ละแผนกมีสิทธิ์เข้าถึงเอกสารที่แตกต่างกัน แคช (Cache) ก็จะต้องถูกแยกตามชุดข้อมูล ซึ่งทั้งสองกรณีนี้เป็นเงื่อนไขที่การค้นหา (Search) สามารถจัดการได้ง่ายกว่า สำหรับวิธีการตั้งค่าการค้นหา สามารถดูได้ที่ บทความเรื่อง Hybrid Search

คำถามมีทั้งหมด 24 ข้อ โดยการพลาดเพียง 1 ข้อจะส่งผลให้คะแนนต่างกัน 0.5 ถึง 1 คะแนน จึงไม่สามารถสรุปความได้เปรียบเสียเปรียบระหว่างเงื่อนไขที่มีส่วนต่างคะแนนน้อยได้ กฎหมายที่เพิ่มเข้ามาเป็นเอกสารที่มีเนื้อหาต่างจากระเบียบภายในบริษัท ในสภาพแวดล้อมที่มีเอกสารเนื้อหาคล้ายคลึงกันจำนวนมาก เช่น ระเบียบของแต่ละแผนกที่มีความแตกต่างกันเพียงเล็กน้อย คาดว่าจะทำให้เกิดการพลาดในการค้นหามากขึ้น และอาจส่งผลให้อัตราความถูกต้องของ CAG ลดลงด้วย

ในส่วนของ CAG เองก็พบข้อผิดพลาดเช่นกัน สำหรับ Haiku ในรอบที่ใช้ 3.6 หมื่นโทเค็น ได้มีการเพิ่มข้อมูลการแนะนำการโอนสายที่ไม่มีอยู่ในเอกสารและเลขข้อที่ไม่มีอยู่จริงเข้ามา ส่วนในรอบที่ใช้ 6.2 แสนโทเค็น ได้ให้คำตอบที่ประโยคแรกกับบทสรุปของเนื้อหาไม่สอดคล้องกัน 1 รายการ

การวัดผลนี้ทำกับ Claude รุ่น Sonnet และ Haiku โดยใช้เฉพาะคำถามภาษาญี่ปุ่นเท่านั้น เวลาที่ระบุเป็นค่าที่วัดจากการเรียกใช้งาน Bedrock ผ่านรีเจียนกรุงเทพฯ ทีละข้อจากอุปกรณ์ของผู้ทดสอบ ไม่ได้วัดเวลารอในกรณีที่มีการสอบถามเข้ามาจำนวนมากพร้อมกัน และไม่ได้เปรียบเทียบกับ GraphRAG หรือ Agentic RAG ที่โมเดลทำการค้นหาซ้ำๆ แต่อย่างใด

ตอบ 3 คำถามที่พบบ่อยเกี่ยวกับการเลือกใช้ระหว่าง CAG และ RAG

หากเอกสารมีขนาดไม่เกิน 100,000 โทเค็น (ประมาณ 100,000 ตัวอักษรสำหรับเอกสารชุดนี้) และมีการอัปเดตไม่บ่อยนัก การเริ่มต้นด้วย CAG จะเป็นวิธีที่ง่ายที่สุด โดยไม่จำเป็นต้องมีดัชนีหรือกลไกการค้นหา และจากการวัดผลในครั้งนี้ อัตราความถูกต้องยังเทียบเท่าหรือสูงกว่าการค้นหาแบบปกติอีกด้วย แต่หากปริมาณข้อมูลเกินกว่านั้น หรือจำเป็นต้องแสดงเอกสารที่แตกต่างกันไปตามผู้ใช้งานแต่ละราย ให้เลือกใช้การค้นหาแบบไฮบริดพร้อมบริบทและการจัดลำดับใหม่ (Reranking) แทน

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

หากมีการแบ่งส่วนเพียงจุดเดียวที่ส่วนท้าย ไม่ว่าจะแก้ไขส่วนใดของเอกสาร การตั้งคำถามเพียง 1 ครั้งก็จะส่งผลให้ต้องเขียนข้อมูลใหม่ทั้งหมด สำหรับเอกสารขนาด 108,000 โทเค็น การเพิ่มเครื่องหมายวรรคตอนเพียงจุดเดียวทำให้ค่าใช้จ่ายต่อการถาม 1 ครั้งเพิ่มขึ้นจาก 0.013 USD เป็น 0.270 USD การรวบรวมเอกสารที่มีการอัปเดตบ่อยไว้ที่ส่วนท้ายและวางจุดแบ่งไว้ก่อนหน้า รวมถึงกำหนดเวลาที่แน่นอนในการอัปเดตข้อมูล จะช่วยลดปริมาณและจำนวนครั้งในการสร้างข้อมูลใหม่ได้

CAG เป็นวิธีการที่แคชเนื้อหาทั้งหมดของเอกสารไว้เพื่อนำกลับมาใช้ใหม่ ทำให้ไม่เกิดปัญหาการค้นหาตกหล่น ในการทดสอบด้วยคำถาม 24 ข้อเกี่ยวกับระเบียบภายในบริษัทสมมติ CAG ได้คะแนน 23.5–24 คะแนนในทุกขนาดของข้อมูล ซึ่งเทียบเท่าหรือดีกว่าการค้นหาแบบปกติ (21.0–23.5 คะแนน) โดยส่วนที่เกิดความแตกต่างคือคำถามที่ต้องอ้างอิงเอกสารอื่นประกอบ และคำถามที่มีค่าจาก FAQ เก่าปะปนอยู่

อย่างไรก็ตาม หากข้อมูลเกิน 300,000 โทเค็น แม้จะใช้แคชแล้ว แต่ค่ามัธยฐานจนถึงตัวอักษรแรกยังคงอยู่ที่ 5–15 วินาที และมีค่าใช้จ่ายสูงกว่าการค้นหาปกติประมาณ 3–5.5 เท่า แนวทางที่แนะนำคือใช้ CAG สำหรับข้อมูลไม่เกิน 100,000 โทเค็น และหากเกินกว่านั้นให้ใช้การค้นหาแบบไฮบริดที่มีบริบทประกอบร่วมกับการจัดลำดับใหม่ (Reranking) ไม่ว่าจะใช้วิธีใด จำเป็นต้องกำหนดลำดับของเอกสาร วิธีการอัปเดต และการตรวจสอบแหล่งที่มาให้ชัดเจนตั้งแต่ขั้นตอนการออกแบบ

บริษัทของเราให้การสนับสนุนตั้งแต่การวัดปริมาณและความถี่ในการอัปเดตเอกสาร ไปจนถึงการคัดเลือกวิธีการและสร้าง AI แชทเพื่อตอบคำถามเกี่ยวกับระเบียบภายในและ FAQ สำหรับสาขาในประเทศไทย ดูรายละเอียดเพิ่มเติมได้ที่ ข้อมูลบริการ AI/DX

เอกสารอ้างอิง (เข้าถึงเมื่อวันที่ 8 พฤศจิกายน 2026)

• Brian J. Chan และคณะ "Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks" https://arxiv.org/abs/2412.15605
• Anthropic "Introducing Contextual Retrieval" https://www.anthropic.com/engineering/contextual-retrieval
• Zhuowan Li และคณะ "Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach" https://arxiv.org/abs/2407.16833
• e-Gov ค้นหากฎหมาย https://laws.e-gov.go.jp/