10 ข้อผิดพลาดในการสร้าง RAG และวิธีแก้ไข — ป้องกันปัญหาที่อาจเกิดขึ้นในการใช้งานจริง

RAG（Retrieval-Augmented Generation）とは、外部ドキュメントをリアルタイムで検索し、その内容をLLMの回答生成に組み込む技術アーキテクチャです。

社内ナレッジ検索や顧客対応チャットボットへの応用が急速に広がる一方、「プロトタイプは動いたのに本番に出せない」という声は現場で繰り返されています。LangChainやLlamaIndexといったフレームワークの成熟で実装の敷居は下がりましたが、設計・実装・運用の各フェーズで踏んでしまう落とし穴の数も比例して増えています。

この記事が対象とするのは、以下のような読者です。

• RAGのPoC（概念実証）は完了したが、本番化で壁にぶつかっているエンジニア
• 検索精度やハルシネーションの問題を抱え、改善の糸口を探っているMLエンジニア・開発リード
• これからRAGを設計・導入しようとしており、事前に失敗パターンを把握しておきたいアーキテクト

記事を読み終えると、現場で繰り返される10の失敗パターンとその具体的な回避策が体系的に把握でき、設計レビューや実装チェックリストとして即日活用できる知識が得られます。

RAG เป็นวิธีการที่มีประสิทธิภาพในการ "ทำให้ LLM มีความรู้ล่าสุดและมีความเชี่ยวชาญเฉพาะด้าน" ซึ่งในปัจจุบันมีบริษัทจำนวนมากกำลังเร่งนำไปใช้งานจริง อย่างไรก็ตาม ยังคงมีกรณีที่ระบบซึ่งเคยทำงานได้ดีในขั้นตอน PoC กลับเกิดปัญหาความแม่นยำของคำตอบลดลงอย่างไม่คาดคิดเมื่อนำไปใช้ในสภาพแวดล้อมจริงอยู่บ่อยครั้ง

เบื้องหลังของปัญหานี้คือไปป์ไลน์การประมวลผลที่ซับซ้อนเฉพาะตัวของ RAG ตั้งแต่การเตรียมเอกสารล่วงหน้า (Document Preprocessing), การแบ่งส่วนข้อมูล (Chunking), การสร้าง Embedding, การค้นหาแบบเวกเตอร์ (Vector Search), การประกอบ Prompt ไปจนถึงการอนุมานของ LLM (LLM Inference) ซึ่งล้วนเป็นจุดที่มีโอกาสเกิดความผิดพลาดได้หลากหลาย

ในหัวข้อ H3 ถัดจากนี้ เราจะเจาะลึกถึงปัจจัยเชิงโครงสร้างที่ทำให้เกิดความล้มเหลวได้ง่าย รวมถึงกับดักในแต่ละขั้นตอนของการออกแบบ การนำไปใช้งาน (Implementation) และการดำเนินงาน (Operation) ตามลำดับ

RAG（Retrieval-Augmented Generation）は、LLMの「知識の鮮度問題」と「ハルシネーション問題」を同時に緩和するアーキテクチャとして広く採用されています。GPTやClaudeといったモデルは学習データのカットオフ以降の情報を持たないため、社内ドキュメントや最新の製品仕様を参照させたい場面では単体では機能しにくい状況があります。RAGはその欠点を補う有力な手段です。

しかし、構造的な難しさも伴います。RAGのパイプラインは主に次の要素で構成されます。

• ドキュメントの前処理：PDF・HTML・Markdownなど多様なフォーマットの正規化
• チャンク分割：テキストを検索可能な単位に分割するサイズ・境界の設計
• 埋め込み（Embedding）：テキストをベクトルに変換するモデルの選定
• ベクトルストア：インデックス構築と近似最近傍探索の設定
• 検索（Retrieval）：クエリに対して関連チャンクを取得するロジック
• 生成（Generation）：取得結果をプロンプトに組み込んでLLMが回答を生成

これらの要素は一つでも設計を誤ると、最終的な回答品質が連鎖的に低下するという脆弱性を持ちます。たとえばチャンク境界が文脈の途中で切れていると、埋め込みベクトルが意味を正しく表現できず、関連度の高いドキュメントが検索上位に来ないケースが報告されています。

さらに、Agentic RAGやマルチモーダル対応RAGなど応用形態が増えるにつれ、パイプラインの複雑度は高まる傾向があります。「動いているように見えて精度が低い」状態が長期間放置されやすい点が、RAG構築の本質的な難しさといえます。

ความล้มเหลวของ RAG ไม่ได้เกิดจาก "จุดใดจุดหนึ่งเพียงจุดเดียว" แต่เป็นปัญหาที่ซับซ้อนเพราะเกิดขึ้น ครอบคลุมทั้งสามเฟーズ ได้แก่ การออกแบบ การนำไปใช้งาน และการดำเนินงาน เนื่องจากธรรมชาติของปัญหาในแต่ละเฟーズมีความแตกต่างกัน จึงมักทำให้การระบุสาเหตุล่าช้าอยู่บ่อยครั้ง

ใน เฟーズการออกแบบ (Design Phase) การกำหนดความต้องการที่ไม่รัดกุมจะส่งผลกระทบต่อเนื่องไปยังขั้นตอนถัดไป:

• การตัดสินใจเลือกกลยุทธ์การแบ่งส่วนข้อมูล (Chunking strategy) โดยไม่ได้ศึกษาแนวโน้มคำถามของผู้ใช้
• การเริ่มงานโดยไม่ได้จัดระเบียบภาษาหรือรูปแบบของเอกสารเป้าหมาย (เช่น PDF, HTML, Wiki ภายในองค์กร)
• การเลื่อนการกำหนดตัวชี้วัดการประเมินผลไปไว้ "คิดทีหลัง"

สิ่งเหล่านี้มักนำไปสู่ปัญหาคลาสสิกที่ว่า "ระบบทำงานได้ตั้งแต่แรก แต่ความแม่นยำต่ำ" นอกจากนี้ ไม่ควรมองข้ามว่าการแพร่หลายของเฟรมเวิร์กการประเมินผลอย่าง RAGAS หรือ TruLens ทำให้การกำหนดตัวชี้วัดตั้งแต่ขั้นตอนการออกแบบกลายเป็นมาตรฐานของอุตสาหกรรมไปแล้ว

ใน เฟーズการนำไปใช้งาน (Implementation Phase) มักเกิดความไม่เหมาะสมในการเลือกใช้เทคโนโลยี:

• การเลือกใช้โมเดล Embedding และ LLM ที่ไม่รองรับภาษาเดียวกัน (เช่น การใช้โมเดลภาษาอังกฤษประมวลผลเอกสารภาษาญี่ปุ่น)
• การพึ่งพาเพียงการค้นหาด้วยเวกเตอร์ (Vector search) จนทำให้พลาดคำถามที่จำเป็นต้องใช้การค้นหาด้วยคำสำคัญ (Keyword match)
• การละเลยกระบวนการจัดลำดับใหม่ (Re-ranking) ทำให้ Chunk ที่มีความเกี่ยวข้องต่ำถูกส่งไปยัง LLM โดยตรง

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

ใน เฟーズการดำเนินงาน (Operation Phase) การจัดการความสดใหม่ของเอกสารคือจุดบอดที่ใหญ่ที่สุด:

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

การสร้างนิสัยในการ ทบทวนแบบข้ามเฟーズ (Cross-phase review) คือก้าวแรกที่สำคัญในการป้องกันความล้มเหลวของการสร้าง RAG

ความล้มเหลวของ RAG มักเกิดขึ้นอย่างเข้มข้นในระหว่างกระบวนการยกระดับจากขั้น "พอใช้งานได้" ไปสู่ "คุณภาพระดับใช้งานจริง (Production Quality)" เราได้รวบรวมปัญหาที่มักเกิดขึ้นบ่อยใน 3 ระยะ ได้แก่ การออกแบบ การนำไปใช้งาน และการปฏิบัติการ ออกเป็น 10 รูปแบบ เพื่อให้คุณเข้าใจภาพรวมและนำไปเปรียบเทียบกับสถานะปัจจุบันของโปรเจกต์ของคุณ สำหรับการวิเคราะห์สาเหตุโดยละเอียดและแนวทางแก้ไข จะอธิบายตามลำดับในส่วนถัดไป

ระยะการออกแบบ (รูปแบบที่ 1-3)

• รูปแบบที่ 1: ความผิดพลาดในการออกแบบขนาดของ Chunk
• รูปแบบที่ 2: การขาดการออกแบบ Metadata
• รูปแบบที่ 3: การเลือก Embedding Model ที่ไม่เหมาะสมกับ Use Case

ระยะการนำไปใช้งาน (รูปแบบที่ 4-7)

• รูปแบบที่ 4: ความไม่สอดคล้องกันของภาษาระหว่าง Embedding Model และ LLM
• รูปแบบที่ 5: การเตรียมข้อมูล (Pre-processing) ไม่เพียงพอสำหรับเอกสารที่ไม่มีโครงสร้าง เช่น PDF
• รูปแบบที่ 6: การใส่ Context ลงใน Prompt มากเกินไป
• รูปแบบที่ 7: การส่งข้อมูล k อันดับแรกไปให้ LLM โดยตรงโดยไม่มีการทำ Re-ranking (Reranker)

ระยะการปฏิบัติการ (รูปแบบที่ 8-10)

• รูปแบบที่ 8: การจัดการช่วงเวลาในการสร้าง Index ใหม่ไม่เหมาะสม
• รูปแบบที่ 9: การนำไปใช้งานจริงโดยไม่ได้กำหนดดัชนีชี้วัด (Evaluation Metrics)
• รูปแบบที่ 10: ความแม่นยำในการค้นหาลดลงเนื่องจากการปะปนกันของเอกสารหลายภาษา

ความผิดพลาดในการตัดสินใจระหว่างขั้นตอนการออกแบบจะส่งผลกระทบเชิงลบต่อกระบวนการทำงานในขั้นตอนถัดไปทั้งหมด เนื่องจากหากพบปัญหาหลังจากเริ่มการติดตั้งใช้งาน (Implementation) แล้ว ต้นทุนในการแก้ไขจะสูงมาก ดังนั้นจึงเป็นเรื่องสำคัญที่จะต้องตรวจสอบ 3 รูปแบบต่อไปนี้ก่อนเริ่มดำเนินการ

รูปแบบที่ 1: การออกแบบขนาดของ Chunk ไม่เหมาะสม

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

• ในกรณีการใช้งานทั่วไป มักจะพิจารณาเริ่มต้นที่ประมาณ 256 ถึง 512 โทเค็น
• ในกรณีที่มีโครงสร้างซับซ้อน เช่น เอกสารทางกฎหมายหรือคู่มือทางเทคนิค มีรายงานว่าการทำ Variable-length Chunking ตามหน่วยของส่วนเนื้อหา (Section) ให้ผลลัพธ์ที่ดี
• LlamaIndex และ LangChain มีฟังก์ชัน Semantic Chunking มาให้เป็นมาตรฐาน ซึ่งสามารถเลือกใช้การแบ่งข้อมูลโดยคำนึงถึงความหมายของประโยคได้

รูปแบบที่ 2: ไม่ได้คาดการณ์ความหลากหลายของ User Query

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

• ในกรณีที่มีทั้งผู้ใช้ภายในองค์กรที่สอบถามด้วยศัพท์เฉพาะทาง และผู้ใช้ทั่วไปที่ใช้ภาษาเรียบง่ายปะปนกัน โมเดล Embedding เพียงโมเดลเดียวอาจไม่สามารถรองรับได้ทั้งหมด
• ควรพิจารณาวิธีการประมวลผลล่วงหน้า (Pre-processing) เช่น Query Expansion หรือ HyDE (Hypothetical Document Embeddings) ไว้ตั้งแต่ขั้นตอนการออกแบบ

รูปแบบที่ 3: ละเลยการประเมินคุณภาพของแหล่งข้อมูล (Data Source)

แม้จะนำเอกสารที่มีคุณภาพต่ำไปทำ Vectorization ก็ไม่สามารถเพิ่มความแม่นยำในการค้นหาได้ หลักการ "ใส่ขยะเข้าไป ก็จะได้ขยะออกมา (Garbage In, Garbage Out)" ยังคงใช้ได้กับ RAG เช่นกัน

• เอกสารที่ซ้ำซ้อน ข้อมูลที่ล้าสมัย และรูปแบบที่ไม่เป็นมาตรฐาน มักเป็นสาเหตุหลักที่ทำให้ดัชนี (Index) เกิดความเสียหาย
• หากไม่มีการกำหนด Pipeline สำหรับการทำ Data Cleansing ไว้ตั้งแต่ขั้นตอนการออกแบบ ปัญหาด้านคุณภาพมักจะปรากฏให้เห็นชัดเจนในช่วงขั้นตอนการดำเนินงาน (Operation)
• ในกรณีที่ใช้แหล่งข้อมูลหลายประเภทผสมกัน เช่น PDF หรือ Wiki ภายในองค์กร สิ่งสำคัญคือต้องกำหนดการออกแบบ Metadata (เช่น วันที่สร้าง, ประเภทของแหล่งข้อมูล, คะแนนความน่าเชื่อถือ ฯลฯ) ควบคู่กันไปด้วย

แม้ในช่วงขั้นตอนการนำไปใช้งานจริงหลังจากที่การออกแบบเสร็จสมบูรณ์แล้ว ก็ยังมีกับดักที่มองข้ามได้ง่ายปรากฏขึ้นอย่างต่อเนื่อง รูปแบบที่ 4 ถึง 7 เป็นตัวอย่างทั่วไปที่ทำให้เกิดสภาวะ "ดูเหมือนจะทำงานได้ แต่ความแม่นยำไม่ถึงเกณฑ์"

รูปแบบที่ 4: ความไม่สอดคล้องกันของภาษาระหว่าง Embedding Model และ LLM

หากนำเอกสารภาษาญี่ปุ่นไปทำ Vectorization ด้วย Embedding Model ที่เน้นภาษาอังกฤษโดยเฉพาะ พื้นที่ความหมายของคำศัพท์จะคลาดเคลื่อน และส่งผลให้คะแนนความคล้ายคลึง (Similarity score) ขาดความน่าเชื่อถือ เนื่องจากปัจจุบันมีตัวเลือกโมเดลที่รองรับหลายภาษามากขึ้น เช่น multilingual-e5-large หรือตระกูล text-embedding-3 ดังนั้นจึงเป็นเรื่องสำคัญที่ต้องตรวจสอบความสอดคล้องของภาษาระหว่าง LLM และ Embedding Model ที่จะใช้งานล่วงหน้า

รูปแบบที่ 5: การตั้งค่า Chunk Overlap ที่ผิดพลาด

หากตั้งค่า Overlap เป็นศูนย์ บริบทจะขาดช่วง แต่หากตั้งค่ามากเกินไป ข้อมูลที่ซ้ำซ้อนจะกลายเป็นสัญญาณรบกวน (Noise) เนื่องจากค่าที่เหมาะสมจะแตกต่างกันไปตามโครงสร้างของเอกสาร จึงจำเป็นต้องทำการประเมินและปรับจูนโดยวัดผลจริงจากหลายรูปแบบ

รูปแบบที่ 6: การค้นหาแบบ Flat Search โดยไม่ใช้ Metadata

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

รูปแบบที่ 7: การส่งผลลัพธ์ k อันดับแรกไปให้ LLM โดยไม่มีการ Re-ranking

ผลลัพธ์อันดับต้นๆ จากการค้นหาด้วยเวกเตอร์นั้นแม้จะ "ใกล้เคียงในเชิงความหมาย" แต่ก็ไม่ได้หมายความว่าจะเป็น "ข้อมูลที่มีประโยชน์ที่สุดในการตอบคำถาม" เสมอไป มีรายงานว่าการเพิ่มขั้นตอนการทำ Re-ranking ด้วยโมเดลประเภท Cross-Encoder จะช่วยยกระดับคุณภาพของบริบทที่ส่งให้ LLM ได้

โปรดตรวจสอบรายการต่อไปนี้เพื่อเป็น Checklist ในการนำไปใช้งาน:

• ตรวจสอบแล้วหรือไม่ว่าภาษาที่ Embedding Model รองรับ สอดคล้องกับภาษาของเอกสาร
• ได้ประเมินอัตราส่วน Overlap ด้วยหลายรูปแบบแล้วหรือไม่
• การออกแบบการกรองด้วย Metadata เสร็จสมบูรณ์แล้วหรือไม่
• ได้ตัดสินใจแล้วหรือไม่ว่าจะเพิ่มขั้นตอนการทำ Re-ranking หรือไม่

หากนำระบบไปใช้งานจริงโดยมองข้ามสิ่งเหล่านี้ มักจะส่งผลให้ต้นทุนในการแก้ไขในช่วงระยะเวลาการดำเนินงาน (Operation phase) บานปลายขึ้นอย่างมาก

問題が本番稼働後に発覚した場合、その修正コストは設計フェーズの数倍に膨らむ傾向がある。「動いているから大丈夫」という慢心が、運用フェーズ特有の失敗を招きやすい。

パターン8：ドキュメント更新時のインデックス再構築を怠る

社内規程や製品仕様書は頻繁に改訂される。古いベクトルインデックスが残ったまま運用を続けると、廃止済みのルールや旧バージョンの仕様を根拠にした回答が生成されるリスクがある。差分更新パイプラインを自動化し、更新トリガーを明示的に設計することが重要だ。

パターン9：評価・モニタリングの仕組みを持たない

• Faithfulness（忠実性）・Answer Relevancy（回答の関連性）などの定量指標を設定しないまま運用するケースが多い
• フィードバックループがないため、精度劣化への気づきが遅れる
• RAGASやTruLensといった評価フレームワークを本番前に組み込むことが、標準的なプラクティスになりつつある

RAGASのスコアを定期バッチで計測し、閾値を下回った際にアラートを出す仕組みが有効だ。

パターン10：LLMのモデルバージョン更新による挙動変化を考慮しない

APIプロバイダーがモデルをアップデートすると、同じプロンプトでも出力の傾向が変わることがある。プロンプトテンプレートや後処理ロジックが旧バージョンに依存している場合、突然の品質低下につながる。

• モデルバージョンを明示的に固定し、更新時は回帰テストを実施する
• プロンプトをコードと同様にGitで管理する
• 本番環境と検証環境を分離し、段階的なロールアウトを行う

継続的な計測と更新管理を設計段階から組み込むことが、長期的な品質維持の鍵となる。

เมื่อคุณเข้าใจภาพรวมจากรายการตรวจสอบ (Checklist) แล้ว ขั้นตอนถัดไปคือการทำความเข้าใจอย่างเป็นระบบว่า "ทำไมความล้มเหลวนั้นถึงเกิดขึ้น" และ "จะหลีกเลี่ยงได้อย่างไร"

ในแต่ละรูปแบบจะมีสาเหตุเฉพาะตัวในแต่ละเฟสของการออกแบบ (Design) การนำไปใช้งาน (Implementation) และการดำเนินงาน (Operation) หากแก้ไขเพียงอาการที่ปรากฏอยู่ภายนอก แต่ยังคงทิ้งสาเหตุที่แท้จริงไว้ ปัญหานั้นก็มีแนวโน้มที่จะเกิดขึ้นซ้ำอีก โปรดอ่านโดยเปรียบเทียบกับระบบของคุณว่าอยู่ในเฟสใด

การตั้งค่า Chunk size ผิดพลาดเป็นหนึ่งในความล้มเหลวที่ถูกรายงานบ่อยที่สุดในการสร้าง RAG การตัดสินใจที่ว่า "ตัดให้ใหญ่เข้าไว้จะได้ไม่เสียข้อมูล" มักส่งผลเสียต่อความแม่นยำในการค้นหาอย่างมาก

ทำไม Chunk ที่ใหญ่เกินไปถึงเป็นปัญหา

ในการทำ Vector search ข้อมูลของ Chunk ทั้งหมดจะถูกบีบอัดให้เป็น Embedding vector เพียงหนึ่งเดียว ยิ่ง Chunk มีขนาดใหญ่ Vector นั้นก็ยิ่งมีแนวโน้มที่จะกลายเป็น "การแสดงผลที่คลุมเครือซึ่งเกิดจากการเฉลี่ยหลายหัวข้อเข้าด้วยกัน" ทำให้การคำนวณความคล้ายคลึง (Similarity) กับ Query ไม่แม่นยำ ส่งผลให้เกิด "ข้อผิดพลาดในการค้นหา" ที่เนื้อหาซึ่งควรจะตรงกันกลับไม่ถูกจัดอยู่ในลำดับต้นๆ

อาการที่มักพบได้บ่อย

• ย่อหน้าที่ไม่เกี่ยวข้องกับเจตนาของ Query มักจะปนเข้ามา
• Context ที่ส่งให้ LLM มีทั้ง "ข้อมูลที่เกี่ยวข้อง" และ "ข้อมูลที่ไม่เกี่ยวข้อง" ปะปนกัน ทำให้ความแม่นยำของคำตอบลดลง
• แม้จะดึงข้อมูล Top-k มาได้ แต่ความหนาแน่นของข้อมูลที่เป็นประโยชน์จริงกลับต่ำ

แนวทางที่แนะนำ: Small-to-Big Retrieval (กลยุทธ์ Parent-Child Chunk)

แนวทางที่เป็นกระแสหลักในปัจจุบันคือ การใช้ Chunk ขนาดเล็ก (ประมาณ 128–256 tokens) ในขั้นตอนการค้นหาเพื่อให้ได้ผลลัพธ์ที่แม่นยำสูง และส่ง Parent chunk (512–1,024 tokens) เข้าสู่ LLM เพื่อให้ได้บริบทที่ครบถ้วน วิธีนี้ช่วยรักษาความแม่นยำในการค้นหาไปพร้อมกับการป้องกันไม่ให้บริบทขาดหายไป ซึ่ง LlamaIndex และ LangChain มีฟังก์ชันมาตรฐานที่รองรับการใช้งานกลยุทธ์นี้

แนวทางในการตั้งค่า (ค่าอ้างอิง)

• Chunk สำหรับการค้นหา: 128–256 tokens (เน้นความแม่นยำ)
• Chunk สำหรับส่งเข้า LLM: 512–1,024 tokens (เน้นการรักษาบริบท)
• Overlap ระหว่าง Chunk: ประมาณ 20–50 tokens (ป้องกันบริบทขาดตอน)

Chunk size ไม่ใช่สิ่งที่ "ตั้งค่าครั้งเดียวแล้วจบไป" การดำเนินงานโดยวัดความแม่นยำในการค้นหาอย่างสม่ำเสมอด้วย Framework การประเมินผลอย่าง RAGAS เป็นสิ่งสำคัญในการรักษาคุณภาพระดับ Production เนื่องจากค่าที่เหมาะสมที่สุดจะแตกต่างกันไปตามลักษณะของเอกสารและ Use case ตัวเลขข้างต้นจึงเป็นเพียงค่าอ้างอิงเท่านั้น ขอแนะนำให้ทำการทดสอบในสภาพแวดล้อมขององค์กรท่านเอง

สภาวะที่ภาษาของ Embedding Model และ LLM ไม่สอดคล้องกันนั้น เป็นสิ่งที่กัดกินความแม่นยำของ RAG ทั้งระบบอย่างเงียบเชียบ หากคุณรู้สึกว่าผลการค้นหาถูกส่งกลับมา แต่คำตอบกลับดูไม่ตรงประเด็น นี่คือหนึ่งในสาเหตุที่คุณควรตั้งข้อสงสัย

โครงสร้างของปัญหา

Embedding Model มีหน้าที่คำนวณ "ระยะห่างทางความหมายระหว่างคำถามและเอกสาร" ในขณะที่ LLM มีหน้าที่ "อ่านบริบทที่ได้รับมาเพื่อสร้างคำตอบ" หากทั้งสองส่วนนี้ทำงานในพื้นที่ภาษา (Language Space) ที่แตกต่างกัน อาจเกิดกรณีที่แม้การค้นหาจะดึง Chunk ที่เกี่ยวข้องขึ้นมาเป็นอันดับต้นๆ แต่ LLM กลับไม่สามารถตีความ Chunk นั้นได้อย่างเหมาะสม

รูปแบบของความไม่สอดคล้องที่พบบ่อยมีดังนี้:

• Embedding Model ที่เน้นภาษาอังกฤษ × เอกสารภาษาญี่ปุ่น: โมเดลที่เรียนรู้จากคลังข้อมูลภาษาอังกฤษเป็นหลัก มักจะมีการแสดงความหมายของเอกสารภาษาญี่ปุ่นที่หยาบกว่า
• Multilingual Embedding Model × LLM ที่รองรับเฉพาะภาษาอังกฤษ: แม้ Embedding จะรองรับหลายภาษา แต่หาก LLM ไม่สามารถประมวลผลบริบทภาษาญี่ปุ่นได้อย่างแม่นยำ คุณภาพของคำตอบก็จะลดลง
• ความไม่สอดคล้องของคำศัพท์เฉพาะทาง: ในสาขาที่มีศัพท์เฉพาะมาก เช่น กฎหมาย การแพทย์ หรือการเงิน มีรายงานว่า Embedding Model แบบทั่วไปอาจไม่สามารถแปลงความหมายของคำศัพท์เหล่านั้นเป็นเวกเตอร์ได้อย่างแม่นยำ

แนวทางการแก้ไข

1. เลือกใช้ Embedding Model และ LLM จากผู้ให้บริการรายเดียวกัน เพื่อลดความเหลื่อมล้ำของพื้นที่ภาษาให้เหลือน้อยที่สุด
2. พิจารณาใช้โมเดลที่รองรับหลายภาษา (Multilingual Model) เข้ามาเป็นตัวเลือกและเปรียบเทียบผลลัพธ์ (แนะนำให้วัดผลจริงในสภาพแวดล้อมขององค์กร แทนการอ้างอิงเพียงคะแนนอย่างเป็นทางการ)
3. ใช้เฟรมเวิร์กการประเมินผล เช่น RAGAS เพื่อวัดคะแนน "Context Relevance" โดยแยกการประเมินความแม่นยำในการค้นหา (Retrieval) ออกจากการตีความของ LLM

การเลือกโมเดลเป็นสิ่งที่เปลี่ยนได้ยากเมื่อตัดสินใจไปแล้ว การสร้างนิสัยในการทำ A/B Testing กับโมเดลหลายๆ ตัวตั้งแต่ขั้นตอนเริ่มต้น จึงเป็นกุญแจสำคัญในการป้องกันการต้องย้อนกลับมาแก้ไขงานในภายหลัง

คุณกำลังส่งมอบ Chunk อันดับต้นๆ k รายการที่ได้จากการทำ Vector Search ให้กับ LLM โดยตรงอยู่หรือไม่? แม้จะเป็นวิธีที่นำไปใช้งานได้ง่าย แต่ก็นับเป็นหลุมพรางสำคัญที่ส่งผลเสียต่อคุณภาพของคำตอบอย่างมาก

Vector Search จะวัดความใกล้เคียงทางความหมายด้วยวิธีอย่าง Cosine Similarity แต่ ความเกี่ยวข้องกับ Query และปริมาณข้อมูลที่จำเป็นต่อการตอบคำถามนั้นไม่จำเป็นต้องตรงกันเสมอไป ดังนั้น แม้จะมีคะแนนความคล้ายคลึงสูง แต่ก็ไม่ได้หมายความว่า Chunk ที่ตอบคำถามได้อย่างถูกต้องจะถูกจัดให้อยู่ในอันดับต้นๆ เสมอไป

ทำไมการส่ง Chunk อันดับต้นๆ k รายการไปโดยตรงจึงเป็นปัญหา

• มักมี Chunk ที่ "เกี่ยวข้องแต่ไม่ใช่คำตอบ" ปะปนเข้ามา
• สิ้นเปลือง Context Window โดยเปล่าประโยชน์ ทำให้ข้อมูลที่จำเป็นจริงๆ เจือจางลง
• ยิ่งมี Noise มากเท่าไร LLM ยิ่งมีโอกาสหยิบข้อมูลที่ผิดพลาดไปใช้ ซึ่งเพิ่มความเสี่ยงต่อการเกิด Hallucination

วิธีแก้ไข: การนำ Re-ranking มาใช้

การเพิ่มขั้นตอน Re-ranking โดยใช้ Cross-Encoder Model ระหว่างขั้นตอนการดึงข้อมูล (Retrieval) และขั้นตอนการสร้างคำตอบ (Generation) เป็นวิธีที่มีประสิทธิภาพ เนื่องจาก Cross-Encoder จะรับ Query และ Chunk เข้าไปประมวลผลพร้อมกันเพื่อประเมินความเกี่ยวข้องอย่างแม่นยำ จึงคาดหวังผลลัพธ์การจัดลำดับที่สูงกว่าการทำ Vector Search แบบ Bi-Encoder ได้

ปัจจุบันมีการใช้งานอย่างแพร่หลาย เช่น Cohere Rerank endpoint, BAAI/bge-reranker series หรือโมเดลขนาดเล็กที่รันในเครื่องได้ (Local model) อย่าง FlashRank การนำเครื่องมือเหล่านี้มาใช้ร่วมกันจะช่วยคัดกรอง Chunk ที่จะส่งให้ LLM และยกระดับคุณภาพของ Context ให้ดียิ่งขึ้น

ข้อควรพิจารณาในการนำไปใช้งาน

• ในการค้นหาครั้งแรก ให้ดึงข้อมูลมาจำนวนมากพอ (top-20 ถึง 50 รายการ) แล้วค่อยคัดให้เหลือ top-3 ถึง 5 รายการหลังจากทำ Re-ranking
• ตรวจสอบให้แน่ใจจากเอกสารอย่างเป็นทางการว่า Re-ranking Model นั้นรองรับภาษาญี่ปุ่นหรือไม่
• วัดผลกระทบด้าน Latency และแก้ไขด้วยการทำ Asynchronous processing หรือการใช้ Cache

RAGシステムは「一度構築したら終わり」ではない。ドキュメントが更新されたにもかかわらず、ベクトルインデックスをそのまま放置するケースは、本番運用で頻繁に報告される失敗パターンの一つだ。

なぜ問題になるのか

ベクトルストアに格納されているのは、インデックス作成時点のスナップショットに過ぎない。社内規程・製品仕様書・APIドキュメントなど更新頻度の高いドキュメントを扱う場合、インデックスが古いままだと以下の問題が生じる。

• 廃止されたルールや旧バージョンの仕様を根拠に回答を生成してしまう
• 最新情報が検索対象から除外され、ユーザーに誤った情報が提供されるリスクが高まる
• 削除済みのチャンクが検索にヒットし、存在しないコンテンツへの参照が発生する

見落とされがちな「差分更新」の設計不足

多くのチームがインデックスの「全件再構築」は意識しても、「差分更新」の仕組みを設計しないまま本番化する傾向がある。全件再構築はドキュメント数が増えるほどコストと時間がかかるため、更新頻度が高い環境では現実的でないケースも多い。

LlamaIndexやLangChainのドキュメントローダーには差分検知機能が整備されつつある。ドキュメントのハッシュ値やタイムスタンプを管理し、変更があったチャンクのみを再埋め込みする設計が推奨されている（各フレームワークの公式ドキュメントで最新仕様を確認すること）。

回避策のポイント

• ドキュメントごとにメタデータ（最終更新日時・バージョン番号）をベクトルストアに付与する
• CI/CDパイプラインにインデックス更新ジョブを組み込み、ドキュメント変更をトリガーに自動実行する
• 定期的なインデックス整合性チェックを設け、参照先ドキュメントが存在するかを確認する
• 削除されたドキュメントに対応する「論理削除フラグ」をメタデータで管理する

インデックスの鮮度はRAGの回答品質に直結する。運用フェーズに入った後こそ、更新フローの自動化と監視体制の整備を優先すべきだ。

หากพอใจเพียงแค่ขั้นตอนที่ว่า "สร้างสิ่งที่ใช้งานได้แล้ว" มักจะมีรายงานว่าเกิดปัญหาที่ไม่คาดคิดขึ้นในสภาพแวดล้อมการใช้งานจริง (Production) ในการทำ RAG implementation นั้น ขั้นตอนที่ดูเหมือนจะถูกต้องในตอนแรกอาจส่งผลเสียอย่างร้ายแรงต่อความแม่นยำในการค้นหา (Search accuracy) และความคุ้มค่าของต้นทุน (Cost efficiency) ในส่วนนี้ เราจะหยิบยกรูปแบบการทำ implementation ที่ไม่แนะนำ (NG patterns) 2 รูปแบบที่มักพบได้บ่อยในหน้างานจริงขึ้นมา และอธิบายว่าเหตุใดจึงเป็นปัญหา

การนำไฟล์ PDF มาทำ Vectorization โดยตรงถือเป็นหนึ่งในตัวอย่างที่ควรหลีกเลี่ยง (NG) ที่พบบ่อยที่สุดในการสร้าง RAG แม้จะดูทำได้ง่าย แต่ต้องระวังเพราะเป็นสาเหตุที่ทำให้ความแม่นยำในการค้นหาลดลงอย่างมาก

ทำไมถึงไม่ควรทำ: ปัญหาเชิงโครงสร้างของ PDF

PDF เป็นรูปแบบไฟล์ที่ให้ความสำคัญกับเลย์เอาต์การพิมพ์ ทำให้เกิดสัญญาณรบกวน (Noise) ต่างๆ แทรกเข้ามาในขั้นตอนการดึงข้อความ ปัญหาหลักๆ มีดังนี้:

• การติดมาของ Header และ Footer: เลขหน้าหรือชื่อบริษัทอาจไปรวมกับเนื้อหาหลัก ทำให้เกิด Chunk ที่ไม่มีความหมาย
• การอ่านเลย์เอาต์แบบคอลัมน์ผิดพลาด: ใน PDF แบบ 2 คอลัมน์ บางครั้งข้อความอาจถูกดึงออกมาในลำดับที่สลับกันระหว่างคอลัมน์ซ้ายและขวา
• ความล้มเหลวในการแปลงตารางและรูปภาพเป็นข้อความ: ข้อมูลในเซลล์อาจรวมกันหรือขาดหายไป ทำให้ไม่สามารถดึงข้อมูลตัวเลขที่ถูกต้องได้
• ข้อความอ่านไม่ออกหรือมีสัญลักษณ์แปลกปลอม: ปัญหาการฝังฟอนต์อาจทำให้ตัวอักษรพิเศษหรือภาษาญี่ปุ่นแสดงผลผิดเพี้ยน

หากนำสัญญาณรบกวนเหล่านี้ไปทำ Vectorization โดยตรง จะทำให้คุณภาพของ Embedding Vector ลดลง และส่งผลให้ Chunk ที่มีความเกี่ยวข้องสูงไม่ถูกดึงขึ้นมาในการค้นหา

วิธีแก้ไข: การสร้างไปป์ไลน์สำหรับการประมวลผลล่วงหน้า (Pre-processing Pipeline)

การประมวลผลล่วงหน้าโดยใช้ไลบรารีอย่าง PyMuPDF, pdfplumber หรือ Unstructured เป็นวิธีที่นิยมใช้กันอย่างแพร่หลาย โดยมีขั้นตอนพื้นฐานดังนี้:

1. ตัดส่วน Header และ Footer ออกโดยใช้ Regular Expression หรือการวิเคราะห์เลย์เอาต์
2. แปลงตารางให้อยู่ในรูปแบบ Markdown หรือ CSV ก่อนนำไปทำ Chunking
3. สุ่มตรวจสอบข้อความที่ดึงออกมาเพื่อดูว่ามีสัญญาณรบกวนหรือไม่
4. สำหรับ PDF ที่เป็นไฟล์สแกน ให้พิจารณาใช้ Tesseract หรือ Azure Document Intelligence

การประมวลผลล่วงหน้าสำหรับ PDF คือรากฐานที่กำหนดคุณภาพของ RAG ทั้งระบบ การจัดสรรเวลาและทรัพยากรให้เพียงพอในขั้นตอนก่อนการทำ Vectorization เป็นสิ่งจำเป็นอย่างยิ่งเพื่อให้ได้คุณภาพระดับใช้งานจริง (Production Quality)

การนำ "Chunk" ที่ค้นหาได้ทั้งหมดมาใส่ไว้ในช่องบริบท (Context) ของ Prompt โดยคิดว่า "ใส่ไปให้หมดปลอดภัยที่สุด" เป็นหนึ่งในตัวอย่างที่ผิด (NG) ซึ่งพบเห็นได้บ่อยในการทำงานจริง

แม้จะดูเหมือนว่ายิ่งมีข้อมูลมากเท่าไร ความแม่นยำของคำตอบจะยิ่งสูงขึ้น แต่ในความเป็นจริงมักจะส่งผลตรงกันข้าม มีรายงานว่ายิ่งบริบทมีความยาวมากเท่าไร LLM จะยิ่งตัดสินใจได้ยากขึ้นว่า "ข้อมูลใดสำคัญ" ส่งผลให้คุณภาพของคำตอบลดลง ปรากฏการณ์นี้เป็นที่รู้จักในชื่อปัญหา "Lost in the Middle" ซึ่งงานวิจัยระบุว่าข้อมูลที่วางไว้บริเวณกึ่งกลางของ Prompt มักถูกโมเดลละเลยหรือไม่ได้รับการอ้างอิง

ลำดับความล้มเหลวที่พบบ่อย

• นำ Chunk อันดับสูงสุด 20 รายการมาต่อกันใน System Prompt โดยตรง
• จำนวน Token รวมสูงเกิน 10,000 - 20,000 Token
• โมเดลมองข้ามข้อมูลในช่วงกลางและช่วงท้าย แล้วสร้างคำตอบโดยใช้เพียงเนื้อหาช่วงต้นเท่านั้น
• ส่งผลให้เกิด "คำตอบที่ไม่ตรงประเด็น" หรือ "คำตอบที่ไม่สมบูรณ์" บ่อยครั้ง

ปัจจัยที่ทำให้ปัญหาเลวร้ายลง

• มีเนื้อหาที่ซ้ำซ้อนกันระหว่าง Chunk ทำให้โมเดลเกิดความสับสนได้ง่าย
• มี Chunk ที่มีความเกี่ยวข้องต่ำปะปนอยู่ในอันดับต้นๆ ซึ่งทำหน้าที่เป็นสัญญาณรบกวน (Noise)
• ยิ่งบริขตยาวเท่าไร ต้นทุนการอนุมาน (Inference Cost) และเวลาในการตอบสนอง (Response Latency) ของ API ก็จะยิ่งเพิ่มขึ้น

แนวทางการแก้ไข

• ใช้การทำ Re-ranking (เช่น Cross-Encoder) เพื่อคัดเลือก Chunk อันดับต้นๆ ให้เหลือเพียงประมาณ 3-5 รายการ
• กำหนดเกณฑ์ (Threshold) สำหรับคะแนนความเกี่ยวข้องของ Chunk และตัดรายการที่ต่ำกว่าเกณฑ์ออก
• กำหนดเพดานจำนวน Token รวมของบริบทที่จะส่งไป และใช้ตรรกะตัดส่วนที่เกินออก

แม้ในปัจจุบันที่ Context Window ของ GPT หรือ Claude จะขยายออกไปมากแล้ว แต่ "ใส่ได้ยาว ไม่ได้หมายความว่าควรใส่ให้ยาว" การออกแบบโดยยึดหลักการจำกัดปริมาณบริบทให้เหลือเพียงเท่าที่จำเป็นที่สุดอยู่เสมอ ถือเป็นสิ่งสำคัญในการรักษาความสมดุลระหว่างความแม่นยำ ต้นทุน และเวลาในการตอบสนอง

ในขณะที่ทุ่มเทให้กับการออกแบบ Chunk และการเลือกอัลกอริทึมการค้นหา ก็ยังมีหลุมพรางที่มักถูกมองข้ามอยู่ กรณีของการปล่อยใช้งานโดยไม่มีการกำหนดตัวชี้วัดการประเมิน (Evaluation Metrics) และความแม่นยำที่ลดลงในสภาพแวดล้อมที่มีเอกสารหลายภาษาปะปนกัน เป็นปัญหาที่ได้รับรายงานซ้ำๆ ในหน้างานจริง ในหัวข้อ H3 ถัดไป เราจะเจาะลึกถึงหลุมพรางทั้งสองประการนี้และชี้แนวทางการรับมืออย่างเป็นรูปธรรม

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

ความเสี่ยงหลักที่เกิดจากการนำระบบขึ้นใช้งานจริงโดยไม่มีการประเมิน

• ไม่สามารถรับรู้ถึงอัตราการค้นหาข้อมูลที่ตรงประเด็น (Recall) ที่ลดลงเป็นตัวเลขได้ ทำให้ไม่สามารถจัดลำดับความสำคัญในการปรับปรุงได้
• มีความเสี่ยงที่ข้อมูลผิดพลาดจะถูกสะสมและแพร่กระจายออกไป โดยที่ไม่ทราบความถี่ในการเกิดอาการประสาทหลอน (Hallucination) ของโมเดล
• ไม่สามารถเปรียบเทียบผลลัพธ์เชิงปริมาณจากการปรับเปลี่ยนการออกแบบ Chunk หรือ Prompt ได้ ทำให้การปรับปรุงขึ้นอยู่กับการตัดสินใจส่วนบุคคล
• ไม่สามารถตรวจพบ Regression (คุณภาพที่ถดถอยจากการแก้ไข) ทำให้มีความเสี่ยงด้านคุณภาพทุกครั้งที่มีการอัปเดตระบบ

RAGAS เป็นเฟรมเวิร์กที่ได้รับการอ้างถึงอย่างกว้างขวางสำหรับการประเมิน RAG โดยสามารถวัดคุณภาพของระบบในหลายมิติผ่านตัวชี้วัดหลัก ดังนี้:

• Faithfulness (ความซื่อตรง): คำตอบที่สร้างขึ้นอ้างอิงจากบริบทที่ค้นหามาได้หรือไม่
• Answer Relevancy (ความเกี่ยวข้องของคำตอบ): คำตอบตอบสนองต่อคำถามได้อย่างเหมาะสมหรือไม่
• Context Precision / Recall: Chunk ที่ค้นหามาได้มีความแม่นยำและครอบคลุมเพียงพอหรือไม่

ขั้นตอนการประเมินขั้นต่ำที่ควรดำเนินการก่อนนำระบบขึ้นใช้งานจริง มีดังนี้:

1. เตรียมชุดทดสอบ (Test set) ที่ประกอบด้วยคำถามตัวแทนจำนวน 50–100 ข้อ
2. วัดค่า Baseline ของตัวชี้วัดแต่ละตัวโดยใช้ RAGAS หรือเครื่องมืออื่น ๆ
3. กำหนดเกณฑ์ขั้นต่ำ (เช่น Faithfulness 0.8 ขึ้นไป) และตั้งกฎว่าหากต่ำกว่าเกณฑ์ให้ระงับการปล่อยระบบ
4. หลังจากนำระบบขึ้นใช้งานจริง ให้ทำการประเมินซ้ำด้วยชุดทดสอบเดิมอย่างสม่ำเสมอเพื่อเฝ้าติดตามการเปลี่ยนแปลงของคะแนน

การนำระบบขึ้นใช้งานจริงโดยอาศัยเพียงการประเมินเชิงอัตวิสัยที่ว่า "รู้สึกว่าความแม่นยำน่าจะดี" ถือเป็นข้อบกพร่องเชิงโครงสร้างในมุมมองของการประกันคุณภาพ การจัดเตรียมพื้นฐานสำหรับการประเมินจึงเป็นก้าวแรกที่สำคัญที่สุดในการรับประกันความน่าเชื่อถือของระบบ RAG

ฐานความรู้ที่มีทั้งภาษาญี่ปุ่นและภาษาอังกฤษปะปนกันเป็นบ่อเกิดของปัญหาความแม่นยำในการค้นหาที่ลดลง ซึ่งมักถูกมองข้ามใน RAG แม้ว่าโมเดล Embedding ที่รองรับหลายภาษาจะมีการพัฒนาอย่างต่อเนื่อง แต่ในการใช้งานจริงยังคงมีรายงานปัญหาที่เกิดจากการปะปนกันของภาษาอยู่บ่อยครั้ง

ทำไมความแม่นยำจึงลดลง

โมเดล Embedding มักมีการกระจายตัวของเวกเตอร์สเปซที่แตกต่างกันไปในแต่ละภาษา แม้ว่าเอกสารภาษาอังกฤษจะมีความหมายใกล้เคียงกับคำค้นหา (Query) ภาษาญี่ปุ่น แต่ระยะห่างของเวกเตอร์กลับกว้างขึ้น ทำให้เกิดกรณีที่ข้อมูลนั้นหลุดจากการค้นหาได้ง่าย

ปัจจัยหลักที่ทำให้ประสิทธิภาพลดลงมีดังนี้:

• ความแตกต่างของขอบเขตการรองรับหลายภาษาของโมเดล: แม้จะเป็นโมเดลที่ระบุว่ารองรับหลายภาษา แต่ก็มีรายงานว่าความแม่นยำของภาษาในเอเชียตะวันออกมักต่ำกว่าภาษาอังกฤษ
• อิทธิพลของ Tokenizer: ภาษาญี่ปุ่นจะถูกแบ่งเป็นหน่วยคำ (Morpheme) ทำให้จำนวนโทเค็นเพิ่มขึ้น ซึ่งส่งผลให้บริบทขาดช่วงที่รอยต่อของ Chunk ได้ง่าย
• ความไม่สมมาตรของการให้คะแนน (Scoring): แม้เนื้อหาจะมีความหมายเดียวกัน แต่หากภาษาต่างกัน คะแนนความคล้ายคลึง (Similarity Score) จะไม่ตรงกัน ทำให้เกิดความลำเอียงในผลลัพธ์ Top-k

สถานการณ์ตัวอย่าง

สมมติระบบที่มีคู่มือผลิตภัณฑ์เป็นภาษาญี่ปุ่นและเอกสารทางเทคนิคเป็นภาษาอังกฤษ เมื่อมีคำค้นหาภาษาญี่ปุ่นว่า "冷却ファンの回転数制御" (การควบคุมความเร็วรอบพัดลมระบายความร้อน) แม้ว่า "cooling fan RPM control" ในเอกสารภาษาอังกฤษจะเป็นแหล่งคำตอบที่มีความหมายเหมาะสมที่สุด แต่ก็มักจะเกิดกรณีที่ข้อมูลดังกล่าวไม่ถูกจัดอยู่ในลำดับต้นๆ ของผลการค้นหา

แนวทางแก้ไข

• ใช้แนวทาง "Query Expansion" โดยการแปลคำค้นหาเป็นหลายภาษาโดยอัตโนมัติก่อนทำการค้นหา
• พิจารณาสถาปัตยกรรมที่แยก Index ตามภาษา และทำ Normalization คะแนนเมื่อนำมารวมกัน
• ใช้โมเดลที่เชี่ยวชาญหลายภาษาควบคู่กับ BM25 เพื่อเสริมความแม่นยำในการค้นหา
• วัดผลความแม่นยำในการค้นหาแยกตามภาษาอย่างสม่ำเสมอด้วยตัวชี้วัด และกำหนดรอบการคัดเลือกโมเดลใหม่

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

จากรูปแบบความล้มเหลวที่ได้กล่าวไปข้างต้น จะเห็นได้ว่าในการออกแบบ RAG แนวคิดเรื่อง "การเลือกโครงสร้างที่ทนทานต่อความเสียหาย" นั้นมีความสำคัญมากกว่า "การตั้งเป้าให้สมบูรณ์แบบตั้งแต่ต้น" หากขาดกลยุทธ์การค้นหา (Search Strategy) การออกแบบ Chunk หรือตัวชี้วัดการประเมิน (Evaluation Metrics) อย่างใดอย่างหนึ่งไป ปัญหาจะปรากฏขึ้นในเฟสใดเฟสหนึ่งอย่างแน่นอน ในส่วนนี้ เราจะเจาะลึกถึงแนวคิดการออกแบบ Hybrid Search ซึ่งถือว่ามีประสิทธิภาพสูง และรูปแบบของ Agentic RAG ที่สามารถตอบสนองต่อคำถามที่ซับซ้อนได้อย่างยืดหยุ่น

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

จุดอ่อนของ Vector Search และ BM25

• จุดอ่อนของ Vector Search: หากคำค้นหาเป็นคำเฉพาะ (Proper Noun), หมายเลขรุ่น (Model Number) หรือชื่อคำสั่ง (Command Name) ที่สะกดไม่ตรงกัน คะแนนความคล้ายคลึงมักจะต่ำลง ตัวระบุอย่าง "AWS Lambda" หรือ "CVE-2024-XXXX" มักจะไม่ถูกฝัง (Embed) ให้อยู่ในตำแหน่งที่ใกล้เคียงกันในเชิงความหมาย
• จุดอ่อนของ BM25: เนื่องจากพึ่งพาการจับคู่คำตามตัวอักษร (Lexical Match) จึงไม่สามารถรองรับการใช้คำพ้องความหมายหรือการเปลี่ยนรูปประโยคได้ เช่น "การลดต้นทุน" และ "การบีบอัดค่าใช้จ่าย" จะถูกมองว่าเป็นคนละคำค้นหากัน

การนำทั้งสองวิธีมาผสมผสานกันจะช่วยให้ครอบคลุมทั้งการค้นหาเชิงความหมาย (Semantic) และการจับคู่เชิงตัวอักษร (Lexical)

วิธีการรวมคะแนน: RRF เป็นวิธีหลัก

สำหรับการรวมคะแนนนั้น Reciprocal Rank Fusion (RRF) เป็นวิธีที่นิยมใช้กันอย่างแพร่หลาย เป็นเทคนิคที่เรียบง่ายโดยการนำอันดับของผลลัพธ์แต่ละรายการมาถ่วงน้ำหนักด้วยค่าส่วนกลับแล้วนำมารวมกัน ข้อดีคือสามารถรวมระบบที่มีสเกลคะแนนต่างกันได้โดยไม่ต้องทำ Normalization แพลตฟอร์มการค้นหาหลักๆ เช่น Elasticsearch, OpenSearch และ Weaviate ต่างก็รองรับการทำ Hybrid Search ด้วย RRF แบบ Native ทำให้ต้นทุนในการนำไปใช้งานจริงลดลงกว่าแต่ก่อน

กรณีที่เห็นผลลัพธ์ได้ชัดเจน

• เอกสารคู่มือผลิตภัณฑ์หรือเอกสารทางเทคนิคที่มีการระบุหมายเลขรุ่นหรือชื่อคำสั่งบ่อยครั้ง
• ระเบียบข้อบังคับภายในบริษัทหรือเอกสารทางกฎหมายที่ใช้เลขมาตราหรือคำศัพท์เฉพาะเป็นคีย์เวิร์ดในการค้นหา
• แชทบอทที่ผู้ใช้งานมักใช้ภาษาพูดผสมกับศัพท์เฉพาะทาง

มีรายงานจากหลายกรณีศึกษาว่าความแม่นยำในการค้นหาสำหรับคำค้นหาที่มีคำเฉพาะเพิ่มขึ้นอย่างเห็นได้ชัด แนวทางที่จัดการได้ง่ายคือการตั้งค่าให้น้ำหนักของ BM25 ต่ำกว่า แล้วให้ Vector Search เป็นตัวนำ จากนั้นจึงค่อยปรับสัดส่วนตามบันทึกความแม่นยำ (Accuracy Log) และเมื่อนำไปใช้ร่วมกับ Agentic RAG ในส่วนถัดไป การวาง Hybrid Search ไว้เป็นพื้นฐานของเลเยอร์การค้นหาจะช่วยเพิ่มขีดความสามารถในการรับมือกับคำค้นหาที่ซับซ้อนได้ดียิ่งขึ้น

RAG ทั่วไปตั้งอยู่บนพื้นฐานของไปป์ไลน์ที่เรียบง่ายแบบ "1 คำถาม → 1 การค้นหา → 1 คำตอบ" อย่างไรก็ตาม ในการใช้งานจริง มักเกิดคำถามที่ต้องการการอนุมานหลายขั้นตอนหรือการบูรณาการจากหลายแหล่งข้อมูล รูปแบบการออกแบบ Agentic RAG จึงถูกสร้างขึ้นเพื่อรองรับคำถามที่ซับซ้อนเหล่านี้

Agentic RAG หมายถึงสถาปัตยกรรมที่ให้ LLM ทำหน้าที่เป็นเอเจนต์ (Agent) โดยจะทำลูปการค้นหา การตัดสินใจ และการค้นหาซ้ำด้วยตนเอง ซึ่งสามารถสรุปรูปแบบการออกแบบหลักได้ 3 รูปแบบ ดังนี้:

• รูปแบบ Plan-and-Execute: เมื่อเอเจนต์ได้รับคำถาม จะสร้าง "รายการงานย่อย" ขึ้นมาก่อน จากนั้นจึงดำเนินการค้นหาและตอบคำถามในแต่ละงานแยกกัน และสุดท้ายจึงสร้างคำตอบแบบบูรณาการ
• รูปแบบ ReAct (Reasoning + Acting): ทำซ้ำวงจรการคิด (Reasoning) → การกระทำ (Acting) → การสังเกต (Observing) หากผลลัพธ์การค้นหาไม่เพียงพอ ระบบจะเปลี่ยนคำถามใหม่โดยอัตโนมัติและทำการค้นหาซ้ำ
• รูปแบบ Self-RAG: โมเดลจะประเมินคำตอบที่สร้างขึ้นด้วยตนเองว่า "คำตอบนี้ได้รับการสนับสนุนจากเอกสารหรือไม่" หากไม่แน่ใจ ระบบจะทำการค้นหาใหม่

ตัวอย่างเช่น คำถามที่ว่า "จงเปรียบเทียบเหตุผลทางเทคนิคที่ทำให้ราคาของผลิตภัณฑ์ A และผลิตภัณฑ์ B แตกต่างกัน" นั้นยากที่จะตอบได้ด้วยการค้นหาเพียงครั้งเดียว หากใช้รูปแบบ Plan-and-Execute ระบบจะสามารถแบ่งการทำงานออกเป็น 3 ขั้นตอน ได้แก่ การค้นหาข้อมูลจำเพาะของผลิตภัณฑ์ A, การค้นหาข้อมูลจำเพาะของผลิตภัณฑ์ B และการอนุมานเพื่อเปรียบเทียบ

ข้อควรระวังในการนำไปใช้งาน:

• กำหนดขีดจำกัดจำนวนรอบ (max_iterations) เพื่อป้องกันการวนลูปไม่รู้จบ
• บันทึก Log ในแต่ละขั้นตอนเพื่อให้สามารถตรวจสอบย้อนกลับได้ว่าการค้นหาใดล้มเหลว
• จำเป็นต้องตรวจสอบ Latency และการใช้ Token เนื่องจากมีการเรียกใช้เครื่องมือสะสมเพิ่มขึ้น

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

เราได้คัดเลือก 2 คำถามที่พบบ่อยจากนักพัฒนาและวิศวกรผู้มีส่วนร่วมในการสร้างและดูแลระบบ RAG มานำเสนอ คำถามอย่าง "RAG ยังมีประโยชน์อยู่หรือไม่สำหรับเอกสารขนาดเล็ก" และ "ควรเลือกใช้ LLM รุ่นใด" ยังคงเป็นประเด็นที่ถูกถามถึงอยู่เสมอในหน้างานจริง เนื่องจากคำถามเหล่านี้ส่งผลโดยตรงต่อการตัดสินใจในการออกแบบ เราจึงขออธิบายโดยครอบคลุมมุมมองที่เฉพาะเจาะจงในแต่ละประเด็นครับ

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

ในสภาพแวดล้อมขนาดเล็ก (ประมาณหลักสิบถึงหลักร้อย) ขนาดดัชนีของการค้นหาแบบเวกเตอร์ (Vector Search) จะมีขนาดเล็ก ทำให้ค่าความหน่วง (Latency) ในการค้นหามักจะต่ำ ในขณะเดียวกัน เนื่องจากจำนวน Chunk ที่เป็นตัวเลือกมีน้อย จึงต้องระวังว่าความไม่ละเอียดในการออกแบบ Chunk จะส่งผลโดยตรงต่อคุณภาพของคำตอบ

ตัวอย่างกรณีการใช้งานที่เห็นผลได้ชัด:

• กลุ่มเอกสารที่มีการอัปเดตน้อยและมีความน่าเชื่อถือสูง เช่น กฎระเบียบภายในบริษัท หรือคู่มือต่างๆ
• กรณีที่เนื้อหาหลักเป็นข้อความที่มีโครงสร้างชัดเจน เช่น ข้อมูลจำเพาะของผลิตภัณฑ์ (Product Specification) หรือ FAQ
• ฐานความรู้ภายในบริษัทที่จำกัดเฉพาะโดเมนและมีศัพท์เฉพาะทางจำนวนมาก

ในทางกลับกัน สิ่งที่ต้องระวังคือเมื่อมีเอกสารน้อย กรณีที่ "ค้นหาไม่พบ" จะเพิ่มมากขึ้น หากไม่มี Chunk ที่ตรงกับ Query ตัว LLM จะพยายามเติมเต็มด้วยข้อมูลที่มีอยู่ ซึ่งจะทำให้เกิดอาการหลอน (Hallucination) ได้ง่าย ดังนั้น การใส่คำสั่งที่ชัดเจนลงใน Prompt ว่า "หากไม่มีข้อมูลระบุไว้ในเอกสาร ให้ตอบว่าไม่ทราบ" จึงมีความสำคัญเป็นพิเศษ

สรุปประเด็นสำคัญ:

• แม้จะเป็นขนาดเล็ก RAG ก็ยังคงมีประสิทธิภาพ แต่ความแม่นยำในการออกแบบ Chunk และ Prompt จะมีความสำคัญยิ่งขึ้น
• เพื่อเพิ่มอัตราการค้นหาที่ตรงจุด (Hit rate) ควรพิจารณาการนำ Query Expansion มาใช้
• เนื่องจากมีเอกสารน้อย การวัดคุณภาพด้วย RAGAS หรือวิธีอื่นๆ ผ่านการประเมินข้อมูลทั้งหมด (Full-set evaluation) จึงสามารถทำได้ค่อนข้างง่าย

ในการสร้าง RAG การเลือก LLM ไม่ได้ขึ้นอยู่กับว่า "รุ่นไหนเก่งที่สุด" แต่ควรตัดสินจาก "รุ่นไหนที่เหมาะกับ Use Case ของเรา" ซึ่งเป็นแนวคิดพื้นฐาน โดยทั้ง GPT, Claude และ Gemini ต่างก็มีประสิทธิภาพสูงและยากที่จะสรุปว่ารุ่นใดเหนือกว่ากันอย่างชัดเจน

ลักษณะเด่นและ Use Case ที่เหมาะสมของแต่ละโมเดล:

• GPT (OpenAI): มีผลงานด้านการเชื่อมต่อเครื่องมือ (Tool Integration) และการเรียกใช้ฟังก์ชัน (Function Calling) ที่โดดเด่น มีตัวอย่างการใช้งานร่วมกับ LangChain และ LlamaIndex จำนวนมาก มีการสะสมองค์ความรู้ในการสร้าง RAG Pipeline และมีระบบนิเวศ (Ecosystem) ที่เติบโตเต็มที่
• Claude (Anthropic): มี Context Window ขนาดใหญ่มาก จึงมีจุดแข็งในสถานการณ์ที่ต้องจัดการกับเอกสารยาวๆ ในคราวเดียว อีกทั้งยังมีการออกแบบที่เน้นความซื่อตรงต่อคำสั่ง (Instruction Following) และความปลอดภัย
• Gemini (Google): มีความเข้ากันได้สูงกับ Google Workspace และโครงสร้างพื้นฐานด้านการค้นหา (Search Infrastructure) รวมถึงรองรับมัลติโมดัล (Multimodal) ได้อย่างครบถ้วน คุณภาพในการประมวลผลภาษาญี่ปุ่นก็มีแนวโน้มที่ดีขึ้นเรื่อยๆ

ประเด็นที่ควรตรวจสอบเมื่อเลือกใช้:

• เอกสารเป้าหมายเป็นแบบยาวหรือสั้น (หากเป็นเอกสารยาว โมเดลที่มี Context Length มากกว่าจะได้เปรียบ)
• ต้นทุนในการบูรณาการเข้ากับโครงสร้างพื้นฐานและเฟรมเวิร์กที่มีอยู่
• สัดส่วนของเอกสารภาษาญี่ปุ่น (คุณภาพการรองรับภาษาญี่ปุ่นมีความแตกต่างกันในแต่ละโมเดล)
• โครงสร้างราคา (ควรตรวจสอบหน้าเว็บไซต์ราคาอย่างเป็นทางการของแต่ละบริษัทเพื่อใช้เป็นข้อมูลอ้างอิง ณ เวลาที่เขียน)

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

รูปแบบความล้มเหลวทั้ง 10 ประการที่อธิบายมาข้างต้นนั้น แฝงตัวอยู่ในแต่ละเฟสของการออกแบบ การนำไปใช้งาน (Implementation) และการดำเนินงาน (Operation) การใช้วิธีค่อยเป็นค่อยไปโดยใช้รายการตรวจสอบ (Checklist) ในแต่ละเฟสจะมีความเป็นไปได้จริงมากกว่าการพยายามแก้ไขทุกอย่างในคราวเดียว

การใช้เฟรมเวิร์กการประเมินผลอย่าง RAGAS หรือ TruLens เพื่อทำการประเมินเชิงปริมาณโดยผสมผสานตัวชี้วัดหลายด้าน เช่น Retrieval Accuracy, Answer Relevancy และ Faithfulness กำลังกลายเป็นมาตรฐาน การวัดค่า Baseline ก่อนนำไปใช้งานจริงจะช่วยให้การหมุนวงจรการปรับปรุงทำได้ง่ายขึ้น

ประเด็นสำคัญในการใช้รายการตรวจสอบมีดังนี้:

• เฟสการออกแบบ: ตรวจสอบขนาดของ Chunk, ความกว้างของ Overlap และความเหมาะสมทางภาษาของ Embedding Model
• เฟสการนำไปใช้งาน: ตรวจสอบความเป็นไปได้ในการนำ Hybrid Search มาใช้, การมีหรือไม่มี Re-ranking และขีดจำกัดความยาวของ Prompt
• เฟสการดำเนินงาน: ทบทวนความถี่ในการอัปเดต Index, ระบบการติดตามตัวชี้วัดการประเมินผล และสถานการณ์การปะปนกันของเอกสารหลายภาษาอย่างสม่ำเสมอ

สิ่งที่มักถูกมองข้ามโดยเฉพาะคือ "การติดตามผลอย่างต่อเนื่องในเฟสการดำเนินงาน" เนื่องจากทุกครั้งที่มีการอัปเดตเอกสาร Index มักจะล้าสมัยและคุณภาพของคำตอบจะค่อยๆ เสื่อมถอยลงอย่างเงียบๆ การสร้างกลไกตรวจสอบคุณภาพไว้ในระบบจะนำไปสู่การทำงานที่เสถียรในระยะยาว

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