做AI应用落地这段时间我一直保持一个习惯每隔几周把手头项目相关的外部动态、内部复盘和技术选型变化整理成一份情报式的笔记。今天这份“AI情报 | 20260930”正好赶上我们一个智能问答系统从原型转向生产环境的关键节点里面既有对近期技术趋势的判断也有大量在真实业务里踩出来的经验。如果你正在做RAG落地、Agent架构设计或者被模型选型和评估体系搞得焦头烂额这份笔记应该能帮你少走不少弯路。先说下背景。我们做的不是那种demo级别的聊天机器人而是接入了企业内部知识库、需要处理大量专业文档的问答系统。早期版本是标准的“向量检索大模型生成”路线跑通没问题一上生产就原形毕露检索召回不准、回答胡编乱造、响应延迟高、用户问法一变就崩。到了9月中旬我们决定做一轮大的架构调整把纯粹的RAG改造成带路由分发、工具调用和多轮记忆管理的Agent框架。这个过程踩了很多坑也沉淀了不少可复用的经验趁着9月30日这个节点整理成以下内容。1. 情报筛选的三条主线与技术判断逻辑写情报笔记最忌讳的就是什么都往里面塞最后变成新闻聚合器。我给自己定的规矩是只整理那些对“AI应用落地”有直接影响的信息具体分三条主线去看。1.1 主线一模型能力与推理成本的变化今年下半年的大模型迭代速度明显放缓了各家不是在卷参数规模而是在卷“同成本下的效果上限”。这一点在9月底体现得特别明显几个主流厂商的API价格都有调整中等规模模型的推理成本降到年初的三分之一左右这对我们做私有化部署和成本控制是个好消息。但要注意降价通常意味着能力重心转移有些模型牺牲了长文本理解来换速度采购之前一定要拿自己业务里的真实数据去跑一遍评测不能只看跑分。1.2 主线二Agent框架的成熟度与工程化实践Agent这个概念热了一年多真正能稳定跑生产环境的框架其实不多。9月份我观察到几个趋势一是LangChain之外的国产框架开始成熟比如一些主打轻量级、低侵入的编排工具在中文场景下反而比国外框架顺手二是业界对“Multi-Agent”的狂热开始降温大家意识到90%的业务场景一个Agent加几个工具函数就能解决没必要搞复杂协作。杰瑞米·霍华德那篇关于“单一Agent优先”的观点我很认同复杂架构带来的是调试地狱。1.3 主线三检索增强生成的技术演进与新方案RAG是当前落地AI应用绕不开的底座但传统“向量检索-重排序-拼接-生成”的流程已经明显不够用了。9月份有几篇技术报告值得关注包括混合检索的工业级方案、基于图结构的上下文增强、以及一种自适应检索深度的思路——不是每次检索都固定取Top K而是根据问题难度动态调整。这些对我们改造检索链路启发很大下面第三节我会具体展开我们怎么把这些思路落地的。情报只提供方向方向必须用你自己的数据验证。别人跑得通的方案换一个知识域可能完全失效。2. 模型选型与推理算力成本核算把账算清再动手很多团队做AI项目第一步就卡在模型选型上纠结开源还是闭源、大杯还是中杯。我个人的经验是不要追求“地表最强模型”而要找到“最懂你业务的那个模型”。这个月我们做了一次系统性的模型盘点重点考量推理成本、上下文长度、指令遵循能力和中文场景适配度。2.1 场景与模型能力的匹配矩阵我们9月底做的选型测试表可以给大家参考。核心思路是把手头的业务场景分成四类简单问答、复杂推理、结构化数据抽取、长文生成。每类场景对模型能力的要求完全不同。简单问答问题短、答案直接不需要太多推理适合用中杯模型成本低、速度快。复杂推理涉及多跳问题、逻辑判断必须用大杯模型或专门的推理增强模型。结构化抽取从合同、报告中提取字段对指令遵循和格式输出要求极高要测模型的JSON输出稳定性。长文生成周报、摘要、方案初稿需要模型有长上下文理解和连贯生成能力重点看是否存在中段信息遗忘。我的建议是项目初期即使预算有限也要至少同时测试三个量级的模型——小杯、中杯、大杯用同一批测试集跑效果和成本对比。很多团队直接选了最贵的模型以为效果一定最好实测下来有时候中杯模型的领域表现反而超过大杯因为小模型过拟合于通用数据专业领域微调更容易生效。2.2 推理成本的关键计算维度与降本路径推理成本不是简单看API定价表要结合调用模式算。我们目前平均每天约5万次调用这个月把成本模型拆成了三个维度输入Token成本RAG场景下输入Token是大头因为要把检索到的文档片段全部拼接进去。平均一次问题输入约1200 Token其中900 Token是检索补充内容。输出Token成本这部分占比小但直接影响用户体验。我们在回答中引导模型结构化输出减少不必要的废话输出Token平均控制在400以内。重试成本这个最容易忽略。模型超时、输出格式错误、内容风控拦截都会导致重试重试率超过5%时成本直接飙升20%以上。降本路径我们尝试了几条最有效的是“分层路由”策略——先用一个轻量级分类器判断问题难易简单问题走小模型复杂问题才调大模型。仅这一项就把月度推理成本压低了接近40%。另一个思路是本地部署中小模型处理大批量的低难度请求只让云端大模型处理真正需要“智力”的请求。混合云架构的运维成本会增加但算总账还是划算的。2.3 选型中的三个常犯错误与建议第一是只看公开Benchmark不看业务数据。公开跑分用的评测集跟你的知识域完全是两回事必须自建一套至少覆盖100条真实问题的评测集人工标注标准答案然后让候选模型跑对比输出质量。第二是忽略上下文窗口的作用方式。有个模型标称支持1M上下文但实测发现超过40K Token后中间段检索信息就被弱化了。后来用了分块压缩关键片段优先注入才解决。第三是没考虑数据出境和私有化要求。我们有个项目核心数据不能出内网所以必须同时准备开源模型的私有化方案。建议即使最终选择闭源API也要在架构上预留一个“模型抽象层”随时可以切换本地模型不然一个数据合规要求出现整个技术路线就得推翻重来。3. 从RAG到Agent架构检索增强的工程化演进实录前面说了纯RAG在真实业务里跑不通。9月份我们做的最大动作就是把原来的“先检索-后生成”单链路改造成一个带任务分流和管理机制的Agent框架。这个过程花了两周多核心是解决三个问题——路由分发、工具调用和记忆管理。3.1 检索策略的改进混合检索与动态深度先讲检索这块也是最基础的部分。原来我们只用向量检索用的向量模型对中文专业术语的支持并不好“抑郁症”和“抑郁障碍”这种表达差异会导致召回完全失效。9月上旬我们改成了“稀疏检索向量检索”的混合方案稀疏检索用关键词匹配保底向量检索做语义扩展最后通过一个重排序模型把两路结果合并打分。具体做法是建立关键词索引对知识库文档做分词和实体识别抽取领域专有名词建立倒排索引专有名词匹配优先级高于语义匹配。双路召回同一问题并行发关键词查询和向量查询向量查询取Top 50关键词查询取Top 20。合并重排用交叉编码器对两路结果统一打分兼顾语义相似度和关键词命中度去掉重复内容后取Top 8进上下文。另一个改进是“自适应检索深度”。过去不管什么问题都固定取Top 8结果简单问题塞了一堆无关内容复杂问题又不够用。现在用一个二分类模型预测问题复杂度简单问题Top 4中等Top 6困难Top 10实测准确率没有下降反而因为上下文更干净回答流畅度明显提升。3.2 任务路由与工具调用Agent架构的骨架RAG做不了的事情要靠“工具调用”来完成。我们的Agent框架里内置了四个工具知识库检索、文档解析、结构化查询、外部计算。每个工具都对应一个独立的服务接口Agent根据用户问题决定调哪个或哪几个工具再把工具结果拼进上下文生成答案。这个设计的核心是“路由意图识别”。用户问“最近三个月某个指标的走势如何”和“某个概念的定义是什么”走的完全是两条不同链路。前者触发结构化查询工具后者走知识库检索。我们微调了一个意图分类模型只有四个分类标签训练数据来自线上日志人工标注。这里有个教训意图分类模型不要试图覆盖所有边界情况定义四到六个粗粒度标签把模糊情况交给大模型的兜底判断反而更稳。工具调用还有一个细节要处理好——参数注入。结构化查询工具需要知道查询的时间范围和对象这些参数不是简单从用户话里抽出来就行的要做实体标准化。比如用户说“上季度”系统要能换算成具体的日期区间。我们写了一套基于规则的时间表达式解析器效果远好于让大模型自己瞎猜。3.3 多轮记忆管理Agent不“失忆”的关键Agent和普通问答最大的区别是它要能处理有上下文依赖的多轮对话。我们早期版本直接把最近5轮对话全部塞给模型结果上下文爆炸回答质量急剧下降。9月中我们上线了一个轻量级记忆管理模块核心思路是“分类型记忆”短期记忆当前会话的关键信息用槽位结构记录比如用户提到的主题、目标对象、筛选条件。工作记忆当前任务相关的检索结果和中间结论只保留本轮任务使用。长期记忆用户标识、固定偏好、历史结论摘要存储在外部向量库按需召回。这个模块的好处是模型真正看到的上下文是“被筛选过”的而不是一股脑的全部历史。实测多轮对话的准确率从68%提升到83%。设计上有个坑短期记忆的槽位更新时机要处理好比如用户中途改了查询条件旧的槽位必须及时覆盖和清除否则会出现“用户已经改了需求系统还在按旧条件查询”的尴尬。4. 评估体系没有量化就没有迭代闭环AI应用最怕的就是“感觉还可以”四个字。我见过太多团队上线前用二三十条用例人工看了一遍就觉得行了上线后被用户各种奇怪问题打爆。这个月我们花了大力气搭建评估体系这是我认为这期情报里最有复用价值的部分。4.1 评估数据集的构建方法从线上真实难题中淘金评估集不需要一开始就很大但必须持续累积。我们的做法是从线上日志捞取用户真实问题按频次排序覆盖高频前200条。针对系统答得不好的问题做硬负样本标注明确标出错误类型。每两周新增一批线上新问题保持评估集与真实分布同步。评估集的分层也很重要。我们分了三层基础层覆盖标准问法进阶层覆盖说反话、省略主语、专业黑话等变体挑战层覆盖从前文才能得到的指代问题以及“我不知道”类问题系统应当诚实答复不知道而不是瞎编。4.2 多维度评估指标设计与打分标准光看“答得对不对”太粗了我们拆成四个维度分别打分信息准确率回答中的事实性信息是否与知识库一致按句级检查核心信息错一处扣分。完整率用户问题的所有子问题是否都被覆盖只答一半算不完整。可读性是否病句、逻辑是否通顺、有没有车轱辘话反复说。安全性有没有涉及不该答的内容有没有暴露系统内部提示词。每个维度设1到5分的评分标准建立详细的打分rubric避免不同评估人员标准漂移。安全性的评分要单独设置一票否决制只要触发红线其他维度再高也判失败。4.3 回归测试与CI集成把评估跑成自动化流程评估体系搭建的目的不是为了出一份报告而是让每一次改动可验证。我们最终把评估流程接入了CI流水线逻辑是开发提交新的检索策略或Prompt改动。自动化脚本运行完整评估集并行调模型接口。生成对比报告新版本 vs 上一版本在各维度的分差和案例diff。关键指标回退超过阈值时阻塞合并并要求开发者补充解释或回退改动。这个流水线最大的阻力是成本。跑一次完整评估要用掉约几万Token我们在非高峰期调度并配合本地模型跑部分用例成本控制在可接受范围。当CI评估机制跑起来以后团队改代码的心理安全感明显提升因为每一次改动都能立刻看到影响而不是凭感觉赌一把。自动化评估是“质量底线”的守护者但打分rubric要定期维护频繁出现的错误类型要及时补充到评估集里否则评估体系会滞后于系统演进。5. 工程化落地从Notebook演示到生产系统的四大难点很多实验室阶段跑得好的方案一到生产环境就崩。这周我们处理了四个典型的工程化问题写出来给大家排雷。5.1 流式输出与超时控制的坑用户跟AI对话的耐心极差超过3秒没有首字返回就开始流失。我们把生成方式改成了流式输出但流式输出带来了新的问题用户看到的不完整内容可能包含误导性信息。后来我们加了“缓冲输出”机制模型生成首段约80字后才开始向用户推送既保证首响速度又避免过度剧透。超时控制比想象的难做。大模型接口在高峰期可能响应不稳定我们在网关层配置了分级超时策略连接超时3秒。首字节超时15秒。总生成超时随不同任务分档简单任务30秒复杂任务60秒。超时后触发降级策略重试一次重试仍失败则返回“这个问题有点复杂请换个方式再问一次”并记录日志用于后续分析。5.2 可观测性改造给大模型应用装上仪表盘大模型应用的调试难度比传统软件高一个量级因为输出是概率性的同一个问题每次答案都可能不同。我们上了三个可观测性工具全链路追踪记录从用户请求到检索、到Prompt拼装、到模型生成、到后处理的完整Trace。反馈闭环用户对回答点“有帮助/没帮助”的按钮数据回传后用于针对性优化。成本与延迟看板按接口、按场景、按时段拆分的调用量、Token消耗、延迟分布、错误率监控。其中最有用的是全链路追踪。问题排查时不再靠猜而是能直接看到检索阶段召回的是什么、重排后留下了什么、Prompt里注入了什么、模型针对这个Prompt产出了什么。你会发现很多时候模型没错错的是检索召回了一堆垃圾。5.3 微调什么样的团队才真正需要它9月份我们差点走了歪路——一个业务方提了一堆特殊需求我们第一反应是“微调一个专用模型”。后来评估下来发现超过80%的需求通过优化Prompt和检索就能解决。我给团队定了一个判断标准当系统在“正确检索到信息但答非所问”上频繁出错时先优化Prompt和解码参数。当系统在“需要特定输出格式或特定领域语气”上不达标时才考虑微调。当知识库更新频率远超模型微调频率时绝对不要试图用微调取代RAG知识永远在变模型参数跟不上。如果真要微调数据准备是最大的工程。我们整理了一套数据清洗流程去重、去敏感信息、检测与原文的一致性、规范格式统一。数据量不贪大几千条高质量数据胜过几万条粗糙数据。训练过程用LoRA这类参数高效微调方案单卡就能跑成本低很多。6. 安全、合规与后续规划上线前必补的课对这个月的情报做一个收尾聊聊安全合规和一些接下来的规划。6.1 输出安全的多层过滤实践大模型生成内容的安全把控不能单靠模型本身必须在前后加控制层。我们做了三层过滤输入侧检测用户输入的恶意指令、注入攻击模式。输出侧模型输出后过一道分类器拦截涉及禁忌话题、暴力、歧视等内容。逻辑侧防止系统被诱导吐出知识库外的信息或内部规则。做输出过滤要注意误杀问题。过滤太严格会把正常回答拦截掉用户直接骂街。我们采用分级处理高危词汇直接拦截并返回安全替身话术疑似内容走人工复核队列。6.2 数据合规的一条基本线AI系统处理数据必须清楚哪些能进模型哪些不能。我们对知识库和数据管道做了一次梳理核心做了三件事分级按敏感级别给数据打标敏感数据隔离加密不进模型上下文。脱敏对姓名、手机号、地址等个人信息的结构化字段做替换与掩码处理。审计记录每次数据访问和模型调用的来源与用途确保事后可追溯。不要小看这个环节。一个项目如果上线后被查出数据使用不合规轻则项目叫停重则影响整个部门。合规的投入应该在项目第一天就做而不是在最后一刻补。6.3 年底前的三个技术方向按惯例给下一阶段定几个聚焦点。第一个是“离线批处理在线问答”的双轨架构升级把大量数据整理类任务转为离线批量处理降低在线实时计算的负担。第二个是轻量级微调结合RAG的混合应用在特定领域做小参数适配但保持知识及时性。第三个是更精细的工具调用链——让Agent能自主规划多步骤任务并在每步执行后做自检与修正而不是一把梭地调到底。另外我给自己定了一条规矩每隔一段时间重新审视模型选型但不轻易迁移。市场变化太快频繁换模型带给系统的成本和风险远大于收益。除非新方案在自建评估集上的关键指标能有10%以上的提升否则不换。写在最后的个人经验做AI应用这几个月最深的体会是技术迭代的速度确实快但工程化的基本功永远不过时。好的Agent系统不是靠一个酷炫的模型撑起来的而是靠扎实的检索链路、严格的评估闭环、完善的可观测性和明确的边界控制。如果你的系统正卡在某一个环节上不妨回头看看是哪个基础层面没打牢。这期情报笔记就先写到这里。最后分享一个日常小技巧每次技术选型前把候选方案的优缺点用表格写出来然后隔一个晚上再去看很多冲动型的决定就会冷静下来。我在项目上吃过太多次“当时觉得很好”的亏过几天回头看全是坑。希望这篇笔记能帮你少踩一些同样的坑。
做AI应用落地这段时间我一直保持一个习惯每隔几周把手头项目相关的外部动态、内部复盘和技术选型变化整理成一份情报式的笔记。今天这份“AI情报 | 20260930”正好赶上我们一个智能问答系统从原型转向生产环境的关键节点里面既有对近期技术趋势的判断也有大量在真实业务里踩出来的经验。如果你正在做RAG落地、Agent架构设计或者被模型选型和评估体系搞得焦头烂额这份笔记应该能帮你少走不少弯路。先说下背景。我们做的不是那种demo级别的聊天机器人而是接入了企业内部知识库、需要处理大量专业文档的问答系统。早期版本是标准的“向量检索大模型生成”路线跑通没问题一上生产就原形毕露检索召回不准、回答胡编乱造、响应延迟高、用户问法一变就崩。到了9月中旬我们决定做一轮大的架构调整把纯粹的RAG改造成带路由分发、工具调用和多轮记忆管理的Agent框架。这个过程踩了很多坑也沉淀了不少可复用的经验趁着9月30日这个节点整理成以下内容。1. 情报筛选的三条主线与技术判断逻辑写情报笔记最忌讳的就是什么都往里面塞最后变成新闻聚合器。我给自己定的规矩是只整理那些对“AI应用落地”有直接影响的信息具体分三条主线去看。1.1 主线一模型能力与推理成本的变化今年下半年的大模型迭代速度明显放缓了各家不是在卷参数规模而是在卷“同成本下的效果上限”。这一点在9月底体现得特别明显几个主流厂商的API价格都有调整中等规模模型的推理成本降到年初的三分之一左右这对我们做私有化部署和成本控制是个好消息。但要注意降价通常意味着能力重心转移有些模型牺牲了长文本理解来换速度采购之前一定要拿自己业务里的真实数据去跑一遍评测不能只看跑分。1.2 主线二Agent框架的成熟度与工程化实践Agent这个概念热了一年多真正能稳定跑生产环境的框架其实不多。9月份我观察到几个趋势一是LangChain之外的国产框架开始成熟比如一些主打轻量级、低侵入的编排工具在中文场景下反而比国外框架顺手二是业界对“Multi-Agent”的狂热开始降温大家意识到90%的业务场景一个Agent加几个工具函数就能解决没必要搞复杂协作。杰瑞米·霍华德那篇关于“单一Agent优先”的观点我很认同复杂架构带来的是调试地狱。1.3 主线三检索增强生成的技术演进与新方案RAG是当前落地AI应用绕不开的底座但传统“向量检索-重排序-拼接-生成”的流程已经明显不够用了。9月份有几篇技术报告值得关注包括混合检索的工业级方案、基于图结构的上下文增强、以及一种自适应检索深度的思路——不是每次检索都固定取Top K而是根据问题难度动态调整。这些对我们改造检索链路启发很大下面第三节我会具体展开我们怎么把这些思路落地的。情报只提供方向方向必须用你自己的数据验证。别人跑得通的方案换一个知识域可能完全失效。2. 模型选型与推理算力成本核算把账算清再动手很多团队做AI项目第一步就卡在模型选型上纠结开源还是闭源、大杯还是中杯。我个人的经验是不要追求“地表最强模型”而要找到“最懂你业务的那个模型”。这个月我们做了一次系统性的模型盘点重点考量推理成本、上下文长度、指令遵循能力和中文场景适配度。2.1 场景与模型能力的匹配矩阵我们9月底做的选型测试表可以给大家参考。核心思路是把手头的业务场景分成四类简单问答、复杂推理、结构化数据抽取、长文生成。每类场景对模型能力的要求完全不同。简单问答问题短、答案直接不需要太多推理适合用中杯模型成本低、速度快。复杂推理涉及多跳问题、逻辑判断必须用大杯模型或专门的推理增强模型。结构化抽取从合同、报告中提取字段对指令遵循和格式输出要求极高要测模型的JSON输出稳定性。长文生成周报、摘要、方案初稿需要模型有长上下文理解和连贯生成能力重点看是否存在中段信息遗忘。我的建议是项目初期即使预算有限也要至少同时测试三个量级的模型——小杯、中杯、大杯用同一批测试集跑效果和成本对比。很多团队直接选了最贵的模型以为效果一定最好实测下来有时候中杯模型的领域表现反而超过大杯因为小模型过拟合于通用数据专业领域微调更容易生效。2.2 推理成本的关键计算维度与降本路径推理成本不是简单看API定价表要结合调用模式算。我们目前平均每天约5万次调用这个月把成本模型拆成了三个维度输入Token成本RAG场景下输入Token是大头因为要把检索到的文档片段全部拼接进去。平均一次问题输入约1200 Token其中900 Token是检索补充内容。输出Token成本这部分占比小但直接影响用户体验。我们在回答中引导模型结构化输出减少不必要的废话输出Token平均控制在400以内。重试成本这个最容易忽略。模型超时、输出格式错误、内容风控拦截都会导致重试重试率超过5%时成本直接飙升20%以上。降本路径我们尝试了几条最有效的是“分层路由”策略——先用一个轻量级分类器判断问题难易简单问题走小模型复杂问题才调大模型。仅这一项就把月度推理成本压低了接近40%。另一个思路是本地部署中小模型处理大批量的低难度请求只让云端大模型处理真正需要“智力”的请求。混合云架构的运维成本会增加但算总账还是划算的。2.3 选型中的三个常犯错误与建议第一是只看公开Benchmark不看业务数据。公开跑分用的评测集跟你的知识域完全是两回事必须自建一套至少覆盖100条真实问题的评测集人工标注标准答案然后让候选模型跑对比输出质量。第二是忽略上下文窗口的作用方式。有个模型标称支持1M上下文但实测发现超过40K Token后中间段检索信息就被弱化了。后来用了分块压缩关键片段优先注入才解决。第三是没考虑数据出境和私有化要求。我们有个项目核心数据不能出内网所以必须同时准备开源模型的私有化方案。建议即使最终选择闭源API也要在架构上预留一个“模型抽象层”随时可以切换本地模型不然一个数据合规要求出现整个技术路线就得推翻重来。3. 从RAG到Agent架构检索增强的工程化演进实录前面说了纯RAG在真实业务里跑不通。9月份我们做的最大动作就是把原来的“先检索-后生成”单链路改造成一个带任务分流和管理机制的Agent框架。这个过程花了两周多核心是解决三个问题——路由分发、工具调用和记忆管理。3.1 检索策略的改进混合检索与动态深度先讲检索这块也是最基础的部分。原来我们只用向量检索用的向量模型对中文专业术语的支持并不好“抑郁症”和“抑郁障碍”这种表达差异会导致召回完全失效。9月上旬我们改成了“稀疏检索向量检索”的混合方案稀疏检索用关键词匹配保底向量检索做语义扩展最后通过一个重排序模型把两路结果合并打分。具体做法是建立关键词索引对知识库文档做分词和实体识别抽取领域专有名词建立倒排索引专有名词匹配优先级高于语义匹配。双路召回同一问题并行发关键词查询和向量查询向量查询取Top 50关键词查询取Top 20。合并重排用交叉编码器对两路结果统一打分兼顾语义相似度和关键词命中度去掉重复内容后取Top 8进上下文。另一个改进是“自适应检索深度”。过去不管什么问题都固定取Top 8结果简单问题塞了一堆无关内容复杂问题又不够用。现在用一个二分类模型预测问题复杂度简单问题Top 4中等Top 6困难Top 10实测准确率没有下降反而因为上下文更干净回答流畅度明显提升。3.2 任务路由与工具调用Agent架构的骨架RAG做不了的事情要靠“工具调用”来完成。我们的Agent框架里内置了四个工具知识库检索、文档解析、结构化查询、外部计算。每个工具都对应一个独立的服务接口Agent根据用户问题决定调哪个或哪几个工具再把工具结果拼进上下文生成答案。这个设计的核心是“路由意图识别”。用户问“最近三个月某个指标的走势如何”和“某个概念的定义是什么”走的完全是两条不同链路。前者触发结构化查询工具后者走知识库检索。我们微调了一个意图分类模型只有四个分类标签训练数据来自线上日志人工标注。这里有个教训意图分类模型不要试图覆盖所有边界情况定义四到六个粗粒度标签把模糊情况交给大模型的兜底判断反而更稳。工具调用还有一个细节要处理好——参数注入。结构化查询工具需要知道查询的时间范围和对象这些参数不是简单从用户话里抽出来就行的要做实体标准化。比如用户说“上季度”系统要能换算成具体的日期区间。我们写了一套基于规则的时间表达式解析器效果远好于让大模型自己瞎猜。3.3 多轮记忆管理Agent不“失忆”的关键Agent和普通问答最大的区别是它要能处理有上下文依赖的多轮对话。我们早期版本直接把最近5轮对话全部塞给模型结果上下文爆炸回答质量急剧下降。9月中我们上线了一个轻量级记忆管理模块核心思路是“分类型记忆”短期记忆当前会话的关键信息用槽位结构记录比如用户提到的主题、目标对象、筛选条件。工作记忆当前任务相关的检索结果和中间结论只保留本轮任务使用。长期记忆用户标识、固定偏好、历史结论摘要存储在外部向量库按需召回。这个模块的好处是模型真正看到的上下文是“被筛选过”的而不是一股脑的全部历史。实测多轮对话的准确率从68%提升到83%。设计上有个坑短期记忆的槽位更新时机要处理好比如用户中途改了查询条件旧的槽位必须及时覆盖和清除否则会出现“用户已经改了需求系统还在按旧条件查询”的尴尬。4. 评估体系没有量化就没有迭代闭环AI应用最怕的就是“感觉还可以”四个字。我见过太多团队上线前用二三十条用例人工看了一遍就觉得行了上线后被用户各种奇怪问题打爆。这个月我们花了大力气搭建评估体系这是我认为这期情报里最有复用价值的部分。4.1 评估数据集的构建方法从线上真实难题中淘金评估集不需要一开始就很大但必须持续累积。我们的做法是从线上日志捞取用户真实问题按频次排序覆盖高频前200条。针对系统答得不好的问题做硬负样本标注明确标出错误类型。每两周新增一批线上新问题保持评估集与真实分布同步。评估集的分层也很重要。我们分了三层基础层覆盖标准问法进阶层覆盖说反话、省略主语、专业黑话等变体挑战层覆盖从前文才能得到的指代问题以及“我不知道”类问题系统应当诚实答复不知道而不是瞎编。4.2 多维度评估指标设计与打分标准光看“答得对不对”太粗了我们拆成四个维度分别打分信息准确率回答中的事实性信息是否与知识库一致按句级检查核心信息错一处扣分。完整率用户问题的所有子问题是否都被覆盖只答一半算不完整。可读性是否病句、逻辑是否通顺、有没有车轱辘话反复说。安全性有没有涉及不该答的内容有没有暴露系统内部提示词。每个维度设1到5分的评分标准建立详细的打分rubric避免不同评估人员标准漂移。安全性的评分要单独设置一票否决制只要触发红线其他维度再高也判失败。4.3 回归测试与CI集成把评估跑成自动化流程评估体系搭建的目的不是为了出一份报告而是让每一次改动可验证。我们最终把评估流程接入了CI流水线逻辑是开发提交新的检索策略或Prompt改动。自动化脚本运行完整评估集并行调模型接口。生成对比报告新版本 vs 上一版本在各维度的分差和案例diff。关键指标回退超过阈值时阻塞合并并要求开发者补充解释或回退改动。这个流水线最大的阻力是成本。跑一次完整评估要用掉约几万Token我们在非高峰期调度并配合本地模型跑部分用例成本控制在可接受范围。当CI评估机制跑起来以后团队改代码的心理安全感明显提升因为每一次改动都能立刻看到影响而不是凭感觉赌一把。自动化评估是“质量底线”的守护者但打分rubric要定期维护频繁出现的错误类型要及时补充到评估集里否则评估体系会滞后于系统演进。5. 工程化落地从Notebook演示到生产系统的四大难点很多实验室阶段跑得好的方案一到生产环境就崩。这周我们处理了四个典型的工程化问题写出来给大家排雷。5.1 流式输出与超时控制的坑用户跟AI对话的耐心极差超过3秒没有首字返回就开始流失。我们把生成方式改成了流式输出但流式输出带来了新的问题用户看到的不完整内容可能包含误导性信息。后来我们加了“缓冲输出”机制模型生成首段约80字后才开始向用户推送既保证首响速度又避免过度剧透。超时控制比想象的难做。大模型接口在高峰期可能响应不稳定我们在网关层配置了分级超时策略连接超时3秒。首字节超时15秒。总生成超时随不同任务分档简单任务30秒复杂任务60秒。超时后触发降级策略重试一次重试仍失败则返回“这个问题有点复杂请换个方式再问一次”并记录日志用于后续分析。5.2 可观测性改造给大模型应用装上仪表盘大模型应用的调试难度比传统软件高一个量级因为输出是概率性的同一个问题每次答案都可能不同。我们上了三个可观测性工具全链路追踪记录从用户请求到检索、到Prompt拼装、到模型生成、到后处理的完整Trace。反馈闭环用户对回答点“有帮助/没帮助”的按钮数据回传后用于针对性优化。成本与延迟看板按接口、按场景、按时段拆分的调用量、Token消耗、延迟分布、错误率监控。其中最有用的是全链路追踪。问题排查时不再靠猜而是能直接看到检索阶段召回的是什么、重排后留下了什么、Prompt里注入了什么、模型针对这个Prompt产出了什么。你会发现很多时候模型没错错的是检索召回了一堆垃圾。5.3 微调什么样的团队才真正需要它9月份我们差点走了歪路——一个业务方提了一堆特殊需求我们第一反应是“微调一个专用模型”。后来评估下来发现超过80%的需求通过优化Prompt和检索就能解决。我给团队定了一个判断标准当系统在“正确检索到信息但答非所问”上频繁出错时先优化Prompt和解码参数。当系统在“需要特定输出格式或特定领域语气”上不达标时才考虑微调。当知识库更新频率远超模型微调频率时绝对不要试图用微调取代RAG知识永远在变模型参数跟不上。如果真要微调数据准备是最大的工程。我们整理了一套数据清洗流程去重、去敏感信息、检测与原文的一致性、规范格式统一。数据量不贪大几千条高质量数据胜过几万条粗糙数据。训练过程用LoRA这类参数高效微调方案单卡就能跑成本低很多。6. 安全、合规与后续规划上线前必补的课对这个月的情报做一个收尾聊聊安全合规和一些接下来的规划。6.1 输出安全的多层过滤实践大模型生成内容的安全把控不能单靠模型本身必须在前后加控制层。我们做了三层过滤输入侧检测用户输入的恶意指令、注入攻击模式。输出侧模型输出后过一道分类器拦截涉及禁忌话题、暴力、歧视等内容。逻辑侧防止系统被诱导吐出知识库外的信息或内部规则。做输出过滤要注意误杀问题。过滤太严格会把正常回答拦截掉用户直接骂街。我们采用分级处理高危词汇直接拦截并返回安全替身话术疑似内容走人工复核队列。6.2 数据合规的一条基本线AI系统处理数据必须清楚哪些能进模型哪些不能。我们对知识库和数据管道做了一次梳理核心做了三件事分级按敏感级别给数据打标敏感数据隔离加密不进模型上下文。脱敏对姓名、手机号、地址等个人信息的结构化字段做替换与掩码处理。审计记录每次数据访问和模型调用的来源与用途确保事后可追溯。不要小看这个环节。一个项目如果上线后被查出数据使用不合规轻则项目叫停重则影响整个部门。合规的投入应该在项目第一天就做而不是在最后一刻补。6.3 年底前的三个技术方向按惯例给下一阶段定几个聚焦点。第一个是“离线批处理在线问答”的双轨架构升级把大量数据整理类任务转为离线批量处理降低在线实时计算的负担。第二个是轻量级微调结合RAG的混合应用在特定领域做小参数适配但保持知识及时性。第三个是更精细的工具调用链——让Agent能自主规划多步骤任务并在每步执行后做自检与修正而不是一把梭地调到底。另外我给自己定了一条规矩每隔一段时间重新审视模型选型但不轻易迁移。市场变化太快频繁换模型带给系统的成本和风险远大于收益。除非新方案在自建评估集上的关键指标能有10%以上的提升否则不换。写在最后的个人经验做AI应用这几个月最深的体会是技术迭代的速度确实快但工程化的基本功永远不过时。好的Agent系统不是靠一个酷炫的模型撑起来的而是靠扎实的检索链路、严格的评估闭环、完善的可观测性和明确的边界控制。如果你的系统正卡在某一个环节上不妨回头看看是哪个基础层面没打牢。这期情报笔记就先写到这里。最后分享一个日常小技巧每次技术选型前把候选方案的优缺点用表格写出来然后隔一个晚上再去看很多冲动型的决定就会冷静下来。我在项目上吃过太多次“当时觉得很好”的亏过几天回头看全是坑。希望这篇笔记能帮你少踩一些同样的坑。
