金融文本数据与检索：公告、新闻与 RAG

市场信息不只有行情和财务表，还有公告、新闻和研报。怎样让用户或 Agent 搜到相关资料，回答时能说明依据，并避免把未来才发布的文本带回过去？

公告、新闻、研报和业绩说明会纪要都属于文本数据，但来源、可信度、发布时间、版权和重复情况不同。

• 公告：上市公司披露的正式文件，通常有明确的标题、发布时间、编号和附件。
• 新闻：媒体报道或转载，可能有改写、重复和不同的来源质量。
• 研报和纪要：常有机构或作者署名，使用和再分发要遵守相应授权边界。

一条文本至少应保留这些元数据：

document_id
security_code
published_at
title
source
source_url
content_hash

元数据不是附属品。没有 published_at，就无法做时点过滤；没有 document_id 和 source_url，就无法让读者回到来源；没有 content_hash，就很难去重或发现内容变化。

倒排索引像书后的索引页：它记录每个词出现在哪些文档中，以及词频、位置等信息。查询时直接定位候选文档，而不是从头读完整文档。

中文文本通常需要先分词，也可以在特定场景用字符 n-gram。证券代码、公司简称、公告类型和“回购”“减持”等专有词，关键词检索往往更容易解释，也更适合精确匹配。

BM25 是常见的关键词相关性评分方法。可以先记住三条直觉：

1. 查询词在文档中出现越多，相关性通常越高，但词频增益会逐渐饱和。
2. 越少见的词，区分文档的价值通常越高，这部分由逆文档频率体现。
3. 文档过长时会做长度归一化，避免长文档仅因为包含更多词就总排在前面。

具体分数只适合在同一套索引和参数内比较，不能把不同系统的 BM25 分数直接当成概率。

嵌入（embedding）模型把文本转换成向量。语义相近的文字在向量空间中通常更接近，可以用余弦相似度等方法检索。这样，用户搜索“高管薪酬”时，有机会命中写成“高级管理人员薪酬”的文本。

向量检索也有局限：

• 证券代码、公告编号和专有名词需要精确匹配时，关键词更可靠。
• 嵌入模型、向量索引和更新任务会增加成本与运维复杂度。
• 相似度结果需要结合资料和元数据解释，不能只看一个分数。

因此，实际产品常使用混合检索：先分别得到 BM25 和向量检索结果，再通过合并、重排序和业务过滤选出候选文档。关键词保证精确词，向量补充同义表达。

RAG（Retrieval-Augmented Generation，检索增强生成）的基本流程是：

1. 把问题转成检索请求。
2. 从关键词索引、向量索引或两者中召回文档片段。
3. 按来源、时间、权限和相关性过滤、重排。
4. 把候选资料交给生成模型组织答案。
5. 返回答案、文档 ID、标题、发布时间和可访问的来源链接。

RAG 的价值不是让模型凭空“记住”所有公告，而是把当前检索到的证据放进回答过程。金融场景必须保留出处，方便复查；如果检索不到足够证据，应明确说明范围不足，而不是用模型猜测补齐。

文本切块也影响结果。整份年报作为一个块，可能命中但找不到具体段落；切得过碎，表头、注释和上下文可能分离。切块应尽量保留标题、表格上下文、章节和页码等定位信息。

来源约束：每条重要结论应回到一份具体公告、新闻或其他可核查资料。公告与新闻应分库或至少分标签；转载内容需要去重和来源分级。文本能公开访问，不自动意味着可以任意复制、改编或再分发。

时点约束：如果问题是“站在 10 月 30 日，当时能知道什么”，检索集合只能包含 published_at <= as_of 的文本。对财报公告，还要结合发布时刻和交易日历；盘后发布的信息通常不能假设当天收盘前已经可用于交易决策。

这和第 19 讲的 Point-in-time 数据直接相连：

候选文本 = published_at <= as_of
           且满足数据授权、来源和对象范围

如果研究问题是“公告发布后 3 天股价有什么变化”，还需要用证券代码和时间把文本与行情数据对齐，并避免使用之后才修订或补录的字段。

公告 / 新闻来源
      │ 元数据 + 正文
      ▼
解析、去重、切块、权限标记
      ├─ 倒排索引 / BM25
      └─ 嵌入模型 → 向量索引
                     │
用户 / Agent 问题 ────┘
      │ 混合检索 + as_of + 授权过滤
      ▼
生成回答 + 文档 ID + 发布时间 + 来源链接

它可以和第 38 课《公告和研报怎么读》衔接：先用检索定位原始披露，再回到公告正文判断信息是什么、由谁披露、在什么时间公开；也可以和量化交易 AI 投研专题衔接，把检索结果作为可追溯的上下文，而不是把模型输出直接当作证据。

{
  "document_id": "公告唯一标识",
  "security_code": "证券代码",
  "published_at": "2026-10-30T20:00:00+08:00",
  "title": "公告标题",
  "source_url": "https://example.com/document",
  "score": 0.82,
  "retrieval_method": "hybrid"
}

这里的时间、代码、标题和 URL 是示意字段，具体命名要与数据源和接口合同保持一致。score 只表示当前检索系统的排序依据，不是事实可信度，也不是投资结论。

1. 以为有向量检索就不需要关键词：代码、公告编号和专有名词需要精确匹配，混合检索更稳妥。
2. 只存正文，不存元数据：没有发布时间无法做 PIT，没有文档 ID 无法引用来源。
3. 把新闻当成公告：新闻可能转载、改写和重复，来源质量与正式披露不同。
4. 切块只追求大小：切块应保留标题、表头、页码和上下文，便于检索和检查。
5. RAG 不返回出处：金融回答必须能回到来源，相关性分数不能代替证据。
6. 忽略授权：公开可查不等于可以任意复制、展示、转发或再分发。
7. 忽略 as_of：把未来发布的公告检索进历史研究，会产生前视偏差。

• Lewis 等：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Elasticsearch：Similarity settings（默认 BM25）
• HNSW 论文
• FAISS 向量检索库
• pgvector
• 巨潮资讯网
• 第 38 课：公告和研报怎么读