固定 size 切分、embedding、top-k 这套流程听起来完整，但到了真实场景往往没用，因为真正要回答的是：用户这个问题该召回哪些资料、召回几段、同样内容该切几段。切太大，答案被无关信息淹没；切太小，一个答案被切散，两种情况都会同时伤到召回和精准⁠1。所以更实际的做法是先拿几个真实问题，人工标出“理想答案应该来自哪几段”，再回头决定切分粒度和召回数量，而不是先定切分规则再套问题。

pptx、pdf 里的图、音频、视频要不要全部转文字，取决于你希望它们被“按什么方式找到”。如果用户只会用文字提问，转文字（或转成图片描述）能让它们进入同一套检索；但如果内容本身是图表、版式或画面，硬转文字会丢掉信息，反而降低精准度。一个可试的做法是先只处理最常被问到的那几类文档，观察哪些问题召回不到、哪些召回了却答错，再决定要不要给图片、音视频单独建索引。

出处 1

RAG 的“分块、向量化、检索”是 2023 年上下文窗口小、模型不太会调工具时的产物；真正要学的是信息检索本身，懂了它，RAG 一个周末就能上手⁠2。有团队早期也用向量数据库，后来发现让 agent 自己搜索效果更好，用的就是最简单的命令行查找⁠2。这对你的启发是：与其在 fastgpt、WeKnora 里反复调向量参数，不如先确认你的问题是不是“检索”问题——有些场景把相关内容整体交给长上下文模型，效果反而更好⁠2。

文档处理之所以让人感觉只能人工一个个试，往往是因为没有先说清“处理成什么样算对”。如果验收标准是“利益相关者随机提问都能答对”，那批量跑完就能自动判分，人只看没过的那些。AMD 那套做法就是先做本体建模，再在查询外面加一层审计，把错的查询拦下来、把错误信息发回去让它自己改，这套机制帮很多大客户把 agent 系统真正部署进了生产环境⁠1。放到你的场景：先挑 20 个真实问题当验收集，让处理流程跑一遍，看哪些文档答不对，再决定切分和转文字怎么调。

用文件保存任务当前状态，让 agent 自己读取、检查、修改，直到交付物达标，执行路径由它按现场情况调整，不必事先被人穷举⁠2。视频标题那套工具也是这个分工：AI 处理执行层，人负责判断层，编辑手动选的高光优先于 AI 全文扫描，因为 AI 倾向选戏剧性最高的时刻，而不是叙事上最关键的时刻⁠3。对应到文档：让 agent 批量跑切分、抽图、转写，你只验收结果；哪类文档效果差，再回头改处理方式，而不是一开始就手工测每一个。

长视频直接向量化目前还不成熟，只抽帧会丢掉时间信息，长视频压缩后信息损失太大，所以现在多数方案仍是先转写、用文字检索、再映射回时间戳⁠4。图片向量化相对成熟，甚至能做多向量让搜索更准⁠4。这意味着 pptx、pdf 里的嵌图可以走图片向量化，音频视频先转写再检索，但别指望一步到位直接在视频里搜。至于“有没有必要全转文字”，取决于你的用户会不会用文字提问去命中那些内容。