AI日报：多模态落地、端侧推理与RAG检索的工程实践

这份AI日报不算严格意义上的新闻汇总更准确地说是10月7日收工前写给自己的复盘今天看到了哪些值得留意的方向动手验证了什么想法又踩掉了哪几个不该踩的坑。写日报这个习惯我坚持了好几年早期是为了逼自己每天做输入输出后来慢慢发现它成了最值钱的经验库——很多问题隔两个月回头看当时的记录能帮我省掉大量试错时间。所以这份日报适合谁如果你也在做AI应用落地、模型选型或者只是想知道圈子里最近在关心什么问题可以跟着翻一翻里面没有高深的理论都是今天真实发生过的事。1. 多模态、端侧推理、智能体协作今天圈里的三条主线1.1 多模态从“能看”到“会用”上午刷技术社区时被一篇讲多模态落地细节的讨论吸引住了。去年大家还在比谁能把图片描述得更准确今年风向明显变了讨论重心转移到“模型能不能根据一张图纸直接改代码”“能不能看懂界面截图然后替人操作应用”。这个转变很实际因为“能看”是模型能力问题“会用”是产品价值问题。跑通一个识图接口只需要半天但要把识图结果接进业务流程让它真正替人干活难点全在周边的工程细节上。社区里有个观点我比较认同多模态的下一步不是继续刷新榜单分数而是把“理解”和“操作”之间的闭环补完整。比如让模型看一张报表截图自动生成结构化数据再调用下游工具完成清洗入库。每一步单拎出来都不算新但串联起来的稳定性、错误回退、人工确认机制才是决定能不能上生产的门槛。我自己下午也顺手试了一个小实验给模型丢了一张带表格的截图让它输出Markdown表格。第一轮输出很漂亮但遇到横向合并单元格时它漏了一列。换了提示词、加了格式示例后勉强对上可换个模板又错。这类问题不会上新闻但每个做落地的人都会撞见。1.2 端侧推理的性价比节点今天另一个明显信号是端侧小模型的讨论密度比上个月高了很多。起因是几个开源社区都在聊“把推理放到手机和边缘设备上到底划不划算”。以前大家默认端侧模型只能做简单分类现在陆续有团队公开了把数十亿参数模型量化后跑在手机端的测试数据说句实话结果比我预想的要好。我看到一个比较扎实的对比用表格整理出来供大家参考对比维度云上推理接口端侧量化模型首字延迟稳定500毫秒左右会慢一些但有硬件差异网络依赖完全依赖弱网会抖动零依赖无波动隐私数据需要出设备全程在设备内模型更新服务端一键更新需要发版分发成本高单次调用成本按量计费硬件摊销长期更低这个对比说明一个问题端侧推理真正的主场不是跟云上比速度而是比“确定性”和“合规性”。很多企业场景其实不差半秒钟差的是一次网络切换的随机波动。当然端侧也有很现实的门槛显存和内存占用只是一方面更难的是模型更新分发的成本控制。我见过不止一个团队把模型塞进App之后发现每次更新都消耗大量用户流量最后又退回云端推理。所以现在圈子里比较务实的路线是“云上训练、端侧部署、云端路由”把简单的、隐私敏感的请求留在本地复杂任务再上云。1.3 智能体从单任务走向协作智能体的相关讨论今天也不少但已经不像几个月前那样总在畅想“万物皆可智能体”而是开始讨论调度、权限、任务编排这类工程问题。一个很常见的场景是用协调者去编排若干专用子智能体分别负责检索、写代码、审查、执行发布。听起来很优雅真正跑起来会发现任务之间的上下文交接、失败重试策略、成本上限控制每一项都能让项目复杂度翻倍。我看到有个团队分享的经验很接地气他们一开始设计了六个子智能体结果协同效率还不如让一个模型串行处理。后来砍掉一半只保留真正需要独立交互的子智能体把其余的环节都改成普通函数调用整体成功率反而明显提升。这个案例给我的启发是智能体的“最小有效单元”需要重新思考——不是拆得越细越好而是要看哪些环节真的需要“对话式交互”哪些只是顺序执行。这个趋势接下来会推动一批新工具出现任务编排、上下文持久化、子智能体之间的消息协议。今天只看到雏形我已经准备花一周时间把几个开源编排框架都跑一遍后面专门写一篇对比。2. 本地验证搭一条轻量RAG检索增强流水线2.1 为什么挑RAG而不是全量微调中午有位同行问我“我现在有几百份内部文档想让模型回答问题时能引用到里面的内容到底是微调好还是RAG好”这是个老问题但每次都能听到不同的答案。我的默认答案是数据量不大、内容更新频繁、对溯源要求高的场景RAG是更稳妥的起点。微调擅长改变模型的语气和输出格式但指望它把几百份文档的内容“背下来”成本高且容易过拟合更新一条知识还得重新训练。正好手头有一套整理好的FAQ和操作手册我决定直接搭一个最小可用的RAG流水线把完整过程记录下来。整个过程用到的组件都是成熟的但没有追求最好效果目标只是把链路跑通确认哪几个环节会成为瓶颈。2.2 数据与环境的准备先准备语料。我把几百份文档统一转成纯文本按章节做了切块块的大小控制在400到600字之间。切块这个步骤看起来简单实际对检索效果影响非常大切得太细一句话容易被切成两半语义不完整切得太粗向量表示的噪音就很大召回精度会明显下降。这次的文档结构比较规整我直接按标题切效果还不错如果是扫描版PDF得先过一遍OCR工作量会大很多。环境方面我在一台普通的开发机上操作配置不高。向量库存放在本地内存模式依赖装起来很快。整个准备过程大约花了一个小时其中一半时间花在清洗格式上——各种符号、制表符、乱码真的是拦路虎。这里给个经验建议语料清洗做得越认真后面的检索效果越稳定这个环节不值得省时间。2.3 三行核心链路RAG链路拆开其实就三段把问题转成向量用向量去文档库里找最相似的片段把找回来的片段连同问题一起交给大模型回答。核心代码很短我给一个通用版本# 伪代码按你实际选用的库替换实现 from sentence_transformers import SentenceTransformer import vector_db_client # 1. 加载本地嵌入模型 embedder SentenceTransformer(local-embedding-model) # 2. 初始化向量库并写入文档块 chunks load_chunks(faq_chunks.txt) # 文档切块后的文本列表 for i, chunk in enumerate(chunks): vec embedder.encode(chunk).tolist() vector_db_client.add(idstr(i), embeddingvec, documentchunk) # 3. 查询阶段 query 这个功能怎么配置 qvec embedder.encode(query).tolist() results vector_db_client.query(query_embeddings[qvec], top_k3) context \n.join([doc for _, doc in results])代码写完后第一次跑返回的内容让我有点意外答案本身是对的但引用的片段跟标准答案的关联度并不高。查了一下问题出在查询词太短向量空间里找不到足够相近的文档块。这在真实场景里非常典型因为用户不会像搜索引擎一样用精确关键词提问他们可能说“这个功能怎么配置”而文档里写的是“配置步骤”这样的官方表述。2.4 第一次检索就翻车参数修正既然发现问题就动手修。我做了两个调整一是把文档块切得更小让每个块的主题更聚焦二是加了一层关键词规则先根据问题里的名词过滤掉一批肯定无关的文档再做向量检索。这算很朴素的“混合检索”思路工程上很常见效果立竿见影。调整之后再次运行引用的片段明显靠谱了答案的准确性也上来了。提醒RAG的优化空间大部分不在模型而在数据处理和检索策略。向量检索擅长语义近似但遇到精确数字、型号、日期这类信息反而不如简单关键词匹配可靠。生产系统做混合检索是常见做法先关键词召回再向量精排最后让模型基于候选内容生成答案。今天虽然只跑通了一个很基础的版本但已经足够验证这个判断。后续我打算把混排权重做成可视化调试工具那样调参会更直观。3. 社区今天在吵的三个命题3.1 小模型为什么敢叫板大模型今天一条帖子引发了不小的争论主题是“在特定领域小模型是否已经能媲美大模型”。支持者拿出不少评测数据展示一些数亿参数的领域模型在垂直任务上超过了通用大模型反对者则强调这些评测任务太窄、样本太少换个场景就不行了。两边的说法我都能理解但都觉得有一点过度简化。我的看法是大小模型之争本质上不是谁更强而是“边界”问题。大模型的强在泛化日常对话、复杂推理、跨领域知识都拿手小模型的强在专注在固定指令、固定格式、高频重复的任务上它更省资源、延迟更低、也更可控。真正成熟的落地策略应该是先盘点业务哪些是“长尾开放性任务”哪些是“高频固定任务”前者交给大模型后者用数据蒸馏出来的小模型处理。这个分工思路今天讨论里也有人提我会关注后续的落地案例。3.2 RAG与长上下文的拉锯战另一个热议话题是随着上下文窗口越开越大RAG会不会被逐渐取代。这个命题每隔一段时间就会出现一次。支持RAG的一方认为把几十万字全部塞进上下文成本和延迟都不可接受支持长上下文的一方反驳说模型能直接把整本书读懂为什么还要费劲切块做检索。这个问题在我看来其实是个伪选择题。长上下文解决的是“能不能装下”RAG解决的是“该装什么”和“装哪些”。真正有价值的做法不是把整库文档倒进上下文而是先通过检索定位到最相关的那几段再允许模型在需要时主动引用更多材料。今天讨论里有个比喻很到位长上下文是给模型开卷考但开卷考也得知道翻哪本书。这个说法朴素却很准确。3.3 评测分数越刷越“失真”晚上逛圈子时看到一篇批评当前评测体系的文章说模型厂商普遍在公开榜单刷分榜单上的题目和真实业务之间已经开始脱节。这个观点我深有同感。真实业务需求往往包括从脏数据里提数、在混合语言文档中抽取字段、按特定模板生成公文这类琐碎任务这些几乎不会出现在主流评测集里。这带来的结果是排行榜上零点几个百分点的差异对实际生产毫无感知但有没有认真做数据清洗、提示词模板、错误输出兜底对线上体验的影响反而巨大。所以我现在越来越不愿意拿单点评测分数来横向比较模型更倾向于自己攒一套贴近业务的“冒烟测试集”每次换模型、改提示词之后都用它跑一遍回归。这个习惯已经帮我避免了好几次线上事故也推荐做AI应用的同学试试。4. 两个值得记下来的部署坑4.1 量化后推理反而变慢问题定位下午在另一台配置稍低的机器上我想把前面用的模型量化后部署测试一下效果。结果遇到了一个很反直觉的问题量化之后的模型体积小了很多但单次推理耗时反而比未量化版本还高。一开始我怀疑是量化精度问题导致反复计算排查了半天也没发现报错。后来才想到去查底层推理库的日志发现量化版本并没有真正启用加速指令集而是回退到了通用计算路径。根因是这台机器的CPU指令集不支持量化版本预编译时启用的优化特性推理库在运行时检测到这一点就选择了向下兼容的执行方式。结果就是模型变小了但计算路径变慢整体耗时反而上升。排查链路走下来跟模型本身没有半点关系完全是我没提前确认硬件的指令集支持范围。这次教训很直接做边缘端部署第一步永远是核对硬件能力矩阵而不是直接下载最省资源的模型形态。4.2 批量请求的并发参数拍脑袋设的后果另一个坑是批量跑评测时踩到的。我写了个脚本对着几百条测试问题循环调用推理接口本想着一次性跑完结果刚到十几条推理进程就卡住了。最初以为是接口挂了检查后发现是并发参数设得太大把资源瞬间占满触发了大规模的内存交换。于是整个进程陷入长时间等待表现就是“看起来像死锁”。修这个问题的思路很朴素先把批量大小调到1确认单条能稳定通过再逐步往上加同时观察延迟和资源占用。最终稳定在一个合适的并发值既能跑得快又不至于把资源吃满。这里想提醒大家很多工具参数的默认值是按单用户交互设计的不适合批量脚本批量场景需要像调系统参数一样慢慢试探而不是直接照搬默认配置。4.3 复现与验证方法两个坑都修完之后我把完整环境重新记录了一份说明包括硬件指令集情况、依赖版本、参数配置建议。这么做的原因是部署环境的问题很少只出现一次过段时间重新搭环境还会遇到。有了记录以后可以直接对照检查省掉重复排查的时间。验证方面我也多留了一步修完并发参数之后没有立刻跑全部测试集而是先抽了十条代表不同难度的用例跑一遍确认输出没有异常再放开全量。这种“小范围回归、再逐步放量”的做法在算法部署和调优里都适用。很多看起来玄乎的部署问题最后都是靠这种朴素方法定位出来的。最后收个尾。写这份AI日报最大的感受是这个领域的变化速度确实快但真正决定项目成败的往往不是模型本身而是数据、硬件、参数这些看起来不够“前沿”的东西。今天记录的多模态落地、端侧推理、RAG检索、部署踩坑其实都指向同一个结论——AI应用正在从“模型能力竞赛”转向“工程效率竞赛”。如果你也在做类似的事建议也养成记录日报的习惯不需要多花哨把每天看到的趋势、验证的想法、踩掉的坑如实写下来几个月后再翻开那本记录会比任何收藏夹都值钱。