[Cohere] 在 AWS 上用 Cohere AI 构建金融研究助理

2026 年 10 月 29 日

17 分钟阅读

在 AWS 上用 Cohere AI 构建金融研究助理

要点

在 AWS 上构建金融研究助理。 把 Cohere Embed、Rerank 和 Parse 与 Amazon SageMaker AI、OpenSearch Serverless 和 Amazon Bedrock 组合起来，用于检索财务申报文件并生成带页面级引用的答案。 优化检索质量、延迟和成本。 用 Embed Pro 做高质量文档索引，用 Embed Fast 做低延迟查询，并通过可配置的 embedding 维度和量化来平衡准确率与存储。 用 Rerank 提升搜索相关性。 用 Rerank Pro 对检索到的页面重新排序，并用 Context Focus 标出相关段落，减少送往答案模型的文本量。 处理复杂的财务文档。 对扫描件或表格密集的页面使用 Cohere Parse，并结合文本与页面图像，帮助答案模型解读财务数字并保留上下文。 在你自己的 AWS 账号里部署和试验。 用这个基于 CloudFormation 的演示探索检索、重排、Context Focus 和带引用的答案，同时了解不同配置各自的取舍。

作为一名金融分析师，一天里的大部分时间都花在从一份长达数百页的申报文件里找出某一个数字，然后证明它来自哪里。这两件事都不像听起来那么轻松。这个数字很少出现在正文中，它通常藏在一张表、一个脚注或一幅图表里，而且同一个数字可能在不同地方以不同名字出现。

本文介绍如何用 Amazon SageMaker AI 上的 Cohere 模型为财务申报文件构建一个研究助理——用 Embed 做检索，用 Rerank 给结果排序，用 Parse 把难啃的页面变成干净文本。答案由 Amazon Bedrock 上的 Anthropic Claude 来写，每一条论断都配一条引用。

我们会先讲清楚这件事难在哪里，然后给出方案概览，接着把大部分篇幅放在背后的设计决策上，以及什么情况下你该做出不同的选择。最后，我们会展示如何在你自己的 AWS 账号里部署这套方案并亲自试用。

为什么金融研究很难自动化

金融研究看起来像一个搜索问题，但它有一些会让简单办法失效的特性。

答案藏在版面里。 以 10-K 为例——这是美国上市公司向美国证券交易委员会提交的年度报告，涵盖业务、风险和经审计的财务报表（Form 10-K 包含哪些内容）。你需要的那个数字通常以表格形式出现，比如按年度分的净利息收入、按层级分的监管资本、按贷款类型分的核销等。当 PDF 被转成纯文本时，表格会丢失行列之间的对应关系，多栏页面的顺序可能整个乱掉，图表则常常直接消失。

无法核实的答案没有用。 分析师不能在备忘录里写下「the CET1 ratio was 11.9%」，却说不清它出自哪份申报文件、哪一页，以及这个数字是来自表格、图表还是某一句话。做这类工作的助理必须把来源摆出来，读的人还得能很快核对。

数量和成本会累积。 一个研究团队可能要索引跨越多年的数千份申报文件。每个页面只做一次 embedding，但每个问题也要做一次 embedding，而在每个问题上运行的每个模型都会增加时间和成本。

不是每份文档都干净。 申报文件有的是数字 PDF，有的却是扫描件附件、传真过来的协议，以及完全没有文字层的拍照页面。

问题不一定用文档的语言提出。 同时覆盖多个市场的团队，常常用一种语言去问另一种语言写成的文档。

所以一个真正有用的助理得做到几件事：答案在表格里时能找到正确的那一页、让每条答案都可核验、把成本和延迟控制住、应付不干净的页面，以及跨语言工作。

**

方案概览 **

这套方案是一个研究助理：回答关于一批申报文件的问题，并为每一条论断标出它来自哪一页。它用了四个模型，各司一职：

Cohere Embed 把每个页面、每个问题都变成一个向量——一串刻画其含义的数字——这样与问题谈论同一件事的页面就会落在它附近。Embed 分两个档位：Embed Pro 面向最高检索质量和离线索引，Embed Fast 面向在线请求路径上的低延迟。 Cohere Rerank 拿到问题以及向量检索给出的最佳候选页面，把问题和每一页放在一起读，再排出一个更合理的顺序。配合 Context Focus，Rerank 还能标出每个页面上真正回答了问题的那些段落。和 Embed 一样，Rerank 也分两个档位：Rerank Pro 面向最高准确率，Rerank Fast 面向更低延迟。我们选 Rerank Pro，因为对金融助理来说，找到正确的那一页通常比答案来得更快更重要。 Cohere Parse 读取一张页面图像，返回干净的 Markdown，表格还原成真正的行列。它用于那些文字质量不佳的页面。 Amazon Bedrock 上的 Anthropic Claude 读取排在前面的页面，写出答案，并引用每一页。

人们可以通过一个带三项功能的 Web 应用来使用它：

Assistant。 就申报文件提问。助理找出最相关的页面，读过它们，然后写出一个每条论断都引用对应页面的答案。每条引用还会说明这个事实来自表格、图表、正文、脚注还是插图，点一下就能打开页面图像来核对。 Search。 同样的检索，但不生成答案。它可以把「用过 Rerank」和「没用 Rerank」的结果并排显示，让你看清重排如何改变结果；Rerank 那一列会显示 Context Focus 在每个页面上挑中的段落。 Parse。 Parse 从可下载的页面里把表格抽取成行，并把看起来像扫描件的页面转成文本。

底层有两条流程。摄取（Ingestion）每页只跑一次：对那些需要的页面先跑 Parse，再用 Embed Pro 做 embedding，把向量存进向量索引。回答（Answering）每个问题都跑：先由 Embed Fast 嵌入问题，再检索出最接近的页面，并可选地由 Rerank 重新排序。最后由 Claude 根据最靠前的页面写出答案。Cohere 模型以实时端点的形式跑在 Amazon SageMaker AI 上，从 AWS Marketplace 部署；向量索引是 Amazon OpenSearch Serverless；Web 应用、登录、API 和摄取流水线都是 serverless 的 AWS 服务。

设计决策，以及我们为什么这么定

上面每一个挑战都逼出了一次取舍。

挑战

我们的决定

原因

答案藏在表格里

在保留表格标记的页面文本上检索，并在 Claude 写答案时让它看页面图像

文本做 embedding 和检索都很便宜；图像则在引用某个数字的那一刻把文本丢掉的东西补回来

答案必须可核验

为每条论断标出它所在的页面以及页面上的位置（表格、图表、正文、脚注、插图），并显示页面图像

读者可以直接回到原文，看到那到底是哪一类证据

成本与延迟

用 Embed Pro 建索引，用 Embed Fast 查询。向量以 1,024 维 int8 存储，并把 Rerank 和 Parse 设为可选阶段，让端点很容易关掉

在索引时一次性为质量付费；让每个问题都保持快；只在额外阶段真正有帮助时才为它们付费

不干净的页面

只把文字少、表格多的页面送去 Parse

只在 Parse 能改变结果的地方才用，而且每个页面只解析一次

很长的页面，但只有几行重要

把 Rerank 的 Context Focus 挑中的段落连同页面图像一起发给 Claude

输入 token 更少，图像补上段落没覆盖的上下文，读者看到的正是答案实际用到的内容

其他语言的问题

在一个多语言 embedding 空间里检索所有语言，不加翻译步骤

省掉单独的一套翻译步骤，简化流水线，也避免了与翻译相关的处理开销。

**用 Embed Pro 建索引，用 Embed Fast 查询

**索引和查询的需求不一样。一个页面是提前做好 embedding 的，所以你可以用最准的模型。一个问题是在有人等着的时候做 embedding，而且一天要做上千次，所以速度和单次调用成本才是关键。Embed Pro 和 Embed Fast 共享同一个 embedding 空间，这意味着用 Fast 嵌入的问题可以直接和用 Pro 嵌入的页面比较。你在索引里拿到 Pro 的质量，在每个问题上拿到 Fast 的速度，而且不用重建索引。下面的图展示了这两个模型各自的位置。

第二个选择是每个向量的大小。Embed 提供六种输出规格，从 256 到 2,048 维，可以是 float、int8 或 binary。这些 embedding 是 Matryoshka 表示，模型经过训练，让靠前的维度承载最多的信息，因此更短的向量也能保留长向量的大部分含义。我们选的是按 int8 存储的 1,024 维，每个维度一个字节：

存储 - 一个 1,024 维 int8 向量占 1 KB 原始存储，而 2,048 维 float32 向量要占 8 KB——缩减了 8 倍。对一百万个页面来说，就是大约 1 GB 对 8 GB 的原始向量数据。实际的向量索引存储和成本还会取决于索引结构、元数据以及基础设施开销。 质量 - 1,024 处在规格区间的中段，而 int8 保留的细节远多于 binary。当答案必须精确到那一页、而不是只要一个差不多的页面时，这是个合理的默认值。 什么时候该改 - 如果检索质量比存储更重要，就用 2,048 维。对于成本占主导的超大档案，用 512、256 维或 binary 向量；binary 比 float32 小 32 倍。

无论你怎么选，查询端必须使用与索引相同的规格和格式。以后再改就意味着所有页面要重新做一遍 embedding，所以这件事值得早点定下来。

**嵌入页面文本，把图像留给答案环节

**Embed 可以嵌入页面文本、把页面当图像嵌入，也可以把两者合成一个向量一起嵌入，而且都在同一个空间里。每种选择适合不同类型的文档。

页面文本最便宜也最简单：每页一个向量，Rerank 读的就是文本，所以它能处理同一批页面，你还可以在每条结果旁边显示一段文本摘要。问题在于它的效果取决于抽取出来的文本，而多数时候表格会丢掉结构、图表会消失，扫描件在被人读之前根本没有任何文字。

页面图像不需要抽取文本。表格、图表和版面就是页面看上去的样子，对扫描件和照片也有效。它的每页成本更高，也更难解释某一页为什么被匹配上，而且 Rerank 仍然需要文本。

两者一起（文本与图像融合的向量）让检索同时拥有页面的两种视角，代价是图像的价格和更大的一笔 embedding 调用。

年度报告和 10-K 都是文字质量不错的数字文档，所以我们嵌入页面文本。文本丢掉的东西——主要是图表和复杂表格——留到答案环节再补回来，让 Claude 看到页面图像就行。如果你的页面大多是扫描件、幻灯片、示意图或图表，比如投资者演示材料、扫描的协议或传真附件，那就嵌入图像，或者两者都嵌。

**所有语言共用一个 embedding 空间

**Embed 支持 100 多种语言和 128K token 的上下文窗口。无论语言是什么，问题与页面都落在同一个空间里，所以像「impact de l'immobilier commercial sur le segment Global Banking de Bank of America」这样的法语提问，可以直接找到英文的 Bank of America 页面。Claude 随后用提问的语言写出答案，引用则原样保留。

我们没有选择先把问题翻译成英文。这样就不需要搭建、运行或付费维护一套翻译步骤，也没有把某个术语翻错、把检索带偏的风险。Rerank Pro 同样是多语言的，支持 100 多种语言。一如既往，请在你自己的文档上确认对你重要的那些语言。

**把 Rerank 做成可选阶段，并让它的效果看得见

**向量搜索之所以快，是因为每个页面与问题之间只用一个数字来比较——两个向量之间的距离。重排器的工作方式不同：它把问题和每个候选页面放在一起读，因此能够权衡单个向量承载不了的细节。Rerank Pro 把最多 32K token 的问题和页面放在一起读，支持 100 多种语言，并能处理表格和 JSON 这类半结构化内容。在这套设计里，向量检索返回 30 个候选，Rerank 挑出其中 5 个交给 Claude。

Rerank 位于查询路径上，所以它的延迟在每个问题上都能感觉到。我们仍然选择 Rerank Pro 而不是 Rerank Fast，因为在金融研究里，页选错的代价高于答案变慢。如果你的用户更看重交互速度，Rerank Fast 处理的是同样的请求、返回的是同类的结果，所以两者之间切换是一次配置改动，而不是代码改动。

这份额外的阅读在每个问题上都要花时间，还要养一个端点，而它到底有多大帮助，取决于你的文档和你的问题。所以我们把 Rerank 做成可以随时开关的阶段，并让它的效果看得见：Assistant 会显示每一步花了多长时间，Search 则可以把两份结果列表并排摆出来，用箭头标出每个页面的位置变动。

什么时候该打开它？看关掉它的时候正确的那一页落在哪里。如果通常就在最前面或接近最前面，那就把 Rerank 关掉、保持答案够快。如果它经常掉到列表靠后的位置，或者问题又长又具体，Rerank 通常就是那个解法。

Rerank 5 还会为每个页面返回一个介于 0 和 1 之间的校准相关性分数，这样同一个阈值在不同问题之间含义一致。你可以用它告诉用户「没有哪一页匹配得好」，或者触发另一次检索，而不是拿勉强的页面硬答。

**只解析那些需要解析的页面

**Parse 读取一张页面图像，返回 Markdown 或内容块，带边界框，并能理解表格、表单、示意图和图像。这是一个按小时计费的 GPU 端点，而干净的数字页面本来就有可用的文字，所以我们只在必要处使用它。摄取步骤里的一个路由器逐页决定：

文字极少的页面送去 Parse（比如封面，或者没有文字层的扫描件） 大部分文字都在表格里的页面送去 Parse 其余页面保留它们已有的文字。

Parse 的输出会被保存下来，所以无论你重建多少次索引，每个页面都只解析一次。如果你需要把表格变成数据——填进电子表格或数据库——Parse 同样是把它们从页面里取出来的办法。

**让答案模型读页面，并说清每个事实的出处

**检索跑在页面文本上，但答案不必如此。对挑出的五个页面，查询函数会把页面图像连同页面文本一起发给 Claude——文本可以是完整抽取出来的，也可以只有 Rerank 标出的那些段落（见下一节）——并告诉 Claude：两者不一致时以图像为准。正是这样，答案才能出自一幅图表，或者出自一张结构在文本中已经丢失的表格。

Claude 还会被要求只依据这几个页面作答，在它们不含答案时明说，并按 [文档页 | 类型] 的形式为每条论断给出引用，其中类型是表格、图表、正文、脚注或插图。应用会把每条引用变成指向页面图像的编号链接，把类型显示在旁边，并在页面上重复一遍（"Answer taken from: table"）。分析师能看到助理为某个资本数字引用了哪一页、哪一类内容，并打开原始页面直接核对。

代价是 Claude 要多花输入 token 和处理时间。把五张页面图像和它们的文本一起送进去，会增加 token 消耗和响应延迟，具体取决于图像分辨率、页面内容以及所用的模型。演示里有一个开关可以不带图像，这样你能在自己的问题上看出差别。

**只把要紧的段落发给 Claude

**即便选对了五个页面，每一页的大部分内容也与问题无关。一页 10-K 可能塞着一整张表、一整页风险因素，或者好几条互不相干的附注，而 Claude 要把它们全读一遍，你也全付一遍钱。

Rerank 5 能做的还不只是给页面排序。打开 Context Focus 之后，它还会返回每个页面上与问题匹配的段落，形式是带相关性分数的字符区间。它是 Rerank 请求上的一个设置，不是另一个模型，也不改变排序结果。在这套设计里，查询函数向 Rerank 要那五个选中页面上的段落，然后只把这些段落按页面顺序发给 Claude，而不是整页文本。

这会带来三个效果：

输入 token 更少。 Claude 只读每页文本中相关的部分，答案更便宜也回来得更快。 prompt 更聚焦。 无关文本被拿掉之后，答案模型能分心的东西就少了。 更容易核对。 应用会把页面文本里的这些段落高亮出来，读者看到的不只是「用了哪一页」，而是「答案依据的是哪几段」。

这份取舍换来的是上下文。一段孤立的文字可能丢掉它周围的内容，比如表格的列标题，或者某一列对应的年份。Context Focus 最适合目标明确、能定位并取回具体信息的问题。结构化内容（比如表格和表单）要切成有意义的块就更难一些，因为重要的关联可能横跨多个部分。对于更宽泛的任务，比如总结整页内容，给出完整的页面内容通常能产出更完整、更准确的结果。不过 Cohere 的内部评测表明，即使把输入 token 减少 50–75%，Context Focus 仍能保住绝大部分答案准确率——这说明 token 缩减与准确率之间的取舍远不是线性的。

这正是页面图像挣到位置的地方：Claude 仍然看得到整页，因此能读到段落没覆盖的标题和单位。如果最看重的是 token 数最少，那就只发段落不发图像；如果数字必须精确，那就段落和图像一起发。Context Focus 是在同一次 Rerank 请求里返回相关段落的，不需要额外的模型，也不需要多打一次 API。

演示里这两项各有一个开关：Context Focus 和页面图像。每个答案都会显示有多少 token 发给了 Claude，并高亮出实际发出的那些段落，这样你能在自己的问题上看见这笔取舍。

**让昂贵的部分容易关掉

**Cohere 模型以 SageMaker 实时端点的形式运行，而实时端点按存在的小时数计费，不管有没有人在提问。对试点项目、或者间歇性干活的团队来说，空转的 GPU 小时就是最大的开销。所以这套部署有一个开关，能把全部模型端点移除，同时保留数据、索引和 Web 应用。以后再把模型开回来不需要重新摄取。在稳定生产中，你应该改成加上自动扩缩容和告警。

**为你的文档选择流水线

**需要哪几个阶段取决于你的文档。下面这张图是我们用的决策指南，它有两步：

是否在 embedding 之前先解析页面 是否对结果做重排

Embed + Rerank：当排序比速度更重要时，这是干净数字文档的好起点。 只用 Embed：当速度比排序更重要时，这是最快的。 Parse + Embed（可加可不加 Rerank）：适合扫描件、传真件、照片，以及数字要求精确的密集表格。 只用 Parse：用来把表格、表单和发票变成结构化数据，不是用来检索的。

注意： Rerank 不限于向量检索。它同样能改进 BM25 这类基于关键词的检索方法的结果，因此不需要 embedding 也能跑通 Parse + Rerank 这样的流程。

针对你自己的文档，可以问这样几个问题：

如果……

那么考虑

你的文档是数字文档，文字质量不错

嵌入文本；先不启用 Parse

页面是扫描件、照片或传真件

在 embedding 之前先解析，或者直接嵌入页面图像

答案是密集表格里的精确数字

解析这些页面，并让答案模型读页面图像

页面大多是图表、幻灯片或示意图

单独嵌入页面图像，或者和文本一起嵌入；让答案模型读它

交互速度最重要

用 Embed Fast 查询；把 Rerank 关掉

正确的那一页经常落在结果靠后的位置

加上 Rerank

页面很长，或者输入 token 的成本很要紧

打开带 Context Focus 的 Rerank，并把段落发给答案模型

用户用好几种语言提问

直接用多语言 embedding；不做翻译步骤

无论你怎么选，都要在自己的文档和问题上实测。公开基准告诉你的是模型在那个基准的页面上表现如何，而不是在你的申报文件、扫描件或公司特有的风格指南上表现如何。

不止于财务申报文件

这套流水线并不专属于银行业。它的输入是一组页面图像和对应文本，所以换一批文档，就换一个助理。凡是答案藏在表格、表单和版面里的地方，都适用同一个模式：

保险： 保单、理赔材料和表单，Parse 的结构化输出可以直接喂给下游系统。 法律： 合同、案卷和监管材料，条款检索需要页面级引用。 制造与能源： 带示意图和表格的技术手册与合规文档，嵌入页面图像或读取页面图像能让里面的数字继续可用。 公共部门与生命科学： 政府和监管报告、科学论文。

自己动手试试

我们为这套方案做了一个演示，你可以用一个 AWS CloudFormation 模板把它部署到自己的 AWS 账号里。这个模板会创建 Cohere 模型端点、向量索引、摄取流水线、API，以及带登录的 Web 应用。代码在 GitHub 上。

演示的适用范围

这个演示是一个能跑起来的起点，不是生产系统。它跑在三份公开的年度报告上（Bank of America、Morgan Stanley 和 Wells Fargo，2024 财年，共 928 页），取自 ViDoRe V3 benchmark 的金融子集（论文）；该 benchmark 同时提供了英语、法语、西班牙语、德语、意大利语和葡萄牙语的示例问题。

为了让演示足够轻量、便于快速上手，我们做了一些与上面设计不同的取舍：

预先抽取好的文档文本： 页面用 benchmark 数据集提供的文本建立索引，部署因此更简单。架构本身支持用 Cohere Parse 处理扫描件和复杂文档，但这个演示没有包含对任意上传 PDF 的解析。 索引和查询都用 Embed Pro： 演示用 Embed Pro 做文档索引和查询 embedding，省掉了单独一个 Embed Fast 端点，也降低了 GPU 成本。 用 Rerank Fast 而不是 Rerank Pro： Rerank Fast 跑在更小的 GPU 实例上，避开了 Rerank Pro 更高的 GPU 门槛和潜在的容量限制。两者用相同的请求和响应格式，所以要换回 Rerank Pro 只需改一处模板配置。 检索与答案生成可配置： Assistant 默认开启 Rerank，并为 Rerank、Context Focus 和页面图像各提供一个开关。Search 默认不带 Rerank，但可以并排比较，用来评估这些选择对相关性、延迟和 token 用量的影响。 极简 GPU 基础设施： 演示在 us-east-1 为每个部署的模型用一个 ml.g5.xlarge 实例，AWS Marketplace 模型包也按该 Region 配置。 简化的安全与访问控制： 演示只含一个用户、一个开启公网访问但由数据访问策略保护的 OpenSearch collection，并且没有启用 Bedrock Guardrails。这些设置是为了降低部署复杂度，适合评估而不是生产。 固定的文档数据集： 演示加载的是一组预先定义好的财务申报文件页面，不支持摄取用户上传的 PDF。

在生产环境部署之前，有几件事需要考虑：

网络： 给 OpenSearch Serverless 配 VPC endpoint 和私有访问。 身份： 接入你自己的身份提供方，按用户或按团队授予文档访问权限。 加密： 数据 bucket 使用客户自管的 AWS KMS 密钥；其他存储使用 AWS 托管或 AWS 自有的密钥。 运维： 加上监控、告警、端点自动扩缩容和预算告警。 查询模型： 为问题加上 Embed Fast。 重排器： 使用 Rerank Pro。

部署它

GitHub 仓库里的 README 一步步讲解了整个部署过程：需要的 Marketplace 订阅和 Bedrock 访问权限、部署 stack、加载数据，以及登录。它还说明了成本和如何清理。模型端点按运行的小时数计费，所以用完之后记得关掉。

要点回顾

构建一个金融研究助理，需要的不只是找到相关文档。它意味着取回正确的信息、保住表格和插图里的上下文，以及让答案易于核验。把 Cohere Embed、Rerank 和 Parse 与 AWS 服务组合起来，这套架构为构建能处理复杂财务文档的研究助理提供了一个起点。

几个关键的设计考量是：

从检索质量入手。 根据你的文档选择 embedding 策略，并在优化答案生成之前先验证检索表现。 让流水线匹配你的文档。 干净的文档用文本 embedding，复杂版面和扫描页用 Parse，视觉信息重要时用图像 embedding。 平衡质量、延迟和成本。 索引用 Embed Pro，查询用 Embed Fast，并在真正有价值的地方加上 Rerank 和 Parse。 只把模型需要的内容发给它。 Rerank 的 Context Focus 挑出回答问题所需的段落，页面图像则保留这些段落周围的上下文。 让答案可核验。 提供页面级引用和原始文档的访问入口，让分析师能够核对支撑证据。

了解更多

想进一步了解与这套方案相关的模型、技术和性能基准：

Cohere Embed Cohere Rerank Cohere Rerank 5 —— 检索质量与 Context Focus 基准 Cohere Embed 5 —— 模型能力与改进 Cohere 文档 Amazon SageMaker AI Amazon OpenSearch Serverless Amazon Bedrock