1. “能交付”不是口号是面试官在看的三张工程能力快照最近帮几位朋友内推大模型方向的岗位发现一个特别有意思的现象简历里写“熟悉LangChain”“掌握RAG流程”“了解Agent架构”的人一抓一大把但真正聊到细节时八成卡在“你上次部署的推理服务QPS多少怎么压测的”“你构建的知识库召回率跌到60%时第一反应是调top_k还是查embedding质量”“Agent跑着跑着突然不响应了你是先看日志、重启沙盒还是翻trace链路”——这些不是理论题是现场拆解真实交付场景的手术刀。所谓“能交付”本质是把模型能力变成可上线、可监控、可迭代的生产系统。它不关心你能不能复述Transformer原理而盯着你能不能让一个RAG服务在200并发下稳定返回结果不问你是否读过AutoGen论文而要看你能否在3天内用LlamaIndexFastAPI搭出带fallback机制的客服Agent原型并接入企业微信回调。这背后有三张清晰的能力快照每一张都对应一个真实工程断点推理服务模型不是玩具是API。它要扛住流量、算得准、吐得快、出错有兜底。你调通Ollama本地跑7B模型不算交付你让vLLM在4卡A10上跑满85%显存利用率、P99延迟压到320ms、支持流式SSE输出才算。RAG知识库不是文档堆是检索引擎语义理解结果重排的闭环。你上传PDF建完向量库不算交付你解决PDF表格识别失真、处理跨页标题断裂、让“发票金额大于5000元”这类复合条件精准命中才算。AgentAgent不是多步调用是状态管理工具编排异常熔断的运行时。你写个ReAct循环调用天气API不算交付你设计tool calling失败后的降级策略、实现用户中断后的上下文归档、给每个step加timeout和retry backoff才算。我见过最典型的反例一位候选人花两周用LangChain搭了个“智能会议纪要助手”演示时流畅无比。但当面试官问“如果会议录音转文字错误率超30%你的RAG怎么保证摘要不胡说”“如果调用日程API超时Agent是重试三次还是直接返回‘暂无法同步日志’”他愣住了——那套demo里根本没有异常分支所有接口都假设永远成功。这就是“不能交付”的本质只覆盖happy path不处理现实世界的毛刺。所以别再背概念了。这张清单不是知识点罗列而是你下次部署服务前该自问的 checklist。下面我会用真实项目切片一层层剥开这三块硬骨头怎么啃。2. 推理服务从“跑起来”到“扛得住”的四道生死线很多人以为推理服务就是model.generate()封装成API。实则不然。真正的工程交付必须穿越四道生死线资源利用率、延迟稳定性、错误兜底、可观测性。漏掉任何一道上线即事故。2.1 资源利用率显存不是越满越好是“刚够用”的艺术显存利用率95%听起来很美但实际是悬崖边跳舞。我们曾在线上环境遇到过vLLM加载Llama3-70B后显存占用94%一切正常。某天用户批量上传长文本推理时触发CUDA OOM整个实例崩溃。根因不是模型太大而是vLLM的PagedAttention在动态分配KV cache时预留buffer不足。解决方案不是降batch_size而是预估峰值显存并留20% buffer。计算公式如下峰值显存 ≈ 模型参数量 × 2字节FP16 KV Cache显存 输入输出buffer KV Cache显存 batch_size × max_seq_len × num_layers × num_heads × head_dim × 2字节以Llama3-8B为例参数显存8×10⁹ × 2 16GB假设batch_size4, max_seq_len4096, num_layers32, num_heads32, head_dim128KV Cache显存 4×4096×32×32×128×2 ÷ 1024³ ≈ 10.2GB总峰值 ≈ 16 10.2 2buffer≈ 28.2GB这意味着单卡A1024GB根本不够必须上双卡或换A10040GB。我们最终选A100 vLLM的tensor parallel显存利用率控制在78%留足突发流量缓冲。提示别信“显存占用低浪费”。利用率低于60%说明没榨干硬件高于85%则风险陡增。70%-75%是黄金区间。2.2 延迟稳定性P99延迟才是命门不是平均值很多团队只看平均延迟比如“平均200ms”。但线上真实体验由P99决定。我们曾发现平均延迟180msP99却高达1.2s。排查发现是tokenizer缓存未开启——每次请求都要重新加载分词器冷启动耗时占总延迟70%。vLLM默认关闭tokenizer缓存需显式配置# 启动命令中加入 --tokenizer-mode auto --trust-remote-code同时在代码中复用tokenizer实例from transformers import AutoTokenizer tokenizer AutoTokenizer.from_pretrained(meta-llama/Meta-Llama-3-8B-Instruct, use_fastTrue, trust_remote_codeTrue) # 全局复用避免重复加载更关键的是请求队列深度控制。vLLM默认max_num_seqs256但高并发下队列积压会导致P99飙升。我们通过压测确定当并发150时P99延迟指数增长。于是将max_num_seqs降至64并配合客户端限流令牌桶算法确保队列始终在可控范围。2.3 错误兜底没有“永远成功”的API只有“优雅失败”的设计线上最怕的不是报错而是静默失败或雪崩。我们给推理服务加了三层兜底模型层熔断使用tenacity库对generate调用做熔断。连续3次超时5s则触发熔断后续请求直接返回fallback响应如“当前服务繁忙请稍后再试”5秒后半开试探。from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type retry( stopstop_after_attempt(3), waitwait_exponential(multiplier1, min1, max10), retryretry_if_exception_type((TimeoutError, torch.cuda.OutOfMemoryError)) ) def generate_with_fallback(...): return model.generate(...)协议层降级HTTP 5xx错误时自动切换至轻量模型如Phi-3-mini。通过Nginx upstream健康检查实现upstream llm_backend { server 10.0.1.10:8000 max_fails3 fail_timeout30s; server 10.0.1.11:8000 backup; # 备用轻量模型 }业务层兜底当所有模型均不可用时返回结构化模板答案。例如客服场景固定返回“已收到您的问题工程师正在紧急处理预计2小时内回复。”——比空响应或报错更降低用户焦虑。2.4 可观测性没有监控的API等于裸奔我们用PrometheusGrafana搭了一套最小可行监控栈聚焦四个黄金指标指标采集方式告警阈值业务意义vllm:request_success_ratevLLM内置metrics99.5%服务可用性基线vllm:time_in_queue_secondsPrometheus histogramP99 2s请求排队瓶颈gpu:utilizationnvidia-smi exporter90%持续5min硬件过载预警http:response_latency_secondsFastAPI middlewareP99 800ms端到端体验劣化特别注意不要只看GPU利用率。我们曾发现GPU利用率85%但time_in_queue_secondsP99达5s——根因是CPU瓶颈tokenizer太重。加了use_fastTrue和缓存后CPU占用从95%降到35%队列延迟直降80%。注意监控不是摆设。每周五下午我们强制执行“监控巡检”随机挑3个告警指标回溯过去7天数据手动验证告警逻辑是否合理。去年发现2个误报规则避免了3次无效告警。3. RAG从“能检索”到“检得准”的七处暗礁RAG常被简化为“文档→向量化→检索→拼接prompt”。但真实交付中90%的问题出在文档预处理和检索后处理环节。我整理了七个高频暗礁每个都来自血泪教训。3.1 PDF解析表格与跨页标题是知识库的“阿喀琉斯之踵”OCR类PDF扫描件用PyMuPDF基本能搞定。但原生PDF文字可复制的表格解析PyMuPDF会把单元格内容打乱。我们处理一份财务报表PDF时原始表格项目Q1Q2Q3收入100万120万150万经PyMuPDF提取后变成项目 Q1 Q2 Q3 收入 100万 120万 150万导致embedding时语义断裂“Q1收入”无法关联。解决方案用pdfplumber替代PyMuPDF处理表格。pdfplumber能保留坐标信息精准提取表格import pdfplumber with pdfplumber.open(report.pdf) as pdf: for page in pdf.pages: tables page.extract_tables() for table in tables: # table是二维列表保持行列结构 for row in table: text | .join([cell if cell else for cell in row]) # 再送入embedding更棘手的是跨页标题。一份合同PDF中“甲方义务”章节从第5页末尾延续到第6页开头但PyMuPDF按页切割导致第6页开头丢失上下文。我们的解法是启用overlap chunking相邻chunk重叠100字符并在chunk元数据中标记原始页码和位置from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap100, # 关键重叠100字符 separators[\n\n, \n, 。, , , , , , 、, ] ) docs splitter.split_documents(raw_docs) # docs[0].metadata {source: contract.pdf, page: 5, start_pos: 1200} # docs[1].metadata {source: contract.pdf, page: 6, start_pos: 0}3.2 Embedding质量不是模型越贵越好是领域适配度决定成败我们试过text-embedding-ada-002、bge-large-zh、multilingual-e5-large。结果发现在法律文书场景bge-large-zh的Hit Ratetop-3召回率仅68%而微调后的bge-base-zh达89%。原因在于通用embedding模型没见过“缔约过失责任”“表见代理”等术语。解决方案不是换更大模型而是领域适配微调构建领域词典从1000份判决书中抽取出高频法律术语如“无权代理”“善意取得”生成正例词对“无权代理” ↔ “代理人未获授权却以被代理人名义订立合同”使用Sentence-BERT框架微调from sentence_transformers import SentenceTransformer, losses model SentenceTransformer(BAAI/bge-base-zh) train_examples [InputExample(texts[term, definition]) for term, definition in legal_pairs] train_dataloader DataLoader(train_examples, shuffleTrue, batch_size16) train_loss losses.MultipleNegativesRankingLoss(model) model.fit(train_objectives[(train_dataloader, train_loss)], epochs3)微调后Hit Rate提升21%且推理速度比large版快3倍。提示别迷信SOTA模型。在垂直领域一个微调过的base模型往往碾压未适配的large模型。3.3 检索后重排BM25Cross-Encoder不是叠加是接力纯向量检索cosine similarity在长尾query上效果差。比如搜“员工离职后竞业限制补偿金怎么发”向量检索可能召回“劳动合同法全文”但真正需要的是“最高人民法院关于审理劳动争议案件司法解释四第二十三条”。我们的方案是两阶段检索第一阶段BM25快速召回100个候选利用关键词匹配对长尾query更鲁棒第二阶段Cross-Encoder对Top100重打分取Top5Cross-Encoder用BAAI/bge-reranker-base轻量且效果好from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) pairs [[query, doc.page_content] for doc in bm25_results[:100]] scores reranker.predict(pairs) # scores是numpy array取argmax获取最佳doc索引实测显示两阶段比纯向量检索Hit Rate提升37%且P99延迟仅增加120msCross-Encoder在CPU上跑不占GPU。3.4 Query改写不是让LLM“润色”是做意图矫正用户输入“发票丢了怎么办”直接检索会召回“发票管理办法全文”。但真实意图是“补开发票流程”。我们用LLM做Query改写但不是简单同义替换而是意图识别实体抽取# system prompt 你是一个税务知识助手。请将用户问题改写为标准检索Query要求 1. 提取核心实体如发票、丢失、补开 2. 补充隐含动作怎么办 → 办理流程、如何操作 3. 去除口语词咋、嘛、啦 4. 输出格式【实体】【动作】如发票丢失补开流程 改写后Query“发票丢失补开流程”检索精准度提升52%。关键是改写模型必须用领域数据微调否则会把“个税退税”改成“个人所得税返还”召回一堆无关政策。3.5 Fallback机制当检索失败时别让用户看到“未找到相关资料”我们设计了三级FallbackLevel 1检索层若BM25向量检索top-5相似度均0.3触发fallbackLevel 2LLM层用LLM基于文档元数据标题、摘要生成泛化回答# 提示词 用户问题{query} 文档标题{doc_title}摘要{doc_abstract} 请基于标题和摘要给出一个宽泛但相关的指引不要编造细节。 Level 3业务层若LLM也无响应返回预设话术“您提到的问题涉及XX领域建议查阅《XXX条例》第X章或联系XX部门咨询。”这套机制使“未找到答案”率从31%降至4.7%用户满意度提升2.3倍。3.6 知识库更新不是“删旧建新”是增量索引与版本灰度知识库每天更新但全量重建向量库要4小时。我们的解法是增量索引 版本灰度增量索引用ChromaDB的upsertAPI只更新变更文档的embedding版本灰度新版本索引建好后先切5%流量验证Hit Rate达标后再100%切换回滚机制保留最近3个版本ID一键回滚关键代码# ChromaDB不支持原生版本我们用collection name模拟 client chromadb.HttpClient() # 创建新版本collection new_collection client.create_collection(namefkb_v20240601) # 批量upsert新增/变更文档 new_collection.upsert( idsnew_ids, documentsnew_docs, metadatasnew_metas ) # 流量切分在API网关层实现非数据库层3.7 多模态RAG图片不是“存进去就行”是OCRLayout理解双通道客户问“这张发票金额是多少”知识库存的是PDF。单纯OCR会把发票识别成乱序文本。我们的方案是LayoutParser OCR双通道用LayoutParser检测PDF中的“表格区域”“文字区域”“印章区域”对表格区域用TableBank模型识别结构化数据对文字区域用PaddleOCR识别保留坐标构建混合chunk[{type:table, data:...}, {type:text, bbox:[x,y,w,h], text:¥12,345.00}]embedding时table data转为markdown字符串text按坐标排序拼接这样“金额”字段能精准定位而非在整页文本中模糊匹配。实测发票金额提取准确率从73%升至98.2%。4. Agent从“能调用”到“稳运行”的五维运行时治理Agent常被当成“LLM工具调用”的组合。但真实交付中Agent是运行时系统必须治理五维状态持久化、工具编排、异常熔断、上下文压缩、安全沙箱。4.1 状态持久化不是“内存变量”是分布式状态机Agent对话中用户说“查完天气再订酒店”中间可能断连。若状态只存在内存重连后就丢失上下文。我们的解法是基于Redis的状态机每个session ID对应一个Redis Hash存储state: 当前stepe.g., weather_querycontext: JSON序列化的上下文含历史tool call结果pending_tool: 正在等待的tool call ID每次step执行前先HGETALL session:{id}加载状态step完成后HMSET session:{id}更新状态关键设计状态变更原子化。用Redis Lua脚本保证-- atomically update state and context redis.call(HMSET, KEYS[1], state, ARGV[1], context, ARGV[2]) return redis.call(HGETALL, KEYS[1])这样即使并发请求状态也不会错乱。我们压测1000并发状态一致性100%。4.2 工具编排不是“顺序调用”是DAG依赖与并行调度用户问“对比北京和上海今天气温并查两地机场航班延误率”。朴素做法是串行查北京天气→查上海天气→查北京航班→查上海航班。耗时4×API延迟。我们用异步DAG调度import asyncio from typing import Dict, Any async def run_tool_graph(graph: Dict[str, Any]) - Dict[str, Any]: # graph定义依赖关系如 {weather_beijing: [], weather_shanghai: [], flight_beijing: [weather_beijing], ...} results {} pending {k: asyncio.create_task(_call_tool(v)) for k, v in graph.items()} while pending: done, pending await asyncio.wait(pending.values(), return_whenasyncio.FIRST_COMPLETED) for task in done: tool_name, result await task results[tool_name] result return results实测将4步串行平均延迟1.8s优化为2轮并行平均延迟0.95s性能翻倍。4.3 异常熔断不是“重试三次”是分级熔断与降级策略Tool调用失败不能简单重试。我们定义三级熔断熔断级别触发条件动作示例L1瞬时HTTP 429限流指数退避重试1s, 2s, 4s天气API限流L2服务连续3次5xx切换备用API或返回缓存航班API宕机返回昨日缓存数据L3业务工具返回空结果或格式错误调用LLM生成兜底回答地图API返回坐标缺失LLM基于城市名估算经纬度熔断策略存在Redis中可热更新{ weather_api: {level: L2, fallback: cache}, flight_api: {level: L3, fallback: llm} }4.4 上下文压缩不是“删历史”是语义摘要与关键事实提取10轮对话后token数爆炸。我们不用简单截断而是LLM驱动的摘要压缩每3轮对话调用专用摘要模型如Qwen1.5-0.5B生成关键事实Key Facts{location: 北京, date: 2024-06-01, intent: 查询天气与航班}对话摘要Summary用户想了解北京今日天气及首都机场航班情况已确认天气晴朗正在查询航班延误率。新prompt中用Key Facts替换原始历史Summary作为背景实测使context长度减少68%且关键信息100%保留LLM理解准确率无损。4.5 安全沙箱不是“禁用exec”是工具权限的RBAC管控Agent调用工具必须隔离。我们用RBAC基于角色的访问控制定义角色customer_service只能查天气、航班、admin可调用数据库备份工具工具注册时声明所需权限tool(permissions[read_weather, read_flight]) def get_weather(city: str) - str: ...Agent执行前校验当前session角色是否有对应权限权限配置存于PostgreSQL支持动态调整这样客服Agent绝不可能误删数据库安全边界清晰。5. 工程能力清单一张可自查、可面试、可落地的交付核对表最后我把前面所有要点浓缩成一张交付核对表Delivery Checklist。它不是学习大纲而是你每次上线前必须逐项确认的工程红线。打印出来贴在显示器边或者存进团队Confluence——它比任何JD都更能定义“能交付”。能力域核心问题自查方法不合格表现合格标准推理服务显存利用率是否在70%-75%nvidia-smi实时监控压测时记录峰值单卡A10跑70B模型显存95%A100上Llama3-8B利用率73%P99延迟≤320msP99延迟是否≤800ms用k6压测导出P99数据平均延迟200msP99 1.5s200并发下P99780ms无超时是否有三层错误兜底检查代码熔断、降级、fallback只有try-except无fallback熔断tenacity降级Nginx backupfallback模板响应RAGPDF表格是否准确解析随机抽10份PDF人工核对表格内容PyMuPDF提取的表格行列错乱pdfplumber提取表格结构100%保真Embedding是否领域微调查看训练脚本和eval报告直接用bge-large-zhHit Rate 65%微调bge-base-zhHit Rate≥85%是否有两级检索BM25Cross-Encoder检查检索代码逻辑只用向量检索BM25召回100→Cross-Encoder重排→Top5Query改写是否意图矫正抽样10个用户query对比改写前后“发票丢了”→“发票丢失”无动作补充“发票丢了”→“发票丢失补开流程”Agent状态是否Redis持久化查看session存储逻辑状态存在内存断连即丢失Redis Hash存储state/context/pending_tool工具调用是否DAG并行分析trace日志看tool call时间线4个tool串行调用依赖无冲突的tool并行执行是否有三级熔断检查tool装饰器和fallback配置只有重试无降级L1重试/L2缓存/L3 LLM兜底上下文是否语义压缩检查对话历史处理逻辑简单截断最后2000token每3轮生成Key FactsSummary长度减60%工具权限是否RBAC管控查看tool注册和权限校验代码所有tool无权限检查tool(permissions[read_weather]) RBAC校验这张表的价值不在于告诉你“该学什么”而在于帮你判断“现在能不能上线”。我建议你每次交付前拉着后端、算法、测试一起过一遍这张表逐项打钩面试时如果被问“你做过哪些RAG项目”不要讲流程直接说“我确保了表格解析准确、Embedding领域微调、两级检索、Query意图矫正——这是我的交付核对表第3、4、5、6项都已达标”团队新人入职第一周任务不是写代码而是用这张表 audit 一个线上服务找出3个不合格项并修复工程能力不是玄学。它是一行行代码、一次次压测、一个个深夜排查堆出来的肌肉记忆。当你能把这张表上的每一项都变成条件反射你就真正拿到了大模型时代的入场券——不是作为调包侠而是作为交付者。我在实际交付中发现最有效的提升方式不是学新框架而是每周选一项核对表条目用生产环境数据验证。比如这周专攻“PDF表格解析”找100份真实PDF跑自动化校验统计错误率下周攻“P99延迟”用k6压测并分析火焰图。三个月下来你会惊讶于自己解决问题的直觉——那不是运气是肌肉记忆长成了本能。
