做AI系统别为了技术概念把架构做重
在AI系统设计中,简单往往比复杂更有效。本文通过多模态文件处理和短视频脚本优化两个实战案例,揭示了过度设计的陷阱——从图片解析的RAG化到脚本生成的架构膨胀,作者用亲身经历告诉你:满足核心需求的轻量方案,往往比追求技术概念的复杂系统更实用。

「本来我们想做的事情比较简单,对AI很友好,现在又好像变得很复杂。」
这是我最近在做AI Agent内容生产系统时的真实感受。
一开始想的很简单,做着做着就想加东西,然后发现架构越来越重。
今天聊聊怎么避免把简单的系统做复杂。
先说多模态文件处理这个问题。
我们在做的系统需要处理用户上传的文档,文档里可能有图片。
第一次调用模型解析图片内容没问题,但如果后续需要检索整个文件,就会重复解析图片。
重复解析带来不必要的消耗。
我最开始想的方案是做预处理。
提前对文档里的图片做解析,把解析结果按等级存在meta信息里。
后续需要使用时直接调取预解析结果,避免二次解析。
听起来挺合理的对吧。
但讨论着讨论着方案就膨胀了。
有人提出可以让AI自行对文档切块,不需要提前手动切分。
图片也可以做embedding后和文本一起检索。
听起来更智能了。
但这个方案延伸后会变成每个文件夹每个文档都单独做RAG。
会非常依赖向量数据库,让整个文件系统变重。
这就偏向传统RAG的架构了,偏离了原本做轻量AI友好型文件系统的初衷。
全量RAG化还会带来其他问题。
请求队列管理变复杂,内容更新顺序监测难以实现。
对比RagFlow,提前分目录再做RAG的粒度更细,但整体架构还是过度设计。
最后我们决定回到原点,只做图片预处理这个轻量方案。
不是所有场景都需要全量RAG。
再说脚本优化的事。
我最近在想怎么让AI生成更好的短视频脚本。
当前脚本结构已经合格了,但有些话术是过去在用的,现在已经不用了,关键词需要随时间更新。
还有过度润色的问题,有时候为了抓注意力盲目追求口语化,反而不自然。
脚本的核心难点在于平衡。
怎么在开头抓住注意力,同时在过程中不断设置刺激点。
两秒一个刺激点或者五秒一个刺激点,这个节奏很难把握。
我测试了一些方法,发现从提示词层面优化效果比改架构要好。
不需要做复杂的系统改造,调好提示词就够了。
做AI系统最大的教训就是。
简单够用比什么都重要。
不要为了凑技术概念把架构做重。
预解析meta信息可以满足基础多模态需求,不需要上全量RAG。
脚本优化从提示词入手,不需要做复杂的生成系统。
在满足功能需求的前提下,尽量维持架构简洁。
为边缘需求做过度设计只会拖慢进度。
以上,既然看到这里了,如果觉得不错,随手点个赞、在看、转发三连吧,如果想第一时间收到推送,也可以给我个星标⭐~
谢谢你看我的文章,我们,下次再见。
/ 作者:鸣老师
本文由 @鸣老师 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
- 目前还没评论,等你发挥!

起点课堂会员权益



