LangChain

🎁 一、30 天成果回顾 我们已构建一个功能完备的 RAG 系统，包含： 表格 模块 技术栈 功能 文档处理 PyPDFLoader + RecursiveTextSplitter PDF/Word

📡 一、为什么 RAG 需要监控？ 上线后的 RAG 系统如同“黑盒”： ❌ 用户反馈“变慢了”，但不知道哪一环出问题 ❌ 向量库突然查不到结果，却无告警 ❌ LLM 响应时间飙升，运维后知后觉 后果

⚡ 一、为什么 RAG 需要性能优化？ 一个典型 RAG 请求耗时分解： Embedding 生成：300~800ms（CPU） 向量检索：50~200ms（Milvus/PGVector） LLM

🔒 一、为什么 RAG 需要安全加固？ RAG 系统连接企业知识库，一旦被攻破： ❌ 提示注入：用户诱导 AI 执行越权操作 ❌ 数据泄露：AI 泄露检索到的敏感片段 ❌ 越权访问：普通员工查高管薪酬

📊 一、为什么需要 RAG 评估？ 很多团队部署 RAG 后只做“人工抽查”： “AI 回答看起来挺对” “用户没投诉，应该没问题” 但隐藏风险巨大： ❌ 幻觉：编造政策条款 ❌ 漏检：未召回关键文档

🚀 一、为什么需要升级向量数据库？ 在 Day 17–19 中，我们使用 Chroma 快速构建了本地 RAG。 但它不适合生产环境： 表格 问题 Chroma 生产级方案 数据规模 <10万条 ✅ 

🧠 一、为什么需要 Plan-and-Execute？ ReAct Agent（Day 23）虽强，但面对复杂任务仍显不足： ReAct 可能： ❌ 直接编造内容（无真实数据） ❌ 顺序混乱（先写计划

📚 一、为什么需要长文档处理？ Qwen 7B 的上下文窗口约 32K tokens（≈2万汉字），看似很大，但： 一份技术白皮书 ≈ 50K tokens 公司年度报告 ≈ 100K+ tokens

🤖 一、为什么需要 Function Calling？ 普通聊天机器人只能“说”，但企业需要 AI 能“做”： “帮我查订单 1001 的状态” “如果已发货，发邮件通知客户” “顺便查下今天北京天气

💭 一、为什么需要 Memory？ 没有记忆的 AI 像“金鱼”： 用户：“帮我查订单 1001” AI：“订单 1001 已发货。” 用户：“那物流单号是多少？” AI：“请提供订单号。” 问题：A

🔌 一、为什么需要自定义 Retriever？ 在 Day 17–19 中，我们使用 Chroma 作为向量库。 但真实企业环境往往已有成熟检索系统： 📈 Elasticsearch：公司全文搜索引擎

🎯 一、为什么需要 RAG 优化？ 在 Day 18 中，我们构建了基础 RAG 系统，但它存在检索瓶颈： ❌ 单一向量检索可能漏掉关键文档 ❌ 相似度高的片段未必最相关（语义鸿沟） ❌ 用户问题表述

🔗 一、RAG 是什么？为什么重要？ RAG = Retrieval-Augmented Generation（检索增强生成） 传统 LLM 的问题： ❌ 知识截止（如 Qwen 训练数据止于 202

🔍 一、为什么需要向量数据库？ 在 Day 16 中，我们把 PDF、Word 等文档转成了文本块（chunks）。 但如何快速找到与用户问题最相关的片段？ ❌ 关键词搜索：“退货” → 找不到“如何

📚 一、为什么需要 Document Loaders？ 在构建 RAG（检索增强生成）系统时，第一步永远是：把非结构化数据变成纯文本。 但现实中的知识分散在： 📄 PDF 技术手册 📝 Word 产品

⚡ 一、为什么需要流式响应？ 传统 AI 调用是“全有或全无”： 用户提问 → 等待 5 秒 → 一次性返回全部答案 问题： 用户焦虑：“AI 是不是卡了？” 长回答体验差（如生成 500 字文章）

🔍 一、为什么需要 Callback？ 当你在生产环境部署 AI 应用时，会面临这些问题： 调试困难：AI 返回错误，但不知道中间哪步出问题 无法监控：不知道 LLM 调用耗时、token 消耗 安全

🎯 一、为什么需要“带重试的结构化输出”？ 在 Day 6 中，我们用 PydanticOutputParser 让 AI 输出合法 JSON。 但现实是：即使加了格式指令，大模型偶尔仍会“跑偏” ：

🔧 一、为什么需要自定义 Tool？ 内置工具（如搜索、维基）很好用，但真实业务需求千奇百怪： “查一下订单号 12345 的物流状态” “给用户张三发一条短信提醒” “重启测试环境的 Web 服务”

🧰 一、为什么用内置 Tools？ 在 Day 10 中，我们手动写了 Calculator 工具。但 LangChain 社区已封装了数十种常用工具，开箱即用： 表格 工具 功能 适用场景 Duck