过去，知识库检索通常围绕 PDF、网页和纯文本展开。现在，TwelveLabs Marengo Embed 3.0 已在 Amazon Bedrock Knowledge Bases 中正式可用，应用可以用自然语言搜索视频、图片和音频内容，而不必先为每种媒体单独搭建一套索引服务。
这项能力的价值不只是"给视频加个向量"。它把媒体内容纳入了知识库的检索链路：数据进入存储桶后，经过解析和向量化，应用再用一个问题检索与语义最相关的媒体片段。
Marengo 3.0 适合解决什么问题
传统关键词搜索很容易错过这样的内容：
- 用户搜索"有人在仓库里演示叉车安全检查"，但视频标题只有一个编号；
- 用户想找"海浪拍打黑色礁石的镜头"，描述并没有明确写在文件名中；
- 支持团队需要定位一段讲解故障排查的录音或培训视频。
Marengo 3.0 的定位是多媒体嵌入模型。结合 Amazon Bedrock Knowledge Bases 后，开发者可以把视频、图片和音频作为知识源的一部分，并通过自然语言查询这些内容。具体的文件格式、大小限制、区域可用性和知识库配置选项，应以当前 AWS 控制台和服务文档为准。
这里有一个重要边界：向量检索返回的是语义上相关的结果，不等于它已经完成了精确的时间码级事实核验。对合规审计、医疗判断或安全控制等场景，仍应保留原始媒体、人工复核和必要的转录或元数据。
一条典型的媒体检索链路
可以把流程拆成四步：
- 准备媒体源：把视频、图片或音频放入 Amazon S3，并按照项目需要划分目录。
- 创建知识库：在 Amazon Bedrock Knowledge Bases 中选择支持 Marengo 3.0 的配置，并连接数据源和向量存储。
- 同步数据：让知识库读取数据源、处理媒体并生成可检索的表示。
- 执行查询：应用把自然语言问题发送给 Retrieve API，再根据返回的相关结果展示媒体、片段或交给生成模型总结。
在实际项目中，S3 路径最好承载稳定的业务元数据，例如部门、项目、拍摄日期和访问级别。这样可以在语义相关性之外，再叠加过滤条件和权限控制。不要把"检索到了"直接等同于"当前用户有权查看"。
创建知识库时要关注的配置
在控制台中创建或更新知识库时，可以重点检查下面几项：
- 模型与区域：确认 Marengo Embed 3.0 在目标 AWS 区域可用，并完成相应的模型访问配置。
- 数据源同步：新文件不会自动代表已经进入可检索索引；完成首次同步或增量同步后再进行验收。
- 向量存储：确认所选向量数据库、索引维度和知识库集成方式由当前 Bedrock 配置支持。
- 权限：为知识库服务角色授予读取 S3、访问向量存储以及调用所需模型的最小权限。
- 媒体元数据：在对象键、伴随 JSON 或数据源字段中保存业务标识，便于后续过滤和审计。
如果是第一次验证，建议只放入一小批媒体：几段主题明显不同的视频、若干图片和一两个音频文件。先确认查询能区分内容，再扩大数据规模。
可复制的 Retrieve API 查询
下面的 AWS CLI 示例假设你已经完成知识库创建、数据源同步，并且拥有对应的知识库 ID。把 KB_ID 和查询文本替换成自己的值后即可改造使用。该命令调用 Bedrock Agent Runtime 的检索接口，返回与问题相关的结果和元数据。
export AWS_REGION=us-east-1
export KB_ID=xxxxxxxxxx
aws bedrock-agent-runtime retrieve \
--region "$AWS_REGION" \
--knowledge-base-id "$KB_ID" \
--retrieval-query '{"text":"Find the video segment showing a technician checking a forklift before operation"}' \
--retrieve-configurations '{"vectorSearchConfiguration":{"numberOfResults":5}}'
如果查询对象是中文，可以直接使用中文问题：
aws bedrock-agent-runtime retrieve \
--region "$AWS_REGION" \
--knowledge-base-id "$KB_ID" \
--retrieval-query '{"text":"查找演示叉车作业前安全检查的视频片段"}' \
--retrieve-configurations '{"vectorSearchConfiguration":{"numberOfResults":5}}' \
--output json
命令中的 numberOfResults 不是越大越好。结果太多会增加后续处理成本，也可能把相似但不够准确的媒体带进上下文。可以从 5 或 10 开始，用一组人工标注的问题评估召回率和误召回率，再调整数量。
在应用中消费检索结果
应用通常不会把 Retrieve 返回的原始 JSON 原样交给用户，而是抽取位置、来源和元数据，生成可点击的结果卡片。下面是一个使用 boto3 的最小示例；它假设 AWS 凭证已通过环境变量、配置文件或 IAM 角色提供。
import os
import boto3
client = boto3.client("bedrock-agent-runtime", region_name=os.environ.get("AWS_REGION", "us-east-1"))
response = client.retrieve(
knowledgeBaseId=os.environ["KB_ID"],
retrievalQuery={"text": "查找展示仓库安全检查流程的视频"},
retrievalConfiguration={
"vectorSearchConfiguration": {
"numberOfResults": 5
}
},
)
for index, item in enumerate(response.get("retrievalResults", []), start=1):
print(f"[{index}] score={item.get('score')}")
print("content:", item.get("content", {}).get("text", ""))
print("location:", item.get("location"))
print("metadata:", item.get("metadata", {}))
print()
示例中的结果结构和媒体位置字段可能随服务配置、SDK 版本及数据源类型变化。上线前应针对实际返回值做 schema 适配，不要把示例中的字段结构当成所有媒体类型都完全相同。
如果应用还需要回答"这段视频讲了什么"，可以采用检索增强生成模式：先用 Retrieve 找到候选媒体和元数据，再将允许使用的文本描述、转录内容或经过处理的片段交给生成模型。媒体检索负责缩小范围，生成模型负责组织答案；两者的权限和日志应分开设计。
评估时不要只问“能不能搜到”
媒体搜索的验收集至少应覆盖三类问题：
- 直接描述：问题明确描述画面、声音或事件。
- 同义改写：用不同说法表达同一个目标，检查语义检索是否稳定。
- 负面查询：查询一个库中不存在的场景，观察系统是否会返回看似相近的内容。
对每个问题记录期望媒体、实际排名、用户是否点击，以及最终答案是否引用了正确来源。还应测试重复文件、低质量素材、背景噪声、多人说话和跨语言查询。一个能在演示数据上工作的索引，不一定能在真实媒体库中保持同样效果。
落地清单与取舍
Marengo 3.0 适合把媒体搜索从文件名和标签，推进到内容语义层面。采用前可以按下面的清单检查：
- [ ] 目标区域支持所需模型和知识库能力；
- [ ] S3 数据组织、知识库服务角色和访问权限已明确；
- [ ] 首次同步和增量同步都有可观测性；
- [ ] 已准备包含正例和负例的评估问题集；
- [ ] 检索结果与用户权限做了独立校验；
- [ ] 对原始媒体、转录、向量和查询日志制定了保留策略；
- [ ] 对误检、漏检和生成模型幻觉保留人工复核路径。
最稳妥的起步方式不是一次导入全部媒体，而是选一组业务价值明确、权限边界清楚的内容，先打通同步、检索和结果展示，再根据评估数据决定是否扩大规模。