很多同行都在做生成式人工智能Generative AI服务但真正能跑通、能上线、能给业务带来增量的其实不多。这篇文章我想把生成式人工智能服务从技术选型、数据准备到落地调优的关键要点拆开讲一遍同时附上一份中英双语术语对照方便你在实际项目里直接查、直接抄。不管你是刚接触大模型Large Language ModelLLM的开发者还是需要给团队做技术判断的负责人这篇内容都能给你一条明确的落地路径。我会重点讲清楚每个步骤背后的“为什么”而不是只给一堆操作命令。1. 生成式AI服务的技术底座与选型思路1.1 先搞懂生成式AI服务的核心能力边界生成式人工智能服务本质上是利用深度生成模型根据用户的输入指令Prompt自动生成文本、代码、图像、音视频等内容。跟传统的判别式AI不同生成式模型输出的不是分类标签而是一段全新的、有概率性的内容。所以你在设计服务架构时第一件事就是接受一个现实模型的输出不是确定的。同样一个问题十次请求大概率有十次措辞差异甚至偶尔会出现事实性错误。这不是Bug而是生成式模型的工作方式决定的。所有后续的缓存设计、用户提示Prompt设计、输出校验都是围绕这个“不确定性”展开的。技术底座通常包含这几类组件基座模型Base Model负责理解和生成的核心引擎例如对话模型、文生图模型。推理引擎Inference Engine把模型跑起来并对外提供接口的中间层常见的有vLLM、TGI、SGLang等。向量数据库Vector Database用于存放和检索知识库中的向量化内容支撑检索增强生成RAG。应用框架Application Framework把模型、数据、工具编排起来常见的包括LangChain、LlamaIndex等。1.2 基座模型选型通用模型与垂直模型的权衡选型是一切的起点也是最容易踩坑的地方。很多团队一上来就追求“参数最大”的模型结果发现部署成本高到无法承受响应速度又不达标业务根本跑不起来。我的建议是按“任务复杂度×调用频率×数据敏感性”三个维度来选简单任务关键词提取、文案润色、标题生成参数量在7B到14B之间的小模型完全够用可以本地化部署。中等任务复杂对话、结构化信息抽取建议使用70B级别的开源模型或者调用成熟的API接口。高难度任务长文档分析、复杂推理、代码生成才需要考虑更大规模的模型或顶尖闭源模型。数据敏感性也要重点考虑。如果服务涉及企业内部数据、用户隐私数据本地化部署往往是唯一选项如果只是公开内容生成调用API的成本优势就非常明显。我实测过很多次中小团队最容易犯的错误是拿最聪明的模型去做最琐碎的活。模型越大单次调用成本越高响应延迟也越大。用“杀鸡用牛刀”的方式做服务成本账单会教你做人。2. 服务落地中的核心实操要点2.1 数据准备与知识库建设决定服务质量的上限生成式AI服务的质量一半靠模型一半靠数据。尤其是做知识库问答类服务数据不进库模型就只能是“嘴硬的空架子”什么问题都敢编。知识库建设的核心流程分四步数据清洗把原始文档中的页眉页脚、乱码、重复段落、无意义符号全部去掉。这一步看似简单但直接影响切分效果。文本切分Chunking按语义边界把长文档切成固定大小的文本块常见策略是按段落、标题、固定字符数切分。切得太大会稀释检索精度切得太小会丢失上下文。向量化Embedding用嵌入模型把每个文本块转成向量存进向量数据库。嵌入模型的选择很关键中文场景下可以考虑bge系列、m3e系列等针对中文优化的模型。索引构建给向量库建好索引设置合适的相似度检索算法比如余弦相似度、内积等。有一点很多人没注意到切分策略要跟着下游任务走。如果你的业务是“文档问答”最好按文档原有的标题和段落层级切分而不是纯按固定字符数硬切否则检索出来的片段经常是半句话模型想答好也难。2.2 Prompt工程花小钱办大事的关键Prompt是用户与模型交互的接口也是性价比最高的调优手段。一个结构良好的Prompt能直接提升输出质量而且不需要额外训练模型。我常用的Prompt结构包含四个要素角色设定Role告诉模型“你是一个资深的技术文档工程师”。任务描述Task明确说明需要完成什么任务要输出什么格式。约束条件Constraint写明不许怎么做比如“不要编造数据”“不要超过200字”。输入内容Input把需要处理的原始内容放进来。实操中我建议把“约束条件”写在Prompt的后半部分靠近生成位置。因为模型对离当前位置越近的文本关注度越高关键约束放后面被遵循的几率更大。另外如果你在用RAG方案Prompt里一定要带上“检索到的参考资料”并且明确告诉模型“优先参考给定资料资料中找不到答案时直接说明不知道”。这个简单技巧能把幻觉率降下一大截。2.3 微调的必要性与分寸把握很多团队动不动就想微调模型但我得泼盆冷水微调不是万能的而且成本不低。大多数业务场景先做好Prompt和RAG就足以解决80%的问题。什么时候才真的需要微调模型输出风格与业务要求严重不符比如要求“严谨的合同条款”模型老是“口语化发挥”。需要模型稳定按特定格式输出结构化数据而Prompt怎么调都不稳定。希望模型学会业务内的专业术语和专有名词比如企业内部产品代号、医疗术语等。微调方案上我推荐优先尝试LoRALow-Rank Adaptation这类参数高效微调方法。它只训练一小部分参数显存需求低、训练速度快效果在很多场景下已经接近全参微调。等LoRA验证有效再考虑是否值得做更大的投入。2.4 服务端架构与并发设计生成式AI服务和传统API服务最大的区别在于推理请求的耗时特别长而且显存占用高。如果你用传统“一个请求一个线程”的思路来做很容易被并发打爆。几个我踩过坑之后的经验用异步推理框架vLLM等框架自带Continuous Batching连续批处理技术能把多个请求拼在一个批次里推理大幅提高吞吐。设置合理的超时和排队机制给用户端一个“排队中”的反馈比让用户干等要好得多。做缓存层把常见的重复请求做语义级缓存命中后直接返回历史结果能省一大笔推理成本。比如“产品功能介绍”这类问题答案基本稳定缓存命中率很高。3. 实操案例从零搭建一个企业内部知识问答助手这一部分我拿一个实际做过的项目来还原完整流程需求是给企业内部搭建一个基于产品文档的问答助手让员工通过自然语言提问就能查到制度、操作手册和技术规范。3.1 第一步需求拆解与方案定型需求方给的原话是“弄个机器人把咱们的文档都喂进去员工想问啥就问啥。”这句话听着简单但如果不拆清楚就动手后面必返工。我把它拆成四个可执行指标知识范围涵盖三个产品线的操作手册、FAQ、故障处理文档约1200篇。问答形式支持中文自然语言提问答案需要标注引用来源。响应要求首字响应时间小于3秒单次问答完整耗时小于15秒。部署环境内网部署不允许调用外部API。因为不允许外部API方案直接定为本地部署开源模型 私有向量数据库 RAG。3.2 第二步数据清洗和知识库构建原始文档有一大半是PDF直接从里面抽文本出来格式乱、有乱码还有重复内容。为了洗干净这批数据我分了三道工序来做。第一道转换与解压。用PDF解析工具把每一页转成纯文本同时记录页码信息。过程中发现很多扫描版PDF文本根本抽不出来只能先用OCR光学字符识别过一遍再进入后续流程。第二道清洗与去重。写了一个清洗脚本把空行、不可见字符、页眉页脚水印全部去掉。按文本相似度做了一遍全局去重结果发现有大概百分之十几的文档内容重复出现在不同文件里这些不处理检索时会造成严重的重复干扰。第三道结构与切分。这1200篇文档里手册类文档有清晰的章节结构不适合固定字符切分。我先把每篇文档的目录结构解析出来然后按“标题层级段落”先生成候选片段再对超过500字的片段做二次切分。切分完之后全部向量化存入向量数据库。3.3 第三步模型部署与向量化选型模型最终选了Qwen系列的开源权重版本7B级别。选它的原因很简单中文效果足够、社区活跃、量化和部署资料非常全。部署时直接用vLLM做推理服务开一个HTTP接口给上层应用调用。模型加载时做了一次4-bit量化用GPTQ方案把显存占用从原始全精度的约14GB压到了5GB左右这样一台显卡比较旧的服务器也能稳定跑。向量化模型选了bge-base-zh-v1.5。这里有个很多人容易忽略的细节向量化模型要和检索场景匹配。bge系列默认适合短文本检索而我切出来的文档片段平均有300到500个字符所以我在向量化时对长文本也做了归一化处理并且把查询文本和文档文本用不同的前缀区分开。这样改完后检索准确率明显上升。3.4 第四步Prompt设计与问答链路联调问答链路的逻辑是用户提问 → 查询改写 → 向量检索 → 拼装Prompt → 模型生成 → 输出返回。查询改写是容易被忽略但很有用的一步。员工提问常常是口语化的比如“那个报销流程咋走来着”直接用这句话去检索向量库效果通常不好。我在检索前先让模型把口语问题改写成一个更规范、更适合检索的查询语句然后用改写后的语句去做向量检索命中率提升很明显。拼装Prompt时我固定用下面这个模板你是一名企业内部知识库问答助手。请严格依据提供的参考资料回答用户问题。 参考资料 检索到的文档片段 用户问题 用户原始问题 回答要求 1. 答案必须来自参考资料不得自行编造。 2. 如果参考资料中找不到答案请明确回答“资料库中暂未找到相关信息”。 3. 请尽量使用口语化、简洁的表达。 4. 在回答末尾标注引用来源的文档名称和页码。整个链路调通后我拿100个业务真实问题做了一轮评测把回答结果分成了“准确”“部分准确”“错误”三档。初版“准确”率大约在68%后来通过调整检索TopK参数、优化切分粒度、细化Prompt约束跑到了85%以上。3.5 第五步效果评测与持续优化评测是把关质量的核心手段不能只靠人肉看几条就完事。我搭了一个简易评测脚本对每个问题同时记录三样东西检索命中的文档片段、模型生成的答案、人工标注的准确率。评测之后发现错误回答主要集中在这两类情况问题涉及多份文档交叉内容比如“新员工的报销额度和差旅标准”单看命中的某一个片段答不全。问题包含了文档里没有的具体数值模型开始自行推断。针对第一类我把检索的TopK从原来的3调到6并且把多片段在Prompt里的排列顺序按相关度重新排序再让模型先综合分析所有参考资料再作答针对第二类我在Prompt里加了一条硬性约束“涉及数字和日期时必须引用原文档原文否则即视为未找到”。这两处改动上线后“准确”率涨了约8个百分点。所以说原来满脑子想着“给模型做微调”的项目最后靠结构化的知识库和Prompt优化就已经达到了业务验收标准微调自然就不需要了。先把检索和提示做扎实比一上来就动模型训练要划算得多。4. 常见问题与排查技巧实录4.1 模型回答出现幻觉怎么办幻觉Hallucination是生成式AI服务最讨厌的问题模型一本正经地编出不存在的事实。我的排查顺序是先看检索质量。打开日志看看模型拿到的那几份参考资料和用户问题是否真正相关。如果检索到的资料本身就是无关的模型只能瞎编。再检查Prompt约束。有没有明确写“不准编造”有没有要求“找不到就承认找不到”很多时候加上这句话幻觉率就能降一半。最后看模型大小。7B级别的小模型在复杂任务上的幻觉率明显高于大模型如果业务场景对真实性要求极高可能需要换更大的模型或者对输出内容增加二次校验。4.2 响应速度慢到用户崩溃速度问题的原因往往不在模型本身而是在链路设计上。排查要点文本切分是否太大如果单个片段长达上千字符模型一次推理要处理的Token数就很多响应自然慢。检索时是否一次捞太多文档TopK设为10以上时Prompt会被塞得很长响应时间成倍上升。部署时是否开了流式输出改成流式输出Streaming Output用户看到的是逐字出来的结果主观等待感会大幅降低。服务器显存是否触发了频繁换入换出如果显存不够模型权重在CPU和GPU之间来回搬会慢到怀疑人生。4.3 向量检索命中率低答案东拉西扯这个问题的根源通常是“问法”和“文档写法”差异太大。员工的问法口语化文档里的表达却是严谨书面语两边的语义空间隔着一条河。我常用的对策是查询改写加同义词扩展。让模型把口语问题改写成文档风格的关键词组合再对改写结果做一次同义词扩充比如“报销”同时扩充为“费用报销”“报销流程”“报销申请”。扩充后一次性发起多条检索请求把结果合并去重再返回给大模型。4.4 并发一高服务直接崩这种情况十有八九是推理框架没选对或者压根没用批处理。我在早期项目里直接用PyTorch原生接口部署模型一个请求占一份显存并发一过5就崩。后来换成vLLM并开启Continuous Batching同样一张卡并发到了20也稳如老狗。如果你的部署环境受限至少也要在应用层加个请求队列控制并发数量给后端减压。5. 中英双语术语对照速查表考虑到很多团队要写方案、发邮件、跟跨部门协作我把生成式AI服务里的高频核心术语整理成了一份中英对照方便你直接引用和查阅。中文术语英文术语简要说明生成式人工智能Generative AI能够生成新内容的人工智能技术总称大语言模型Large Language Model (LLM)以海量文本训练的语言生成模型基座模型Base Model未经任务定制化训练的原始模型推理引擎Inference Engine负责运行模型并输出结果的系统组件提示词Prompt用户输入给模型的指令文本提示工程Prompt Engineering设计和优化提示词以提升输出质量检索增强生成Retrieval-Augmented Generation (RAG)先检索知识库再指导模型生成的方案向量化Embedding将文本转换成的稠密向量表示向量数据库Vector Database存储和检索高维向量的数据库系统语义缓存Semantic Caching按语义相似度命中并复用历史结果微调Fine-tuning用业务数据继续训练模型以适应特定任务低秩适配Low-Rank Adaptation (LoRA)一种高效轻量的模型微调方法量化Quantization降低模型参数精度以节省显存和加速推理幻觉Hallucination模型生成与事实不符内容的现象流式输出Streaming Output逐字逐句输出结果降低用户等待感文本切分Chunking将长文档拆成适合检索的片段连续批处理Continuous Batching动态拼批多个请求共同推理的技术上下文窗口Context Window模型单次能够处理的文本长度范围多模态模型Multimodal Model同时支持文本、图像、音视频等输入输出的模型人工反馈强化学习Reinforcement Learning from Human Feedback (RLHF)基于人工反馈优化模型行为的方法这张表里的大部分术语在实际项目文档里都会频繁出现。建议你把它们存下来下次写方案或者做评审时直接套用。根据我个人做过的这些项目我最大的体会是生成式AI服务能不能成技术选型只占一小部分更关键的是把数据、Prompt、检索和评测这四个环节的细节做扎实。很多人拿着大模型跑出一段好结果就急着上线忽略了知识库质量和评测闭环结果一到真实场景就翻车。如果手里有准备启动的生成式AI服务项目建议你从今天就开始干两件事第一把现有文档梳理干净哪怕只有几十篇先把高质量的知识库建起来第二用一个小模型把问答链路完整跑通再考虑扩展。这个方向后续还能继续扩展出多轮对话、主动追问、跨文档对比分析等能力但地基一定是从简单方案开始的。