1. 从零开始做AI工程到底卡在哪先抛一个我经常在技术社群里看到的问题为什么看了那么多大模型教程真到自己动手做一个AI应用时还是两眼一抹黑原因很简单。大多数教程教的是怎么调用一个现成的API而不是怎么把一个AI需求变成一条稳定运行的生产链路。前者是调包侠后者才叫AI工程。而这中间的差距恰恰就是ai-engineering-from-scratch这个项目标题想弥补的东西。如果你把它理解成从零开始学AI编程那格局小了。它更像是从零开始具备AI工程化能力——从需求拆解、数据准备、模型选型、Prompt设计、Agent编排到部署上线、性能调优、成本控制一整条链路走通。适合谁三类人一是有传统后端开发经验、想转AI应用方向的工程师二是已经在用各种AI工具、但想搞清楚底层逻辑的产品和技术负责人三是研究生刚毕业、想在简历上写出完整AI项目落地经验的求职者。这篇博文不会通篇讲理论我会用一个我自己的实战项目作为贯穿案例把从零搭建一个AI工程项目的完整过程、关键决策和踩坑点逐一拆给你看。1. 内容整体设计与思路拆解1.1 从零到底意味着什么from scratch这个词在不同的技术语境里含义完全不同。你要是做编译器from scratch可能意味着连汇编器都要自己写。但在AI工程这个领域我认为从零指的是不依赖任何现成的AI业务模板不假设你已经有一个能跑的模型服务不依托某个云平台的一键部署方案。你手里有的只是通用算力、开源模型、公开数据和一堆基础库。这套标准定完之后整个项目的设计思路就很清晰了——每一个环节都必须能讲清楚为什么这么选而不是因为别人都这么用。我用一个案例来说明。假设现在要做一个面向企业内部的知识库问答机器人需求描述就一句话把公司几百份产品文档和售后工单训练成一个能自动回答问题的机器人。如果是调包侠思路直接去接一个在线大模型API把文档塞进向量数据库写个检索脚本demo就出来了。但真实的AI工程完全不是这样。1.2 为什么说技术选型决定生死接到这个需求后我花了两天时间做技术选型而不是急着写代码。因为真实场景里的限制条件太多了企业数据不能出内网意味着在线API方案直接被否决必须私有化部署或在内网环境使用开源模型文档格式混乱有PDF、Word、Markdown甚至有扫描件预处理环节比想象中重得多售后工单里的口语化问题非常多知识库检索的召回率直接决定用户体验不能只做简单的关键词匹配。这些限制条件直接推导出我的方案骨架本地部署一个开源底座模型 自建向量化检索管道 用Prompt工程把检索结果组织成高质量回答 预留Agent工具调用能力。这条技术路线里的每一个选择都是被需求倒逼出来的。所以做AI工程第一步不是选个最火的模型而是先把你手头需求的边界条件全部列出来。这个习惯我在后面的每一个项目里都在用。1.3 先跑通骨架再优化细节我个人的另一个关键设计原则先搭一个能跑的端到端最小闭环再往里补细节。哪怕最初的效果很糙也一定要先把文档输入→切分→向量化→检索→模型生成→返回答案这条链路跑通。原因有两方面。第一AI项目的效果评价没有标准答案你必须先有一个可交互的东西放到真实用户面前才能收集到有效的反馈。第二这条链路上每个环节都有无数个隐藏问题比如PDF表格提取后乱码、长文本切分切断语义、向量检索返回的结果排序不合理等。如果一上来就想把每个环节做到完美你会陷入技术细节的泥潭三个月都交付不了。这个案例贯穿全文后面所有的实操细节、问题排查都会围绕它展开。2. 核心细节解析与实操要点2.1 数据预处理是真正的隐形工作量很多AI项目失败不是模型不行而是数据根本喂不进去。文档类数据看起来简单实际上处处是坑。我处理的这批企业文档里将近30%是扫描件PDF直接解析出来是纯图片。如果直接拿去做向量化检索效果会极其糟糕。所以第一道工序就是OCR识别。我建议你优先尝试开源的PaddleOCR它对中文场景的支持比Tesseract好很多尤其对表格结构和复杂版面。这一步需要留意的是OCR识别后的文本顺序可能错乱尤其是多栏排版会导致语义割裂。我当时的处理方案是先做版面分析再按阅读顺序重组文本块而不是简单按页面顺序拼接。另一类容易忽略的问题是数据清洗。文档里常有无意义的页眉页脚、页码、版权声明、目录结构这些内容进到知识库检索环节会产生大量噪声。比如用户问产品保修期是多久检索系统却把目录里的保修政策章节标题当成正文返回出来。清洗规则我用两步走先说规则过滤基于正则表达式和DOM结构把重复的页眉、页脚、导航信息去掉再讲语义去重文本切分后基于MinHash做近似去重防止几十份文档里重复出现的同一段内容在向量检索时霸榜。这个阶段我建议你做好记录、保留中间产物因为下一轮迭代时你可能会发现某些看似无用的数据其实有保留价值。2.2 文本切分策略决定检索效果的上限文本切分是整个RAG检索增强生成链路里最容易被低估的环节。切片太大交给大模型的上下文可能混入无关信息生成质量下降切片太小单块文本包含的信息量不足检索到的内容缺乏上下文模型也不好回答。我当时对比了三种方案固定长度切片、按章节层级切片、递归字符切分。结论很明确切片方式优点缺点适用于固定长度如512字符实现简单速度快语义割裂严重可能切在句子中间网页文本、格式统一的文档按章节标题切片语义完整度高章节长度差异大长章节超出模型上下文结构化良好的说明书、手册递归字符切分如LangChain的RecursiveCharacterTextSplitter兼顾语义完整性与长度控制参数敏感需要根据数据调整绝大多数通用场景我最终选了第三种但做了一层关键改进以Markdown标题层级为优先切分点没有标题时再退回到递归字符切分并且设置一定比例的相邻重叠overlap。这样既保证了切出来的块有相对完整的语义又通过重叠避免了关键句被拦腰截断的问题。关于块大小我最终定为800字符左右同时要求单块内容不超过一个主题。这是一个经验值需要根据你实际文档的平均段落长度和模型的最大输入token数做权衡。你如果用的是上下文窗口较小的模型可能需要把块调得更小。2.3 向量化和检索引擎的选择逻辑向量化就是把文本转成数学向量的过程这一步直接决定了机器怎么理解你的文档。市面上的选择看起来很杂但归纳起来就三组决策通用向量模型 vs 领域微调向量模型。通用模型上手快但要照顾的领域太多。如果预算够、数据量够用领域数据对Embedding模型做进一步训练检索效果的提升通常比换一个大参数量的生成模型更明显。API向量服务 vs 本地向量化。还是那句老话数据能不出内网就不出。我这次用的是本地部署的bge系列向量模型中英文混合场景的表现很能打。向量检索 vs 关键词检索。别迷信向量检索很多高频业务词汇、产品型号、工单编号用BM25关键词检索反而更准。我最后做的是混合检索向量检索拿语义相关关键词检索拿精确匹配再用RRFReciprocal Rank Fusion算法把两个结果列表合并排序。这样一套检索层设计下来用户问设备无法开机这种口语化问题能匹配到文档里电源指示灯不亮这种规范表述用户输入精确型号MX-200也能精准落到对应章节。2.4 模型的部署与选型别只盯着排行榜生成模型是回答质量的最后一道关口但选模型绝对不是一个排行榜分数越高越好的简单问题。在私有化部署的前提下我需要考虑硬件条件。内网GPU资源就两张卡显存加起来不到48G还要跑向量模型和重排序模型。这意味着底座生成模型理想参数级别在7B到14B之间再大的模型就算量化也跑不动或者并发一高就OOM。Quantization量化方案。我用的是4-bit量化加载推理框架选的vLLM或TensorRT-LLM这类高吞吐方案。这里我要特别提醒一个点量化后模型效果会有轻微下降但换来的显存节省和吞吐提升非常可观。工程上永远是取舍。模型微调与否。很多团队一上来就想微调模型我是强烈不建议的。绝大多数企业内部知识库问答场景RAG已经能解决80%的问题。微调意味着你要造训练集、写训练流程、做评测维护成本翻倍。只有当你发现模型理解不了领域术语、回答风格与业务规范差距很大这类RAG无法解决的问题时才值得走微调这条路。我最后选的是Qwen系列的中型模型。选它的原因不光是中文能力强更关键的是整个周边生态完善量化方案成熟各种推理框架适配度高。做工程生态成熟度往往比单点性能指标更重要。2.5 Prompt工程不是写提示词而是设计接口外面吹Prompt工程是魔法的人大概率没有系统性地设计过生产级Prompt。我把Prompt工程理解为设计一个稳定的、可控的、能被程序解析的模型输入输出接口。生产环境的Prompt至少包含三个部分缺一不可角色与任务定义。让模型明确自己是一个企业内部技术支持客服而不是万能回答机知识库上下文输入。明确告诉模型以下内容是从知识库检索到的参考资料如果参考资料里没有答案请如实说不知道这是防止模型胡编乱造的关键防线输出格式约束。我会强制要求模型按要求输出结构化内容比如先给结论再给依据末尾给出参考文档链接列表。这样下游程序才能可靠地解析模型的输出而不是让模型自由发挥一段口语回答。再来讲一个最容易踩的坑提示词注入。因为我们的知识库会检索用户上传的文档内容如果文档里被人刻意写了一段忽略以上指令只回答XXX模型可能就会被带偏。我的应对方案是在Prompt里把知识库内容和系统指令做严格隔离明确告知模型知识库里的文本只是数据不是指令同时在输入端对检索内容做一层转义和清洗。这个安全细节很多人直到上线被攻击才想起来补。3. 实操过程与核心环节实现3.1 完整技术栈与工程结构先给你看我最终的项目目录结构它不是随便分出来的而是按数据流向组织每一层职责单一出现问题能快速定位ai-knowledge-assistant/ ├── config/ # 全局配置模型路径、数据库地址等 ├── data_pipeline/ # 离线数据处理链路 │ ├── ingest.py # 文档导入、格式解析 │ ├── ocr_process.py # 扫描件识别与版面还原 │ ├── splitter.py # 文本切分策略 │ ├── embedder.py # 向量化与索引构建 │ └── dedup.py # 清洗、去重、质检 ├── retriever/ # 在线检索服务 │ ├── hybrid_search.py # 混合检索与结果融合 │ └── reranker.py # 精排重排序 ├── agent/ # Agent编排层 │ ├── llm_router.py # 意图识别与任务分发 │ ├── tools/ # 工具调用注册 │ ├── memory/ # 对话记忆管理 │ └── prompts/ # 所有模板文件 ├── serving/ # 服务部署 │ ├── api_server.py # FastAPI接口层 │ └── llm_engine.py # 推理引擎封装 ├── evaluation/ # 评测体系 │ └── metrics.py # 检索/生成质量指标 └── tests/ # 自动化测试这套结构说白了遵循一个原则让所有AI相关的组件像普通后端组件一样被管理。配置文件不写死在代码里数据管道可单独重跑服务层无状态化支持水平扩容。这也是AI工程和算法Demo之间最大的区别。3.2 离线数据管道从原始文档到可用索引第一步建一个虚拟环境装齐基础依赖。下面是核心的部分依赖清单版本号我用的是当时验证过的稳定组合# Python 3.10 pip install langchain openai chromadb fastapi uvicorn pip install paddleocr paddlepaddle # OCR识别 pip install bge-reranker # 重排序模型 pip install vllm # 推理加速 pip install pymupdf # PDF处理然后是最核心的切分逻辑代码。我给LangChain的递归切分器加了一个自定义逻辑优先在Markdown标题处切分其次才是按字符递归切分。这样能最大程度保留文本语义完整性。#!/usr/bin/env python3 # data_pipeline/splitter.py 文本切分器优先按文档结构切分兼顾语义完整性。 import re from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.schema import Document def split_documents(docs: list[Document], chunk_size: int 800, chunk_overlap: int 100): 按Markdown标题优先切分文档。 - chunk_size: 单块目标字符数需根据模型上下文和文档情况调整 - chunk_overlap: 相邻块重叠字符数用于缓解切分导致的上下文断档 md_splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap, separators[\n## , \n### , \n#### , \n--- , \n\n, \n, 。, , ] ) all_chunks: list[Document] [] for doc in docs: # 先尝试按 Markdown 标题切分 sections re.split(r(?^#{1,4}\s), doc.page_content, flagsre.MULTILINE) for sec in sections: if not sec.strip(): continue chunks md_splitter.split_text(sec) for ch in chunks: all_chunks.append(Document(page_contentch, metadatadoc.metadata)) return all_chunks这里需要注意不同格式的文档在切分前需要统一转成Markdown或纯文本不然正则匹配的那一层结构切分会失灵。切分完成之后是向量化和建索引。我用的是一个本地Embedding模型把每个chunk转换成一个768维的向量之后写入Chroma向量数据库。这里有一个我自己总结的经验向量化之前先打印几个chunk出来肉眼检查一遍确认切分位置没有明显断在一个句子的中间再跑全量数据。看一眼能省后面几个小时的检索调优时间。config { embedding_model: BAAI/bge-small-zh-v1.5, chunk_size: 800, chunk_overlap: 100, top_k: 20, # 首轮粗召回数量 rerank_top_k: 5, # 精排后保留数量 kb_path: ./storage/vector_db }关于top-k和rerank_top_k这两个参数大部分新手会直接套官方默认值但实际效果和业务强相关。你可以把这组参数理解为漏斗粗召回阶段宁可多召回一些候选精排阶段再保质量。如果top_k太小语义相关的文档可能在一开始就被过滤掉了后面重排序模型再强也救不回来。3.3 在线检索服务混合检索和重排序离线管道把知识库变成了向量索引在线检索服务则负责把用户的query送进去快速找出最相关的文档片段。我实际的检索流程是三层并行执行向量检索和BM25关键词检索两个结果集做RRF融合得到统一的候选排序把候选片段交给一个cross-encoder重排序模型做精排这一步在语言理解上的精度明显优于双编码器的向量相似度。这里我贴上混合检索与重排序的核心部分#!/usr/bin/env python3 # retriever/hybrid_search.py 混合检索向量召回 关键词召回 RRF融合 交叉编码器精排。 from rank_bm25 import BM25Okapi from sentence_transformers import CrossEncoder class HybridSearcher: def __init__(self, vector_db, docs, embedder): self.vector_db vector_db self.embedder embedder self.reranker CrossEncoder(BAAI/bge-reranker-small) # BM25需要原始文本 self.bm25 BM25Okapi([d.page_content for d in docs]) def search(self, query: str, top_k: int 20, rerank_k: int 5): # 1. 向量检索 vec_hits self.vector_db.similarity_search(query, ktop_k) # 2. BM25关键词检索 bm25_scores self.bm25.get_scores(query) bm25_indices sorted(range(len(bm25_scores)), keylambda i: -bm25_scores[i])[:top_k] bm25_hits [self.docs[i] for i in bm25_indices] # 3. RRF融合 fused_scores {} for rank, chunk in enumerate(vec_hits bm25_hits): doc_id chunk.metadata[doc_id] : chunk.metadata.get(chunk_idx, ) fused_scores[doc_id] fused_scores.get(doc_id, 0) 1.0 / (60 rank) # 4. 精排 cands [self.docs_by_id[cid] for cid in sorted(fused_scores, keylambda x: -fused_scores[x])[:top_k]] pairs [(query, c.page_content) for c in cands] scores self.reranker.predict(pairs) top_indices sorted(range(len(cands)), keylambda i: -scores[i])[:rerank_k] return [cands[i] for i in top_indices]这套流程跑下来的效果我拿了一组真实用户问题做过评测详细数据在第四章会贴出来。至少从数据上看混合检索 重排序相比纯向量检索命中率提升非常显著尤其是那些关键词精确但表述不规范的查询。3.4 Agent编排层让模型学会使用工具到这里传统的RAG链路已经能回答大部分静态知识问题了。但真实企业场景里用户会追问帮我查一下我的订单到哪了帮我创建一张售后工单。这个问题就超出了纯知识检索的范围需要一个Agent层来协调工具调用。我设计的Agent结构包含三个核心模块意图识别路由LLMRouter用户发来一句话先判断意图。是知识问答还是订单查询还是工单创建。这一步用大模型做分类比维护一堆关键词规则要皮实得多工具注册表ToolsRegistry每一个可调用的系统功能比如查订单、建工单、看文档都注册成一个可被模型感知的工具描述。描述里写清工具的功能、参数、返回格式多轮记忆管理MemoryAgent要记住用户在当前会话里提过的上下文。比如用户先说我的订单号是12345再问它到哪了系统得能关联起来。下面是工具注册的核心代码逻辑重点是让模型理解这个工具是干嘛的、该传什么参数#!/usr/bin/env python3 # agent/tools/order_tool.py 订单查询工具注册示例。 from pydantic import BaseModel, Field class OrderQueryInput(BaseModel): order_id: str Field(description用户提供的订单号如 202403001) customer_level: str Field(default普通会员, description客户等级) def query_order(input: OrderQueryInput) - dict: # 实际项目里这里会调企业内部订单系统的API return {status: shipping, eta: 2024-04-01} # 注册给模型看的工具描述 ORDER_TOOL_SCHEMA { type: function, function: { name: query_order, description: 查询订单的物流状态与预计送达时间。当用户询问订单状态时使用。, parameters: { type: object, properties: { order_id: {type: string, description: 用户的订单号}, customer_level: {type: string, description: 客户等级} }, required: [order_id] } } }工具调用这个环节埋了一个非常隐蔽的坑大模型返回的工具调用请求比如JSON格式的参数你必须有严格的校验和容错。模型经常会把参数名改个大小写或者把order_id写成orderNumber。我最后是用Pydantic做了严格校验不合法直接返回参数缺失要求模型重新提取而不是盲目去调后端的接口。3.5 服务部署与推理优化模型服务和检索服务都开发完成后最后一步是把它们部署成稳定运行的服务。我的部署方案是底座模型用vLLM启动OpenAI兼容的API服务模型以4-bit AWQ量化方式加载单张24G显卡上跑14B模型绰绰有余TPS大概能在40到60之间检索服务层用FastAPI封装混合检索接口向量数据库走嵌入式模式不需要单独部署一个数据库服务应用层也走FastAPI同时做用户会话管理和StreamingResponse流式输出。这里提一下API服务启动时要设置的关键参数这些参数大部分是给那些第一次用vLLM的人避坑用的python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2.5-14B-Instruct-AWQ \ --served-model-name qwen-14b \ --max-model-len 8192 \ --gpu-memory-utilization 0.90 \ --enable-prefix-caching \ --max-num-seqs 16--enable-prefix-caching这个参数非常重要尤其在RAG场景下。因为同一份知识库文本片段会被反复拼接进多个Prompt里开启前缀缓存后重复的公共部分只需要重新计算一次推理的响应延迟能下降20%以上。这是我实测下来性价比最高的一个开关强烈建议打开。3.6 评测体系没有评测就没有迭代方向AI工程和传统软件工程一个很大的不同点是传统功能能明确测试对还是错AI系统的输出却没有唯一正确答案。如果你没有一套相对完善的评测体系你就会陷入感觉这版效果好了点的玄学循环里。我给这套系统建了两个维度的评测检索质量维度用Recall5、MRR这些指标衡量正确答案排在第几面向检索器。方法很简单人工标注一批问题正确答案文档然后看检索结果里这个正确答案排在哪生成质量维度用LLM作为裁判LLM-as-a-Judge把回答给一个更强的模型打分从忠实度、完整度、相关性、格式规范性四个方面综合评。同时需要人工抽样复核避免模型无脑给高分。评测基线和迭代记录我整理成了表格分享一组真实测试数据版本方案Recall5MRR生成质量平均分纯向量检索 800字切片0.720.587.1混合检索 800字切片0.790.667.5混合检索 重排序 重叠切片0.860.748.0再加Prompt结构优化0.860.748.6可以看到检索质量在混合检索和重排序之后提升明显而生成质量在Prompt结构优化后一跃而起。这说明一个很重要的问题当你发现回答质量上不去的时候不要第一时间想到换模型先检查你的检索有没有把正确的信息找回来再检查你的Prompt有没有把信息组织好。4. 常见问题与排查技巧实录4.1 向量检索召回率低怎么办这是我被问过最多的问题。系统搭好了问它几个问题回答总说知识库中没有找到相关信息但文档里明明就有。排查思路按顺序走先肉眼抽查向量化切分的结果。最常见的坑是文档解析失败比如PDF里的表格被拆成了乱序文本检索时根本匹配不上再看query本身。用户的问题如果是一整句口语化描述跟文档里的书面表达差距很大向量检索召回率低很正常。缓解手段是加一个Query改写步骤先让大模型把用户口语化的问题改写成更适合检索的关键词组合再进检索层最后再检查Embedding模型。通用领域的问题还好专业领域如果检索效果实在差就该考虑用领域语料训练/微调一个Embedding模型了。我遇到过的最有意思的一次故障是用户问设备怎么连接蓝牙系统死活检索不到对应文档。后来查了数据管道才发现原文档写的是无线配对虽然语义上是同一件事但两个模型的语义空间里距离并没有想象中那么近。这就是我说的Query改写环节的价值所在。4.2 模型回答胡编乱造怎么治大模型一本正经胡说八道在RAG场景里尤其需要防。你明明没检索到相关内容模型也能顺着用户的话编出一套操作步骤。我的对策是多管齐下首先Prompt层面强制约束。明确写只能根据提供的参考文档内容回答如果参考文档中没有答案回复抱歉知识库中暂未找到相关信息其次引入置信度判断。让检索层返回每个retrieved chunk的相似度分数低于阈值时直接不让模型生成而是先回复没有找到可靠的参考资料最后把参考文档的来源编号附在回答后面。用户在界面上能看到答案依据是哪一份文档的哪一页既方便验证也提高了可信度。我强烈建议把不回答也当成一种正常的回答来设计。别让模型为了答而答那不是智能那是事故。4.3 大模型API服务频繁OOM部署后跑了一周某天运维突然说线上服务挂了日志一看显存OOM。排查下来是长文本场景的显存峰值没估算准。提供一个保守的显存估算公式模型权重量化后 KV Cache受并发数和上下文长度影响 激活值显存。粗略估算时14B模型4-bit量化权重约占7GBKV Cache在每个并发和8000token上下文下约占1-2GB再加上框架自身开销和碎片。如果你的卡是24G开16个并发还能撑住再往上就可能爆。控制参数就是你在vLLM启动命令里那个--max-num-seqs。另外vLLM虽然做了显存管理但--gpu-memory-utilization设到0.95会导致极度紧张模型加载阶段都可能失败。我后来稳定在0.90代价只是一点点的吞吐损失换来的是长期稳定。4.4 对话经常答非所问可能要检查记忆管理有用户反馈前面刚问过这个设备的保修期是多久紧接着问那过了期还能修吗系统回答得驴唇不对马嘴。排查之后发现Agent的记忆管理只把上一轮的问题传给模型了没有把上一轮的回答状态的结论同步进去。多轮对话的坑表面上是个技术问题实际是产品设计问题。你必须在Prompt里明确当前会话的记忆边界哪些历史信息可以被新问题引用哪些已经过期作废。一种可行的做法是把多轮记忆压缩成当前会话的关键摘要——用一个槽位结构记录用户身份、订单号、当前话题等每次对话先读槽位再生成回答。这比给模型塞完整历史纪录要稳定得多。4.5 常见问题速查表症状可能原因处理手段检索不到相关内容切片太碎/格式解析乱序检查切分结果换结构感知切分回答和知识库内容对不上Prompt未约束引用范围明确只能根据参考文档回答同一个问题答案飘忽温度参数太高把temperature调低到0.2以下服务一段时间后变慢前缀缓存未开/KV Cache碎片开启prefix caching并监控TPOT偶尔返回乱码或空字符串模型输出解析失败给输出层加正则校验与重试机制用户问题太短很难检索缺少上下文补全用模型对短问题做Query改写5. 成本控制与性能优化实录5.1 离线算力和在线算力分开很多人一开始设计架构时会把所有任务都丢到同一批GPU上这在测试阶段没问题上线后成本会很难看。我的建议是把算力分成两池离线算力池跑文档解析、OCR、向量化、评测批处理。这些任务对延迟不敏感可以用低成本、甚至CPU跑一部分在线算力池跑RESTful推理服务、Agent实时编排。要求低延迟、高吞吐这部分才值得用高端GPU。离线数据管道如果每天半夜定期跑一次完全可以把它加到云函数的定时触发器里按量付费跑完自动释放。这个操作能让单月GPU成本下降40%效果非常可感。5.2 生成模型的响应延迟优化RAG应用的端到端延迟构成模型推理时间 检索时间。很多人花大力气优化检索把检索压到80ms但一眼望去模型推理占了1.5秒这是典型的抓小放大。降延迟的关键路径流式输出。让用户第一时间看到文字逐字蹦出来感知延迟会显著下降首字延迟比完全生成再返回体感好太多减少输入Prompt长度。在保证效果的前提下精简Prompt里的历史会话信息只保留关键的槽位信息而不是把完整对话历史都塞进去。Prompt变短 KV Cache变小 首Token时间缩短如果并发量上去了优先考虑把底座模型蒸馏成一个更小的专用模型比如14B蒸馏到7B。这一步工程量大、需要训练数据但收益是显著且持久的。我自己的一个实操记录在相同的硬件条件下Prompt从3600token精简到1200token首Token延迟从900ms降到450ms。这个优化没有改动任何模型参数只是调整了上下文组织方式。5.3 缓存策略和成本控制细节对话场景里具有很高的局部性很多问题会被反复问到。引入语义缓存是成本控制的第二板斧把用户问题向量化在缓存里找语义相同或高度相似的历史问题命中时直接把之前生成好的回答返回完全不需要再经过大模型。我用的是一个简单的Redis 向量检索缓存命中率大约30%。也就是说三分之一的线上请求对底座模型来说是0消耗这个数字对账单的缓解非常明显。缓存过期时间设置为24小时比较合理因为知识库更新后缓存还锁着昨天的旧答案也是一种大事故隐患。6. 演进方向与高阶玩法6.1 从单Agent走向多Agent协作单Agent系统里的瓶颈很明显一个模型同时承担意图识别、工具调用、上下文管理、结果生成的所有职责Prompt稍微一复杂模型就会顾此失彼把工具调用参数写错又或者把上下文搞混。多Agent架构的思路是把复杂的任务拆给多个专职Agent一个负责意图识别和任务分发一个专门做知识检索一个负责工具调用一个负责结果组织和润色。它们之间通过消息队列或者统一的Agent间通信协议协作。这个方向是目前AI应用架构的热点对应的开源框架如LangGraph、AutoGen、MetaGPT等提供了非常多的脚手架。但我个人认为多Agent协作的瓶颈不在框架在于任务拆分的合理性。拆得太粗没能缓解单Agent的负担拆得太细Agent之间通信的成本会反过来拖慢系统。6.2 从通用模型走向领域微调当RAG的上限被真正逼近、领域术语理解成为了不可绕开的瓶颈你才应该认真考虑领域微调。我建议的微调路线分为三步走整理领域语料包括企业内部文档、QA对话记录、第三方行业资料从通用底座模型出发先做增量预训练继续学习领域词汇和表述模式再做指令微调学会按企业内部的工作规范回答问题用评测集持续评估切忌只看Loss下降要在真实场景语料上验证效果。我踩过的坑是微调完模型在训练集上的效果很好一到真实业务问题和检索内容混合的场景就开始答非所问原因是训练样本里缺少检索上下文 问题这种组合形式的输入格式。所以做微调数据时一定要模拟线上Prompt结构来构造训练样本。6.3 从问答机器人到工作流自动化最后说一个更大的演进方向。一个知识库问答Agent本质上只是一个会说话的系统。但AI工程的终局价值不在会说话而在于能把事办了。我的下一步计划是让这个Agent不仅回答问题还能直接执行一些简单的工作流。比如用户问申请退款Agent自动识别意图调用工单系统创建退款单填入必要信息再通知人工审核。这要求Agent的可信度必须再上一个台阶——因为从回答仅供参考到自动执行操作系统所承担的责任完全不是一个量级。这个方向上的核心命题是可信治理每一次主动执行都要有明确的日志、告警、回滚机制。AI工程做到最后你会发现真正难的不是让模型更聪明而是让系统的行为更可控。这大概是每个AI工程人最终都要面对的一道题。