Most RAG tutorials end exactly where production begins. You split your documents into 512-token chunks, push them through a single embedding model, and call a vector database with simple top-k retrieval. In a demo, this looks convincing. Ask the bot about your company leave policy and it returns a coherent paragraph. Everyone nods. Unfortunately, demos lie.

Production exposes every shortcut. Fixed chunks slice through legal contracts in the middle of indemnification clauses. API documentation turns into overlapping noise that drowns the signal you actually need. Latency creeps up until users abandon the query before the answer arrives. We hit this wall and had to rebuild. Our retrieval layer evolved from “semantic search and hope” into a measured, instrumented pipeline. The result was 95% recall and a 40% cut in latency. Here is what actually worked.

Match the Chunking Strategy to the Document

The 512-token default persists because it is easy, not because it is correct. Different documents carry meaning differently, and your chunking strategy should reflect that.

For legal contracts, use recursive chunking that respects structural boundaries. Legal language is nested. A clause depends on the section above it, and a fixed cut mid-sentence destroys the logic of an obligation. Recursive chunking attempts splits on natural separators first—paragraphs, then sentences—before imposing a token limit. This keeps indemnification or liability clauses intact.

For API documentation, use function-aware chunking. Developers do not search for random paragraphs; they search for endpoints, parameters, and error signatures. A chunk should contain the full function signature, its description, and the return schema as one logical unit. If you split that block in half, the retrieval system returns half the context and the generation model hallucinates the rest.

For support tickets, rely on semantic chunking that follows conversation turns. Support threads are linear and repetitive. A customer repeats the problem, an agent asks for logs, the customer attaches them. Each turn is its own semantic unit. Chunking by turns preserves who said what and when, which matters when the user asks, “What did the agent suggest on Tuesday?”

For internal wikis, try agentic chunking. Hand an LLM a section and ask it to decide where one topic ends and another begins. This costs more at ingest time, but wikis are messy. Pages contain unrelated updates from different teams, and a human-defined boundary rarely helps. Letting a model draw boundaries based on topic shifts cuts noise dramatically.

Running multiple strategies in one pipeline requires tagging documents by type at ingest. That small bit of schema discipline pays off immediately.

Combine Search Methods, Don’t Choose One

Vector search understands intent, but it routinely fails on exact matches. Ask for error code ERR_CONNECTION_REFUSED or a specific SKU, and dense embeddings often return conceptually similar but factually wrong results. BM25, the classic keyword sparse retrieval method, handles exact strings beautifully but misses semantic nuance. You need both.

Use hybrid retrieval. Run vector search and BM25 in parallel. Then combine them with Reciprocal Rank Fusion (RRF). RRF rewards documents that both methods agree are relevant, while still surfacing strong candidates from either approach. The math is simple and the result is stable: no single retrieval method dominates the final ranking.

After fusion, add a cross-encoder reranker. The first stage — vector plus sparse retrieval — is fast and broad. The cross-encoder then scores each query-document pair with full attention, meaning it actually reads the candidate against the original question. Yes, this adds latency. In our case, roughly fifty to one hundred milliseconds. But the gain in precision is sharp enough that the trade is obvious. You cannot afford to skip this if you care about recall.

Fix the Query Before You Fix the Index

Users do not write queries for your search engine. They write them for humans. “It doesn’t work” is a common support query. A vague feature description is a common internal wiki search. If you search the index with that raw input, you get garbage back.

Transform the query before it hits the retriever.

ใช้ query expansion เพื่อสร้างคำถามของผู้ใช้ในหลายรูปแบบ หากมีคนพิมพ์ว่า “server down” ระบบของคุณควรค้นหาคำว่า “service unavailable,” “502 error,” และ “connection timeout” ด้วย การครอบคลุมรูปแบบความตั้งใจ (intent variants) เหล่านี้ช่วยเพิ่มค่า recall ของเราจาก 78% เป็น 96% ซึ่งเป็นเพียงขั้นตอนเดียวและมีต้นทุนต่ำมากเมื่อเทียบกับผลลัพธ์ที่ได้

ใช้ query decomposition สำหรับคำถามที่ซับซ้อน เมื่อผู้ใช้ถามว่า “ฉันจะย้ายจาก legacy billing API ไปยังตัวใหม่ได้อย่างไร และมี breaking changes อะไรบ้างที่ส่งผลกระทบต่อบัญชีระดับองค์กร (enterprise accounts)?” ให้ย่อยคำถามออกเป็นคำถามย่อยๆ คำถามย่อยหนึ่งจะมุ่งเป้าไปที่ขั้นตอนการย้าย (migration steps) อีกคำถามหนึ่งจะมุ่งเป้าไปที่ breaking changes เฉพาะสำหรับองค์กร แต่ละคำถามจะเข้าถึงส่วนต่างๆ ของ index ที่แตกต่างกัน โมเดลภาษาในขั้นตอนถัดไป (downstream language model) จะสังเคราะห์คำตอบสุดท้ายจาก chunk ที่ถูกดึงมาได้อย่างถูกต้อง แทนที่จะเป็นการคาดเดาผ่าน context window ที่มีสัญญาณรบกวน

เลิกเดาสุ่มค่า Hyperparameters

เมื่อคุณมีทั้งกลยุทธ์การแบ่ง chunk (chunking strategies), การดึงข้อมูลแบบไฮบริด (hybrid retrieval) และการแปลงคำค้นหา (query transformation) แล้ว คุณจะพบกับปัญหาเชิงการจัดหมู่ (combinatorial problem) เนื่องจากขนาดของ chunk, การซ้อนทับ (overlap), ค่าน้ำหนักการรวม (fusion weights), ความลึกของ reranker และจำนวนการขยายคำค้นหา ล้วนมีปฏิสัมพันธ์ต่อกัน การปรับค่าใดค่าหนึ่งเพียงอย่างเดียวอาจทำให้ค่าอื่นเสียไป การทำ Grid search ในพื้นที่นี้จึงเป็นการสิ้นเปลืองและล่าช้า

ให้ใช้ Bayesian optimization แทน โดยปฏิบัติกับมันเหมือนเป็นงานปรับจูน machine learning กำหนดวัตถุประสงค์ของคุณให้ชัดเจน: เพิ่ม recall ให้สูงสุดในขณะที่รักษา latency ให้อยู่ภายใต้เพดานที่กำหนด สร้าง golden dataset ขึ้นมา ซึ่งประกอบด้วยคำถามที่เป็นตัวแทนจำนวนไม่กี่ร้อยคำถามที่คุณทราบแน่ชัดว่าควรจะดึง chunk ใดออกมา จากนั้นปล่อยให้การค้นหาแบบ Bayesian สำรวจพื้นที่การตั้งค่าอย่างมีประสิทธิภาพ มันจะสร้างโมเดลความน่าจะเป็น (probabilistic model) ของสิ่งที่ใช้งานได้จริง และทดสอบในบริเวณที่มีแนวโน้มดีที่สุดในลำดับถัดไป

ทุกการตั้งค่าที่เสนอ (candidate configuration) ต้องผ่านการทดสอบกับ golden dataset ก่อนที่จะถึงขั้นตอน staging หากขนาด chunk ใหม่ทำให้ recall ลดลง หรือ reranker ที่หนักขึ้นทำให้ latency เกินงบประมาณที่ตั้งไว้ ระบบ optimization จะตรวจพบโดยอัตโนมัติ สิ่งนี้ช่วยตัดเรื่องความเห็นส่วนตัวออกไป คุณจะไม่ต้องมาถกเถียงกันว่า 256 หรือ 512 tokens นั้น “ดีกว่ากัน” แต่จะเริ่มจากการอ่านผลลัพธ์ที่เกิดขึ้นจริงแทน

ผลลัพธ์ที่ได้

การเปลี่ยนแปลงใน pipeline ส่งผลลัพธ์ทวีคูณตามที่เราคาดหวังไว้

  • Recall@10 เพิ่มขึ้นจาก 78% เป็น 95%
  • P95 latency ลดลงจาก 850 ms เหลือ 320 ms
  • อัตราการหลอน (Hallucination rate) ลดลงจาก 12% เหลือ 3%
  • ต้นทุนต่อการค้นหา (Cost per query) ลดลง 38% ซึ่งส่วนใหญ่เป็นเพราะการดึงข้อมูลที่ดีขึ้นทำให้เราสามารถใช้โมเดลการสร้างคำตอบ (generation model) ที่เล็กลงและใช้ prompt tokens น้อยลง

การลดลงของ latency สร้างความประหลาดใจให้กับบางคนในทีม เพราะการเพิ่ม rerankers และ query expansion ฟังดูเหมือนจะทำให้ทุกอย่างช้าลง แต่เนื่องจากคุณภาพของการดึงข้อมูลดีขึ้น โมเดลการสร้างคำตอบจึงต้องการการสั่งการ (prompting) น้อยลง ลดการคาดเดา และลดการลองใหม่ (retries) การดึงข้อมูลที่ดีจะทำให้ทุกอย่างในขั้นตอนถัดไปถูกลง

ปฏิบัติต่อการดึงข้อมูลเสมือนเป็นโครงสร้างพื้นฐาน

การดึงข้อมูล (Retrieval) ไม่ใช่ notebook ที่คุณรันเพียงครั้งเดียวแล้วลืมไป แต่มันคือโครงสร้างพื้นฐาน (infrastructure) และควรได้รับการจัดการเหมือนกับโค้ด จงทำ versioning ให้กับกลยุทธ์การแบ่ง chunk ของคุณ เมื่อทีมกฎหมายออกเทมเพลตสัญญาฉบับใหม่ ให้ทดสอบ recursive splitter ของคุณก่อนที่จะนำไปใช้จริงใน production รักษา golden dataset ของคุณให้เป็นเอกสารที่มีการอัปเดตอยู่เสมอ (living documents) ไม่ใช่แค่ไฟล์ CSV นิ่งๆ จากไตรมาสที่แล้ว ทำการประเมินผลใน CI โดยอัตโนมัติ เพื่อที่ว่า pull request ที่มีการแก้ไข embedding model หรือ fusion weight จะได้รับคอมเมนต์ระบุตัวเลข recall และ latency ก่อนที่มนุษย์จะเข้ามาตรวจสอบด้วยซ้ำ

ผู้ใช้ของคุณจะไม่มีวันถามว่าคุณใช้ embedding model ตัวไหน พวกเขาไม่สนใจหลักการแบ่ง chunk (chunking heuristic) หรือสถาปัตยกรรม reranker ของคุณ สิ่งที่พวกเขาสนใจคือคำตอบถูกต้องหรือไม่ มาถึงเร็วไหม และพวกเขาสามารถเชื่อถือมันได้หรือไม่ จงสร้าง pipeline ที่สร้างความเชื่อมั่นนั้น วัดผลอย่างซื่อสัตย์ และเลิกปฏิบัติกับการดึงข้อมูลเหมือนเป็นเพียงสิ่งที่คิดขึ้นมาทีหลัง

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community