你有没有遇到过这种情况问大模型一个公司内部的问题它一本正经地胡说八道比如问它我们公司的退款流程是什么它给你编一套看起来很合理的步骤——但跟你公司的实际制度完全对不上。你追问它它还能继续编编得越来越像真的。这不是模型笨是它压根没见过你的数据。大模型的训练数据是公开互联网你的公司制度、产品文档、私有知识它一概不知。 但它不会说我不知道而是编一个概率上最合理的答案——这就是幻觉。RAG 就是解决这个问题的。今天这篇文章从原理到生产一次讲透全程不依赖任何框架。1.RAG 就是开卷考试先回答一个根本问题为什么需要 RAG因为大模型有三个治不好的毛病毛病具体表现例子幻觉不知道就瞎编还编得像真的问它你公司的退款政策它一本正经地胡说知识过时训练数据有截止日期问它昨天的汇率、上周发布的 API不认识私有数据企业文档、个人数据它没见过问它你家产品的参数、你的写作风格这三个毛病有一个共同的根因LLM 是闭卷考试选手。它靠肚子里的记忆答题记忆里没有的它不会说我不知道而是编一个概率上看起来合理的答案。RAG 的思路简单粗暴让它开卷。答题之前先去资料库里把相关内容翻出来塞进提示词让它照着资料回答。闭卷裸 LLM 提问 → 靠记忆硬答 → 没有的部分瞎编 开卷RAG 提问 → 先检索相关资料 → 基于资料生成 → 答不上就说不知道说白了RAG 根本没动生成那一环——生成用的还是同一个 LLM。它干的唯一一件事是在模型答题前替它把对的资料翻出来。检索错了生成再强也白搭——就像开卷考试翻错了书答得再流畅也是零分。记住这句话它是后面所有优化的出发点混合检索、Rerank、Agentic RAG全都在解决同一个问题——怎么把对的那一段捞出来。一句话RAG 开卷考试。模型没变变的是它答题前能不能翻到对的一页。2.全链路离线四步 在线四步RAG 的完整链路分两个阶段这个划分必须刻在脑子里后面所有内容都挂在这两条线上【离线阶段建索引】—— 一次性 / 定期做回答知识怎么进系统 文档加载 → Chunk 分块 → Embedding 向量化 → 存入向量库 【在线阶段查询】—— 每次提问都做回答问题怎么找到答案 用户提问 → 向量检索召回 → Rerank 重排 → 拼进 Prompt → LLM 生成RAG 完整链路光看链路有点抽象我们用一个电商客服助手的场景把两条链路各走一遍。2.1 离线阶段把《退货退款政策》变成可检索的库假设你是一家电商公司的技术负责人客服团队每天要回答大量退货退款问题。你决定做一个 RAG 系统把公司的《退货退款政策 v2.1》5000 字喂进去。始文档《退货退款政策 v2.1》5000 字 Markdown ↓ 加载解析成纯文本标题层级保留 ↓ 分块按章节递归切七天无理由退货退款时效运费承担各自成块 每块约 500 字相邻块重叠 10%防关键条款卡在切分线上 ↓ 向量化每个块过 embedding 模型变成一串数字如 1536 维向量 ↓ 入库向量 原文 元数据章节路径售后/退货/运费存进向量库产出几十个政策片段等用户来问① 文档加载把各种格式的文档读进来转成纯文本。听着简单实际是全链路最脏的活▪ PDF 最难搞扫描件图片型 PDF得先 OCR带表格的 PDF 转出来经常是乱码▪ 表格直接转纯文本会丢结构要转成 Markdown 表格保留行列▪ 代码块要保留格式和语言标记电商场景比较幸运政策文档是 Markdown天然干净。但如果你的源是 PDF听我一句劝这一步至少预留三分之一的工程时间。② Chunk 分块为什么必须切块三个原因文档太长塞不进上下文窗口embedding 模型有输入上限通常几百 token切块后才能精准命中相关的那一段而不是甩一整篇过去。我们的政策文档按章节递归切分章节块大小内容七天无理由退货~500 字退货条件、适用范围、不适用商品退款时效~400 字审核时间、到账时间、不同支付方式运费承担规则~300 字买家承担 vs 商家承担、质量问题例外特殊商品退货~350 字生鲜、定制商品、数码产品的特殊规则顺带把三种切法都摆出来按场景选切法怎么切优点缺点固定大小每 N 字符切一块简单可预测无视结构段落表格被拦腰斩结构感知按标题→段落→句子递归切尊重文档结构略复杂语义切分相邻句 embedding 相似度突变处下刀块内主题最纯要额外算一遍相似度成本高Chunk 大小怎么定这是高频追问。答案是没有万能值得实测调。太大2000 字一块混多个主题向量被稀释太小100 字以内语义不完整该公司收入增长 3%脱离上下文根本不知道指谁。经验起点是 256-1024 token重叠 10%-20%再根据实际检索质量微调。重叠是为了防边界截断——关键信息恰好落在切分线上时不重叠就会丢。③ Embedding 向量化Embedding 干的事把文本变成一串数字向量让语义相近的文本数字也相近。听着抽象打个比方。给水果定坐标苹果 → (甜度 8, 酸度 3, 硬度 7) 橙子 → (甜度 7, 酸度 6, 硬度 3) 土豆 → (甜度 2, 酸度 1, 硬度 8)苹)和橙子坐标接近都是甜的、不太酸土豆和它们差得远。Embedding 做的就是这件事——给每段文字定一组语义坐标坐标越近意思越像。只不过不是手工定 3 个维度而是让模型自动学出几百上千个维度。向量还能捕捉语义方向。经典例子国王 - 男性 女性 ≈ 女王。这不是在做数学题而是在向量空间里把性别方向换了一下——国王和女王只差一个性别维度去掉男性、叠上女性自然就到了女王附近。衡量近不近用余弦相似度——看两个向量方向一不一致不管长短。两篇内容相同但长度不同的文章向量长度不同、方向一致相似度照样接近 1。到这里都还顺利真正埋雷的地方在容错逻辑上。很多项目会做API 挂了自动降级本地模型的设计看起来贴心但藏着 RAG 全链路最阴的一个坑⚠️ 大坑建库和查询必须用同一个 embedding 模型。如果建库那天用的 1536 维模型查询那天降级成 384 维本地模型会发生什么——两个模型的向量空间完全不一致检索结果全是乱的。而且这是隐性 bug代码不报错、接口不超时只是检索出来的东西莫名其妙。你第一反应绝对不会是模型换了而是chunk 切得不好然后调三天切分参数越调越魔幻。修复方案建库时把 embedding 模型名写进元数据查询时校验不一致直接报错拒绝服务——宁可明确失败不要静默胡说。④ 存入向量库向量库选型看规模和基础设施向量库定位适用Chroma轻量嵌入式本地文件持久化个人项目、十万级以内 chunkPGVectorPostgreSQL 插件已有 PG 基础设施不想多运维一套Milvus分布式专业向量库生产海量、要高可用FAISS本地库不是服务离线批量实验选型的核心是够用不是最强——数据量没到十万级Milvus 的分布式能力一分都用不上。入库时有三个细节别忘▪ 向量旁必须存原文——检索出来拼回 prompt 的是原文不是向量▪ 存元数据来源章节、分类、块序号——后面做过滤全靠它▪ 批量入库——避免一次性内存暴涨2.2 在线阶段用户问买了三天想退货运费谁出光看链路有点抽象我把在线阶段四步拆开用同一个例子走一遍你就知道每一步到底在干嘛。第一步向量召回粗筛用户问题过 embedding 模型变成向量去向量库里算相似度拉回 top 20 条。实际跑出来大概长这样排名 来源章节 内容摘要 相似度 1 七天无理由退货 签收后7天内可申请无理由退货需商品完好... 0.89 2 退款流程 提交申请后1-3个工作日审核退款原路返回... 0.85 3 运费承担规则 退货运费由买家承担因质量问题退货的运费... 0.83 4 特殊商品退货 生鲜、定制商品不支持无理由退货... 0.78 5 退货时效 签收次日起算7个自然日... 0.76你可能发现了——用户明明问的是运费但运费承担规则只排第 3排在前面的反而是七天无理由退货和退款流程。原因也不复杂向量检索比的是整体语义相似度七天无理由退货和退款流程跟退货这个大主题更近自然排前面。但用户要的不是怎么退货是运费谁出——粗筛捞得全但排不准这很正常。第二步Rerank 精排粗筛不准那就加一道精排。把 top 5 条和用户问题一起丢进跨编码器逐词对照打分排名 来源章节 跨编码器得分 变化 1 运费承担规则 8.72 ↑ 从第3升到第1 2 七天无理由退货 6.35 ↓ 从第1降到第2 3 特殊商品退货 4.18 ↑ 从第4升到第3 4 退款流程 2.05 ↓ 从第2降到第4 5 退货时效 1.32 ↓运费承担规则直接从第 3 翻到了第 1。原理也不复杂粗筛比的是整体像不像精排比的是局部对不对。跨编码器是把问题和文档拼在一起逐词比对的——用户的运费和文档的运费承担规则精确匹配得分自然高而退款流程虽然语义相关但里面压根没有运费这个词逐词比对后得分就掉下去了。粗筛像猎头扫简历5 秒一份快速过精排像面试官坐下来深聊一个一个对。 先粗筛再精排捞得全也排得准。取 top 3 进入下一步。第三步拼接 Prompt把 top 3 的原文塞进提示词。直接把检索结果丢给模型还不够还得加工一下你是电商客服助手。请基于以下参考资料回答用户问题。 如果资料里没有相关信息请如实说我暂时无法回答不要编造。 【参考资料 1】运费承担规则 退货运费由买家承担因质量问题退货的运费由商家承担。 运费在退款时一并扣除无需单独支付。 【参考资料 2】七天无理由退货 签收后7天内可申请无理由退货需商品完好、包装齐全。 不适用于生鲜、定制商品、已拆封的数码产品。 【参考资料 3】特殊商品退货 生鲜、定制商品不支持无理由退货。 数码产品已拆封的需提供检测报告方可退货。 用户问题买了三天想退货运费谁出两个细节参考资料带了来源标记运费承担规则方便溯源——用户追问的时候能说清楚这个结论来自哪条政策提示词里写了资料里没有就说不知道——这是在给模型上缰绳不让它瞎编。第四步LLM 生成模型看到参考资料后基于资料生成回答您购买三天在7天无理由退货期限内可以申请退货。退货运费由您自行承担退款时会一并扣除。如果是因为商品质量问题退货运费则由商家承担。答案里的每一个数字、每一条规则都来自参考资料——7天内来自参考资料 2运费买家承担来自参考资料 1质量问题商家承担也来自参考资料 1。要是粗筛里压根没有运费承担规则那段模型再聪明也只能编。四步走完整个流程的核心就一句话粗筛负责捞得全精排负责排得对Prompt 负责给模型上缰绳。 三件事做好了RAG 的在线阶段就不会掉链子。一句话离线四步把知识变成可检索的向量在线四步把问题变成最相关的答案。两阶段必须用同一个 embedding 模型否则向量空间对不上检索结果全乱。3.怎么检索得准链路搭完第一次检索大概率会让你失望——不是完全不准是大部分还行关键时候掉链子。3.1 检索方式全景先搞清楚有哪些牌可以打。三种检索方式每种都有自己的绝活和盲区检索方式原理擅长盲区速度向量检索稠密语义相似度同义词、意译、模糊表达精确编号、专有名词快关键词检索 BM25稀疏词频 稀有度精确匹配、型号、报错码同义词、语义改写快混合检索两路并行 RRF 融合盲区互补成本翻倍中光看表格没体感每种举个正反例子向量检索——比的是意思像不像不是字面。搜小狗能找到只写了幼犬的文档因为小狗和幼犬语义接近。但搜HTTP-403 报错返回的可能是一堆泛泛的服务器错误讨论——语义确实近但你要的就是 403 这个精确编码它抓不到。BM25 关键词检索——比的是字面命中。搜HTTP-403精确命中写了这个错误码的文档。但搜kitty找不到通篇只写了cat的文档——它只认字面不懂同义。混合检索——两路都跑盲区互补。向量检索管语义BM25 管精确关键词两路各查各的用 RRF 融合。搜RTX 4090 价格向量检索能找到显卡多少钱BM25 能精确命中RTX 4090这个型号——单靠任何一路都会漏。三种检索负责的是捞得全但捞回来的顺序不一定对。后面还需要一道精排把真正相关的排到前面——这就是 Rerank3.3 再展开讲。整个流程是这样的检索三选一 → 负责捞得全召回阶段 ↓ Rerank 精排 → 负责排得对精排阶段 ↓ 拼 Prompt → 负责约束生成3.2 混合检索两种盲区互补3.1 里已经看到两种检索的盲区了——向量检索抓不住精确编码BM25 读不懂同义词。生产环境的标准做法是混合检索两路各查各的结果合并。但合并有个技术难题向量相似度在 0~1 之间BM25 得分动辄几十两个尺度的分数根本没法直接加权相加这就好比一个百分制一个五分制硬加没有意义。解法是 RRFReciprocal Rank Fusion倒数排名融合干脆不看分数只看排名。综合得分 Σ 1 / (60 rank) # rank 是文档在某一路结果里的名次手算一个例子感受一下它为什么合理文档 A向量检索排第 2BM25 排第 3 得分 1/62 1/63 0.0161 0.0159 0.0320 文档 B向量检索排第 1BM25 排第 50 得分 1/61 1/110 0.0164 0.0091 0.0255文档 B 在其中一路拿了第一总分却输给两路都是前三的文档 A。RRF 的逻辑就一句话两路都说你好你才真的好偏科生靠边站。但是混合检索不是必选项。网上太多文章把它讲成RAG 标配了搞得不上混合检索就不好意思打招呼。判断标准就一条用户会不会拿精确字符串来搜。报错码、型号、人名——出现这些必须混合。纯语义任务纯向量就够。3.3 Rerank粗筛之后的精挑混合检索解决了捞得全但还有一个问题捞回来的顺序不对。向量检索是粗筛为了快用近似匹配从几千个 chunk 里捞出 top 20-50。但近似匹配的第一名未必真的最相关。就像猎头看简历5 秒一份快速筛出 30 份看起来还行的但哪份最匹配得面试官坐下来逐个深聊才知道。这个深聊就是 Rerank重排序换一个更强的模型对召回的候选逐个精打分重新排序。为什么换模型就能变准底层是两种架构的差异双编码器Bi-Encoder跨编码器Cross-Encoder怎么算查询和文档各自编码成向量再算距离查询和文档拼成一段文字一起送进模型交互深度编码时互不相见只能向量间接比较逐词对照能捕捉细粒度匹配速度极快文档向量可离线预计算慢每对都要实时算一遍用在哪召回阶段海量粗筛重排阶段几十条精排双编码器 vs 跨编码器双编码器是猎头按学历 年限快速筛简历快但粗糙跨编码器是面试官拿着 JD 和你逐条对慢但准。先粗筛再精挑捞得全也排得准。回到我们的电商客服案例粗筛把运费承担规则排到第 3因为它语义上和退货相关但不是最直接的精排时跨编码器逐词比对发现用户的运费和文档的运费承担规则精确匹配直接翻到第 1。3.4 效果怎么量化调了半天参数怎么知道变好还是变坏了不能凭感觉得靠数字说话。三个指标按顺序问自己三个问题指标回答什么问题直觉recallk该找的找到了吗前 k 条里有没有正确答案MRR找得够靠前吗第一个相关结果排第几nDCG整个列表质量如何相关的都排前面不相关的都沉底用电商客服的例子走一遍。用户问运费谁出标准答案在运费承担规则这个 chunk 里。分别看两套检索方案的效果复制方案 A纯向量检索没 Rerank 1. 七天无理由退货 ← 不对 2. 退款流程 ← 不对 3. 运费承担规则 ← 对了排第 3 4. 特殊商品退货 5. 退货时效 方案 B向量检索 Rerank 1. 运费承担规则 ← 对了排第 1 2. 七天无理由退货 3. 特殊商品退货 4. 退款流程 5. 退货时效三个指标分别算recall3前 3 条里有没有正确答案方案 A 的运费承担规则排第 3命中recall3 1。方案 B 排第 1也是 1。看起来一样别急。MRR第一个正确答案排第几方案 A 排第 3MRR 1/3 ≈ 0.33。方案 B 排第 1MRR 1。差距就出来了——MRR 关心的是找到得够不够快排第 1 和排第 3 体验完全不同。nDCG整个排序列表质量如何方案 B 把正确答案排在最前面不相关的沉底nDCG 更高。方案 A 虽然也找到了但正确答案被两个不相关的压着列表整体质量差一截。三个指标各管一件事recall 管找没找到MRR 管找得快不快nDCG 管整个列表排得好不好。实际评估时从真实用户问题里挑 30-50 个人工标好标准答案改一版参数跑一遍三个指标——数字涨了才算优化。凭感觉说好像准了不算真的不算。一句话混合检索补精确匹配、Rerank 把对的排前面、RRF 用只看排名的方式融合两路结果优化效果盯 recallk数字涨了才算数。4.怎么检索得聪明前三章解决的是检索得准这一章换一个维度怎么让检索变聪明——该查什么、什么时候查、查几次。4.1 三板斧改写、过滤、补上下文查询改写Query Rewriting用户的原话往往不适合直接拿去检索。比如用户问那个东西怎么退——检索引擎知道那个东西是啥就有鬼了。解法是先让 LLM 把问题改写成适合检索的形式再拿去查用户原话那个东西怎么退 ↓ LLM 改写 改写后退货退款流程是什么 ↓ 再去检索 命中退货退款政策、退款时效...成本是一次额外的 LLM 调用收益在模糊查询场景下非常明显。用户不知道你的知识库用的是什么术语LLM 知道——让它当翻译。元数据过滤Metadata Filtering检索时先按标签缩小范围再做向量检索。回到电商客服场景知识库里既有退货退款政策也有会员积分规则还有配送时效说明。用户问退货问题时先用元数据过滤把范围缩小到售后分类再做向量检索——砍掉一半不相干的检索精度立刻上来。用户买了三天想退货运费谁出 ↓ 元数据过滤category 售后 ↓ 向量检索只在售后分类里搜 ↓ 结果退货相关的内容不会混进会员积分配送时效粗判会不会判错会但判错的代价很低——大不了就是没过滤退回全库检索不会引入错误结果。元数据过滤追求的是砍掉明显不相干的不是搞精准分类。Contextual Retrieval上下文感知检索切块有个天然缺陷会切断指代关系。比如一段政策文档写着该公司收入增长 3%——该公司指谁答案在上一段但切块后上一段不在同一个 chunk 里了。带着这种残缺的文本去嵌入向量自然也残缺。Anthropic 的解法是嵌入之前先让 LLM 给每个 chunk 补一段上下文说明。原始 chunk该公司收入增长 3%Q3 营收突破 50 亿。 ↓ LLM 补上下文 带上下文的 chunk本文讨论的是小米集团2024年财报。 该公司收入增长 3%Q3 营收突破 50 亿。 ↓ 再去嵌入 向量里包含了小米集团的语义信息代价是建库时多一遍 LLM 调用收益是长文档场景下的召回质量。Anthropic 的实测数据结合 Contextual Embedding BM25 Rerank检索失败率降低 67%。4.2 Agentic RAG检索是工具不是必经之路传统 RAG 是无脑流水线每个问题都检索不管需不需要。但检索是有成本的——延迟、token、还有噪声。检索回来无关内容不仅浪费还会干扰生成模型看到一堆不相关的资料答案质量反而下降。Agentic RAG 的思路是把检索当成 Agent 的一个工具由模型自己决策要不要查、查什么、查几次。什么时候该查、什么时候不该查用电商客服的例子走一遍。不查的场景用户问什么是七天无理由退货——这就是常识模型肚子里有直接答就行不需要检索。硬要去查反而多此一举。查一次就够的场景用户问买了三天想退货运费谁出——这是单跳问题检索一次运费承担规则就能回答。需要迭代查的场景用户问双十一买的东西想退货优惠券还能用吗——这个问题涉及两块不同的知识一次查不全。第一轮检索 想这个问题既涉及退货又涉及优惠券先查退货规则 查检索双十一退货政策 看找到了促销活动期间购买的商品退货后优惠券不退还 但用户可能还会问那退款金额怎么算——促销价和原价不一样 第二轮检索 想需要补充促销订单退款金额的规则 查检索促销订单退款计算方式 看找到了促销订单退款按实付金额计算优惠券抵扣部分不退 综合两轮结果给出完整回答 双十一购买的商品可以退货退款按您的实付金额计算。 优惠券抵扣的部分不退还退货后优惠券也不会恢复。传统 RAG 只能查一次要么只捞到退货规则漏了退款金额要么两块都捞到但混在一起排序混乱。Agentic RAG 的价值在于第一轮查完发现信息不够能根据结果构造更精确的第二轮查询——就像研究员反复查阅、交叉验证材料够了再动笔。一句话查询改写救模糊问题元数据过滤先砍一半噪声Contextual Retrieval 补回切断的上下文检索频率跟内容复用性走——常识够答就不查Agentic RAG 让模型自己决定。5.动手实操前面四章讲的都是原理和链路这一章用一个真实项目把 RAG 走一遍。项目叫 article-writer一个 AI 写公众号文章的 Agent。它的 RAG 和第二章的电商客服有一个本质区别客服检索的是答案写作检索的是风格。客服用户问运费谁出系统去知识库里找运费承担规则那段原文当答案。写作场景不一样——用户说写一篇关于 RAG 的文章系统不需要找 RAG 的知识LLM 自己肚子里有。它需要找的是楼仔写这类技术文章时是什么风格——怎么开头、怎么用比喻、段落多长、语气什么样。5.1 离线197 篇文章怎么变成风格参考库知识源是我写的 197 篇 Markdown 文章按分类放在 11 个目录里。技术类占大头——Spring 全家桶 39 篇、Java 与 JVM 30 篇个人类也不少——个人成长 29 篇、管理与随笔 28 篇。这些文章切块入库后每个 chunk 带两个元数据标签styletechnical / personal和category来自哪个目录。写技术文章时只检索 technical 的 chunk写随笔时只检索 personal 的 chunk——用元数据过滤风格不过滤知识。切块一篇真实文章的拆解拿《手动撸一个 Redis 分布式锁》走一遍7745 字切块参数是每块 1000 字符、重叠 150 字符、从切点往前扫空行找段落边界。切完产出 10 个 chunk挑几个有代表性的Chunk 1988 字文章开头 大家好呀我是楼仔。对于使用 Java 的小伙伴其实我们完全不用 去手动撸一个分布式锁直接使用 Redisson 就行。但是因为这些封 装好的组建让我们越来越懒…… Chunk 2796 字锁超时的核心问题 通过和当前时间比较判断锁是否超时。如果锁未超时直接返回 如果锁超时重新设置锁的超时时间成功获取锁。还有其它问题么 当然因为在并发场景下会存在 A、B 两个线程同时…… Chunk 3907 字并发场景分析 延长或缩短了锁的超时时间不会有问题么其实在现实并发场景中 能走到这一步基本是同时进来的两者的时间差非常小……Chunk 1 是典型的技术文章开头——大家好呀我是楼仔打招呼然后用口语化表达引入话题。Chunk 2 的句式也很有代表性——先抛技术问题再用反问转折。Chunk 8-10 是文章尾部的总结和好文推荐链接。197 篇文章的尾部长得一模一样——都是欢迎关注公众号楼仔进阶之路那套模板。这些是噪声入库前应该清洗掉我这个库建得糙没做这一步。入库真实参数参数值为什么这么定CHUNK_SIZE1000 字符约 500-700 中文 token试过 2000混主题太严重试过 500语义太碎。1000 是经验甜点CHUNK_OVERLAP150 字符约 15%防止关键信息卡在切分线段落边界回扫从切点往前找空行避免在段落中间下刀Embedding 模型OpenAItext-embedding-3-small1536 维优先降级用本地bge-small-zh-v1.5384 维批量入库50 块一批避免内存暴涨元数据styletechnical/personalcategory按目录结构自动推断用于过滤风格197 篇文章切完产出约 2800 个 chunk向量库文件 28MB。就是一个小文件的事ChromaDB 一个嵌入式文件就装下了。5.2 在线写一篇 RAG 文章时系统怎么找风格参考以这篇 RAG 文章为例走一遍完整流程。第一步风格判断用户输入写一篇关于 RAG 原理和实战的技术文章。RAG原理实战都是技术关键词过滤styletechnical把聊聊我的焦虑谈谈35岁危机这类个人风格的 chunk 先排除掉。第二步向量召回粗筛拿RAG 原理 实战 技术文章当查询去检索拉回 top 20。这些 chunk 不是 RAG 的知识是楼仔写技术文章时的风格样本。实际跑出来前 5 条排名 来源文章 相似度 风格特征 1 手动撸一个 Redis 分布式锁 0.842 口语化开头大家好呀我是楼仔 2 MySQL 单表可以放多少数据 0.817 数据驱动先抛数字再展开 3 Redis 高可用原理 0.814 技术类比用生活例子解释原理 4 只会单机执行定时任务多机执行 yyds 0.794 反问句式还有什么策略呢 5 如何保障 MySQL 和 Redis 数据一致性 0.788 表格对比用表格讲方案差异粗筛的问题和第三章讲的一样噪声混进来了——有些 chunk 是测试输出日志、好文推荐链接和写作风格没关系纯粹因为关键词重叠被捞上来。第三步Rerank 精排粗筛结果丢进跨编码器精排排序变了排名 来源文章 跨编码器得分 变化 1 手动撸一个 Redis 分布式锁 0.998 保持第 1 2 MySQL 单表可以放多少数据 0.996 保持第 2 3 Redis 高可用原理 0.994 ↑ 从第 3 升到第 3噪声被淘汰后补位 4 如何保障 MySQL 和 Redis 数据一致性 0.992 ↑ 从第 5 升到第 4 5 只会单机执行定时任务多机执行 yyds 0.990 ↓ 从第 4 降到第 5粗筛里混进来的测试输出日志、好文推荐链接精排后都掉出了 top 5——跨编码器逐词比对后发现这些 chunk 和RAG 技术文章的匹配度很低。和电商客服的例子一样——粗筛比整体像不像精排比局部对不对。第四步拼 Prompt精排后取 top 3拼进 system prompt你是公众号文章写作助手。请参考以下历史文章的写作风格来写作。 【风格参考 1】来源手动撸一个 Redis 分布式锁 大家好呀我是楼仔。对于使用 Java 的小伙伴其实我们完全不用去 手动撸一个分布式锁直接使用 Redisson 就行。但是因为这些封装好 的组建让我们越来越懒。 【风格参考 2】来源MySQL 单表可以放多少数据 我说MySQL每张表最好不超过2000万数据面试官让我回去等通知 【风格参考 3】来源只会单机执行定时任务多机执行 yyds 留给大家一个问题如果有一条数据一直处理失败每次获取数据 都会先获取到这条问题数据那么有什么策略可以让这条数据推后执行呢Agent 看到这些参考会模仿里面的口吻、句式、节奏来写新文章。RAG 的知识来自 LLM 本身风格来自这些检索到的历史文章片段。整个流程和第二章的电商客服链路一样——切块、入库、粗筛、精排、拼 Prompt。目的不同链路相同。最后说一句实话用 RAG 做风格匹配效果其实一般。RAG 检索的依据是语义相似度找的是主题相近的文本不是风格相近的文本。两篇文章主题完全不同写作风格可能一模一样——RAG 分辨不出来。最后说一句技术成长不只是写代码职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料适合想在职场上走得更远的朋友看看。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。