企业官网建设流程全解析

AI搜索这个词，这两年被频繁刷屏。从最初聊天机器人式的“给一段答案”，到现在很多团队用开源大模型自建检索问答系统，信息获取的方式确实在被重新定义。我身边不少开发者朋友都在琢磨同一件事：把开源模型接进自己的数据流，搭一套真正能用于内部知识库或垂直行业检索的AI搜索应用。这条路覆盖了语义召回、重排、生成、引用溯源，技术栈完整且充满坑点，踩完之后对“信息检索”的理解完全不同。

这篇文章适合谁？手头有文档积累、想搞AI搜索问答的开发者，正在评估开源模型选型的技术决策者，以及刚入门RAG检索想建立完整认知的同学。我会从技术逻辑、系统设计、落地实操、问题排查到格局变化，讲清楚AI搜索为什么能在开源模型推动下重新塑造信息检索的未来，也把我实操中的参数选择、踩坑记录和一些经验判断分享出来。

1. 新浪潮背后的技术拐点：为什么AI搜索突然“能打”了

1.1 传统搜索的核心痛点依然存在

传统搜索引擎的核心流程是：输入关键词、分词、倒排索引、词频统计、返回网页链接。这套机制在过去二十年极其成功，但它的根本劣势一直存在——它匹配的是“字面”而不是“意图”。当你问“最近有什么轻薄的办公本推荐”，传统搜索会把“轻薄”“办公本”“推荐”切词后去匹配网页，返回一堆电商详情页和评测文章，你需要自己打开好几个页面，人工筛选、对比、综合，才能得出一个相对靠谱的结论。

这个过程中有三类典型问题：一是有价值的信息可能分散在很多页面里，且互相矛盾，需要用户自己判断到底谁对；二是长尾查询或口语化表达，关键词匹配效果很差，比如“代码跑着跑着内存就没了咋回事”；三是搜索结果只给线索，不给答案，用户还得二次加工。本质上，传统检索是“候选集召回技术”，它并不具备“综合理解与生成答案”的能力。对应到技术术语，就是缺了语义理解和内容综合这两个关键环节。

1.2 大模型把“匹配”升级成“理解加生成”

大模型技术介入检索链路后，信息获取方式发生了质变。现在一个典型的AI搜索流程是：用户输入自然语言问题，系统先做意图识别和查询改写，然后走向量召回和关键词召回，再做重排，最后把高相关的文档片段喂给大模型，生成一段结构化的回答，并附上引用来源。

这个链路相比传统搜索，最本质的变化是增加了“语义检索”和“生成综合”。语义检索把问题和文档都映射成向量，通过余弦相似度找到“意思相近”的内容，而不是字面相同的内容。这解决了口语化表达和同义改写的问题。生成综合则把原本需要用户自己跳转、阅读、比较的活儿交给了模型，直接输出带结论和依据的回答。

如果用一个生活类比来说，传统搜索像给你一大堆菜谱，让你自己买菜、配菜、做菜；AI搜索像一个厨师先读了所有菜谱，再按你的口味直接端上一道菜，同时告诉你这道菜参考了哪几个菜谱。这种体验上的跃升，让用户对检索系统的期望也彻底改变了。

1.3 开源大模型在其中的角色不可替代

为什么这个浪潮会跟开源大模型绑定在一起？原因很简单：闭源大模型接口按Token收费，单次查询成本在几厘到几分钱之间，对于日访问量上百万次的搜索系统来说，成本是不可承受的。更关键的是，企业数据不能随便出域，很多公司根本不允许内部文档通过外部API处理。把模型部署在自有环境里，数据全部留在内部，这是不开源就没得选的事情。

开源模型在近两年的能力进步也非常明显。我记得前两年跑本地模型，几B参数（B指十亿参数）的模型生成的回答经常逻辑混乱，更不用说做带引用的检索问答了。但现在的开源模型体系已经完全不同，主流开源系列在中文理解、长文本处理、指令跟随方面都达到了足够可用的水平，配合量化技术，一张消费级显卡就能跑起来。社区生态里还有大量配套的向量模型，中文语义向量表现稳定，检索精度已经可以支撑真实业务。

开源模型降低了AI搜索的入场门槛，让一个几个人组成的小团队也有能力搭出自己的检索问答系统。这个趋势直接刺激了应用层的爆发：企业内部知识库、学术文献检索、电商导购问答、医疗科普解析、法律条文查询……各种垂直场景的AI搜索应用像雨后春笋一样冒出来。我可以负责任地说，开源模型是这波AI搜索创新浪潮里最核心的“基础设施”。

2. AI搜索系统设计与开源模型选型要点

2.1 经典RAG链路拆解：不是所有人都在做检索

很多人一提到AI搜索就想到RAG（检索增强生成）。实际搭建时，链路里的每一步都藏着坑。我按照生产环境的设计思路，把一个常规AI搜索系统拆成六个核心模块。

• 查询分析：识别用户问题的意图、实体、是否带限定条件。比如“2024年的旗舰手机对比”和“三年前发布的手机还值得买吗”，前者需要时间限定，后者需要对比和年代判断。这一步通常用一个小参数模型就能做，不一定要走大模型。
• 查询改写：把口语化、有歧义的输入改写成更适合检索的查询词。比如用户输入“涨工资申请书怎么写”，系统可以改写成“员工调薪申请报告范文”“涨薪申请流程模板”等多个检索子查询，以此提高召回率。
• 混合召回：同时走向量召回和关键词召回两条路。向量召回负责语义泛化，关键词召回负责精确匹配专有名词、编号、型号，两者结果做融合。这一步效果好坏的直接决定因素是向量模型和切分策略。
• 重排：把召回回来的候选片段按真实相关性精排。向量相似度高不代表内容正确，粗粒度召回后必须用重排器精调，否则生成阶段很容易被误导。
• 生成回答：将重排后的片段拼接进Prompt，让大模型输出答案并标注引用。这个环节的真正技术含量在于Promot设计和后处理策略，比如怎么防止模型只看了片段标题就臆造内容。
• 缓存与反馈：对高频问题和答案做缓存，节省算力；对用户反馈做收集，形成闭环优化数据。

这个链路组合的巧妙之处在于，它是“多级筛选加最终生成”的结构。每一级只做自己最擅长的事，控制各自引入的错误率，最终输出质量才能稳定。如果只想用一个模型解决全部问题，要么召回不准，要么生成幻觉严重。

2.2 开源模型选型的核心指标

开源模型领域每隔一段时间就会冒出新面孔，很多人选型时容易陷入“追新”的误区。我自己实际跑过几个模型之后，总结出四个在AI搜索场景里真正重要的指标，而不是单纯看跑分。

第一是上下文长度。检索问答场景经常把多段长文档拼进Prompt，如果上下文窗口太短，要么拼不下，要么只能粗暴截断，检索效果大打折扣。我建议至少选择原生支持8K上下文的模型，最好能支持更长上下文，为后续扩展留空间。第二是中文指令跟随能力。AI搜索的Prompt里有严格的格式要求，比如“如果片段中没有相关信息，必须回答未知”，模型会不会老老实实照做很重要。实测中有些模型英文表现不错，中文指令一变就“放飞自我”，这需要针对性测试。

第三是推理显存和速度。一个7B参数的量化模型大概占用6-8G显存，生成速度约每秒20-40个token；13B模型则可能需要12-16G显存。如果你的系统期望高并发，就要考虑是否使用更轻量模型或用多卡部署。第四是引用标记的稳定性。AI搜索的答案要求带上[1][2]这类引用编号，模型在长回答中是否会把编号写丢、写错位置，是影响用户信任度的关键细节。有些模型在短回答里没问题，一长就乱了，这靠评测集才能暴露出来。

参考我的经验，可以把模型选型分成三档：轻量档（几十秒内能响应，用于简单问答和意图识别），均衡档（兼顾速度和推理质量，适合大部分知识库问答），重量档（离线分析、复杂推理场景，对显存要求高但效果最好）。实际项目里我们一共测试了国内外多个开源模型，最终落地用均衡档模型做主力，配合轻量档模型做路由分流，整体成本和效果比较理想。

2.3 数据切分与向量化：检索效果的地基

如果生成模型决定了AI搜索的上限，那么数据切分与向量化就决定了实际能达到的下限。很多同学第一次搭完系统，发现模型经常答非所问，排查到最后发现是切片不合适。

切分文档需要根据内容类型区别对待。Markdown或HTML格式的文档，尽量按照章节、标题层级切分，保留结构信息；纯文本或PDF解析出来的内容，按段落切分，再根据Token数设置上限和重叠区域。一般我建议每片控制在200-500个Token之间，片与片之间保留10%-15%的重叠，防止内容在边界被切开导致语义不连贯。更细一点，代码类文档要保留函数完整性，合同文书要保留条款编号，这些需要做自定义切分逻辑。

向量化方面，最关键的参数是Embedding模型的选择和维度大小。Embedding模型负责把文本变成向量，如果模型本身不够强，后续所有环节都受影响。实测中，通用型向量模型对垂直领域术语的表示能力往往不够，比如医学、法律领域的罕见表述，最好能用领域微调的向量模型或在自有数据上做增量训练。向量维度不是越大越好，维度越高存储和计算成本越大，检索精度的提升会边际递减。检索时常用的相似度计算方式是余弦相似度，阈值一般设置在0.6-0.8之间，低于阈值的候选直接丢弃，防止无关内容干扰生成。

这一环节出了问题是比较隐蔽的，表面看是“回答不好”，实际是“根本没召回对”。所以建议每个项目在启动时，先切几千条高质量问答对做检索精度基线测试，把它当成评估一切后续改动的基础。

3. 从零搭一套AI搜索系统：完整实操流程

3.1 整体组件清单与部署拓扑

纸上谈兵聊理论是不够的，这里我说一下我实际搭建一套AI搜索系统的过程。场景是企业内部知识库问答，数据源是几百份产品文档、技术方案和工单记录，总量在50万Token左右，属于中小型规模。整体组件包括：

• 文档解析与预处理模块：负责读取PDF、Word、Markdown等格式，转成纯文本并清洗格式噪声。
• 切片与向量化模块：负责按结构切分长文档，调用Embedding模型生成向量，写入向量数据库。
• 向量数据库：负责存储向量和原文映射，支持相似度检索和过滤条件。
• 问答服务接口：接收用户问题，执行查询分析、改写、召回、重排、生成全链路逻辑。
• 大模型推理服务：加载开源模型，提供生成能力。
• 前端交互页面：简单的聊天窗口，支持展示引用来源。

这一套系统部署在一台32G显存的GPU服务器上，所有模型都跑本地，数据不出域。实际上对于50万Token这种量级，连GPU都不需要多高配，瓶颈主要在推理服务的并发能力上，这块可以用消息队列做异步削峰来缓解。

3.2 全流程核心步骤与关键参数

我把搭建过程拆成六个可以照着做的步骤。

第一步，数据处理。把原始文档统一转成纯文本，处理掉页码、页眉页脚、表格噪点。这一步最容易被忽略，但重要性极高，因为大模型不懂PDF里的OCR错别字，也不懂被分页切断的段落。清洗完后做段落合并，把同一标题下的连续段落拼接成完整语义块，再进行切片。我在这个项目里每片控制在300Token左右，重叠30Token，实测效果比较稳定。

第二步，向量化入库。把切片内容提交给Embedding模型，生成维度为768的向量，连同原文文本、文档来源、标题、章节路径一起存入向量数据库。入库前需要建立索引，索引类型直接影响检索速度。项目数据量不大，我直接用了暴力检索加GPU加速的方式，速度足够快。数据量大之后，建议改为HNSW这类近似最近邻索引，检索速度会提升几个数量级，精度损失可接受。

第三步，查询分析与改写。用户问题到达服务端后，先用轻量模型判断问题类型：是否与文档相关，是事实型查询还是建议型查询，需不需要时间过滤。如果问题比较长或口语化，让大模型生成2-3个检索子查询。这一步能显著提高召回率。比如“我们产品的保修政策到底是怎样的，坏了自己能不能拆”会被改写成“产品保修政策说明”“用户自行拆解保修是否失效”两个查询。

第四步，混合检索与融合排序。每个改写后的查询分别走向量召回和关键词召回，取Top20结果，然后做合并去重。融合排序我用的是加权融合方式，向量相似度权重0.7，关键词BM25得分权重0.3。这个比例是我多次试出来的，偏重向量能够保住语义泛化能力，但完全放弃关键词会导致精确型号和报错信息召回变差。

第五步，重排精排。把Top20候选片段拼接后，让重排模型逐对打分，取Top5片段作为生成阶段的上下文。这个环节值得多说一句，重排模型的目的是解决“相似但不相关”的问题。有些片段在语义上与查询有重叠，比如聊话题A的文档里顺带提了一句相关概念，向量检索会把它捞回来，但重排能把它压下去。我用的重排策略是对每个查询-片段对计算相关性分数，保留分数最高的片段，再按原文顺序排列它们，避免上下文顺序错乱，影响生成逻辑。

第六步，生成回答与引用后处理。将Top5片段按下述方式组织成Prompt：开头说明系统角色，中间放检索片段并标注源编号，结尾强调“如果没有依据就直接说不知道，禁止编造”。模型生成回答后，做一次引用后处理校验，检查每个[编号]是否能对应到实际存在的片段，如果模型引用了不存在的编号，要么重新生成一次，要么降级为只输出片段里直接找到的内容。这一步是控制幻觉的最后一道闸门。

3.3 一个最小可用的问答服务实现思路

这里我给出一个简化版的实现思路，用伪代码说明，方便理解整个链路串联。

def ai_search(query): # 查询分析 intent = light_model.analyze(query) # 查询改写 sub_queries = llm.rewrite(query) # 混合召回 candidates = [] for sq in sub_queries: vector_hits = vector_db.search(sq, top_k=20) keyword_hits = bm25_search(sq, top_k=20) candidates.extend(merge(vector_hits, keyword_hits)) candidates = dedup(candidates) # 重排精排 top5 = reranker.rerank(query, candidates, top_k=5) # 构造Prompt context = build_context(top5) prompt = system_prompt + context + query # 生成并校验引用 answer = llm.generate(prompt) answer = verify_citations(answer, top5) return answer, top5

这段逻辑看起来不长，实际要稳定跑起来，每一行背后都需要大量细节支撑。比如build_context时，如果片段长度超过上下文上限，需要按重要度裁剪；llm.generate时，要设置合理的温度参数（我建议0.2-0.3），温度太高回答发散容易幻觉，太低则显得机械；verify_citations本身也是一个要细心实现的逻辑，不是简单字符串匹配能解决的。

部署方面，最合理的做法是把模型推理服务独立出来，和业务服务通过HTTP或gRPC通信。这样模型升级、重启、量化调整都不会影响业务主流程，也能单独做推理服务的扩容。我用的是容器化部署，模型推理服务挂载GPU资源，业务服务用CPU跑召回和重排，两者解耦，运维省心很多。

3.4 量化配置与资源消耗估算

很多人在本地跑模型，第一个需求就是模型量化（把模型权重从高精度变成低精度，以降低显存占用）。量化其实是在精度和资源占用之间取平衡。主流开源模型支持4bit和8bit量化，实测下来，4bit量化会让模型在某些专业术语的生成上出现轻微质量损失，但显存占用几乎减半。如果显存吃紧，可以量化到4bit；如果追求回答质量，8bit更好一些。

我跑7B模型的时候，32G显存的服务器同时加载生成模型、Embedding模型和重排模型，整体显存占用在22G左右。为了让服务更稳定，我把Embedding模型和重排模型合并到一个常驻进程，生成模型单独占一个进程，避免高峰期的显存争抢。服务器CPU方面，向量数据库检索和文档解析主要在CPU上执行，建议至少8核16G内存，否则高并发时容易卡顿。

并发能力是另一个需要实事求是的指标。单张GPU运行一个7B量化模型，单请求生成300个Token大约需要5-8秒，不考虑并发优化的话，单机同时只能处理2-4个请求，再高GPU就显存不足了。解决方案有几个方向：一是对高频问题做语义缓存，命中后直接返回历史答案；二是用流式输出，让用户边看边等内容生成，主观等待感大幅降低；三是在业务层面做查询路由，简单查询走一个更小的模型快速回答，复杂的问题才动用大模型，分流后整体并发能力可以提升一倍以上。

4. 实操中的典型问题与排查技巧

4.1 答非所问：十有八九是召回坏了

很多第一次搭AI搜索的小伙伴，遇到“模型回答和问题完全对不上”的情况，第一反应是换更大的模型。但我可以告诉你，大部分情况下，问题根本不在生成模型，而在更前面的召回阶段。我自己的Debug流程通常是先看召回结果，把用户问题对应的Top5片段打印出来，直接判断这些片段“看起来像不像正确答案”。

如果Top5片段本身就跑偏了，那后面再怎么调整Prompt都没用。召回跑偏的原因一般有那么几类。最常见的是切片粒度不对。比如一个产品技术文档里，“网络配置”这一节内容很长，被切成多个小片后，每个小片都只包含部分配置参数，查询“如何配置静态IP”时，向量检索容易捞到同一节的其他小片，看起来相关，实际没命中正确答案。解决办法是尽量合并同一个标题下的完整段落，再用章节路径作为上下文补充。

另一个常见原因是Embedding模型选用不当。通用Embedding模型对长文本、术语密集的领域表现较弱。我的经验是针对项目数据量，准备几百条领域内问答对，对Embedding模型做轻量微调。有些场景下甚至要换用领域适配的Embedding模型。这一步启动时不情愿，碰到检索效果瓶颈的时候才会意识到它的重要性。

4.2 幻觉和引用错误：用“证据约束”对抗编造

大模型天生爱“一本正经地胡说八道”，在AI搜索场景里，幻觉是比答非所问更麻烦的问题，因为答案看起来结构完整、语气笃定，用户很难分辨。应对幻觉，我有一套组合策略。

第一，Prompt中强制加入证据约束。明确告诉模型：“以下内容来自检索片段，回答只能基于片段信息。如果片段中没有任何相关内容，请回复：未找到相关信息。”不要小看这句话，它对降低幻觉有明显作用。第二，生成后做引用校验，如前面所述，如果模型引用了不存在的片段，或生成内容明显超脱片段范围，直接重试或回退。第三，设置温度参数在0.2以下，降低随机性。第四，在回答的末尾自动附上“回答依据为以下文档”，让用户能自查。

要说明的是，这些策略只能降低幻觉概率，不能完全消除。所以在系统设计层面，AI搜索应该始终向用户展示引用来源，把“参考了哪些文档”作为回答的一部分呈现，而不是让用户面对一段无来源的结论。这也符合搜索场景用户对可信度的天然要求。

4.3 查询延迟高：先缓存，再分流

AI搜索系统的延迟体验与普通关键词检索完全不同。广告很省时间，但传统搜索返回结果通常0.1秒级，而AI搜索需要生成几百字回答，动辄几秒钟。如果你的用户习惯了“秒出结果”，你就需要想办法优化延迟。

我的建议是分三层解决。第一层是缓存层，把用户问题和标准答案都向量化，每次查询进来先和缓存库做相似度匹配，命中高相似度就直接返回。实测里，企业内部知识库的常见问题重复率很高，缓存命中率能做到20%-30%，这对整体负载的减轻是质变级的。需要注意的是，答案缓存要设置平滑过期时间，否则文档更新之后，缓存里的旧答案还会继续输出，引起内容不一致。第二层是分流层，简单问题走小模型或直接走规则匹配，比如“有哪些文档”“某功能在哪个模块”这类固定句式问题，完全可以写规则，不消耗大模型推理资源。第三层是异步流式输出，首字延迟控制在1秒以内，后续内容边生成边推送，用户从“看着转圈等待”变成“看着文字逐渐出现”，实际体感流畅很多。

4.4 数据更新后检索不到：索引同步的坑

知识库数据不是静态的，文档会增删改。迭代过程中，我遇到过几次系统上线后新文档怎么都检索不到的情况，最后定位到是索引同步的时序问题。增量文档解析完成后，向量已经入库，但检索服务的缓存还保留着旧的文档列表，或部分是增量更新失败、部分元数据丢失，导致召回阶段直接把新文档过滤掉了。

这个问题的排查流程，建议分三步。第一步检查数据入库日志，确认文档解析和向量化是否真的完成；第二步检查向量库里的文档记录，用检索脚本直接查一个新文档里的特有词组，如果向量记录存在但检索不到，问题在索引或过滤条件；第三步检查服务配置，看有没有业务层面的时间过滤、权限过滤未更新。我踩过最明显的坑是在向量数据库的元数据过滤条件里，把“有效”字段的布尔值写反了，新文档全部被过滤掉，开发时数据量小发现不了，数据量一大就暴露了。所以上线前一定要准备一条“新增文档后能否被检索到”的自动化测试用例。

5. 开源大模型如何重塑信息检索的未来格局

5.1 检索系统从“黑盒依赖”走向“模块化组合”

过去信息检索领域的核心系统基本封闭，技术栈厚重，普通团队只能在边缘调参。开源大模型改变了这种格局。现在的检索系统可以被拆成几个可替换的模块：Embedding模型可以换，生成模型可以换，重排模型可以换，向量库可以换。每个环节都有开源方案，且质量可以达到生产标准。

这种模块化最大的价值是让企业不再被单一厂商绑定。你可以先用一套开源组件快速搭建原型，验证效果后再针对瓶颈模块做专项优化。比如初期用通用重排模型，后期换领域微调的重排模型，或自研更精细的融合排序逻辑。这种演进路径在闭源时代是难以想象的，因为每个环节都被封装在别人手里。开源模型把技术链路的透明度提上来了，我们终于能看清楚每一个环节到底在做什么。

演进方向也指向了更强的组合能力。未来的AI搜索系统很可能会是两个并行的路由器：一个路由给“模型能力”，根据问题难度选择轻量模型还是重量模型；一个路由给“数据源”，根据问题领域选择向量库里的不同集合或外部API。这种多路由分层架构，会进一步压低单次查询的算力成本，让百万级日活也能托得住。

5.2 应用场景拓展：从通用搜索到行业智能助理

开源模型的落地能力把AI搜索的战场拉到了垂直行业。企业内部知识库是最先受益的场景，以前的搜索系统只能帮你找到文档标题，现在的AI搜索能直接回答具体问题，并标出答案出自哪份文档的哪个章节。这等于把全公司的经验沉淀变成了一个随时问、随时答的虚拟专家。

学术领域同样变化明显。研究者面对海量论文，以前只能靠关键词碰运气，现在可以先让AI搜索系统对多篇论文做语义级定位，找到关键方法和实验结论，再人工精读。法律与政务场景里，检索系统需要对条文进行精确引用，开源模型的本地部署优势在这里体现得很直接——敏感数据完全不出域，同时模型可以被微调以适应法律文书逻辑。医疗科普场景也在尝试AI搜索，但需要注意，这类应用对事实核查的要求极高，目前更适合辅助定位资料，而非直接面向患者给结论。

在这些场景里，AI搜索的共同价值是从“给链接”进化为“给依据”。用户获得的不只是一串URL，而是整理好的事实、观点、引用来源，决策效率极大提升。

5.3 未来趋势：多模态、Agent化与搜索主动化

信息检索的未来不会止步于文本问答。多模态检索是一个明确方向，现在的文档里包含大量图表、截图、流程图，而开源的视觉语言模型正在快速成熟，把图像内容转成可检索的文本描述，甚至直接基于图像回答问题的能力，会逐步进入实际系统。比如“这张拓扑图里哪里可能配置错误”这样的查询，未来可以通过模型的视觉理解能力结合检索链路去回答，而不只在文本里打转。

Agent化也是重要趋势。AI搜索不再是被动地等用户提问再返回结果，而会演变为一个“主动探索型智能体”。它会根据用户目标，自动拆分任务，执行多轮检索，判断信息是否足够，必要时追问用户或切换数据源，最后输出一份完整报告。这种搜索形态已经超越了传统意义上“检索”的概念，更接近“研究助理”。

从信息生态的视角看，搜索行为本身也会反哺模型迭代。用户在AI搜索里的点击、追问、对答案的评价，是高质量的人类反馈数据，可以用来微调模型和优化重排策略。谁能把这套反馈闭环跑起来，谁就能在未来的信息生态中占据主动。

5.4 想跟进这个浪潮，我的一点务实建议

不要等新模型发布再行动，现在就用已有的开源方案搭一个最小系统。选一个小场景、一批文档、一个开源模型、一个开源向量库，用一周时间把它们串起来，你就能获得对AI搜索最真实的直觉。在这个过程中，重点记录三个数据：检索精度、回答延迟、幻觉率，用它们驱动后续优化。模型更新换代很快，但链路架构和评测方法论是相对稳定的，那些经验会成为你长久的资产。

我自己的体会是，AI搜索的落地难点从来不在某一个单点技术上，而在全链路的系统整合和持续评测。开源模型让这个链路变得可用，但不代表它开箱即用。你需要像对待一个产品一样对待你的检索系统，持续调整切分、重排、Prompt、缓存策略，才能让它真正扛住并发、稳定输出。

这篇内容的最后，分享一个小技巧。你可以用一组日常工作中常被问到的问题，固定成评测集，每次对系统做任何改动后，都跑一遍这组数据。用“回答正确率”和“引用可用率”两个指标监控效果。只要评测集覆盖了典型场景，系统的整体健康度经常能超出你的预期。我每次模型升级、切分调整、阈值修改之后，都会靠这个评测集做回归验证，省掉了大量凭感觉调参的时间。这套方法，也推荐你从第一天搭系统就用起来。