Gemini API 怎么用多模态 File Search 根据图片资料写文章

资料范围与结论依据

Gemini API 的更新说明显示，File Search 已支持多模态搜索，可使用 gemini-embedding-2 对图片进行原生嵌入和检索；返回的 grounding metadata 可包含用于视觉引用的 media_id，以及指示信息所在位置的 page_numbers。开始前，应先把这些能力放在“辅助定位资料”的位置，而不是把模型输出直接视为最终事实。

• 准备一组边界清楚的材料：产品图、扫描页、规格说明和已确认的文字资料分开存放。
• 为每份文件记录来源、版本、上传时间和可用于写作的范围；不确定的信息单独标记。
• 先定义文章要回答的问题，例如产品外观、适用场景、材料中明确写出的功能，不把未提供的参数加入任务。
• 规定模型遇到资料不足时输出“未找到依据”，不能补写推测内容。

图片资料集合

将图片、扫描页和文字资料上传或接入到同一篇文章对应的资料范围中，再创建供 File Search 使用的检索集合。资料命名应能让编辑看出文件身份，例如用项目名、资料类型和版本组合，而不要只保留手机自动生成的文件名。

1. 按文章任务建立一个资料集合，避免把不同产品或不同版本的素材混在一起。
2. 检查图片是否清晰可辨，扫描页是否包含完整页边和必要上下文；模糊局部图不应承担关键事实依据。
3. 在业务数据库保存文章任务 ID、资料集合标识、原文件标识和资料版本，便于后续重跑与追溯。
4. 先用单个具体问题测试检索，例如“资料中是否出现包装背面的使用步骤”，确认命中结果确实来自预期材料。

检索与成文分层

不要只提交“根据资料写文章”。先让模型检索并列出可用事实，再基于已确认的事实写成正文。这样可以把“模型看到了什么”和“模型写了什么”分开检查。

1. 第一轮只要求返回事实清单：每项包含事实表述、资料类型、是否来自图片或页面，以及无法确认的内容。
2. 读取检索返回的 grounding metadata，保存其中可用的 media_id 和 page_numbers，与文章任务关联。
3. 由应用或编辑审核事实清单，删除无依据、范围不明或与任务无关的项目。
4. 第二轮传入审核后的事实清单，要求按指定读者、结构和语气成文，并限制只能使用清单内的事实。
5. 将正文中的关键句映射回保存的资料标识，供编辑点击或在后台检索原始图片、扫描页进行核对。

产品资料成文示例

假设资料集包含三张产品外观图、一页扫描版说明和一份已审核的文字规格。第一轮任务可要求模型输出“图片中可直接观察到的外观信息”“扫描页中可定位的操作信息”“文字规格中明确的字段”，并为每项保留引用线索。

任务：整理资料集中的可用事实，不补充资料外信息。
输出字段：事实、资料类型、引用线索、是否需要人工确认。
写作范围：只介绍外观、包装内可见内容和扫描页明确说明的操作步骤。
未知信息：标记为未找到依据。

审核后，若某条内容写着“包装图中可见一根连接线”，编辑应回看对应图片；若写着“扫描页列出三步操作”，应回到对应页码确认步骤顺序。只有这些事实通过复核，再让模型组织为面向读者的文章段落。

故障排查

• 故障：文章漏掉图片里的关键信息。原因：图片与文字资料混放，提问过于宽泛，或图片本身不清晰。修正动作：将问题改成针对对象、位置和用途的具体问法，并用单图测试检索命中情况。
• 故障：正文出现资料中没有的规格或承诺。原因：写作阶段允许模型自由补充。修正动作：先审核事实清单，成文时明确限定只能使用已审核事实，无法确认时保留为空或标注待补。
• 故障：编辑无法找到结论出处。原因：只保存了正文，没有保存检索元数据。修正动作：将 media_id、page_numbers、原文件标识和任务版本与关键结论一并归档。
• 故障：同一问题命中旧版本资料。原因：资料集合包含历史文件但没有版本边界。修正动作：按版本分集合或在任务创建时明确可用资料清单，并在发布前核对版本号。

发布验收

• 文章中的产品名称、版本和适用范围与当前资料一致。
• 每个关键事实都能回到原始图片、扫描页或文字资料复核。
• 已保存可用的 media_id、page_numbers 或内部原文件标识。
• 正文没有把图片观察结果扩展成未被资料确认的性能、价格或承诺。
• 资料不足处已标记待确认或删除，没有以确定语气发布。
• 抽查至少一条视觉引用和一条页面引用，确认编辑可实际定位到原始材料。