Lucy 基于 Qdrant 构建了 280 万+ SEC 和 DART 文件的权威数据源检索层

四条混合检索通道部署在 Qdrant 上，payload 过滤在查询内部完成，而非查询后处理。

在 FinanceBench 上 Recall@10 达到 94.7%。

仅靠检索，固定答案模型不变的前提下，回答准确率提升 0.160。

一个开源权重模型搭配 Lucy RAG，在与搜索网络的前沿模型对比中胜出。

https://qdrant.tech/blog/case-study-lucy/…

Lucy 如何用 Qdrant 为 280 万+ SEC 和 DART 文件构建权威数据源检索层 - Qdrant

来源：https://qdrant.tech/blog/case-study-lucy/ Lucy 为金融 AI 构建数据基础设施，将 280 万+ SEC 和韩国 DART 报告文件转化为结构化、可溯源的数据。Lucy RAG 在 Qdrant 上运行带过滤约束的混合检索，在 FinanceBench 上达到 94.7% Recall@10，并在固定模型下将回答准确率提升 0.160

Lucy (https://lucydata.ai/) 为金融 AI 构建数据基础设施。该公司将来自美国证券交易委员会（SEC）EDGAR 系统和韩国 DART 披露系统的海量监管文件，转化为 AI 系统可以搜索、检索和推理的结构化数据。

其语料库涵盖 27 种申报和报告类型、超过 280 万份文件，覆盖 2016 至 2026 年约 10 年的历史数据，新申报文件以接近实时的速度持续处理。SEC 一侧涵盖公司、持股和基金类申报：10-K、10-Q、8-K、20-F、DEF 14A、S-1、S-3、Form 3、4 和 5、13F、13D/G、N-1A、N-PORT，以及 485 和 497 系列。资产管理公司和 ETF 发行方已经在 Lucy 的数据之上构建应用。

金融申报文件是最难让语言模型直接使用的文档之一。单份 10-K 可能包含超过 200 页的叙述文本、财务表格、图片、交叉引用和元数据，而其中最重要的表格恰恰是最难解析的部分。Lucy 的判断是：申报文件本身就是金融问题的权威数据源，围绕它们构建的检索层能够超越在开放网络上搜索的前沿模型。

前沿模型会答错金融问题，而这代价高昂

今天的分析师和投资者可以使用 ChatGPT、Claude、Gemini 以及所有其他前沿模型。Lucy 的客户告诉团队的内容，与团队自己得出的结论一致：向这些模型提出关于某家公司申报文件的具体问题时，它们有时会给出错误答案。在金融领域，放错位置的一个错误数字可能造成数百万美元的损失，因此一个可用答案的标准不是“大体正确“，而是“可追溯到申报文件“。

金融领域十分复杂，AI 模型有时会针对具体的金融问题给出错误答案。我们认为这些答案需要权威数据源，而对于上市公司的金融数据，这个数据源就是原始的 SEC 申报文件。

构建这一检索层意味着同时解决两个问题。第一个是数据质量：将 200 页的申报文件转换为组织良好的文本、保留原始行列结构的表格、标准化的 XBRL（可扩展商业报告语言）财务事实，以及带来源链接的数据块——同时还要保留可追溯到原始文档的出处信息。

第二个是在数百万份文档的语料库中实现精准检索。正如 Lucy 的 RAG 工程师 Jongbok Lee 所说，对海量数据进行向量化并不是难点，把搜索范围收窄、让正确的数据块排在第一位才是。

成本和延迟同样重要。对于这类工作负载，前沿模型昂贵、笨重且缓慢。团队想弄清楚的是：一个构建良好的检索层，能否让一个小型开源权重模型回答金融问题时，表现与带网络搜索的前沿模型相当甚至更好。

Lucy 并没有针对所有备选方案做正式的对比基准测试。团队选择 Qdrant 是因为它满足了 SEC 和 DART 检索工作负载的三项具体要求。

第一项是过滤。每个关于申报文件的问题都带有结构化信号：哪家公司、哪个股票代码、哪个中央索引号（CIK）、哪种表格类型、哪个报告期间、哪个条目或章节，以及经常还有通过受理编号定位到的具体文档。这些信号需要在相似度排序之前约束搜索范围，而不是在查询完成后从长长的候选列表中删减。Qdrant 的 payload 过滤 在查询内部应用这些条件，因此过滤和向量搜索一起执行，而不是分两步进行。

第二项是搜索本身。金融文本中充斥着嵌入模型无法捕捉的精确术语、股票代码和科目名称，因此 Lucy 需要在同一个查询中既使用用于语义匹配的稠密向量，也使用用于词法精准匹配的稀疏向量。Qdrant 的 混合搜索 覆盖了这两者，而 Lucy 通过倒数排名融合（RRF）合并排序列表。

仅靠向量搜索可能漏掉金融申报文件中的重要细节，而向 LLM 提供过多上下文又可能导致遗漏或幻觉。结合关键词搜索和向量搜索让我们的检索结果可靠得多。Qdrant 让这种混合方案易于实现和扩展。

第三项是语料库增长带来的成本。新的申报文件持续到达，因此 Lucy 需要在基础设施成本不随语料库规模同步攀升的前提下保持召回率。原生的 量化 降低了索引的存储占用，Qdrant 的分布式架构和分片机制也为团队随着覆盖范围扩大而进行水平扩展提供了空间。

我们需要量化来提升语料库增长时的效率，但我们主要担心的是它是否会损害检索质量。在我们的测试中，TurboQuant 显著降低了内存占用，同时检索性能几乎不受影响。

Lucy 在正式采用前，在两个语料库上都对 TurboQuant 进行了评估。在维度为 1,536 的 10-K 语料库上，4 位 TurboQuant 将实测内存占用从约 52 GB 降至 10.7 GB，减少了 4.9 倍。

质量上的代价很小。在不使用元数据过滤的情况下测量：

混合检索的结果实际上没有变化，因为稀疏检索补偿了压缩给稠密向量带来的损失。基于这一评估，Lucy 在 DART 文件上运行 2 位量化——韩文文本在每份文件中产生更多数据块，更高的压缩比带来最大的节省——而在 SEC 文件上采用更保守的 4 位量化。

FinanceBench 上召回率超过 94%，仅靠检索带来 0.16 的回答准确率提升

Lucy 使用两个公开的金融基准来评估其检索层。

更有说明性的测试将检索与答案模型分离开来。固定答案模型（Claude Fable 5）不变、只更换上下文层时，RAGAS 回答准确率从使用通用网络搜索上下文的 0.792 提升到使用 Lucy RAG 上下文的 0.952，提升 0.160 归因于检索本身。

这一结果也重新定义了成本问题。在另一项评估中，一个开源权重的 Gemma 模型搭配 Lucy RAG，得分超过了所有运行网络搜索上下文的前沿模型。

按上下文层统计的 RAGAS 回答准确率：一个开源权重 Gemma 模型搭配 Lucy RAG 上下文得分 0.863，领先于三个使用网络搜索上下文的前沿模型（0.845、0.792 和 0.786）

一个扎根于正确申报文件数据块的小模型，战胜了在开放网络上搜索的更大模型。

对这类工作负载而言，前沿模型可能更昂贵、速度也更慢。我们发现，有了强大的 RAG 系统，即使是较小的开源模型也能产生非常有竞争力的结果。

对 Lucy 的客户来说，回报是一个会引用其所来自的数据块、并高亮原始申报文件中对应段落的答案，这样分析师在据此行动之前可以先验证数字。目前最明显的好处是在海量申报文件中找到并验证正确披露信息所需的时间。

Lucy RAG 如何通过 Qdrant 处理查询

Lucy RAG 架构：路由器解析实体、CIK 和确切的申报文件，然后将 payload 过滤条件传入 Qdrant，在那里四条通道各自执行相同的稠密+稀疏混合查询。倒数排名融合和去重将候选结果缩减到前 20 个数据块，再由答案模型生成带来源链接的回答

查询通过路由器进入 Lucy RAG，路由器的首要职责是确定用户指的是哪家公司、哪份申报文件。它查询 Lucy 的目录数据库，解析实体和 CIK，并通过 SEC 受理编号或 DART 登记编号锁定确切文档。如果问题存在歧义，路由器会先要求用户澄清再进行检索。

一旦确定目标，路由器将元数据过滤条件（公司、表格类型、日期范围和文档 ID）传递给 Qdrant，Qdrant 是主要的检索路径。检索在四条通道上运行，每条通道使用相同的过滤条件执行相同的稠密+稀疏混合查询。

窄通道运行聚焦式的多查询检索，并附带章节过滤以保证精准度。宽通道的搜索范围更广，作为召回率的兜底保障，始终与窄通道同时运行。XBRL 通道仅在涉及财务报表或财务数字的问题时运行，通过添加相关的 XBRL 标签将正确的财务表格在排序中往上推。伴随通道在申报文件通过引用整合另一份文件时运行，例如 10-K 中引用的 DEF 14A 委托书。

每条激活的通道最多返回 60 个候选结果。Lucy 通过 RRF 融合排序列表、去重，然后将最终的前 20 个数据块交给答案模型。位于 Amazon S3 的补充知识库保存着每份申报文件的预处理摘要和关键财务事实，流水线会按主题选取并将其作为额外上下文添加进去。团队还在增加一个 Neo4j 图层来捕捉申报文件之间的关联关系，首先从修订版本开始。

在 1,517 次实测搜索中，Qdrant 平均每次搜索耗时 32 ms，p50 为 16 ms，p90 为 82 ms。各通道在搜索约束程度上区分得很清晰。

宽通道最慢，因为它在最宽的范围内施加了限制性最低的过滤条件——而正是这一特性使它成为召回率的有效兜底。约束更紧的窄通道和 XBRL 通道在 p50 下都在个位数毫秒内完成。

生产环境中的实际运行情况

Lucy 以自托管方式运行 Qdrant。生产环境中有 12 个 collection，包含约 5,225 万个稠密向量和数量相同的稀疏向量，随着团队对更多 SEC 和 DART 文件进行向量化，这两个数字都在持续增长。

两个语料库使用不同的稠密模型，共享同一个稀疏模型。

不同语料库的数据块数量也存在差异，因为按 Lucy 当前的分词和分块设置，韩文文本会产生更高的 token 数。这也是 DART 获得更激进的 2 位量化的原因之一。

SEC 和 DART 每份文件的数据块数量，按 P25、平均值、P75 和 P90 统计。SEC 分别为 91、194、236 和 373；DART 分别为 178、418、520 和 846，在分布的每个点上大约是 SEC 的两倍

Collection 的布局经过一轮迭代才调整到位，这也是 Lucy 扩展经验中最清晰的一课。团队最初将所有 SEC 申报类型存放在单个 collection 中，并在每个数据块前加上公司名称、股票代码和报告日期等元数据。这在小规模下是可行的。随着覆盖范围扩大，检索延迟上升了约 2 到 3 倍，召回率也有所下降。

Lucy 将数据按申报类型拆分到不同的 collection 中，并将这些元数据从数据块文本中移出，放入可索引的 payload 字段：accession_number（DART 一侧为 receipt_number）、chunk_type 和 item_key，以及每种文档类型为过滤所需的额外字段。通过这种方式收窄搜索范围后，随着语料库持续增长，延迟和召回率同时得到改善。

所有这一切都由一个不到十人的工程团队在 SEC 和 DART 两侧共同运维。

接下来：在同一检索层上进行基准生成与评估

Lucy 正在三个方向上扩展。覆盖范围将超越当前的 27 种申报类型和 10 年窗口，对这个市场感兴趣的合作伙伴可以获取韩国 DART 语料库。Neo4j 图层将把修订和跨文件关系纳入检索流程。

公司还在与专家主导的 AI 训练和评估机构探索合作，以自动化创建基于可验证申报文件证据的私有金融基准，这将把 Qdrant 的角色从检索扩展到基准生成与评估工作流。

从“看起来合理“到“可验证“

Lucy 的出发点是：仅靠前沿模型无法被信任用于金融问题，而申报文件才是权威数据源。要让 280 万份文件变得可检索，需要在摄入时保留其结构，并在查询时对检索加以约束。

借助 Qdrant 上的混合搜索、payload 过滤和量化，Lucy RAG 在 FinanceBench 上将 Recall@10 保持在 94.7%，在固定模型下将回答准确率提升 0.160，并让一个开源权重模型的表现超过了使用网络搜索的前沿模型——而这一切的运行足迹，一个不到十人的工程团队即可运维。分析师现在得到的答案，会附上其所来自的申报文件段落。