企业官网建设流程全解析

把本地大模型和wiki式知识库结合起来，最头疼的问题就是模型容易一本正经地胡说八道。我折腾这个“本地llama-rag-wiki三层降级复利知识库”，核心思路不是追求一次问答的完美，而是给RAG加上三套“保险”，让每次使用后的经验、修正和内容沉淀都能回到知识库本身，越用越值钱。这套方案适合想在离线环境里搭一个私有知识问答系统、又受限于显存和模型能力的开发者，也适合那些已经跑通RAG但经常被错误答案困扰、想提升回答稳定性的朋友。

整个项目不依赖任何云端推理，大模型推理、向量检索、wiki页面存储全在本地完成。三层降级解决的是“模型不知道”和“模型乱编”之间的矛盾；复利则是指知识库在持续使用中不断被修正、扩充，问答质量随使用次数增长而改善。下面我把整个设计思路、关键技术选型、落地步骤以及我踩过的坑一次讲清楚。

1. 内容整体设计与思路拆解

1.1 三层降级究竟是什么

很多RAG方案只有一条路：查询 -> 检索 -> 拼接提示词 -> 让模型生成。这条链路一旦检索质量不行，生成结果就会直接“裸奔”。我的做法是给这条链路加了三档“撤退路线”，每一档都比上一档更保守，但也更可靠。

第一层是完整版RAG：用户问题进来后，先走向量检索加全文检索，拿到相关片段后做重排序，最后把片段和问题一起交给本地llama模型生成答案。这一层负责输出有依据、有细节的回答，也是体验最好的路径。

第二层是摘要兜底：当第一层检索到的内容太零散、相关性分数过低时，不再强行要求模型基于片段作答，而是让模型根据知识库中相关页面的标题和摘要生成一个概括性回答，并明确给出页面链接，让用户自己点击查看详情。这一层牺牲了一部分“直接告诉答案”的体验，但保证了回答内容是有出处、可核验的。

第三层是退路：如果连摘要都不够用，或者问题完全不在知识库范围内，就让模型直接说“这个我不清楚”，并给出几个可能相关的搜索建议或wiki入口。这一层看起来最“傻”，但恰恰是防止幻觉最重要的保险。

1.2 为什么把“降级”作为核心思想

最开始我也想过把检索增强做得更强，比如换更大的embedding模型、塞更多文档、上更重的重排序模型。但实测下来，本地环境的算力是硬约束，追求单点极致会让整个系统变得既慢又不稳定。降级思路的出发点不是“做得不够好”，而是“在有限资源里把失败场景提前设计好”。

举一个生活化的例子：开车时导航信号丢失，高德不会让车停着，而是根据最后一次定位继续推，实在不行也会提示“当前信号弱，请沿当前道路行驶”。这个“继续推”和“明确提示”的动作，就是降级。RAG系统也一样，与其让模型在没有依据的情况下强行编答案，不如提前告诉它“没把握的时候，把话说死”。

另外，三层降级还解决了另一个隐性问题：用户对错误答案的容忍度。一个错误但自信的答案，比一个“我不确定，请看这几篇”的回答危害大得多。尤其在私有知识库场景下，使用者往往不是AI专家，他们可能直接采信模型的输出。降级机制让系统的失败模式变得可预期、可控制，这比任何指标都重要。

1.3 “复利”在知识库里是怎么实现的

知识库复利包含两层意思。第一层是内容层的复利：每次问答产生的优质问答对、用户反馈、修正后的文本，都会通过wiki的编辑机制回写回知识库，让后续检索能命中更多内容，相当于知识资产在缓慢增值。

第二层是系统层的复利：随着wiki页面越来越多，页面之间的双链关系也越来越密集。双链本身可以作为检索的辅助信号——比如一个问题命中了某个页面，我可以顺着这个页面的反向链接快速找到兄弟页面，扩大候选池。这种“越用越密”的网络效应，就是复利。

我在实现时专门加了一个“问答回灌”脚本：每星期把本周用户确认过“很有用”的问答对自动转成wiki页面，并打上标签“来自问答记录”。这样不需要人工整理，知识库就会自己生长。

2. 核心细节解析与实操要点

2.1 本地llama模型选型与推理准备

本地大模型的选择直接决定整个知识库的生成质量和响应速度。不要一上来就追求最大的参数规模，量化后的7B或13B模型往往更适合RAG场景。因为RAG的主要信息来自于检索片段，模型更多是扮演“理解片段并组织语言”的角色，而不是记忆大量事实。我实测下来，7B量化模型配合好的检索链路，效果能接近甚至超过直接拿大模型硬答。

推理框架我建议选择支持OpenAI兼容接口的本地推理服务，这样可以让你后续的检索调度代码完全不用关心模型是怎么跑的，统一用HTTP请求调用。启动时务必开启长上下文模式，RAG拼接多个片段后提示词往往会超过2K，上下文窗口低于4K会很痛苦。模型量化级别在显存允许的情况下优先选Q5或更高，能明显减少“模型自己编造”的倾向。

还有一个小细节：关闭推理服务的流式输出选项，或者在后端做好缓存。因为三层降级逻辑里，第一层失败后可能会立刻发起第二层请求，流式输出会在调度层面增加不必要的复杂性。先把同步调用跑通，再优化流式体验。

2.2 RAG链路的核心组件拆解

RAG链路里最容易拖后腿的是检索部分，而不是生成部分。我的方案里做的是混合检索：向量检索负责语义相似，全文检索负责关键词精准匹配，最后用重排序模型把两边的结果合并排序。

向量检索使用的embedding模型我选的是中文效果较好的通用型模型，维度不需要太高，768维足够。文档切块是最容易踩坑的地方，直接按固定字数切会切断语义，我建议按照标题和段落结构做“语义切块”，每个块控制在600字左右，块与块之间保留20%重叠。这样既不会让模型丢失上下文，也不会因为块太小导致检索碎片化。

全文检索不需要额外引入重型服务，用SQLite的全文索引就能满足单机量级。重排序我用的是一个轻量级交叉编码器模型，它会给每个候选片段打一个“与问题相关”的分数，这个分数是三层降级里判断走第一层还是走第二层的关键依据。重排序模型虽然会增加几十毫秒延迟，但价值非常大。

重要提示：不要把重排序分数直接当作置信度来用。重排序分数只表示“这些片段里谁相对更相关”，不表示“这个片段确实能回答问题”。所以我在判断降级时，会结合召回比例、最高分数绝对值以及时间维度的投票来确定是否降级。

2.3 wiki页面的组织与双链设计

知识库的底层存储用的是wiki，而不是一堆散落的Markdown文件，原因很简单：wiki自带版本历史、标签系统和页面链接，这些特性正好能被RAG利用起来。

每个wiki页面除了正文，我都要求维护两个隐藏字段：aliases（别名）和summary（摘要）。别名的用处是增强召回，比如页面标题是“部署故障排查”，别名可以有“部署失败”“服务起不来”“exit code 1”，这样的话用户无论怎么问都能通过全文检索命中。摘要则是第二层降级的关键输入，模型在走摘要兜底时，就用每个页面的summary组成候选答案，而不是从正文里临时概括。

双链的价值体现在交叉引用上。我在页面底部手动维护“相关页面”列表，同时靠反向链接自动聚合。做混合检索时，我会把命中的页面及其一跳邻接页面都拉入候选池，会明显提升跨主题问题的回答质量。举个例子，用户问“知识库备份策略是什么”，如果“备份”页面和“数据目录结构”页面有双链，那么即使“备份”页面本身内容不全，模型也能从关联页面里找到补充信息。

2.4 三层降级的触发条件与切换逻辑

降级不能靠人工在页面里去选择，必须有一套自动化规则。我在调度层设计了一个简单的评分函数，输入是重排序分数和检索覆盖率，输出是“走哪一层”的决策。

触发第一层条件：重排序最高分超过0.6，且第一名和第二名的分数差大于0.1。这说明检索结果明确有指向性，模型可以基于片段作答。触发第二层条件：最高分在0.3到0.6之间，或者分数差距不大，此时不再拼凑正文，而是用所有候选页面的summary让模型做概括回答，附上页面原始链接。触发第三层条件：最高分低于0.3，或者没有召回任何片段，那就让模型根据问题模板明确拒绝作答。

这套阈值看起来简单，实际调整起来花了我不少时间。不同文档集合的embedding分布差异很大，同一个阈值在技术文档里很好用，换到产品手册里就可能频繁误触发。我建议把决策函数做成可配置的，并且把每次决策的日志记录下来，方便后面根据用户反馈反推调参。

3. 实操过程与核心环节实现

3.1 本地推理部署与模型加载

以我的环境为例，一台32GB内存、8GB显存的机器，跑7B量化模型毫无压力。部署的第一步是下载模型权重，我使用的是开源社区常见的GGUF量化格式，选择Q5_K_M版本，好处是文件体积适中，显存占用约5GB，还能给embedding和重排序模型留出空间。

启动本地推理服务采用类似下面的命令：

# 以llama.cpp系推理引擎为例，启动一个OpenAI兼容接口 llama-server \ --model /models/qwen7b-q5_k_m.gguf \ --ctx-size 8192 \ --n-gpu-layers 35 \ --host 127.0.0.1 \ --port 8080

启动后可以用一个简单的curl请求验证接口是否正常：

curl http://127.0.0.1:8080/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"local","messages":[{"role":"user","content":"你好"}]}'

看到返回内容就可以继续了。注意显存不够的时候把--n-gpu-layers调小，让部分层跑到CPU上，代价是速度慢一些，但总比崩溃好。

3.2 知识库索引构建与向量化

索引构建分四步走。第一步是文档清洗，把wiki导出的原始HTML或Markdown里无关的导航、页脚、模板标记全部去掉。第二步是语义切块，我写了一个基于Python的分块器，先按二级标题分节，再把超过800字的节按段落拆开，同时给每个块附加所在页面标题和URL作为元数据。

第三步是生成向量并入库。向量数据库建议用轻量级的本地方案，不需要分布式。我用的库支持余弦距离和元数据过滤，把embedding字段和元数据一起存进去。生成向量的代码大致长这样：

from sentence_transformers import SentenceTransformer model = SentenceTransformer('BAAI/bge-large-zh-v1.5') chunk_text = "你的文本块" vector = model.encode(chunk_text, normalize_embeddings=True) # 将vector写入向量库，同时存入chunk_text、page_title、url等字段

第四步是构建全文索引。把每个块的纯文本导入SQLite的FTS5表，分块器的结果原样写入，再用match语法做关键词检索。我通常会把向量检索的top 20和全文检索的top 10合并，去重后交给重排序模型。

3.3 三层降级调度代码的最小实现

整个调度逻辑可以收敛成一个函数，输入是用户问题，输出是最终答案和对应的降级层级。下面是一个去掉异常处理的最小伪代码，方便理解核心流程：

def query(question): # 1. 混合检索 vector_hits = vector_search(question, top_k=20) keyword_hits = bm25_search(question, top_k=10) candidates = dedupe(vector_hits + keyword_hits) # 2. 重排序 reranked = rerank(question, candidates) top_score = reranked[0]['score'] second_score = reranked[1]['score'] gap = top_score - second_score # 3. 三层降级决策 if top_score >= 0.6 and gap >= 0.1: context = build_context(reranked[:5]) return llama_chat(question, context), 1 if top_score >= 0.3: summaries = [p['summary'] for p in reranked[:8]] answer = llama_chat(question, summaries) return answer + "\\n\\n相关页面：" + format_links(reranked[:5]), 2 return "知识库里暂时没有找到足够的信息回答问题。你可以试试搜索这些关键词：" \ + suggest_keywords(question), 3

这段代码的重点在第三阶段：第一层返回纯答案，第二层返回答案加链接，第三层返回人工设好的话术。注意第一层因为上下文片段较多，提示词里一定要强调“只根据提供的材料回答，不要联想”，否则llama会把训练记忆里的内容也混进来。

3.4 核心参数配置与调优记录

参数调优是整个项目最磨人的部分，我直接给出实测过的一组基线配置，再说明调整方向。

我调整最频繁的是重排序最高分阈值。如果知识库里有很多高度相似的文档，比如多个版本的接口说明，这个分数会普遍偏高，但答案却不一定是用户想要的。此时可以把阈值提高到0.7，同时结合“命中的页面最近是否有更新”这个时间信号加权，效果更好。

4. 常见问题与排查技巧实录

4.1 为什么检索不到明显存在的内容

这个问题我遇到过不下五次，原因通常不是内容没入库，而是查询表达和文档用词差异太大。比如文档里写的是“初始化配置”，用户问的是“怎么开始用”，向量模型如果没学到位，召回结果就会很差。

排查技巧是先把问题拆词，拿到全文检索里跑一下，看能不能命中。如果全文检索能命中而向量检索不行，说明embedding模型对同义表达理解不足，可以换更强的embedding模型，或者给wiki页面补充更多别名。如果两边都命中不了，那就是文档本身没有覆盖到这个说法，需要回灌内容。

另一个隐藏原因是文本块切得太“整齐”，把一句话拆到了两个块里。我加了一个很笨的检查工具：把切出来的块打印出来人工看一遍，尤其是标题和代码块附近。不要让切块器把代码示例或者表格从中间切断，因为重排序模型对破碎的代码块会给出很低分，但内容明明是可用的。

4.2 模型回答内容明显编造

这是RAG项目最常见的问题，也是我做降级设计的动机。如果模型经常答非所问，第一步先检查当前走的哪一层。如果走的是第一层，但答案里出现了知识库里不存在的具体人名、数字或操作步骤，那多半是提示词没有约束住模型。

我的做法是在第一层的系统提示词里写死一段话：“你只能使用上下文里出现的材料进行回答。如果上下文材料不足以回答，请明确回答‘根据当前知识库无法确认’。”不要相信模型会天然遵守，需要反复强调。还可以把温度调低到0.1试试，会显著降低幻觉概率。

如果降级逻辑本身没有生效，检查一下重排序分数的分布。很多时候“检索内容不相关但分数虚高”是因为整个候选集都跟问题相关，但互相之间没有区分度。此时不应只看最高分，还应该计算第二名到第五名的平均分，如果平均分也很高但第一名和其他差距小，说明内容同质化严重，需要更精细的文本块切分或引入更多过滤条件。

4.3 降级策略被频繁触发，体验变差

频繁降级不等于系统做错了，但说明第一层质量确实不够。我曾经把一个技术手册接进来试跑，几乎70%的问题都走了第二层，原因就是文档本身写得过于概括，每个页面都像目录一样，没有具体操作步骤。

解决办法不是去调阈值，而是补内容。我做了个“空白页面检测”脚本，找出那些摘要过于简短、正文低于300字的wiki页面，然后手动把详细说明补进去。知识库这种东西，内容量决定检索质量上限，算法只能在这个上限内发挥作用。

另外，第二层降级时生成摘要答案，如果提示词里没有要求模型“逐条列出页面标题并附一行说明”，模型很容易把摘要合并成一段流畅但无出处的叙述。我在第二层提示词里加了一个硬性格式要求：每页对应一行，以“来源：页面标题”结尾，实测好评率提升了很多。

4.4 显存占用过高和推理速度慢

本地llama跑起来之后，显存占用会比模型本身多出不少。原因是RAG场景下上下文长度不稳定，模型会预分配一部分KV cache。我建议把上下文长度固定下来，比如直接设置ctx-size 8192，不要把窗口开得太大。同时用--n-gpu-layers控制GPU层数，一般把95%的层放到GPU，剩下的留在CPU，性能差距很小但能避免显存溢出。

推理速度慢通常是同时请求太多导致的。我的调度层用了单进程线程池，默认并发数是2，实测7B模型排队响应比并发乱跑更稳定。如果一条请求查询的内容包含很多候选片段，前端等十几秒是常事，这里可以在API层加一个“降级说明”字段，让前端根据层级展示不同UI，比如第一层直接展示答案卡片，第二层展示答案与参考资料列表，第三层展示搜索入口，用户体验会好很多。

4.5 知识库更新之后检索结果不变

这个问题通常是向量索引没有随wiki内容同步更新导致的。我最初的做法是每天晚上全量重建索引，但白天更新页面之后，至少还要等半天才能被检索到，非常影响使用。后来改成事件驱动更新：wiki页面每次保存时，触发一个后台任务，只重新embedding被修改的页面及其关联页面，并更新向量库中对应的记录。

注意“关联页面”也要更新，因为页面双链会让被引用页面的“反向链接”发生变化，相关页面的摘要也可能需要重写。这块是复利机制的关键，如果只想改一行错别字就触发全量更新，成本太高；完全不更新又会导致检索结果失真，所以事件驱动更新是最平衡的方案。

5. 经验沉淀与复利循环实践

5.1 把问答记录变成新知识

复利的第一步是记录。我给每次查询都打上日志，包括问题、命中的页面、走的降级层级、最终答案、用户是否点了反馈按钮。一开始数据稀疏，但跑了一个月之后，这些数据就是最宝贵的知识来源。

我设计了一个简单的“答案保温”机制：当一个问题连续被问到三次以上，且每次走的是第二层降级，系统会自动生成一个待办提醒，让我把这个问题写成一篇专门的FAQ页面放进wiki里。页面里不仅要有最终答案，还要把当时调到的最佳上下文片段也放进去，相当于直接给未来的检索提供靶子。这样操作过几次之后，很多常见问题都能走第一层直接精准回答了。

5.2 wiki版本历史作为评测数据集

wiki自带的版本历史被我拿来当评测集用。我会挑一些“被修正过”的页面，把旧版本设为错误答案，新版本设为正确答案，然后构造提问让RAG去检索。如果检索结果还总是把旧版本排前面，说明切块或重排序对新内容权重不足，需要调整时间衰减因子。这一招相当于免费的金标准测试集，比手动标数据省事多了。

时间衰减是我后期加入的：重排序分数乘以一个随页面修改时间衰减的系数，比如一个月内的页面乘1.1，三个月内的乘1.0，更早的乘0.9。这样能让修正后的知识优先浮出水面。注意衰减不能太激进，否则旧知识的长期积累作用会被抹掉。

5.3 持续迭代的一点体会

这套系统跑了大半年，最大的体会是“三层降级”不是一种技术妥协，而是一种产品思维。每次模型回答不完美，都是知识库成长的机会。模型负责连接已有知识，人的修正负责扩充知识边界，wiki负责把两者沉淀下来，三者循环起来就是复利。

如果你也想搭一套类似的系统，我建议不要一上来就照搬别人的完整架构，先把最简单的一层RAG跑通，再逐步加入第二层、第三层和回灌机制。每加一层都仔细记录前后效果差异，你就能逐渐摸清自己知识库的脾气。我最后想分享的实用小技巧是：降级日志里一定要记录当时的检索片段ID列表，否则日后想复盘“这个问题当时为什么答成这样”会完全无从下手。这个习惯帮我排查掉了很多棘手的案例，希望对你也有用。