# How to Master RAG and Build AI Agents That Remember Everything (Full Course)
**作者**: Khairallah AL-Awady
**日期**: 2026-05-01T09:28:47.000Z
**来源**: [https://x.com/eng_khairallah1/status/2050145400204783631](https://x.com/eng_khairallah1/status/2050145400204783631)
---
There is one problem that kills most AI Agents before they ever reach production.
Save this :)
The model does not know your data.
It does not know your company's products. It does not know your documentation. It does not know your customer history. It does not know anything that is not in its training data.
And for most business applications, the value lives entirely in YOUR data. Not the internet's data. Yours.
RAG (Retrieval-Augmented Generation) fixes this. It gives any AI model access to your specific data - documents, databases, knowledge bases, wikis, transcripts - and lets it answer questions and complete tasks using that data as its source of truth.
Without RAG, your AI assistant is a well-read stranger. With RAG, it is a colleague who has read every document your company has ever produced.
This course teaches you RAG from the ground up. By the end, you will be able to build AI Agents that answer from YOUR data with accuracy and citations.
# What RAG Actually Does (In Plain English)
Imagine you ask Claude: "What is our refund policy for enterprise customers?"
Without RAG, Claude does not know your refund policy. It will either say "I do not know" or hallucinate something that sounds plausible but is wrong.
With RAG, your application does this:ƒA
Step 1: Takes your question and converts it into a mathematical representation (an embedding) that captures its meaning.
Step 2: Searches through your document collection to find the chunks that are most relevant to your question - your refund policy document, your enterprise terms of service, your customer support guidelines.
Step 3: Passes those relevant chunks to Claude along with your question.
Step 4: Claude reads the relevant documents and answers your question based specifically on what those documents say.
The result: an accurate, grounded answer based on your actual documentation, with the ability to cite exactly where the information came from.
RAG does not fine-tune the model. It does not change the model at all. It changes what information the model has access to at the moment it generates a response. Think of it like giving someone a reference book before asking them a question - they do not memorize the book, they look up the relevant sections.
# The RAG Pipeline: 5 Stages
Every RAG system follows the same pipeline. Understanding these five stages is the foundation for building any RAG application.
# Stage 1: Document Ingestion
Your data lives in many formats - PDFs, Word documents, web pages, databases, spreadsheets, Slack messages, email archives. Before RAG can use this data, it needs to be converted into a format the system can process.
The ingestion process:
Collect your source documents from wherever they live. Convert everything to plain text. PDFs need text extraction. Word documents need parsing. Web pages need HTML stripping. Databases need query export.
Clean the text. Remove headers, footers, navigation elements, and formatting artifacts that add noise without adding meaning.
Chunking - the most important decision in your entire RAG system.
Your documents need to be split into smaller chunks because models have context limits and because smaller, focused chunks produce more precise search results than entire documents.
Chunking strategies:
Fixed-size chunks: Split text every 500 tokens. Simple but can split mid-sentence or mid-paragraph, breaking meaning.
Semantic chunks: Split at natural boundaries - paragraph breaks, section headers, topic transitions. Preserves meaning but produces uneven chunk sizes.
Recursive chunking: Try to split at paragraphs first. If a chunk is still too large, split at sentences. If still too large, split at a fixed character count. Best general-purpose approach.
Overlapping chunks: Each chunk overlaps with the previous one by 50 to 100 tokens. Ensures that information spanning a chunk boundary is not lost. Slightly increases storage but significantly improves retrieval quality.
The sweet spot for most Agents: 300 to 500 tokens per chunk with 50 to 100 tokens of overlap. Too small and chunks lack context. Too large and search results are diluted with irrelevant information.
# Stage 2: Embedding
Each chunk needs to be converted into a vector - a mathematical representation that captures its meaning. This is called embedding.
Two chunks that discuss similar topics will have similar vectors, even if they use completely different words. The embedding captures meaning, not just keywords.
Which embedding model to use:
For most applications, use an established embedding model like text-embedding-3-small from OpenAI or the equivalent from your preferred provider. These produce high-quality embeddings at low cost.
For specialized domains (medical, legal, financial), consider domain-specific embedding models that are trained on text from that field. They understand domain vocabulary and relationships better than general models.
Embed every chunk and store the vector alongside the original text. You will need both: the vector for searching, the text for passing to the model.
# Stage 3: Storage
You need a place to store your chunks and their vectors. This is called a vector database.
Options by complexity:
For learning and small projects: Chroma. Open-source, runs locally, simple API, perfect for getting started.
For production applications: Pinecone, Weaviate, or Qdrant. Managed services that handle scaling, backups, and performance optimization.
For existing PostgreSQL users: pgvector extension. Add vector search to your existing database without deploying a separate system.
Your vector database stores each chunk as a record with the original text, the embedding vector, and metadata (source document name, page number, section, date, and any other attributes useful for filtering).
# Stage 4: Retrieval
When a user asks a question, the retrieval stage finds the most relevant chunks from your database.
The process:
Embed the user's question using the same embedding model you used for your documents. Search the vector database for the chunks whose embeddings are most similar to the question embedding. Return the top 3 to 10 most relevant chunks.
Improving retrieval quality:
Hybrid search: Combine vector similarity search with traditional keyword search. Some questions are best answered by semantic similarity, others by exact keyword matches. Hybrid search covers both cases.
Metadata filtering: Before searching, filter by relevant metadata. If the user asks about a specific product, only search chunks from that product's documentation. If they ask about a recent policy, filter by date. Fewer, more relevant chunks beat more, less relevant chunks.
Re-ranking: After the initial retrieval, run a second pass that re-ranks the results by relevance. Cross-encoder models are excellent at re-ranking because they evaluate the relevance of each chunk in the context of the specific question.
# Stage 5: Generation
The final stage passes the retrieved chunks to Claude along with the user's question and a system prompt that instructs Claude to answer based on the provided documents.
The system prompt structure:
```
You are a helpful assistant that answers questions based on
the provided context documents.
Rules:
- Answer ONLY based on information in the provided context
- If the context does not contain enough information to answer
the question fully, say so explicitly
- Cite the source document for every claim you make
- Never make up information that is not in the context
- If the context contains conflicting information, present
both perspectives and note the conflict
Context documents:
{retrieved_chunks}
User question: {question}
```
The explicit instruction to answer only from the context is critical. Without it, Claude will supplement with its general knowledge, which may be outdated or incorrect for your specific domain.
# Building Your First RAG Application
Here is the minimum viable RAG system. Build this first, then add sophistication.
Step 1: Collect 10 to 20 documents from your domain. Product documentation, FAQs, policy documents - whatever your users would ask questions about.
Step 2: Chunk the documents using recursive chunking with 400-token chunks and 100-token overlap.
Step 3: Embed each chunk using an embedding API. Store the chunks and vectors in Chroma.
Step 4: Build the retrieval function that embeds a query, searches Chroma for the top 5 most similar chunks, and returns them.
Step 5: Build the generation function that takes the retrieved chunks and the user's question, constructs the prompt with the system prompt above, and sends it to Claude.
Step 6: Build a simple interface - a text input for questions and a display area for answers. Use Next.js or even a simple command-line interface.
Step 7: Test with 20 questions that you know the answers to. Compare the system's answers against the correct answers. Identify where it fails and why.
This minimum system takes a weekend to build. It will not be perfect. But it will work, and every improvement you make from here is incremental.
# The 5 Most Common RAG Failures (And How to Fix Each One)
Failure 1: Wrong chunks retrieved.
The system returns chunks that are not relevant to the question. The answer is either wrong or generic.
Fix: Improve your chunking strategy. If chunks are too large, they contain too much irrelevant information alongside the relevant part. If they are too small, they lack sufficient context. Experiment with chunk sizes. Add metadata filtering to narrow the search space. Implement hybrid search to catch keyword-specific queries that vector search misses.
Failure 2: Answer not in the retrieved chunks.
The answer exists in your documents, but the relevant chunk was not in the top results.
Fix: Increase the number of chunks retrieved (from 5 to 10 or 15). Implement re-ranking to push the most relevant chunks to the top. Check if your chunking strategy splits the relevant information across two chunks - if so, increase overlap.
Failure 3: Hallucination despite having context.
Claude generates information that is not in the provided context, presenting it as if it came from your documents.
Fix: Strengthen the system prompt. Be extremely explicit: "Answer ONLY from the provided context. If the answer is not in the context, say 'This information is not available in the provided documents.'" Add a verification step where Claude quotes the specific passage it is basing each claim on.
Failure 4: Duplicate chunks inflating results.
Multiple copies of the same information appear in the retrieved chunks, pushing out other relevant chunks.
Fix: Add deduplication during ingestion. Hash each chunk and skip duplicates. During retrieval, check for near-duplicate results and remove them before sending to the model.
Failure 5: Stale data.
Your documents change but your vector database still contains old versions.
Fix: Implement a refresh pipeline. When source documents are updated, re-ingest and re-embed the changed documents. Track document versions with metadata. For frequently changing data, schedule regular refresh cycles - daily for fast-changing content, weekly for stable content.
# From MVP to Production
Your weekend RAG system works. Here is how to make it production-grade:
Add authentication. Users should be able to create accounts and access only documents they are authorized to see. Document-level access control is critical for any business application.
Add source citations. Every answer should include links or references to the specific source documents. This builds trust and allows users to verify information.
Add feedback collection. Let users rate answers as helpful or not helpful. Use this feedback to identify which documents need better chunking, which questions fail consistently, and where new documentation is needed.
Add monitoring. Track query volume, retrieval quality, answer quality, latency, and error rates. This data drives continuous improvement.
Add a document update pipeline. When source documents change, your RAG system should automatically detect the changes, re-process the modified documents, and update the vector database.
# The Bottom Line
RAG is the bridge between general AI and YOUR specific domain. Without it, AI gives generic answers. With it, AI gives answers grounded in your actual data.
The pipeline is straightforward: ingest documents, chunk them, embed them, store in a vector database, retrieve relevant chunks for each query, and generate answers from those chunks.
Build the minimum viable system this weekend. Test it. Fix the failures. Add production features incrementally.
Every business has knowledge trapped in documents that nobody reads. RAG turns that trapped knowledge into an AI system that answers questions instantly and accurately.
The businesses that build RAG systems now will have a knowledge advantage that compounds every day as they add more documents.
Follow me @eng_khairallah1 for more technical deep-dives, building guides, and AI architecture breakdowns.
hope this was useful for you, Khairallah ❤️
## 相关链接
- [Khairallah AL-Awady](https://x.com/eng_khairallah1)
- [@eng_khairallah1](https://x.com/eng_khairallah1)
- [13K](https://x.com/eng_khairallah1/status/2050145400204783631/analytics)
- [@eng_khairallah1](https://x.com/@eng_khairallah1)
- [5:28 PM · May 1, 2026](https://x.com/eng_khairallah1/status/2050145400204783631)
- [13K Views](https://x.com/eng_khairallah1/status/2050145400204783631/analytics)
- [View quotes](https://x.com/eng_khairallah1/status/2050145400204783631/quotes)
---
*导出时间: 2026/5/1 21:23:25*
---
## 中文翻译
# 如何精通 RAG 并构建能记住一切的 AI 智能体（完整教程）
**作者**: Khairallah AL-Awady
**日期**: 2026-05-01T09:28:47.000Z
**来源**: [https://x.com/eng_khairallah1/status/2050145400204783631](https://x.com/eng_khairallah1/status/2050145400204783631)
---
有一个问题导致大多数 AI 智能体在投入生产之前就夭折了。
收藏这篇文章吧 :)
模型不了解你的数据。
它不了解你公司的产品。它不了解你的文档。它不了解你的客户历史。它不了解任何不在其训练数据中的内容。
对于大多数商业应用来说，价值完全存在于**你的**数据中。而不是互联网的数据。是你的数据。
RAG（检索增强生成）解决了这个问题。它让任何 AI 模型都能访问你的特定数据——文档、数据库、知识库、Wiki、录音稿——并允许它利用这些数据作为事实来源来回答问题和完成任务。
没有 RAG，你的 AI 助手只是一个博览群书的陌生人。有了 RAG，它就变成了一位阅读过你公司产出的所有文档的同事。
本课程将从头教你 RAG。学完后，你将能够构建能够根据**你的**数据准确回答并提供引用的 AI 智能体。
# RAG 到底是做什么的（用大白话讲）
想象一下你问 Claude：“我们要针对企业客户的退款政策是什么？”
如果没有 RAG，Claude 不知道你的退款政策。它要么会说“我不知道”，要么会臆造出一个听起来合理但却是错误的答案。
有了 RAG，你的应用会执行以下操作：
第一步：接收你的问题，并将其转换为能捕捉其含义的数学表示形式（嵌入）。
第二步：搜索你的文档集合，找到与你问题最相关的块——你的退款政策文档、你的企业服务条款、你的客户支持指南。
第三步：将那些相关的块连同你的问题一起传递给 Claude。
第四步：Claude 阅读相关文档，并根据这些文档的具体内容回答你的问题。
结果：一个基于你实际文档的准确、有依据的答案，并且能够准确说明信息来源。
RAG 不会对模型进行微调。它根本不会改变模型。它改变的是模型在生成响应那一刻所能访问的信息。你可以把它想象成在向某人提问前给他一本参考书——他们没有背下这本书，而是查阅了相关章节。
# RAG 流程：5 个阶段
每个 RAG 系统都遵循同样的流程。理解这五个阶段是构建任何 RAG 应用的基础。
# 第一阶段：文档摄取
你的数据以多种格式存在——PDF、Word 文档、网页、数据库、电子表格、Slack 消息、电子邮件存档。在 RAG 使用这些数据之前，需要将它们转换为系统可以处理的格式。
摄取过程：
从数据所在的任何位置收集源文档。将所有内容转换为纯文本。PDF 需要文本提取。Word 文档需要解析。网页需要去除 HTML。数据库需要查询导出。
清洗文本。移除页眉、页脚、导航元素和格式化残留，这些只会增加噪音而不会增加意义。
分块——这是整个 RAG 系统中最重要的决策。
你的文档需要被分割成更小的块，因为模型有上下文限制，而且与整个文档相比，更小、更聚焦的块能产生更精确的搜索结果。
分块策略：
固定大小的块：每 500 个 token 分割一次文本。简单但可能会在句子或段落中间分割，破坏含义。
语义分块：在自然边界处分割——段落分隔、章节标题、主题转换。保留含义但会产生大小不一的块。
递归分块：首先尝试在段落处分割。如果块仍然太大，则在句子处分割。如果还是太大，则按固定字符数分割。最佳通用方法。
重叠分块：每个块与前一个块重叠 50 到 100 个 token。确保跨越块边界的信息不会丢失。稍微增加存储空间，但显著提高检索质量。
大多数智能体的最佳平衡点：每个块 300 到 500 个 token，重叠 50 到 100 个 token。太小则块缺乏上下文。太大则搜索结果会被不相关的信息稀释。
# 第二阶段：嵌入
每个块都需要转换为一个向量——一个捕捉其含义的数学表示形式。这被称为嵌入。
两个讨论相似主题的块将具有相似的向量，即使它们使用的词汇完全不同。嵌入捕捉的是含义，而不仅仅是关键词。
使用哪种嵌入模型：
对于大多数应用，使用成熟的嵌入模型，例如 OpenAI 的 text-embedding-3-small 或你首选提供商的等效模型。这些模型以低成本生成高质量的嵌入。
对于专业领域（医疗、法律、金融），考虑使用在该领域文本上训练过的特定领域嵌入模型。与通用模型相比，它们更能理解领域词汇和关系。
嵌入每个块，并将向量与原始文本一起存储。你两者都需要：用于搜索的向量，以及用于传递给模型的文本。
# 第三阶段：存储
你需要一个地方来存储你的块及其向量。这被称为向量数据库。
按复杂度分类的选项：
用于学习和小型项目：Chroma。开源、本地运行、简单的 API，非常适合入门。
用于生产应用：Pinecone、Weaviate 或 Qdrant。处理扩展、备份和性能优化的托管服务。
对于现有的 PostgreSQL 用户：pgvector 扩展。在无需部署单独系统的情况下，向现有数据库添加向量搜索功能。
你的向量数据库将每个块存储为一条记录，其中包含原始文本、嵌入向量和元数据（源文档名称、页码、章节、日期以及任何其他有助于过滤的属性）。
# 第四阶段：检索
当用户提问时，检索阶段会从你的数据库中找到最相关的块。
过程：
使用你用于文档的相同嵌入模型对用户的问题进行嵌入。在向量数据库中搜索其嵌入与问题嵌入最相似的块。返回前 3 到 10 个最相关的块。
提高检索质量：
混合搜索：结合向量相似度搜索与传统关键词搜索。有些问题最好通过语义相似度来回答，有些则通过精确关键词匹配来回答。混合搜索涵盖了这两种情况。
元数据过滤：在搜索之前，按相关元数据进行过滤。如果用户询问特定产品，则仅搜索该产品文档中的块。如果他们询问最近的策略，则按日期过滤。更少、更相关的块胜过更多、不太相关的块。
重排序：在初次检索后，运行第二轮处理，按相关性重新排列结果。交叉编码器模型非常擅长重排序，因为它们会在具体问题的语境下评估每个块的相关性。
# 第五阶段：生成
最后阶段将检索到的块连同用户的问题以及一个系统提示词传递给 Claude，该系统提示词指示 Claude 根据提供的文档进行回答。
系统提示词结构：
```
你是一个基于提供的上下文文档回答问题的有用助手。
规则：
- 仅根据提供的上下文中的信息进行回答
- 如果上下文不包含足以完整回答问题的信息，请明确说明
- 为你的每一个陈述引用源文档
- 永远不要编造上下文中不存在的信息
- 如果上下文包含相互矛盾的信息，请展示两种观点并注明冲突
上下文文档：
{retrieved_chunks}
用户问题：{question}
```
明确指示仅根据上下文回答至关重要。没有它，Claude 会利用其通用知识进行补充，这对于你的特定领域来说可能已经过时或不正确。
# 构建你的第一个 RAG 应用
这是最小可行性 RAG 系统。先构建这个，然后再增加复杂度。
第一步：从你的领域收集 10 到 20 个文档。产品文档、常见问题解答、政策文档——任何你的用户可能会问的问题。
第二步：使用递归分块对文档进行分块，每块 400 个 token，重叠 100 个 token。
第三步：使用嵌入 API 嵌入每个块。将块和向量存储在 Chroma 中。
第四步：构建检索函数，该函数嵌入查询，在 Chroma 中搜索前 5 个最相似的块，并返回它们。
第五步：构建生成函数，该函数接收检索到的块和用户的问题，使用上面的系统提示词构建提示词，并将其发送给 Claude。
第六步：构建一个简单的界面——用于问题的文本输入区域和用于答案的显示区域。使用 Next.js 甚至一个简单的命令行界面。
第七步：用 20 个你知道答案的问题进行测试。将系统的答案与正确答案进行比较。找出失败的地方及原因。
这个最小系统需要一个周末来构建。它不会很完美。但它能工作，从这里开始的每一次改进都是渐进的。
# RAG 最常见的 5 种失败（以及如何修复每一种）
失败 1：检索到错误的块。
系统返回与问题不相关的块。答案要么是错误的，要么是通用的。
修复：改进你的分块策略。如果块太大，它们会在相关部分旁边包含太多不相关的信息。如果它们太小，则缺乏足够的上下文。实验不同的块大小。添加元数据过滤以缩小搜索范围。实施混合搜索以捕获向量搜索漏掉的关键词特定查询。
失败 2：答案不在检索到的块中。
答案存在于你的文档中，但相关的块不在前列结果中。
修复：增加检索到的块数量（从 5 个增加到 10 个或 15 个）。实施重排序以将最相关的块推到顶部。检查你的分块策略是否将相关信息分成了两个块——如果是这样，增加重叠。
失败 3：拥有上下文但仍产生幻觉。
Claude 生成了不在所提供上下文中的信息，并将其呈现为来自你的文档。
修复：加强系统提示词。要极其明确：“仅从提供的上下文中回答。如果答案不在上下文中，请说‘所提供的文档中没有该信息’。”添加一个验证步骤，让 Claude 引用它作为每个主张依据的具体段落。
失败 4：重复的块夸大了结果。
相同信息的多个副本出现在检索到的块中，挤占了其他相关的块。
修复：在摄取期间添加去重。对每个块进行哈希处理并跳过重复项。在检索期间，检查近似重复的结果并在发送给模型之前将其删除。
失败 5：数据过时。
你的文档发生了变化，但向量数据库仍然包含旧版本。
修复：实施刷新流程。当源文档更新时，重新摄取并重新嵌入更改的文档。使用元数据跟踪文档版本。对于频繁变化的数据，安排定期的刷新周期——对于快速变化的内容，每天一次；对于稳定的内容，每周一次。
# 从 MVP 到生产环境
你的周末 RAG 系统运行起来了。以下是如何使其达到生产级质量的方法：
添加身份验证。用户应该能够创建账户并仅访问其有权查看的文档。文档级访问控制对于任何商业应用都至关重要。
添加来源引用。每个答案都应包含指向特定源文档的链接或参考。这建立了信任并允许用户验证信息。
添加反馈收集。让用户评价答案是有帮助还是没有帮助。利用此反馈来确定哪些文档需要更好的分块，哪些问题总是失败，以及哪里需要新文档。
添加监控。跟踪查询量、检索质量、答案质量、延迟和错误率。这些数据推动持续改进。
添加文档更新流程。当源文档更改时，你的 RAG 系统应自动检测更改、重新处理修改后的文档并更新向量数据库。
# 总结
RAG 是通用 AI 和你特定领域之间的桥梁。没有它，AI 给出的是通用答案。有了它，AI 给出的是基于你实际数据的可靠答案。
流程很简单：摄取文档，分块，嵌入，存储在向量数据库中，为每个查询检索相关块，并从这些块生成答案。
这个周末构建最小可行性系统。测试它。修复失败之处。逐步增加生产功能。
每个企业都有被困在无人阅读的文档中的知识。RAG 将这些被困的知识转化为一个即时准确回答问题的 AI 系统。
现在就构建 RAG 系统的企业将拥有知识优势，随着他们添加更多文档，这种优势会每天累积。
在 @eng_khairallah1 关注我，获取更多技术深度解析、构建指南和 AI 架构拆解。
希望这对你有用，Khairallah ❤️
## 相关链接
- [Khairallah AL-Awady](https://x.com/eng_khairallah1)
- [@eng_khairallah1](https://x.com/eng_khairallah1)
- [13K](https://x.com/eng_khairallah1/status/2050145400204783631/analytics)
- [@eng_khairallah1](https://x.com/@eng_khairallah1)
- [5:28 PM · May 1, 2026](https://x.com/eng_khairallah1/status/2050145400204783631)
- [13K Views](https://x.com/eng_khairallah1/status/2050145400204783631/analytics)
- [View quotes](https://x.com/eng_khairallah1/status/2050145400204783631/quotes)
---
*导出时间: 2026/5/1 21:23:25*