企业官网建设流程全解析

1. 从“刷榜”到“落地”：为什么真实场景成了大模型的新战场

过去两年，我身边做AI的朋友聊天的画风经历了三次明显转变。2023年上半年，大家见面第一句是“你那边卡够不够”；2023年下半年变成“你们微调用的什么数据集”；到了2024年，话题几乎统一成了“你们那个场景到底跑通了没有”。这个变化本身就说明了一件事：大模型的技术红利期正在收窄，真正决定一个AI项目能不能活下去的，不再是模型参数有多大、榜单排名有多高，而是它有没有扎进一个真实、具体、有人愿意买单的场景里。

我自己是从2022年底开始接触大模型应用的，最早也走过一段弯路。那时候觉得只要把模型部署起来、接口调通、做个聊天界面，就算“做了AI”。结果拿去给几个做传统行业的朋友看，他们的反应出奇一致：“这东西挺好玩的，但我用它干嘛？”这句话当时把我问住了。后来我才慢慢想明白，模型能力再强，如果找不到一个具体的业务切口，它就只是一个昂贵的玩具。所谓“真实场景”，说白了就是有人愿意为这个AI的输出结果付出时间、金钱或者注意力，而且这个付出是可持续的。

这篇文章我想聊的不是“大模型有多厉害”这种已经被说烂的话题，而是从一个一线开发者的角度，拆解一下当大模型进入真实场景时，到底会遇到哪些坑、需要做哪些取舍、以及有哪些可以直接抄作业的思路。适合的读者包括：正在做AI应用开发但卡在落地环节的工程师、想用大模型改造自己业务流程的产品经理、以及那些看着大模型很热闹但不知道从哪里下手的技术负责人。我会尽量少讲概念，多讲我实际踩过的坑和验证过的做法。

2. 真实场景到底“真”在哪里：三个判断标准

2.1 标准一：需求是否足够“窄”且“痛”

我见过太多项目死在“什么都想做”上。一个团队拿着通用大模型，今天想做法律咨询，明天想做医疗问答，后天又想切教育赛道。这种打法在2023年可能还能靠信息差拿到一些关注，但到了现在，几乎没有任何生存空间。真实场景的第一个特征就是足够窄。窄到什么程度？窄到你能够用一句话说清楚“这个AI是给谁、在什么情况下、解决什么具体问题”。

举个例子，我认识一个做外贸的朋友，他没有去做什么“外贸AI助手”这种大而全的东西，而是只做了一个功能：把客户发来的英文询盘邮件，自动提取出产品型号、数量、目标价格、交货期这四个字段，然后生成一个结构化的表格。就这么一个看起来非常简单的功能，他每个月愿意付几百块钱使用。为什么？因为他的业务员每天要处理上百封询盘邮件，人工提取这些字段平均每封要花三到五分钟，而且经常漏看或者看错。这个需求足够窄，窄到可以用一个提示词模板加一个解析逻辑就搞定；也足够痛，痛到愿意为它持续付费。

反过来，那些“万能AI助手”类的产品，看起来什么都能做，但用户真正需要的时候往往发现它什么都做不好。这不是模型能力的问题，而是场景定义的问题。通用能力意味着没有针对特定场景做优化，没有优化就意味着在关键环节上不够可靠，不够可靠用户就不会把真正重要的事情交给它。

2.2 标准二：容错空间是否足够大

这一点是我踩过最大的坑。早期我做一个合同审查的AI工具，想法很美好：把合同丢进去，AI自动标出风险条款。技术上确实能跑通，模型也能给出一些看起来有道理的分析。但问题在于，合同审查这个场景的容错空间极小。如果AI漏掉了一个关键条款，或者把一个正常条款误判为风险，用户可能要承担实实在在的法律风险。这种情况下，用户对AI的信任度会急剧下降，用了一次就不敢再用第二次。

后来我调整了思路，把同样的技术用在了另一个场景上：帮法务团队做合同条款的初步分类和归档。这个场景的容错空间就大很多，因为分类错了，人工复核的时候改一下就行，不会造成实质性损失。而且因为AI把大部分重复性工作做了，法务团队反而愿意花时间去复核和修正。这就是容错空间带来的差异：同样是法律领域的AI应用，一个因为容错空间太小而失败，另一个因为容错空间足够而跑通。

所以判断一个场景是否“真实”，一定要问自己：如果AI输出错了，后果是什么？如果后果很严重，那这个场景在当前技术条件下就不太适合直接让AI做决策，最多只能做辅助。如果后果可控，那就可以大胆尝试。

2.3 标准三：是否有持续的数据回流

这一点经常被忽略，但我觉得它是区分“一次性项目”和“可持续产品”的关键。所谓数据回流，就是用户在使用AI的过程中，能不能产生新的数据来反哺模型或者提示词优化。如果一个场景用完就走，没有任何反馈机制，那这个AI的能力就永远停留在初始状态，不会随着使用变得越来越好。

我做过一个帮科研人员做文献摘要的项目。一开始只是简单地调用模型生成摘要，用户看完就关掉了。后来我加了一个很小的功能：让用户可以对摘要进行打分和修改。就这么一个改动，三个月积累了上千条修正数据。我用这些数据做了一轮轻量微调，摘要质量有了肉眼可见的提升。更重要的是，用户看到自己的反馈被采纳了，使用意愿也明显增强。这就是数据回流带来的正向循环。

反过来，如果一个场景没有数据回流机制，那它本质上就是一个“套壳”工具，今天用这个模型，明天换那个模型，用户感知不到任何差异，也就没有任何粘性。所以在选择场景的时候，一定要想清楚：这个场景能不能产生持续的数据反馈？如果不能，那它可能只是一个短期项目，而不是一个长期产品。

3. 从技术视角拆解：真实场景需要什么样的AI能力

3.1 不是所有场景都需要微调

很多人一提到做AI应用，第一反应就是“我要微调一个行业大模型”。这个想法在2023年很流行，但到了现在，我的经验是：大部分场景根本不需要微调。微调的成本很高，需要准备高质量的数据集、需要租用GPU资源、需要反复调参和评估，而且微调后的模型往往会损失一部分通用能力。对于大多数场景来说，一个好的提示词工程加上一个合适的检索增强生成（RAG）架构，就能解决百分之八十的问题。

我做过一个对比实验：同一个客服问答场景，一组用提示词工程加RAG，另一组用微调后的模型。结果在常见问题上，两组的准确率差距不到三个百分点；但在一些边缘问题上，微调后的模型反而表现更差，因为它过度拟合了训练数据中的模式，遇到没见过的问题就容易胡编。而提示词工程加RAG的方案，因为知识库可以随时更新，反而更灵活。

当然，微调也不是完全没用。如果你的场景有非常明确的输出格式要求，或者需要模型掌握一套特定的术语体系，那微调确实能带来提升。但前提是你已经积累了大量高质量的标注数据，而且这些数据是稳定的、不会频繁变化的。如果数据还在不断变化，那微调就是在给自己挖坑，因为每次数据更新都要重新训练一遍。

3.2 RAG不是万能药，但确实是当前最实用的方案

检索增强生成（RAG）这个技术，我在实际项目里用得最多。它的核心思路很简单：用户提问的时候，先从知识库里检索出相关的内容，然后把检索结果和问题一起交给模型，让模型基于这些内容来回答。这样做的好处是模型不需要记住所有知识，只需要学会如何利用检索到的内容就行。

但RAG也不是没有坑。我踩过最大的坑是检索质量。一开始我用的是简单的向量相似度检索，结果发现经常检索出一些“看起来相关但实际上没用”的内容。比如用户问“这个产品的保修期是多久”，检索出来的却是“产品介绍”和“售后服务政策”这种大段文本，模型拿到这些内容后反而不知道该看哪一句。后来我做了两件事：一是把知识库切得更细，每个片段只包含一个完整的信息点；二是在检索之后加了一个重排序步骤，用一个小模型对检索结果做二次筛选。这两步做完之后，回答准确率有了明显提升。

另一个坑是知识库的更新。很多场景下，知识库是需要频繁更新的，比如产品价格、库存状态、政策条款。如果每次更新都要重新做向量化，那维护成本会很高。我的做法是把知识库分成两层：一层是相对稳定的知识，比如产品说明、操作手册，这部分可以定期批量更新；另一层是频繁变化的数据，比如价格和库存，这部分直接通过接口实时查询，不走向量检索。这样既保证了回答的准确性，又降低了维护成本。

3.3 多模态能力在真实场景中的切入点

多模态大模型这两年进步很快，但在真实场景里，我发现它的切入点其实很具体。不是那种“上传一张图片让AI描述”的演示级功能，而是真正能解决实际问题的场景。比如我做过一个工业质检的辅助工具，工人用手机拍下产品照片，AI自动判断有没有外观缺陷。这个场景的关键不在于模型能不能识别缺陷，而在于它能不能在工人可接受的时间内给出结果，以及误判率能不能控制在可接受范围内。

实测下来，多模态模型在标准化的缺陷检测上表现不错，比如划痕、凹陷、色差这些。但在一些需要专业判断的场景上，比如判断一个焊接点是否合格，模型的表现就不太稳定。所以我的建议是，多模态能力适合用在那些“人眼能快速判断但需要大量重复劳动”的场景，而不是那些“需要专业经验才能判断”的场景。前者是效率工具，后者是决策工具，两者的容错要求和落地难度完全不在一个量级。

4. 实操落地：一个真实场景的完整拆解

4.1 场景选择与需求验证

我拿一个自己实际做过的项目来拆解。这个项目的背景是：一家做工业设备维护的公司，他们的工程师经常需要查阅大量的设备手册和维修记录。这些资料分散在PDF、Word、Excel各种格式里，查找起来非常费劲。他们的需求很明确：能不能做一个工具，让工程师用自然语言提问，然后直接给出答案和出处。

这个场景符合我前面说的三个标准：需求足够窄（就是查设备手册和维修记录），容错空间足够大（工程师会自己判断答案是否合理），有数据回流（工程师可以标记答案是否有用）。所以我觉得值得做。

在正式开发之前，我先做了一轮需求验证。方法很简单：找三个工程师，让他们把最近一周遇到的需要查手册的问题列出来，然后我人工模拟AI的回答过程，看看能不能从现有资料里找到答案。结果发现，百分之七十的问题都能在现有资料里找到明确答案，剩下百分之三十要么是资料里没有，要么是需要结合多个文档才能判断。这个验证结果让我心里有底了：至少七成的问题是可以解决的，剩下的三成可以通过标注“未找到”来引导工程师补充资料。

4.2 技术方案选型与架构设计

技术方案上，我选择了“提示词工程加RAG”的路线，没有做微调。原因很简单：设备手册的内容是相对稳定的，但维修记录是不断新增的，微调的话需要频繁重新训练，成本太高。而RAG只需要更新知识库就行，维护成本低很多。

具体架构是这样的：首先把PDF和Word文档解析成纯文本，然后按照章节和段落切分成小块，每个小块控制在三百字左右。切分的时候有个技巧：不要机械地按字数切，而是按照语义完整性来切。比如一个操作步骤，哪怕只有一百字，也单独成块；一个背景介绍，哪怕有五百字，也尽量不拆开。切分完之后，用嵌入模型把每个小块转成向量，存到向量数据库里。

检索的时候，先用用户的提问去向量数据库里找最相似的十个片段，然后用一个重排序模型对这十个片段做二次排序，选出最相关的三个。最后把这三个片段和用户的问题一起交给大模型，让模型基于这些片段来回答。提示词里我会明确要求模型“只根据提供的资料回答，如果资料里没有就说不知道”，这样可以有效减少胡编的情况。

4.3 关键参数与配置细节

嵌入模型我选的是开源的BGE系列，原因是它在中文语义相似度任务上表现稳定，而且可以本地部署，不依赖外部接口。向量数据库用的是Milvus，主要是因为它支持混合检索，可以同时做向量检索和关键词检索。重排序模型用的是BGE-reranker，这个模型不大，推理速度快，对整体延迟影响很小。

大模型这块，我测试了几个选项。闭源模型的效果确实好一些，但成本高，而且数据要传到外部，客户有顾虑。开源模型里，Qwen2.5-7B在中文理解和指令遵循上表现不错，用llama.cpp做量化部署后，在一张消费级显卡上就能跑起来，推理速度也能接受。最终我选择了本地部署Qwen2.5-7B的方案，虽然效果比闭源模型差一点，但数据不出内网，客户更放心。

这里有个参数需要特别注意：温度值。在问答场景下，温度值要设得很低，我一般设在0.1到0.3之间。温度值越高，模型输出越随机，越容易胡编。温度值太低又会导致回答过于死板。实测下来，0.2是一个比较平衡的值。

4.4 效果评估与迭代过程

上线之后，我建立了一个简单的评估机制：每次工程师提问后，可以点击“有用”或“没用”按钮。每周统计一次有用率，然后针对没用的问题做分析。第一个月的有用率大概在百分之六十五左右，主要问题集中在两类：一是检索不到相关内容，二是检索到了但模型没有正确使用。

针对第一类问题，我优化了切分策略，把一些过长的片段进一步拆分，同时增加了关键词检索的权重。针对第二类问题，我调整了提示词，把“请根据以下资料回答”改成了“请从以下资料中提取信息来回答，不要添加资料之外的内容”，并且给了一个示例。调整之后，第二个月的有用率提升到了百分之七十八。

第三个月，我加了一个功能：如果模型回答“不知道”，就自动把这个问题记录下来，推送给管理员。管理员可以补充资料或者手动回答。这个功能上线后，有用率又提升到了百分之八十五左右。而且因为管理员补充的资料会进入知识库，后续类似问题就能自动回答了，形成了一个正向循环。

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

5.1 检索不准怎么办

检索不准是RAG系统最常见的问题。我的排查思路是这样的：先看检索出来的片段和问题的语义相似度到底高不高。如果相似度本身就不高，那说明嵌入模型或者切分策略有问题。如果相似度很高但内容不对，那说明切分粒度太粗，一个片段里混了多个信息点。

解决办法有几个：一是换一个更适合中文的嵌入模型，比如BGE-large-zh；二是调整切分粒度，尽量保证每个片段只包含一个完整的信息点；三是加入关键词检索作为补充，有些问题用向量检索找不到，但用关键词能精确匹配。我一般会同时用向量检索和关键词检索，然后把两边的结果合并后做重排序。

5.2 模型胡编怎么治

模型胡编的根本原因是它在“不知道”的时候倾向于编一个看起来合理的答案。治这个毛病，提示词是关键。我常用的提示词模板是这样的：

你是一个严谨的问答助手。请只根据下面提供的资料回答问题。 如果资料中没有相关信息，请直接回答“根据现有资料无法回答”，不要尝试猜测或编造。 回答时请注明信息来自哪个资料片段。 资料： {context} 问题：{question}

这个模板的关键在于三点：明确限定回答范围、明确要求“不知道就说不知道”、要求注明出处。注明出处这一条特别有用，因为模型为了注明出处，会倾向于从资料里找内容，而不是自己编。

另外，温度值一定要调低。我试过温度值设成0.8的时候，模型胡编的概率明显上升。设成0.2之后，胡编的情况少了很多。

5.3 响应速度太慢怎么优化

响应速度是影响用户体验的关键因素。一个RAG请求的延迟主要来自三部分：检索、重排序、模型推理。检索和重排序一般很快，几十毫秒到几百毫秒。大头在模型推理上，尤其是用本地部署的开源模型时。

优化推理速度有几个方向：一是用量化模型，比如把FP16量化成INT4，速度能提升两到三倍，效果损失很小；二是用推理加速框架，比如llama.cpp或者vLLM，它们对推理过程做了很多优化；三是控制输出长度，在提示词里要求模型“回答尽量简洁”，减少生成的token数量。我实测下来，Qwen2.5-7B在INT4量化加llama.cpp部署的情况下，一个典型问答的响应时间大概在两到三秒，用户基本可以接受。

5.4 知识库更新了但回答没变

这个问题通常是因为向量数据库没有同步更新。RAG系统的知识库更新不是简单地替换文件就行，还需要重新做向量化并更新索引。我的做法是写一个定时任务，每天凌晨检查知识库目录有没有新增或修改的文件，如果有就自动重新处理并更新索引。另外，对于频繁变化的数据，比如价格和库存，我建议不要放进向量数据库，而是通过接口实时查询，避免数据不一致。

6. 我踩过的坑和总结出的几条经验

第一个坑是过早追求“全自动”。我一开始做设备维护问答的时候，想让AI完全替代人工查询，结果发现有些问题AI确实回答不了，但用户又不知道AI回答不了，就拿着错误答案去操作了。后来我加了一个“置信度”显示，如果检索到的资料相似度低于某个阈值，就提示用户“这个问题可能需要人工确认”。这个改动虽然简单，但避免了很多潜在问题。

第二个坑是忽略了用户的输入习惯。工程师提问的方式和我想象的完全不一样。我以为他们会问“XX设备的保养周期是多久”，结果他们实际问的是“那个XX多久保养一次”。这种口语化的表达，向量检索经常匹配不准。后来我在检索之前加了一步“查询改写”，用一个小模型把用户的口语化问题改写成更规范的表达，检索准确率提升了不少。

第三个坑是低估了数据清洗的工作量。设备手册的PDF格式五花八门，有的能直接解析，有的是扫描件需要OCR，有的表格结构复杂解析出来全是乱的。我一开始以为解析文档是很简单的事，结果花了整整两周才把数据清洗干净。所以如果你要做RAG项目，一定要在数据清洗上留足时间，这部分的工作量往往比模型调优还大。

最后一个经验是：不要追求一步到位。我见过很多团队想做一个“完美”的AI系统，结果做了半年还没上线。我的做法是先做一个最小可用版本，哪怕只支持十个最常见的问题，先让用户用起来，然后根据反馈快速迭代。真实场景里的需求是不断变化的，你不可能在办公室里想清楚所有情况，只有让用户用起来，你才知道下一步该做什么。

这个设备维护问答系统后来扩展到了三个工厂使用，每天处理几百个提问。有用率稳定在百分之八十五以上，工程师的平均查询时间从原来的十几分钟缩短到了两三分钟。这个项目让我深刻体会到，大模型的价值不在于它有多聪明，而在于它能不能在一个具体的场景里，稳定地、可靠地解决一个具体的问题。那些看起来“不够酷”的场景，往往才是真正能跑通的场景。