oreilly-retrieval-augmented-gen-ai
O'Reilly 讲师 Sinan Uozdemir 打造的 RAG+GraphRAG 全链路实战教程，配套 Jupyter Notebook 从向量检索讲到知识图谱增强生成
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
O'Reilly 讲师 Sinan Uozdemir 打造的 RAG+GraphRAG 全链路实战教程，配套 Jupyter Notebook 从向量检索讲到知识图谱增强生成
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象一个场景：你问 AI 助手"今天A股涨跌幅最大的板块是什么"，AI 却一本正经地胡编数据——这就是大语言模型（LLM）的知识截止问题。解决这个问题的主流方案，就是检索增强生成（Retrieval-Augmented Generation，RAG）——让AI在回答前先去外部知识库查资料，再结合实时数据生成答案，而不是靠"记忆"硬撑。
sinanuozdemir/oreilly-retrieval-augmented-gen-ai 正是这样一个RAG+AI Agents 全链路实战教学仓库，由 O'Reilly 平台签约讲师 Sinan Uozdemir 创建和维护。Sinan 是自然语言处理领域的实践派，专注于将学术前沿落地为可运行代码。本仓库配套 O'Reilly 视频课程与他的新书，面向有一定 Python 基础的开发者，系统讲解如何让 LLM 接入真实数据源。
简单来说，这个仓库的作用是：给 AI 装上"实时数据检索"的装备包。它不只是一个工具库，更是一套由浅入深的学习路径，从最基础的向量检索讲起，一路延伸到 GraphRAG 知识图谱增强检索、Agentic RAG 自动化代理、以及多模态图片检索。
第一个 notebook RAG_Retrieval.ipynb 聚焦 RAG 的检索侧，讲解向量数据库（Vector Database）的核心概念。Sinan 使用 Pinecone 作为向量数据库存储文档嵌入（Embedding），结合 OpenAI 的 text-embedding-3-small 模型将文本转为高维向量。当用户提问时，系统先将问题本身也转为向量，然后在 Pinecone 中做相似度最近邻搜索（ANN Search），找到语义最相关的 Top-K 文档片段。
这个环节的关键在于理解：RAG 的效果上限由检索质量决定。Sinan 在 notebook 中演示了不同的分块策略（chunking strategy）如何影响检索精度——块太大容易引入噪声，块太小则丢失上下文。
图1：Sinan Uozdemir 的 O'Reilly 新书，系统讲解 LLMs 实用指南
第二个 notebook RAG_Generate.ipynb 展示了完整的 RAG 问答流程：在检索到相关文档后，将其作为上下文（Context）注入 LLM 的提示词（Prompt），引导模型基于真实数据而非训练知识作答。Sinan 设计了一个结构化的提示模板，包含了日期上下文、检索到的内容块、置信度评分（Context Score）以及一个 Agent Thought 字段，让模型先"思考"检索结果是否足以回答问题，再决定是生成答案还是回复"信息不足"。
这种设计反映了 RAG 系统设计中的核心权衡：何时信任检索结果，何时拒绝回答。直接让 LLM 看到什么就答什么，容易产生幻觉（hallucination）；但过度保守又会让系统失去实用性。
第三个 notebook 探讨了 RAG 输出的评估问题。Sinan 提出用 Rubric（评分量规）来结构化评估 LLM 的生成质量：预先定义评分维度（如准确性、相关性、完整性），LLM 在生成答案后再根据这些维度给自己打分。这是一个巧妙的"LLM 自我评估"思路，评估结果可用于指导 Prompt 优化或检索策略调整。
LangGraph_RAG.ipynb 引入了 LangGraph，这是 LangChain 生态中的工作流编排工具，专门用于构建有状态的、多步骤的 LLM 应用。Sinan 在 notebook 中演示了如何用 LangGraph 将 RAG 流程建模为一个状态机：检索 → 评分 → 判断 → 生成（或拒绝），每一步都维护一个共享状态（State），支持条件分支和循环。
这种编排方式的强大之处在于：真实场景中的 RAG 很少是单轮检索就完事的，往往需要多次迭代检索（比如 HyDE 假设性文档检索）、结果重排序（Reranking）等步骤。LangGraph 让这些复杂逻辑变得可视化、可维护。
GraphRAG.ipynb 是仓库中最进阶的部分，引入了**知识图谱（Knowledge Graph）**来增强 RAG 的检索能力。传统向量检索只考虑语义相似度，而 GraphRAG 还利用了实体之间的结构关系——比如"苹果公司成立于1976年"这条知识里，实体是"苹果公司"和"1976年"，关系是"成立于"。
Sinan 使用 Neo4J 作为图数据库存储实体和关系，结合 Cohere 的 Re-Rank 做结果重排序，用 GPT-4o 作为 LLM 引擎。当用户提问时，系统不仅做向量检索，还会查询知识图谱中相关的实体路径，捕捉那些"语义相近但表达不同"的相关信息——比如问"苹果公司创始人"，能召回"Steve Jobs"相关信息，即使文档中没出现"苹果"这个词。
仓库的 fastapi/ 目录提供了一个可运行的 RAG 聊天应用，架构非常清晰。
后端（FastAPI） — app.py 文件约 150 行，核心逻辑：使用 Pinecone Python 客户端连接向量数据库，执行 ANN 检索；用 OpenAI Embedding API 生成查询向量；用 OpenAI Chat API（gpt-4o）结合检索上下文生成回答。定义了 OpenAIChatLLM 类封装 LLM 调用，支持温度（temperature）参数；定义了 /process_text API 端点，接收用户输入、多轮对话 ID、阈值参数，返回生成结果和更新后的对话 ID；支持基于 Pinecone 的会话管理（conversation_id），实现多轮上下文记忆。
前端（Streamlit） — chat.py 文件约 60 行：用 Streamlit 构建了一个简洁的 Web 聊天界面，每个对话自动生成 UUID 作为 conversation_id，用户输入通过 requests.post 调用 FastAPI 后端，渲染回复消息。
# chat.py 核心调用逻辑
payload = {
"text": user_input,
"temperature": 0.1,
"threshold": 0.3,
"conversation_id": st.session_state["conversation_id"]
}
response = requests.post("http://localhost:8000/process_text", json=payload)
这种 FastAPI + Streamlit 的组合在 AI 原型开发中非常流行——FastAPI 提供结构化的 REST API，Streamlit 快速搭 Web UI，无需前端经验。两者都支持热重载，开发体验友好。
仓库的 requirements.txt 列出了丰富的依赖，揭示了项目的多模型策略：openai / anthropic / google-generativeai 对接 OpenAI GPT、Anthropic Claude、Google Gemini 三大闭源 API；cohere 提供 Embedding + Re-Rank 服务；pinecone-client / pinecone 是向量数据库双版本客户端；langchain / langchain-openai 是 LangChain 框架及 OpenAI 集成；sentence-transformers 支持开源 Embedding 模型（本地部署选项）；ollama-python 支持 Ollama 本地 LLM 调用；supabase 提供可选的后端即服务。
值得注意的是，ollama-python 的存在说明项目也支持本地部署 LLM，不完全依赖商业 API。这为有隐私要求或希望控制成本的团队提供了灵活性——可以用 Ollama 本地运行 Llama、Mistral 等开源模型。
适合谁学： 有一定 Python 基础，了解机器学习基本概念，最好接触过 LangChain 或类似 LLM 编排框架。完全零基础的话会有些吃力。
学习路径建议： 先跑通 RAG_Retrieval.ipynb + RAG_Generate.ipynb，理解 RAG 基本原理；读 LangGraph_RAG.ipynb，理解工作流编排如何让 RAG 更可控；最后啃 GraphRAG.ipynb，感受知识图谱带来的检索质量提升；用 fastapi/ + chat.py 部署一个自己的 RAG 聊天机器人。
本地运行步骤： git clone 后配置 .env（填写 OpenAI、Pinecone、Anthropic 等 API Key），pip install -r requirements.txt，然后启动 jupyter notebook 即可。
图2：可通过 Intro 平台预约 Sinan 的 1:1 辅导
值得坦诚的是，这个仓库并非生产级系统。
依赖商业 API 的代价：项目需要同时配置 OpenAI、Pinecone、Anthropic、Cohere、Google 等多个商业服务，API 调用成本不可忽视。在生产环境中，换用开源替代（如 Qdrant 替代 Pinecone、Ollama 替代 GPT-4o）需要进行较多代码修改。
无容器化支持：仓库没有提供 Dockerfile 或 docker-compose.yml，无法一键部署。对于不熟悉 Python 环境配置的开发者而言，光是配置虚拟环境、安装依赖、处理 Python 版本（推荐 3.13.11）就可能劝退不少人。
GraphRAG 复杂度较高：Neo4J 图数据库的部署和维护本身就有一定门槛，加上 Cohere Re-Rank 服务，学习曲线比较陡峭。
缺乏测试覆盖：仓库主要是 Jupyter Notebook 的教学代码，没有配套的单元测试或集成测试。如果要基于此做二次开发，缺乏回归测试保障。
从行业视角看，这个仓库的价值不仅在于代码本身，更在于它的教学设计。RAG 作为一个快速演进的领域，官方文档往往是碎片化的，而这个仓库将 RAG 从入门到 GraphRAG 串联成了一条清晰的学习路径。每一步都有可运行的代码、清晰的解释和直观的可视化结果。
RAG 领域的核心趋势之一就是多模态和结构化知识融合。GraphRAG 正是这一趋势的典型代表——用知识图谱补充向量检索，用 Re-Rank 优化结果排序，用多 Agent 协作处理复杂查询。这个仓库将这些前沿技术拆解成了可学习的模块，对于想深入 RAG 领域的开发者来说是难得的优质资源。