RAG

https://www.cnblogs.com/huangdh/p/19176094 |langchain中的上下文压缩方案

LangChain RAG 系统实战(Qwen3 Embedding&Reranker)

复刻网站
https://github.com/JCodesMore/ai-website-cloner-template

Agent工程师，基本功反而更重要了

最近连续面了几位Agent工程师，我越来越明显地感受到：

Agent工程并没有让传统的软件工程能力失效。

并发、重试、幂等、任务调度、状态管理、故障恢复，这些能力依然决定了一个Agent系统能不能真正上线。

AI Coding也是一样。

可以让AI帮你写项目，但一定要进一步理解它为什么这么设计、解决了什么问题、还有哪些替代方案。

只有当你能脱离AI，把整个设计重新解释清楚，AI的输出才真正变成了你的经验。


Agent 系统架构选型，思路是围绕三个问题倒推，而不是背名词。 
1、任务有多复杂：简单验证用单 Agent；多步试错走上 ReAct，可解释但 token 烧得快；要工程化稳定用 Plan and Execute，先计划再执行，但计划错了会全盘重来。 
2、你要多强的控制力：复杂任务上 Multi-Agent，分工协作、上下文不串味，但成本翻倍。
最推荐的是 Router + Skill，意图路由加分诊式执行，企业级可控、好评估，代价是 skill 设计成本高、路由可能撞车。
还有 Blackboard 共享状态玩法，适合开放协作，但状态一多就很难 debug。 
3、要不要上生产：唯一正解是 Graph Workflow，用有向无环图编排，支持条件分支、并行、回溯重放，出问题能定位到具体哪一站。 一句话收束：模型负责聪明，架构负责可控，你选的从来不是架构，而是你要的控制力档位。
-----------------
1.请先主题
2.简约直白，核心分点总结，(各分点总结排版要求，①序号，②先关键词，再核心总结，③分段隔开1行)
3.视频相应核心内容，未来现实行动指南（前有序号）
4.再一句金句总述，并且给出相关网址或下载链接
@元宝 总结视频内容，详细介绍项目背景、设计思路、架构、创新点、功能和具体使用方法，以及怎么安排agent去完成PRD，分点回答


视频核心问题是：企业级RAG知识库如何实现权限隔离，确保普通员工看不到老板的机密合同？

常见错误方案：
1️⃣ 先检索后过滤：先搜top10文档再校验权限。问题：若top10全是机密文档，过滤后结果清零，大模型只能回答"不知道"。
2️⃣ 先过滤后检索：先查出几万条有权限文档ID再去向量库检索。问题：ID列表过长导致索引失效，系统卡顿宕机。
3️⃣ 多套RAG分开：机密/普通文档分两套库。问题：中大型企业会导致服务冗余、数据混乱、员工需切换多个入口。

致命误区：
⚠️ chunk级权限绑定：权限应绑定完整文档层，切片只继承父文档权限。否则会导致数据碎片泄露（用户可通过多轮问答拼凑机密文档）。
⚠️ 混淆接口鉴权与数据鉴权：网关Token鉴权只能判断能否调用服务，解决不了"能看到哪些数据"的核心问题。

终极方案：文档级元数据混合检索
✅ 入库阶段：完整文档层绑定权限元数据（部门/角色/密级），切片仅关联文档ID
✅ 查询三步走：
① 网关鉴权+秒级拉取权限标签
② 权限标签透传至向量检索接口
③ 引擎优先通过权限索引圈定合法文档池，再计算相似度

优势：既避免机密数据抢占结果，又保证高性能，同时杜绝数据碎片泄露，形成完整安全闭环。核心思路是把计算逻辑下推到引擎层，用底层索引解决精度、性能、安全三大问题。


父子分片：精准召回+背景补全
RAG里的语义分片，核心思路一句话：别急着换模型，先看看分片是不是把完整意思切散了。 具体做法分四步：
一是找边界，硬边界看标题段落列表代码块，软边界看embedding相似度突变；
二是工程化流水线，解析保留结构、归一化去噪声、按边界初切、连贯性打分修正；
三是长度只做护栏，用最小目标最大三个区间，别拿固定值硬切；gg四是上下文修复，记录章节路径页码邻居等元数据，配合父子分片，child精准命中、parent补背景。 
最后还要重组重排，按原文顺序接回上下文，用cross-encoder或LLM rerank删弱相关，
并用Recall@K、MRR、引用抽查来验证分片质量。

RAG准确性的关键不在向量模型，而在整条链路：

1、档案本身要靠谱，版本、权限、有效期、解析质量都得先管好。2、切片要合理，尽量别把一件完整的事机械切开。
3、小块找准、大块看全，用父子Chunk把精准命中和完整背景结合起来。
4、关键词加向量混合检索，一个认字、一个懂意思，互补才稳。
5、先召回再Rerank，第一轮尽量别漏，第二轮挑最相关的排到前面。
6、最后让模型基于证据回答，有依据就答，没有就坦白说没找到。

一句话总结：RAG难的不是把文档变成向量，而是让这个资料员稳定找回正确、完整、最新的事实，知识库才敢真正用起来。


大模型推理显存消耗的"三笔账"： 
1️⃣ **权重账**：参数本身占用，7B模型FP16约14GB，量化能压缩但无法消除； 
2️⃣ **KV Cache账**：上下文缓存才是真杀手，大小=层数×头数×维度×上下文长度×并发数，长文本高并发时极易爆显存； 
3️⃣ **运行账**：框架开销与批处理临时数据。 
多数人翻车因只算第一笔。优化需权衡：量化压权重、Page Attention减缓存、连续批处理调并发，
但"没有免费午餐"——省显存往往要牺牲精度或延迟。


关键字搜索 BM25 TF IDF SFD
RAG里稀疏检索和稠密检索的区别，三个重点：

1、BM25稀疏检索靠词项匹配，精准、可解释、稳定，适合专有名词、订单号、法律条款这类精确文本，
但同义词和口语化表达极差，换个说法就可能召回为空。

2、Embedding稠密检索靠语义向量，不卡字面，擅长同义改写和模糊提问，
但可解释性几乎为零，对精准字符串不敏感，还依赖领域语料。

3、BGE-M3只是把两套实现统一了，底层逻辑没变，该混合还得混合。
成熟方案是双路召回加归一化去重，再用重排模型精排，既保精准又覆盖语义


视频作者预测未来AI应用将形成模型分层体系：
3B-8B模型负责分类提取等基础任务，
14B-35B处理本地内容生产与Agent执行，
70B-120B专注复杂推理，万亿参数模型则承担研究规划等高级职能。
他认为这种分层架构才是AI普及的经济可行路径。

RAG 向量数据库选型：
一、开场
如果你是一名 Agent 开发工程师，恭喜你，钱少活多。需求是你，开发是你，技术选型还是你，锅是你背。RAG 项目一启动，第一个讨论的问题就是：向量库到底选哪个？Milvus、pgvector、Qdrant，网上一搜每个人都有自己的答案。但真正做过企业项目的人一般不会先比较产品，而是先问：我的项目到底需要什么？

二、场景一：pgvector 最省事
很多人觉得专业向量数据库一定更好，其实很多企业第一版 RAG 都会选择 pgvector。原因很简单，公司原来就在用 PostgreSQL，现在只需要安装一个插件，就拥有了向量检索能力，不用维护第二套数据库，原来的权限、备份、监控、运维流程全部继续使用。对于几十万甚至几百万条数据，性能其实已经够用。所以大家选择 pgvector，很多时候不是因为它最强，而是因为它让整个项目最省事。

三、场景二：Milvus 规模升级
那为什么后来很多企业又换成了 Milvus？不是因为 pgvector 不好，而是业务变了。去年知识库只有 20 万条，pgvector 很轻松；一年以后文档变成 3000 万条，查询量翻了几十倍。这时候不是 pgvector 不行了，而是公司已经不是去年的公司了。数据越来越大，并发越来越高，单机开始扛不住。这时候真正需要的已经不是更快，而是自动分片、高可用、水平扩容，这些能力正...


视频作者预测未来AI应用将形成模型分层体系：
3B-8B模型负责分类提取等基础任务，
14B-35B处理本地内容生产与Agent执行，
70B-120B专注复杂推理，
万亿参数模型则承担研究规划等高级职能。
他认为这种分层架构才是AI普及的经济可行路径。


Agent记忆系统设计精髓：摒弃"万能向量库"思维。核心是分层架构+三大机制：
写入策略(异步处理+信度评估)、
读取策略(按需路由)、
时间管理(双时间戳)。
这解决了精确查询与状态时序的根本难题，是生产级系统与Demo的本质区别。
--------------------
租户指的是企业入驻tenantId，用户指的是用户id。
一般ai_memory，分为个人空间和租户空间，记忆存储根据tenant_user_id隔离，这种可以解决单用户多租户的问题。
用户id和租户id根据时间+命名单调，保证分布式存储唯一。思路炒deepseekharness的

视频讲的是 Agent 多用户记忆隔离，为什么面试里只答"加个 user_id 过滤"会踩坑。

简单过滤有四个问题：
1、过滤条件容易漏，几百个接口只要一个忘加就全量泄露；
2、向量库很多是后置过滤，先全量召回再筛，别人的向量已经算进来了；
3、缓存 key 没带用户身份，A 查过 B 直接命中，串号；
4、短期上下文、长期记忆、用户画像、历史偏好混为一谈，隔离策略不能一刀切。

给出的三层兜底方案：
存储层用 Namespace 做结构性隔离，向量检索走前置过滤；
链路层框架自动注入用户身份，封装统一访问层，禁止业务代码裸调底层 SDK；
缓存层 key 强制绑定用户 ID，按用户维度管生命周期，敏感内容不缓存或极短 TTL。

另外线上还要防四个隐性泄露：全局变量禁存用户状态、SSE 流式每个连接独立持有上下文、长期记忆摘要严格按用户维度、日志脱敏不打原文。

核心一句话：隔离不能靠开发者自觉，要靠架构和框架强制保证。


企业级RAG很少直接拿用户问题去检索，因为在检索前通常会加一步"查询改写"，原因和做法主要有三点：
1、补全上下文：把"它什么时候发布的"这类依赖指代的短句，结合历史对话扩成完整问题。
2、语义归一化：用户说"VPN怎么申请"，知识库写的是"远程办公权限申请流程"，改写后更容易匹配。
3、Multi-Query多路检索：把一个问题扩展成多种说法同时查，宁可多找也不要漏。
还有个进阶玩法叫HyDE，先让大模型写一篇假设答案，再对答案做向量检索，因为文档的语义空间比短问题更好匹配。

核心一句话：RAG的上限不只是Embedding，更取决于问题本身是否"可检索"。


企业级RAG很少直接拿用户问题去检索，因为在检索前通常会加一步"查询改写"，原因和做法主要有三点： 
1、补全上下文：把"它什么时候发布的"这类依赖指代的短句，结合历史对话扩成完整问题。 
2、语义归一化：用户说"VPN怎么申请"，知识库写的是"远程办公权限申请流程"，改写后更容易匹配。 
3、Multi-Query多路检索：把一个问题扩展成多种说法同时查，宁可多找也不要漏。 
还有个进阶玩法叫HyDE，先让大模型写一篇假设答案，再对答案做向量检索，因为文档的语义空间比短问题更好匹配。 

核心一句话：RAG的上限不只是Embedding，更取决于问题本身是否"可检索"。


multiQuery 定义多个搜索方向 query rewrite

RAG里的Multi Query机制，几个要点： 
1、本质不是多生成几个问题，而是从一个用户表达扩展出多个检索方向，解决"去哪找"的覆盖问题。 
2、流程是LLM先分析意图，提取实体、属性、范围，再围绕锚点逻辑发散，分头检索后合并。 
3、和Query Rewrite不同：后者是表达对齐的翻译官，前者是空间覆盖的侦察兵。 
4、不是Query越多越好，太多会带来噪声、延迟、成本三重暴击，关键是生成哪些高质量Query。 
5、它只是RAG检索优化的一环，召回内容本身质量不行，后面生成照样出错。

RAG系统中Query改写的核心逻辑与实践方法。关键点包括：i
1）改写必要性源于用户口语与知识库书面语间的语义断层，需解决语义鸿沟、意图模糊和历史指代三大问题；
2）三层改写打法——规则改写（快速兜底）、传统NLP改写（平衡成本）、大模型改写（主流方案，含HyDE语义增强、任务分解和上下文补全三路径）；
3）工程落地三大难点：延迟问题（需微调小模型或异步流水线）、查询漂移（需语义相似度校验）、成本问题（需意图路由层）。面试回答可按"明本质-讲方案-论权衡-说闭环"四步法组织。 
关于参考资料，出于版权考虑我无法提供完整清单，但视频中提及的关键技术如HyDE、Step-back子查询、指代消解等，都是当前RAG领域的重要研究方向，建议结合具体应用场景深入探索。


Apache Tika 总结： 
1、是什么：开源内容解析工具包，专门从 PDF、Word、Excel、PPT、邮件等文件中抽取纯文本和元数据，不是编辑软件也不是搜索引擎。 
2解决什么：企业大量非结构化数据（合同、报告、邮件等）没法被数据库、搜索引擎和大模型直接读取，Tika 把格式解析统一成标准化接口，省去每种格式写一套代码的成本。 
3、怎么工作：两步，先读文件头字节识别真实类型，再自动匹配对应解析器提取文本和元数据；插件架构支持格式很广。 
4、怎么用：可嵌入 Java 程序当库调用，也可跑 Tika Server 通过 HTTP 接口调用，方便 Python 等非 Java 团队使用。 
5、亮点能力：遇到扫描版 PDF 会自动触发 OCR（如 Tesseract）识别图片文字，同时提取作者、创建时间、页数、加密状态等元数据。 
6、为什么现在更火：大模型 RAG 应用需要先把手里大量文档解析成干净文本再切片向量化，Tika 是这条流水线的前置环节；法律、金融、媒体、数据治理等传统场景也离不开。 
7、局限性：复杂表格（合并单元格、嵌套表）提取易乱序，OCR 准确率依赖原图清晰度，加密文件需先给密码，私有格式可能要自己扩展。 

一句话：它不一定出现在你的最终产品里，但往往是分析、搜索和 AI 应用前面"首先打开文档"的那个工具。


这张图核心就一句话：做RAG前先认清文档类型，别再用PyMuPDF一套抽文本走天下。
八类文档对应方案：
论文用MinerU，
合同用TextIn，
扫描件用PaddleOCR，
Office用MarkItDown，
网页用FireCrawl，
音视频用Whisper，
表格单据用MinerU或TextIn。

关键是解析对了检索才有意义。

Markdown转换工具。MinerU能将PDF等文档转结构化Markdown，如果特指微软的Markdig，它专注Markdown渲染，
而MinerU强在端到端文档解析，能把扫描件直接转成结构化数据。


Agent加RAG结合的生产级落地，核心三点： 
一、价值不在"解决幻觉"这种表层答案，而在让Agent从闭卷考生变成开卷考生，能查资料、能推理。 
二、五大工程手段：多级缓存降本提速、
三层预算模型控成本、指数退避重试保稳定、增量更新知识库、调优HNSW参数做向量检索加速。 
三、面试答题框架：先说价值，再说能力，
最后说架构，展现从demo到生产系统的设计思维。 

一句话：面试官想考察的是你能不能把玩具变成能扛流量的真实系统。

评估业务效果
全程追踪，量化评估, 可观测性和评估体系
每一次模型调用，企业关心的： Agent、模型、工具、数据和故障， 响应速度和调用成本，最终输出准确率
人机协同能力，如：发送邮件、提交审批、涉及资金的操作和隐私数据处理等高风险操作
完整的业务闭环，扎实的工程能力,自主的任务规划，规范的上下文管理,完善的监控评估体系,以及合理的人工协同机制

自主任务规划能力，自动拆解任务，自动执行,工具调用失败和的自动恢复能力, 以及结果校验
上下文工程： 当前任务、用户记忆、知识库、上下文等

AI Agent服务，不仅仅是prompt和调用LLM， 还有后端工程：
API接口， 数据库设计， 权限管理，日志追踪， 异常处理， 多用户并发
工程化 高并发分布式,超时和熔断，异常处理
milves 分布式处理


知识更新：知识扫描，知识增量更新


成本预算控制模型

向量检索优化：hwsw 索引

mock 测试服务生产环境
有状态测试和无状态测试
内存数据库和持久化数据库
高并发测试。 docker部署高并发mock

视频讲的是面试中如何回答"Agent调用外部API怎么测试"这道题，核心是用生产级思维做Mock，分五层推进： 
1、基础隔离层：和外部团队先定接口契约，再用Mock服务按契约模拟成功、失败、超时三种基本情况。 
2、异常模拟层：注入故障，比如加100到500毫秒随机延迟测超时，连续失败几次返回5xx测熔断和降级。 
3、数据一致性层：用内存数据库让Mock有状态，比如扣库存后真实减一，后续查询能拿到更新后的值。 
4、集成验证层：在测试环境部署真实服务实例，用同一套契约测试用例分别跑Mock和真实服务，对比结果。 
5、性能与稳定性层：Mock服务本身性能至少要达到Agent预期峰值的两倍，用容器化加自动扩缩容来扛高并发。 

面试回答框架可以浓缩成三步：先Mock做基础隔离，再注入异常测容错，最后用契约测试保兼容。

一句话升华就是：真正的Mock不是造假数据，而是对复杂外部世界的精准仿真。

知识AI: TrustGraph vs samntica

Semantica官方GitHub主仓库地址：https://github.com/semantica-agi/semantica。这个仓库更新活跃且文档完善，建议优先使用

视频围绕Semantica知识图谱框架展开，将官方37个Notebook拆解为六阶段十五节课。
第一阶段（第1课）介绍框架四层架构：输入层接数据、语义层提特征、存储层管数据库、输出层做可视化。
第二阶段（2-3课）覆盖九大类数据源接入，核心API为FileInspector和DocumentParser。
第三阶段（4课）讲解数据规范化五工具：文本清洗、语言检测、实体规范、日期数字标准化。
第四阶段（5-6课）详解实体抽取三种模式（pattern/LLM/混合）及关系抽取方法。
第五阶段（7-14课）包含图谱构建（自动消歧）、四种存储后端切换、图分析三算法、RAG文本分块策略、向量化原理及本体定义。第六阶段（15课）支持八种导出格式实现闭环。

参考资料仅含视频提及的官方Notebook体系，无外部文献引用。


向量坍塌指不同样本学成相似向量，语义空间失去区分能力（如猫狗汽车被挤成一团）。
三大诱因：
监督信号太弱、负样本不足、只拉近正样本。

解决路径：
1.用InfoNCE对比学习损失 
2.增加高质量负样本与Hard Negative 
3.配合温度系数调控与batch增大 
4.引入DINO/SigLIP均匀性正则。
核心原则：同类要聚、异类要散、空间需均匀。视频中未明确引用外部文献资料，主要基于实践经验总结。

SAG是新一代RAG开源解决方案，核心突破在于"存储事件化，查询图谱化"。
它将文本拆解为完整语义事件，提取多维实体作为索引，查询时通过SQL JOIN动态构建关联图谱，实现增量更新零成本。
相比传统RAG，SAG显著提升跨文档推理能力：
在三大多跳问答数据集上，Recall@2平均提升16.4%（SAG 79.30% vs HippoRAG 68.14%），
最难数据集MuSiQue提升达29.3%。已在数亿级生产环境验证，GitHub获1.6k stars。 
参考资料： 
1. 论文《SAG: Graph retrieval technology capable of running on large-scale dynamic data》(https://arxiv.org/abs/2606.15971) 
2. 开源项目地址：github.com/Zleap-AI/SAG

SAG和LightRAG的核心差异在架构思路上：
SAG采用"存储事件化，查询图谱化"，动态用SQL Join激活关联，特别擅长多跳问答（如MuSiQue数据集Recall@2提升29.3%）；
LightRAG则侧重轻量级实现，更适合简单查询场景。

SAG已在数亿级生产环境验证，增量更新零成本，而GraphRAG类方案需预先构建知识图谱。

Ontology

#Palantir 为什么你的AI知识库一问三变、答案飘忽不定？本质上是缺少一张清晰的 “知识地图"，即Ontology 本体。视频深度解析LLM时代构建知识本体的五大技术流派：从最稳妥的 "拆解派"、数据驱动的 "聚类派"、快速原型的 "两步走派"、行业标准的 "框架派"，再到擦边试水、最快也最危险的 "直给派"。逐一拆解每种方法的核心思路、代表性案例、幻觉风险与工程复杂度，并提供清晰的场景选型框架：POC 验证用直给派、全新领域探索用聚类派、有行业标准用框架派、生产系统必选拆解派。帮助听众跨越 LLM 构建本体的四道坎，真正实现从 "AI 猜答案" 到 "AI 懂推理" 的质变。

主题：LLM构建知识本体的五大技术流派与落地指南

① Ontology本质
知识地图——定义数据间关系与规则，使AI从"随机猜"变为"有据可查"

② 五大流派对比
拆解派：生产系统首选，双重验证保障可靠性，工程量大但错误率最低

聚类派：探索新领域利器，数据驱动发现520+实体类型，适合开放域场景

框架派：行业标准依托者，基于WikiData等框架约束LLM输出，合规性强

两步走派：快速原型专家，先提概念再构层次，适合初期验证但推理能力有限

直给派：POC验证快枪手，半小时出结果，幻觉风险高仅限概念验证

③ 四道坎警示
类型未知：建图前不知领域含几十还是上千种实体

幻觉陷阱：LLM易创造原文不存在的概念关系

粒度困境：关系太宽泛无用，太细致难维护

评估难题：Ontology无标准答案，质量难量化

视频核心内容：
1. 知识本体(Ontology)是解决AI"一问三变"的关键，它构建数据间的结构化关系网络
2. 生产级系统必选拆解派+双重验证，POC验证可用直给派快速试错
3. 实体提取是关键环节，此处错误会一路传导至后续环节
4. Prompt措辞极度敏感，结构化模板比自然语言更稳定可靠
5. 数据质量比数量更重要，we contek仅用1000 token就构建有效知识图谱

未来行动指南：
1. 评估场景：明确是POC验证、新领域探索还是生产部署
2. 选择...