企业官网建设流程全解析

第十二天的晚上，我合上电脑，把当天的笔记从头到尾又翻了一遍。这是我从零开始学大模型应用开发的第十二天，前两天刚跑通了一个基于RAG的知识库问答系统，今天却在调优时被检索准确率这个问题卡了一整天。翻完笔记我反而踏实了——这段时间踩的坑、找到的规律、还有一些只可意会的手感，都记下来了。这篇文章就是那天笔记的完整版，写给同样在自学大模型应用开发、走到中途正被各种细节磨耐心的朋友。

1. 前十一天的路：从调通API到做出一个能跑的项目

先说下我为什么会在第十二天跟检索准确率较劲。这十几天我走了一条挺典型的自学路线，没有任何基础，就是靠文档、开源项目和一些零散的教程硬啃。

1.1 前四天：先把调用链路跑通

第一到第四天我都在跟大模型API打交道。从注册云厂商账号、申请API密钥，到写第一个ChatCompletion请求，再到处理流式输出、多轮对话，一步步把最基础的调用链路弄明白。这阶段我最大的收获是理解了temperature、top_p这些参数的实际手感——温度调高了创意多但容易跑偏，调低了回答稳定但有点呆板，得看场景取舍。

1.2 第五到第八天：啃下向量化和检索的基础

从第五天开始进入RAG的核心环节。我先学了文本向量化的原理，搞清楚一个句子是怎么变成一串几百维的浮点数，又是怎么通过余弦相似度计算找到语义相近的文本。然后动手装了向量数据库，把一批文档切片、向量化、灌库，再写代码做相似度检索。这阶段我犯过不少错，比如切片尺寸设得太大导致检索结果很粗糙，top_k设太高把一堆不相关的内容也捞了进来，都是后面才慢慢调明白的。

1.3 第九到第十一天：做出第一个知识库问答系统

第九天我终于开始动手做一个完整的知识库问答系统。选了一个比较熟悉的领域——把一套产品操作手册做成问答机器人。用户问问题，系统先从文档库里检索相关内容，把最相关的几段拼成上下文，再送给大模型生成答案。

这个过程比想象中复杂，光是搭个简单的服务端、写检索逻辑、接大模型生成回答，就花了我三天时间。从功能上看，第十一天晚上系统已经能跑通了：上传文档、切片入库、提问、返回答案，一个都不少。

但问题恰恰出在“答案”上——很多回答看起来通顺，实际上张冠李戴。比如问A设备的保修期，它会扯到B设备上去；问退换货条件，它只答出一半，另一半信息明明在文档里，它就是没检索到。这让我意识到：系统跑通只是第一步，检索质量才是RAG真正的生死线。

2. 第十二天的主攻方向：为什么答案总是不对劲

第十二天一整个白天，我基本上都在回答一个问题：到底哪一环让答案变质了。RAG的链条无非就是“文档切块 -> 向量化入库 -> 相似度检索 -> 拼上下文 -> 大模型生成”，看起来不长，但每一环都可能埋雷。

2.1 先做一轮端到端排查

我没有急着改代码，先把几个典型的错误案例拿来做端到端排查。拿其中一个问“产品保修期内哪些情况不予免费维修”的问题来说，我把检索环节的结果直接打印出来看：

查询向量得分 Top 5： 1. 文档切片ID 034，得分 0.8123 —— 关于保修期定义 2. 文档切片ID 056，得分 0.8044 —— 关于维修流程 3. 文档切片ID 022，得分 0.7311 —— 关于产品参数表 4. 文档切片ID 089，得分 0.7022 —— 关于退换货政策 5. 文档切片ID 033，得分 0.6877 —— 关于日常保养方法

问题立刻暴露了。得分最高的那个切片确实跟“保修”相关，但讲的只是“保修期12个月”这个定义，没有涉及“不予维修”的排除情况；真正写排除条款的那一段，得分反而排在后面。语义相似度高分不等于它就是回答问题的答案，这个道理我算是亲手验证了。

2.2 把问题拆成两个层面

蹲了一上午之后，我把导致答案不对的因素分成了两大类：

第一类是检索召回问题——该捞的内容没捞上来。文档里的关键信息被切片切散了，或者切片粒度太大把多个主题混在一起，导致查询跟目标内容向量相似度不够高。

第二类是精排和上下文组织问题——捞上来的内容不够精，或者顺序不对。检索只做到“相关文档的粗筛”，等于是从整个图书馆里挑出几本书，但书里具体哪一页有用，还得再精排一轮。

想明白这两点之后，全天的工作就清楚了：先解决切片策略，再引入精排模型，最后优化上下文拼装。

2.3 建立效果验证的标准

在动手之前，我还做了一件关键的事：建了一套评估问题集。选了二十个覆盖各种典型问法的测试问题，比如直接问条款的、带着具体条件问的、还有绕弯子隐性问的。每个问题我都凭人工判断了标准答案出自文档的哪些段落。没有这套基准，后面调什么都像闭着眼睛摸路。

3. 切片策略调整：从固定尺寸切块到语义化切块

切片是RAG系统的地基，但也是最容易被忽视的地方。我第一次建库时偷懒，直接用固定chunk_size=500字符、overlap=50字符的方式把整本手册切成小块，想着反正向量检索会自动找相似的。第十二天的调试彻底推翻了这个想法。

3.1 固定切块的问题出在哪

当文档被机械地按固定长度切块时，一条完整的条款很可能被拦腰截断。我手册里有一条“保修期内以下情况不予免费维修，包括但不限于：人为损坏、进水、摔落、非授权拆机…”原本是一整段，但切块时正好在“包括但不限于”那里被切开了——前半段在032号切片里，后半段在033号切片里。

用户问“哪些情况不保修”时，032切片只含有“保修期内以下情况不予免费维修”这半句话，没有具体内容；033切片虽然接着后半句，但因为缺少前文语境，跟查询的语义重叠度也没那么高。再加上其他噪音切片的干扰，正确答案的排名自然就掉下去了。

3.2 改用带标题层级感知的递归切块

下午我对切片逻辑动了大手术。产品手册本身是有结构的——章节、小节、条目清清楚楚，正确的切片应该尊重这种结构，而不是拿一把刀均匀地剁下去。

我换成了按标题层级感知的递归切块：解析文档时先识别出各级标题，把内容按章节边界分组，再在章节内部根据语义完整性和长度上限做二次切分，保证每个切块尽量是一个完整的话题单元。具体用到的逻辑是这样的：

# 示意代码：按标题层级分组后，再按长度阈值递归切分 def semantic_chunk(doc_tree, max_chunk_size=800, overlap_size=80): chunks = [] for section in doc_tree.sections: # 根据标题层级得到的章节结构 text = section.get_full_text() if len(text) <= max_chunk_size: chunks.append(section) else: # 在一个章节内部按句子边界分段，段之间保留少量重叠 sub_chunks = split_by_sentences(text, max_len=max_chunk_size, overlap=overlap_size) chunks.extend(sub_chunks) return chunks

注意几个关键点：max_chunk_size要按语义完整程度来调，太小容易切断上下文，太大又会让单块向量包含太多噪音主题；重叠部分的作用是把跨切块的转折内容多保留一点，但重叠量过大会导致检索时同一个信息点被重复命中，反而稀释精确度。

3.3 切块调整后的实测对比

改完切片再跑那二十个测试问题，结果有了明显变化，下面这张表是其中几个代表性问题优化前后的对比：

召回这一环优化后，答案的张冠李戴现象少了很多，但仍然存在一个问题：排名前五的切片里依然会混进一两个不太相关的，比如问“保修”时把“产品参数表”也捞进来了。向量检索只能保证“语义方向对”，很难做到“精准对口”。

4. 给检索结果装上精排：让最相关的段落浮上来

如果把向量检索比作一杆大网撒下去捞鱼，初筛捞上来一堆可能相关的切片，那精排就是上桌之前的人工挑鱼——把最合适的那几条挑出来放在最前面。第十二天下午，我给系统加上了重排序这个环节。

4.1 为什么要再加一道精排

很多人刚开始做RAG时会有一个错觉：向量检索的相似度分数就是衡量相关性的黄金标准，得分高的一定最有用。实际测下来完全不是这样。向量相似度衡量的是语义方向上的接近程度，你问“保修期内不保修的条款”，它认为“保修期定义”很接近，因为都在讲保修；但真正回答问题的“排除条款”，因为细节具体、用词特殊，跟问题的向量余弦距离反而不如前一个。

精排模型的工作方式不一样。它会把“用户问题”和“候选文档切片”做成一对一的输入，通过深层语义交互重新打一个相关性分数。通俗地讲，向量检索是在高维空间里“找方向相似的”，精排则是把问题和文档放到一起仔细“读”一遍，判断这段内容到底能不能解答那个问题。

4.2 选型和接入

我用的是开源的bge-reranker-v2-m3，它针对中文语义匹配做了优化，而且支持较长的输入序列。接入方式也简单，先用向量检索把Top20的候选取回来，再交给重排序模型对每个候选切片打分，最后取重新排名后的Top5作为交给大模型的上下文。

# 示意代码：向量召回 + 重排序精排的串联流程 retrieved = vector_store.search(query, top_k=20) # 第一阶段：粗排召回 reranked = reranker.rerank(query, retrieved, top_n=5) # 第二阶段：精排筛选 context = assemble_context(reranked) # 组装上下文 final_answer = llm.chat(query, context) # 大模型生成

这里有个参数值得注意：向量召回的数量top_k=20，意思是让精排模型拥有足够大的候选池。如果粗排只返回5条，精排模型再厉害也没得挑。但召回太多也会拖慢重排序的速度，所以20到30之间是性价比比较高的区间。

4.3 加了重排序之后的提升幅度

精排环节到位后，我重新测了那二十个问题。最直观的变化是，交给大模型的五段上下文中，基本不会再出现完全跑题的内容。针对“保修期内哪些情况不予免费维修”这个问题，精排后的前三段分别是“不予维修的排除条款”“保修范围定义”“维修流程说明”，前两段已经覆盖了问题需要的核心信息，大模型给出的答案也终于一句是一句，不再东拉西扯。

我还记录了一个反差很大的现象：在优化前，很多问题虽然能从检索结果中找到正确信息，但由于正确答案排名太靠后，被挤出了上下文窗口，大模型根本看不见它，只能在残缺信息里“脑补”。加入精排之后，“答案藏在第九段但没被用到”这类问题基本绝迹了。

5. 上下文拼装的细节：同一条信息重复出现是隐形杀手

精排问题解决后，我原本以为收工了，顺手测了几个问题，发现又浮出一个新毛病：答案不完整，甚至会因为上下文里信息太驳杂而被带偏。于是第十二天傍晚，我开始处理上下文拼装的细节。

5.1 去重和不必要的重复

精排后的Top5切片常常会出现信息重叠。还是拿“保修期”举例，Top1是“保修期12个月”，Top2也提到“保修期一年，以购机发票日期起算”，两个切片意思相同但表述略有差异。大模型拿到这种上下文，有时会纠结到底听哪个，甚至会把两个版本的信息都拼进回答里。我去除重复切片的方法是给精排结果做一次相似度去重——对已选人的切片，凡是跟已入选切片内容重合度过高的直接跳过。

5.2 在上下文里标注来源

还有一个不起眼但效果明显的改动：在拼装上下文时给每个切片加上它所属的章节标题前缀，比如“来自第三章 售后保障政策”。大模型在生成回答时能看到这段标注，能更好地理解这段信息的定位和适用范围。

# 示意代码：给上下文切片添加来源前缀 context_blocks = [f"[{chunk.section_title}] {chunk.text}" for chunk in final_chunks] final_context = "\n".join(context_blocks)

原理其实不复杂，大模型对输入结构的敏感性很高，带章节名的上下文比裸奔的一段文本更容易被它当作“资料引用”处理。

5.3 控制上下文的长度预算

我还把传给大模型的上下文总长度做了个预算。之前Top5切片加起来差不多三千多字，喂给模型后经常超长，而实际有信息量的部分可能只占一半。我把目标改成“每段切片经过压缩后再拼装”，结合上面说的去重，最终的上下文量减少了一半，但对答案的支撑力反而更强。

这里也顺带说一句：RAG的上下文不是越多越好。信息密度高的几段话，胜过堆砌一堆边缘内容的超长文本。

6. 晚上复盘：这一天学到的，和接下来要做的事

下面这部分是那天合上电脑之前写的。第十二天最大的收获不是把检索准确率提升了多少个百分点，而是我终于建立了一个完整的调优闭环：发现问题 -> 建立评估集 -> 分段定位 -> 针对性优化 -> 回测验证。这个思路比任何具体的参数都重要。

6.1 一个完整调优闭环的落地方案

在接下来的实践中，碰到RAG效果不好，建议先按这个顺序排查：

1. 先收集一批有代表性的坏case，覆盖不同类型的错误，至少二十个。
2. 对所有坏case做链路切片：把切块内容、检索得分、重排序结果、拼装后的上下文全部打印出来，肉眼定位是在哪一环出问题。
3. 定位到具体环节再做专项优化，而不是一上来就盲目调temperature或者换Embedding模型。
4. 每次只改一个变量，改完回到同一套评估集上跑一遍，用指标对比结果。

这套流程听起来枯燥，但实际排查效率很高。今天我的问题就是通过这个方式，定位到切片和精排这两个矛盾最集中的环节。如果一开始就到处试参数，大概率调了一整天也不知道哪里起作用。

6.2 迭代的节奏和心态

我还有一个个人感受比较深的体会：自学走到第十二天，脑子里的知识反而比前两天更乱。前两天跑通demo时很兴奋，觉得自己已经入门了；这两天才意识到，能跑通和能用好之间隔着一条很宽的河。但乱归乱，整体方向是明确的，因为每天都有具体的工程问题在推着往前走。

如果遇到跟我类似的瓶颈，建议不要卡在一个地方太久。每个环节都设一个时间盒，比如切片优化最多花半天，不行就先换下一个环节试，回头再聚焦。盲目加班不会提高技术判断力，休息好反而容易想明白问题出在哪。

6.3 接下来准备折腾的方向

下一步我打算做两件事：一是给自己的系统加一份更完整的评估指标，比如命中率、答案准确率的人工打分，最好能把调优前后的变化量化出来；二是把固定业务场景之外的通用文档也喂进去测一轮，看看切片和精排参数在换领域之后还能不能保持稳定。

我曾经以为“大模型应用开发”的重点在大模型本身，这十二天走下来才明白，让大模型准确用到该用的信息，才是真正的核心能力，也是市面上大多数项目之间拉开差距的地方。