โครงสร้างพื้นฐาน RAG: การสร้างระบบ Retrieval-Augmented Generation สำหรับใช้งานจริง

อัปเดตเมื่อวันที่ 8 ธันวาคม 2025

อัปเดตธันวาคม 2025: การนำ RAG มาใช้กำลังเร่งตัวขึ้นในฐานะ use case อันดับ 1 ของ LLM ในองค์กร สถาปัตยกรรม GraphRAG และ agentic RAG ได้รับความสนใจมากขึ้นสำหรับการให้เหตุผลที่ซับซ้อน ตลาด vector database กำลังรวมตัวรอบ Pinecone, Weaviate, Milvus และ Qdrant โมเดล Voyage-3-large มีประสิทธิภาพเหนือกว่า embedding ของ OpenAI และ Cohere ถึง 9-20% การทำ semantic chunking ช่วยปรับปรุง recall ได้ถึง 9% เมื่อเทียบกับวิธีแบบ fixed-size ความท้าทายในการใช้งานจริงกำลังเปลี่ยนจาก prototype ไปสู่การขยายขนาด—embedding drift, multi-tenancy และความต้องการ latency ต่ำกว่า 50ms กำลังผลักดันการลงทุนด้านโครงสร้างพื้นฐาน

Harvey AI ให้บริการสำนักงานกฎหมาย 97% ใน Am Law 100 โดยใช้ retrieval-augmented generation เพื่อยึดการวิจัยทางกฎหมายไว้กับคดีจริงแทนที่จะเป็นการอ้างอิงที่ hallucinate ขึ้นมา¹ Anthropic, OpenAI และ Google ล้วนแนะนำ RAG เป็นเทคนิคหลักสำหรับเชื่อมต่อ large language models กับข้อมูลที่เป็นกรรมสิทธิ์ขององค์กร แต่ช่องว่างระหว่าง RAG prototype ที่ใช้งานได้กับโครงสร้างพื้นฐานระดับ production นั้นต้องใช้เวลาหลายเดือนในการพัฒนา องค์กรต่างๆ พบว่า vector databases, embedding pipelines, กลยุทธ์การ chunking และการเพิ่มประสิทธิภาพการ retrieval แต่ละส่วนนำเสนอความท้าทายด้านโครงสร้างพื้นฐานที่แตกต่างกันและทวีความซับซ้อนเมื่อขยายขนาด การสร้างระบบ RAG ที่จัดการเอกสารหลายล้านฉบับ ให้บริการผู้ใช้พร้อมกันหลายพันคน และรักษา latency ต่ำกว่าหนึ่งวินาที ต้องการการตัดสินใจด้านสถาปัตยกรรมที่ทีมส่วนใหญ่ไม่ได้คาดการณ์ไว้ในช่วง proof-of-concept

สถาปัตยกรรมหลักที่ระบบ RAG สำหรับใช้งานจริงทุกระบบต้องมี

ระบบ RAG รวมความสามารถพื้นฐานสองประการ: การดึงบริบทที่เกี่ยวข้องจากฐานความรู้ และการสร้างคำตอบที่ยึดอยู่กับบริบทนั้น สถาปัตยกรรมแบ่งออกเป็นห้าองค์ประกอบที่แตกต่างกัน แต่ละส่วนมีความต้องการด้านโครงสร้างพื้นฐานเฉพาะ

Document ingestion pipelines จัดการการไหลของข้อมูลจากเอกสารดิบไปยัง embeddings ที่ค้นหาได้ ระบบ production ประมวลผล PDF, HTML, เอกสาร Word, ข้อความ Slack และระเบียนฐานข้อมูลผ่าน parsers เฉพาะรูปแบบ Ingestion pipelines ต้องติดตามเวอร์ชันเอกสาร จัดการการอัปเดตแบบ incremental และเก็บ metadata สำหรับการกรอง การ deploy ในองค์กรทั่วไปประมวลผลเอกสาร 100,000 ถึง 10 ล้านฉบับระหว่าง initial backfill โดยมีการโหลด incremental รายวัน 1,000 ถึง 50,000 เอกสารใหม่²

ระบบ Chunking แบ่งเอกสารออกเป็นส่วนย่อยที่เหมาะสมกับการ retrieval การทำ fixed-size chunking ทำงานได้ดีกับเนื้อหาที่เป็นเนื้อเดียวกันเช่นบทความข่าว ในขณะที่ semantic chunking รักษาขอบเขตความหมายสำหรับเอกสารที่ซับซ้อน³ ระบบ production ส่วนใหญ่ใช้ recursive chunking ที่ 400-512 tokens และ overlap 10-20% ซึ่งบรรลุ recall 85-90% ในการทดสอบ benchmark⁴ การเลือกกลยุทธ์ chunking กลายเป็นสิ่งที่กึ่งถาวร—การเปลี่ยนแปลงวิธีการในภายหลังต้องทำ embedding ใหม่ทั้ง corpus

โครงสร้างพื้นฐาน Embedding แปลง text chunks เป็นการแสดงแทนแบบ dense vector องค์กรเลือกระหว่าง managed APIs (OpenAI, Cohere, Voyage AI) และโมเดลที่โฮสต์เอง การสร้าง embedding สร้างโครงสร้างต้นทุนที่แปรผันมากที่สุดในระบบ RAG โดยราคาอยู่ในช่วง $0.02 ถึง $0.18 ต่อล้าน tokens ขึ้นอยู่กับการเลือกโมเดล⁵ Batch processing ทำ embedding generation แบบขนานข้าม GPU nodes สำหรับ initial loads ในขณะที่ streaming pipelines จัดการการอัปเดตแบบ incremental

Vector databases จัดเก็บและดึง embeddings โดยใช้อัลกอริทึม approximate nearest neighbor สี่ตัวเลือกหลัก—Pinecone, Weaviate, Milvus และ Qdrant—ให้บริการ operational profiles ที่แตกต่างกัน Pinecone เสนอ managed service แบบ zero-ops, Weaviate ให้การค้นหาแบบ hybrid พร้อมความสามารถ knowledge graph, Milvus จัดการการ deploy ระดับพันล้าน และ Qdrant โดดเด่นในการกรอง metadata ที่ซับซ้อน⁶ ความต้องการ storage ขยายตามมิติของ embedding และจำนวนเอกสาร; corpus 10 ล้านเอกสารที่มี embeddings 1024 มิติต้องการ vector storage ประมาณ 40GB

การประสานงาน Retrieval และ generation เชื่อมองค์ประกอบต่างๆ เข้าด้วยกัน โดยปกติใช้ frameworks เช่น LangChain, LlamaIndex หรือการ implement เอง การประสานงานจัดการการประมวลผลคำถาม, retrieval, reranking, การสร้าง prompt และการสร้างคำตอบ ระบบ production implement caching layers, fallback strategies และ observability instrumentation ในแต่ละขั้นตอน

การเลือก Vector database กำหนดความซับซ้อนในการดำเนินงาน

ตลาด vector database รวมตัวกันรอบผู้เล่นหลักสี่รายภายในธันวาคม 2025 โดยแต่ละรายให้บริการ operational profiles และ use cases ที่แตกต่างกัน

Pinecone ครองส่วนแบ่ง managed-service โดยจัดการโครงสร้างพื้นฐานทั้งหมดหลัง API ของพวกเขา ทีมสามารถ deploy ระบบ production ได้ในเวลาไม่กี่ชั่วโมงแทนที่จะเป็นสัปดาห์ พร้อม automatic scaling, multi-region replication และ SOC 2 compliance รวมอยู่ด้วย Pinecone รองรับ metadata สูงสุด 40KB ต่อ vector ช่วยให้กรองได้อย่างละเอียดโดยไม่ต้องใช้ระบบภายนอก ข้อแลกเปลี่ยนคือต้นทุนต่อ query ที่สูงกว่าและการควบคุมการเพิ่มประสิทธิภาพโครงสร้างพื้นฐานที่ลดลง องค์กรที่มี workloads ที่คาดเดาได้มักพบว่า Pinecone คุ้มค่า; ส่วนที่มี traffic แปรผันสูงหรือต้องการ scale สุดขีดมักย้ายไปใช้ทางเลือกอื่น⁷

Weaviate เชื่อมความยืดหยุ่นของ open-source กับความสะดวกแบบ managed ผ่าน Weaviate Cloud ระบบรวมการค้นหา vector กับความสามารถ knowledge graph ช่วยให้ทำ hybrid queries ที่กรองด้วยข้อมูลเชิงโครงสร้างในขณะที่จัดอันดับด้วย semantic similarity สถาปัตยกรรมแบบ modular ของ Weaviate รองรับ embedding models หลายตัวพร้อมกัน มีประโยชน์สำหรับองค์กรที่ทดลองวิธีการต่างๆ การ deploy แบบ Docker และ Kubernetes ต้องการความเชี่ยวชาญด้านการดำเนินงานในระดับปานกลาง ทำให้ Weaviate เป็นที่นิยมในหมู่ทีมที่มีความสามารถด้านโครงสร้างพื้นฐานบ้าง⁸

Milvus (และ Zilliz Cloud ที่เป็นเวอร์ชัน managed) เน้นการ deploy ระดับพันล้านโดยมีประสิทธิภาพเป็นเป้าหมายการออกแบบหลัก Milvus นำหน้าใน benchmarks ด้าน raw latency โดยบรรลุเวลา query ต่ำกว่า 10ms บน indices ระดับพันล้าน vector ผ่าน GPU acceleration และอัลกอริทึม indexing ขั้นสูง⁹ สถาปัตยกรรมแยก compute และ storage ช่วยให้ขยายแต่ละ layer ได้อย่างอิสระ การดำเนินงาน Milvus ต้องการความเชี่ยวชาญด้าน data engineering อย่างมาก—ทีมที่ไม่มีบุคลากรด้านโครงสร้างพื้นฐานโดยเฉพาะมักประสบปัญหากับการจัดการ cluster และการปรับแต่งประสิทธิภาพ

Qdrant ได้รับการยอมรับอย่างรวดเร็วสำหรับความต้องการการกรองที่ซับซ้อน สร้างด้วย Rust, Qdrant ทำ payload filtering โดยตรงภายในอัลกอริทึมการค้นหาแทนที่จะเป็น post-processing ให้ประสิทธิภาพที่เหนือกว่าสำหรับ filtered queries¹⁰ Resource footprint ที่กะทัดรัดทำให้ Qdrant เป็นที่นิยมสำหรับการ deploy ที่คำนึงถึงต้นทุน ในขณะที่การออกแบบ API ที่ชัดเจนเร่งความเร็วในการพัฒนา การ deploy แบบ self-hosted ทำงานได้ราบรื่นบนโครงสร้างพื้นฐานที่ไม่ต้องการมาก แม้ว่าฟีเจอร์ enterprise จะต้องมี commercial licensing

เกณฑ์การเลือกควรให้ความสำคัญกับความสามารถในการดำเนินงานก่อน ทีมที่ต้องการ zero-ops เลือก Pinecone หรือ Weaviate Cloud องค์กรที่มีศักยภาพ SRE และสบายใจกับ stateful Kubernetes workloads จะได้รับการประหยัดต้นทุนและการควบคุมจาก Milvus, Qdrant หรือ Weaviate แบบ self-hosted ข้อกำหนดด้าน compliance บางครั้งตัดตัวเลือกออก—Pinecone และ Weaviate Cloud เสนอ SOC 2 และ HIPAA compliance ในขณะที่ข้อกำหนด on-premise ต้องการโซลูชันแบบ self-hosted

การเลือก Embedding model ส่งผลต่อทั้งต้นทุนและคุณภาพการ retrieval

Embedding models แปลงข้อความเป็นการแสดงแทนแบบ vector และการเลือกโมเดลส่งผลโดยตรงต่อความแม่นยำในการ retrieval ภูมิทัศน์ธันวาคม 2025 เสนอสามตัวเลือก commercial ชั้นนำบวกกับทางเลือก open-source ที่แข็งแกร่งหลายตัว

Voyage AI นำหน้าใน MTEB benchmarks โดย voyage-3-large มีประสิทธิภาพเหนือกว่า OpenAI text-embedding-3-large ถึง 9.74% และ Cohere embed-v3-english ถึง 20.71% ใน domains ที่ประเมิน¹¹ Voyage AI รองรับ context windows 32K-token (เทียบกับ 8K สำหรับ OpenAI และ 512 สำหรับ Cohere รุ่นเก่า) ช่วยให้ประมวลผลเอกสารที่ยาวกว่าโดยไม่ต้อง chunking embeddings 1024 มิติราคา $0.06 ต่อล้าน tokens—ถูกกว่า OpenAI 2.2 เท่าและถูกกว่า Cohere 1.6 เท่า—ในขณะที่ต้องการ vector storage น้อยกว่า embeddings 3072 มิติของ OpenAI ถึง 3 เท่า

OpenAI text-embedding-3-large เสนอตัวเลือกที่ผ่านการทดสอบมากที่สุดสำหรับการ deploy แบบ production โมเดลรองรับ output dimensions ที่ปรับได้ตั้งแต่ 256 ถึง 3072 ช่วยให้แลกเปลี่ยนระหว่างต้นทุนและ storage ได้ ที่ราคา $0.13 ต่อล้าน tokens, OpenAI อยู่กลางสเปกตรัมราคาในขณะที่ให้ uptime ที่เชื่อถือได้และเอกสารประกอบที่ครอบคลุม องค์กรที่ใช้ inference APIs ของ OpenAI อยู่แล้วมักมาตรฐานบน embeddings ของพวกเขาเพื่อความเรียบง่ายในการดำเนินงาน

Cohere embed-v4 บรรลุคะแนน MTEB สูงสุด (65.2) ณ เดือนพฤศจิกายน 2025 ปรับแต่งเฉพาะสำหรับการค้นหาและ retrieval แทนที่จะเป็น embedding สำหรับวัตถุประสงค์ทั่วไป¹² Cohere embeddings จับคู่ได้ดีกับ reranker ของ Cohere สำหรับ two-stage retrieval pipelines โมเดลโดดเด่นในแอปพลิเคชันหลายภาษา รองรับมากกว่า 100 ภาษาพร้อม cross-lingual retrieval ที่แข็งแกร่ง

ทางเลือก Open-source รวมถึงโมเดล BGE, E5 และ GTE ช่วยให้ทำ embedding แบบ self-hosted ในระดับใหญ่ได้ องค์กรที่ประมวลผลเอกสารหลายพันล้านฉบับมักจะ deploy โมเดลเหล่านี้บนโครงสร้างพื้นฐาน GPU ภายในเพื่อกำจัดต้นทุนต่อ token การโฮสต์เองต้องจัดการการอัปเดตโมเดล, capacity planning และ inference optimization—ข้อแลกเปลี่ยนที่สมเหตุสมผลเฉพาะในระดับที่มีนัยสำคัญ

การตัดสินใจเรื่อง embedding model ส่งผลต่อเนื่องตลอดทั้งระบบ การเปลี่ยนโมเดลในภายหลังต้องทำ embedding ใหม่ทั้ง document corpus ซึ่งเป็นกระบวนการที่ใช้เวลา, compute และอาจทำให้บริการหยุดชะงัก ระบบ production ควรประเมินโมเดลกับ benchmarks เฉพาะ domain แทนที่จะพึ่งพาคะแนน MTEB ทั่วไป โมเดลที่โดดเด่นในความรู้ทั่วไปอาจมีประสิทธิภาพต่ำกว่าในข้อความกฎหมาย, การแพทย์ หรือการเงิน

กลยุทธ์ Chunking กำหนดความแม่นยำของการ retrieval

Document chunking สร้างหน่วยพื้นฐานที่ระบบ retrieval ค้นหา การเลือกกลยุทธ์ chunking จัดอยู่ในการตัดสินใจด้านโครงสร้างพื้นฐานที่สำคัญที่สุด โดยมีความแปรผันของ recall ได้ถึง 9% ระหว่างวิธีที่ดีที่สุดและแย่ที่สุด¹³

Fixed-size chunking แบ่งเอกสารตามจำนวน token ที่กำหนดไว้ล่วงหน้าโดยไม่คำนึงถึงโครงสร้างเนื้อหา วิธีนี้ทำงานได้ดีสำหรับ corpora ที่เป็นเนื้อเดียวกัน—บทความข่าว, คำอธิบายผลิตภัณฑ์ หรือเอกสารที่เป็นมาตรฐาน การ implement ต้องการความซับซ้อนน้อยที่สุด ทำให้ fixed-size chunking เป็นจุดเริ่มต้นธรรมชาติสำหรับ prototypes ระบบ production ส่วนใหญ่ใช้ chunks 400-512 token พร้อม overlaps 50-100 token เพื่อสร้างสมดุลระหว่างความละเอียดในการ retrieval กับการรักษาบริบท

Semantic chunking แบ่งเอกสารที่ขอบเขตที่มีความหมาย—การขึ้นย่อหน้า, หัวข้อส่วน หรือการเปลี่ยนธีม—รักษาแนวคิดที่สอดคล้องกันภายในแต่ละ chunk การ implement ใช้ sentence embeddings เพื่อตรวจจับขอบเขต semantic โดยแบ่งเมื่อ similarity ระหว่างประโยคที่อยู่ติดกันลดลงต่ำกว่า threshold Semantic chunking ปรับปรุง recall ได้ถึง 9% สำหรับเนื้อหาแบบ narrative เช่นเอกสารประกอบ, FAQs และข้อมูลการสนทนา¹⁴ วิธีนี้ต้องการ compute มากขึ้นระหว่าง ingestion และการปรับแต่ง similarity thresholds อย่างระมัดระวัง

Recursive chunking ใช้กฎการแบ่งแบบลำดับชั้น โดยพยายามแบ่งใหญ่ก่อน (การแบ่งส่วน) จากนั้นแบ่งเล็กลงเรื่อยๆ (การแบ่งย่อหน้า, การแบ่งประโยค) จนกว่า chunks จะถึงขนาดเป้าหมาย RecursiveCharacterTextSplitter ของ LangChain implement pattern นี้ บรรลุประสิทธิภาพที่ดีในประเภทเอกสารที่หลากหลายโดยไม่ต้องปรับแต่งแต่ละ corpus Recursive chunking สร้างสมดุลระหว่างความเรียบง่ายในการ implement กับคุณภาพการ retrieval ทำให้เป็นคำแนะนำเริ่มต้นสำหรับระบบใหม่

Page-level chunking เกิดจาก NVIDIA benchmarks ที่แสดงความแม่นยำ 0.648 พร้อม variance ต่ำที่สุดในประเภทเอกสารต่างๆ¹⁵ สำหรับเอกสารที่มีโครงสร้างเช่นรายงานและเอกสารวิจัย การถือว่าแต่ละหน้าเป็น chunk รักษาความสัมพันธ์เชิงพื้นที่และการอ้างอิงข้าม วิธี page-level ทำงานได้ไม่ดีสำหรับเอกสารที่ไม่มีขอบเขตหน้าที่ชัดเจน (HTML, chat logs, code) แต่โดดเด่นสำหรับ corpora ที่มี PDF เป็นหลัก

Hierarchical chunking สร้าง indexes หลายระดับที่มีความละเอียดซ้อนกัน—ระดับส่วน, ส่วนย่อย, ย่อหน้า และประโยค การ retrieval ระบุส่วนที่เกี่ยวข้องก่อน จากนั้นเจาะลึกลงไปในย่อหน้าเฉพาะ

[เนื้อหาถูกตัดทอนสำหรับการแปล]