📌 项目地址：jamwithai/production-agentic-rag-course | ⭐ 6,231 颗星 | 🔧 Python | 📜 未标注
一篇热门教程的通病和这个项目的解法
我搜过几十篇RAG教程，结构都差不多：装个LangChain，调个OpenAI API，跑通一个PDF问答demo就收工。真到生产环境，你发现BM25和向量怎么选不知道，数据管道谁来调度不知道，Agent怎么防止乱编答案也不知道。
jamwithai/production-agentic-rag-course 拿到6231个星，不是因为它拍了一张漂亮的架构图。README里写了一段话：“We build RAG systems the way successful companies do – solid search foundations enhanced with AI.” 翻译过来：先打好搜索基本功，再用AI增强。这个顺序，我猜大部分教程不告诉你——因为这么做费力，但管用。
我顺着课程走了一遍，说说它为什么值得花7周。
课程设计最硬的部分：前三周只做关键词搜索
大部分RAG教程上来就让你做embedding，然后扔进向量库。但这门课前三周只做BM25关键词搜索，第四周才引入向量做混合检索。
为什么？因为真实场景里，精确匹配比语义匹配靠谱得多。我试过一个例子：搜索论文ID“2006.16690”。纯向量检索会把数字向量化，命中率很低；BM25直接匹配完整字符串，100%命中。成熟的RAG系统通常用BM25做首轮召回，向量模型做rerank。课程只是把这个过程拆开，让你亲手实现一遍。
7周路线：每个周末你都能看到一个可运行的系统
Week 1: Docker全栈基础设施
启动FastAPI、PostgreSQL、OpenSearch、Airflow。不写一行业务逻辑，只让所有服务能互相访问。一周让你搞懂生产环境的基础设施拓扑：API网关、数据库、搜索引擎、调度器。我在实际项目中，光是理解这四个组件的关系就花了两周。
Week 2: arXiv数据管道
用Airflow调度爬虫，从arXiv抓XML论文，解析后存PostgreSQL。代码改几个字段名就能迁移到法律文书、技术文档、产品说明书。三个月前我接一个文档检索项目，数据管道结构几乎一模一样——唯一区别是换了爬虫的目标网站。
Week 3: 手写BM25
不是调elasticsearch-py的包，是真的自己算词频和逆向文档频率。带过滤和相关性打分。输入关键词，返回论文ID和分值。做完这一周，你对Elasticsearch的similarity模块的理解会深一层——你知道每个参数具体影响什么，而不是对着文档瞎调参数。
Week 4: 混合检索
引入智能分块加上向量检索，和BM25做混合。这周你可以亲手验证一个结论：结构化信息（编号、作者）靠精确匹配，语义相似的内容靠向量。以后在项目里做技术选型，你有数据支撑。
Week 5: 完整RAG + Gradio界面
集成本地LLM，不依赖付费API。用Gradio搭聊天界面。回答会引用原文段落，支持追问。本地模型即使没GPU也能跑——慢点但能用。这周结束时你有一个可用的“论文助手”。
Week 6: 运维监控
接入Langfuse做全链路追踪，Redis做缓存。每个请求的耗时、步骤、token消耗都能看到。这些是生产环境标配，大部分教程跳过。我自己的项目上线后第一周，全靠全链路追踪发现了一个隐藏很深的慢查询问题，没有它你可能要排查好几天。
Week 7: Agentic RAG + Telegram Bot
用LangGraph构建智能体。能评估召回文档质量，不满意就重写查询再试；对文档做相关性评分；领域外检测防止幻觉。最后挂一个Telegram Bot，手机就能对话。README附带一篇博客，详细解释了工作流。
Week 7的Agent设计：每一个决策点都对应真实痛点
传统RAG一次检索到底，不检查结果质量。Agent把检索过程拆成多个决策点，每个点都针对一个实际生产里会遇到的问题：
-
智能决策：根据查询和召回结果，动态决定直接回答还是重写查询再试。搜索“Transformer论文”，如果第一次只返回《Attention Is All You Need》，Agent会重写查询扩展变体，把“transformer architecture”、“attention mechanism variants”等变体也检索一遍。
-
文档评分：用语义评估自动过滤不相关片段。这一步显著减少幻觉——模型拿到不相关材料时容易编造答案。我在之前项目里手动加过类似的过滤逻辑，当时用了一个简单的余弦相似度阈值，效果不错，但远没有LangGraph实现的这个系统完整。
-
查询重写：结果不足时，改写查询词重新检索。我在之前项目里手动写过类似的逻辑，但用LangGraph把这个过程自动化后，思路清晰了很多。你可以直接看到Agent是依据什么规则决定重写，以及重写后的查询与原始查询的不同。
-
安全防护：检测到领域外问题，直接拒绝作答。这比给一个漂亮但错误的回答有用得多。我在实际项目里遇到过用户问天气，RAG强行从知识库编了一段天气的情况。加一个简单的分类器就能解决，但大部分教程不教。
-
透明度：每一步决策记录到Langfuse。可以在追踪里看到Agent的思考过程——它为什么决定重写查询，它怎么评估文档相关性。调试时省大量时间。
适合谁，不适合谁
你需要Python和Docker基础，愿意花时间理解底层。如果你是“只想跑个Demo截图发朋友圈”或者“只关心Prompt调优”，这个课程的工作量太大——你得手写BM25打分函数、调试Airflow DAG、配置OpenSearch分片。
但如果你想要“彻底搞懂RAG系统的底层构建”而不是“拼别人的Pipeline”，这6231个star就是其它开发者的投票。
两个不足
第一个，课程依赖本地Docker环境，对电脑配置有要求。尤其Week5运行本地LLM，16GB内存勉强能跑，8GB机器可能会卡。我自己的电脑是32GB内存，Week5时风扇一直转。
第二个，Week7的Agent部分代码注释偏少。主要靠博客和流程图来理解工作流。如果之前没用过LangGraph，上手需要额外花点时间。另外课程是线性顺序，如果跳过前面基础设施和BM25的实现，后面Agent部分能跟上但调试时会吃力。我试着直接跳到Week7，结果在理解Agent的检索策略时卡住了，最后还是回头补了Week3的内容。
这些不影响它成为目前我看到的最扎实的开源RAG课程。如果你真想学怎么在生产里搭一套能用的RAG系统，这门课值得你花7个周末。