简介：FinBERT-QA 是一套面向金融领域问答检索的深度学习项目源码，适合具备一定自然语言处理与信息检索基础的研究者、算法工程师及金融科技方向的学生参考。其核心思路是先用 Lucene 为每个查询召回前 50 个候选答案，再借助预训练 BERT 模型对候选重新排序，并通过 Transfer and Adapt 方法先在通用问答任务上微调、再迁移至 FiQA 金融数据集，在 nDCG、MRR、Precision 三项指标上平均提升约 20%。资源包共 62 个文件，约 142.71MB，包含 9 个 Python 脚本、23 个 pickle 数据文件、4 个 tsv 语料、2 个 Jupyter Notebook，以及 Lucene 索引、Dockerfile、依赖清单与流程示意图等，覆盖数据生成、模型训练、预测与评估的完整链路。目前已有 2087 人学习下载，可帮助读者理解金融问答的检索与重排实现，并复现相关实验。
1. 金融问答系统为什么需要 FinBERT-QA：从 FiQA 数据集到检索式问答的落地路径
金融领域的问答系统跟通用问答完全不是一回事。你问「苹果公司去年营收多少」，通用模型可能给你一段维基百科式的介绍，但金融从业者要的是精确数字、财报原文出处、以及可追溯的文档段落。更麻烦的是，金融文本里充斥着大量专业术语和缩写——EBITDA、ROE、久期、凸性、信用利差——通用 BERT 在这些词上的语义表示往往不够准确，因为它的预训练语料以新闻、百科、网页为主，金融文本占比极低。FinBERT-QA 就是冲着这个痛点来的：它用金融领域语料对 BERT 做进一步预训练，再在 FiQA 数据集上做问答任务的微调，最终输出一个能在大规模金融文档中检索并抽取答案的模型。这套资源适合谁？做金融 NLP 应用的工程师、想了解检索式问答完整链路的算法同学、以及需要在自己的业务数据上复现 FiQA 评测结果的从业者。它不是一个开箱即用的 API，而是一套包含数据预处理、检索器训练、阅读器微调和评测脚本的完整工程。
2. FinBERT-QA 的技术架构：检索器与阅读器的两阶段设计
2.1 为什么是两阶段而不是端到端
检索式问答的核心矛盾在于：文档库可能有几十万篇，你不可能把每一篇都塞进 BERT 跑一遍。BERT 的最大输入长度通常是 512 个 token，一篇财报动辄上万字，直接做端到端抽取在算力上不现实。所以 FinBERT-QA 采用了两阶段架构：第一阶段用检索器（Retriever）从海量文档中快速筛出 Top-K 相关段落，第二阶段用阅读器（Reader）对候选段落做精细的答案抽取。检索器通常基于 BM25 或稠密向量检索，阅读器则是 FinBERT 微调后的问答模型。这种设计的好处是检索器负责「召回」，阅读器负责「精确」，两者各司其职。常见做法是检索器先召回 50 到 100 个候选段落，阅读器再从中定位答案 span。参数上，Top-K 的选择直接影响最终效果：K 太小会漏掉正确答案，K 太大会增加阅读器的计算负担和噪声干扰。我一般会在验证集上扫一遍 K=10、20、50、100，看 F1 和延迟的权衡曲线再定。
2.2 FiQA 数据集的结构与预处理
FiQA 数据集是金融问答领域的基准之一，包含问题、答案以及对应的文档段落。原始数据通常以 JSON 或 CSV 格式提供，每条样本包含 question、answer、context 等字段。预处理阶段需要做几件事：第一，把文档切分成适合 BERT 输入的段落，通常按 200 到 300 个 token 切分，相邻段落保留 50 个 token 的重叠，避免答案被切断；第二，构建检索器的索引，如果用 BM25 就直接对段落做倒排索引，如果用稠密检索就需要先用编码器把所有段落转成向量；第三，把训练集里的 question-answer 对整理成阅读器需要的 SQuAD 格式，即包含 question、context、answer_start、answer_text 四个字段。下面是一个典型的预处理脚本片段：
import json from transformers import BertTokenizer tokenizer = BertTokenizer.from_pretrained("yiyanghkust/finbert-pretrain") def chunk_document(text, max_len=300, overlap=50): """将长文档按 token 切分成带重叠的段落""" tokens = tokenizer.tokenize(text) chunks = [] start = 0 while start < len(tokens): end = min(start + max_len, len(tokens)) chunk_tokens = tokens[start:end] chunk_text = tokenizer.convert_tokens_to_string(chunk_tokens) chunks.append(chunk_text) if end == len(tokens): break start = end - overlap # 保留重叠，防止答案被切断 return chunks def build_squad_format(raw_data, doc_chunks): """把原始 QA 对转成 SQuAD 风格训练数据""" squad_samples = [] for item in raw_data: question = item["question"] answer = item["answer"] # 在切分后的段落中定位答案所在的 chunk for chunk in doc_chunks: if answer in chunk: answer_start = chunk.index(answer) squad_samples.append({ "question": question, "context": chunk, "answer_start": answer_start, "answer_text": answer }) break return squad_samples这段代码的逻辑很直接：chunk_document负责把长文本切成带重叠的段落，build_squad_format负责把答案定位到具体的 chunk 里。参数max_len控制每个段落的 token 数，overlap控制重叠量。注意answer_start是字符级索引，不是 token 级，这一点在后续训练时要和 tokenizer 的 offset mapping 对齐，否则答案位置会错位。常见翻车点就是这里：很多人直接用 token 索引去算 answer_start，结果训练时 loss 一直不降。
2.3 检索器的选型：BM25 还是稠密向量
检索器的选择直接决定了召回质量。BM25 是经典方案，优点是无需训练、速度快、对精确匹配友好；缺点是无法处理语义相似但用词不同的情况，比如用户问「盈利能力」而文档里写的是「利润水平」。稠密向量检索（比如用 Sentence-BERT 或 DPR）能解决语义匹配问题，但需要额外的编码和索引构建步骤，而且金融领域的嵌入模型需要专门微调才能达到理想效果。FinBERT-QA 的实践中，常见做法是先用 BM25 做基线，再尝试用 FinBERT 的 [CLS] 向量做稠密检索，对比两者的 Recall@K。如果 BM25 的 Recall@50 已经超过 85%，那稠密检索的边际收益可能不值得额外的工程复杂度。参数上，BM25 的 k1 和 b 需要根据文档长度分布调整：k1 通常取 1.2 到 2.0，b 取 0.75 左右，但如果你的文档普遍很短，b 可以调低到 0.3 到 0.5。
3. 从零复现 FinBERT-QA：环境搭建、模型微调与评测
3.1 环境依赖与模型加载
复现的第一步是把环境搭好。FinBERT-QA 依赖 PyTorch、Transformers、以及检索相关的库（如 rank_bm25 或 faiss）。我一般会建一个干净的 conda 环境，固定版本避免玄学问题。下面是环境配置和模型加载的代码：
conda create -n finbert-qa python=3.8 conda activate finbert-qa pip install torch==1.13.1 transformers==4.28.0 pip install rank_bm25 faiss-cpu datasets scikit-learnfrom transformers import BertForQuestionAnswering, BertTokenizer import torch # 加载 FinBERT 预训练权重作为阅读器底座 model_name = "yiyanghkust/finbert-pretrain" tokenizer = BertTokenizer.from_pretrained(model_name) model = BertForQuestionAnswering.from_pretrained(model_name) # 检查 GPU 是否可用 device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model.to(device) print(f"模型已加载到 {device}，参数量：{sum(p.numel() for p in model.parameters())}")这里用的是yiyanghkust/finbert-pretrain作为底座，它是公开的金融领域 BERT 预训练权重。注意BertForQuestionAnswering的输出是 start_logits 和 end_logits，分别对应答案在序列中的起始和结束位置。如果你的显存不够，可以把 batch size 降到 8 或 16，同时开启梯度累积来保持等效 batch size。参数上，学习率通常设 2e-5 到 3e-5，epoch 数 3 到 5 就够，再多容易过拟合。
3.2 阅读器微调的关键参数与训练循环
阅读器微调是整个流程里最耗算力的一步。训练数据是 SQuAD 格式的 question-context-answer 三元组，损失函数是 start 和 end 位置的交叉熵之和。下面是一个精简的训练循环：
from torch.utils.data import DataLoader from transformers import AdamW, get_linear_schedule_with_warmup def train_reader(model, train_dataset, epochs=3, batch_size=16, lr=3e-5): train_loader = DataLoader(train_dataset, batch_size=batch_size, shuffle=True) optimizer = AdamW(model.parameters(), lr=lr, weight_decay=0.01) total_steps = len(train_loader) * epochs scheduler = get_linear_schedule_with_warmup( optimizer, num_warmup_steps=int(0.1 * total_steps), num_training_steps=total_steps ) model.train() for epoch in range(epochs): total_loss = 0 for batch in train_loader: input_ids = batch["input_ids"].to(device) attention_mask = batch["attention_mask"].to(device) start_positions = batch["start_positions"].to(device) end_positions = batch["end_positions"].to(device) outputs = model(input_ids, attention_mask=attention_mask, start_positions=start_positions, end_positions=end_positions) loss = outputs.loss loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step() scheduler.step() optimizer.zero_grad() total_loss += loss.item() print(f"Epoch {epoch+1}, Avg Loss: {total_loss/len(train_loader):.4f}") return model关键参数说明：lr=3e-5是 BERT 微调的经典学习率，太大容易震荡，太小收敛慢；weight_decay=0.01防止过拟合；clip_grad_norm_设 1.0 是防止梯度爆炸的常规操作；warmup_steps占总步数的 10%，让模型在初期慢慢适应。训练时如果发现 loss 在前几百步就降到很低但验证集 F1 不涨，大概率是过拟合了，这时候要么加数据增强，要么减 epoch。另一个常见问题是start_positions和end_positions超出序列长度，这通常是因为预处理时没做截断，需要在 tokenizer 里设truncation=True和max_length=512。
3.3 评测指标与结果解读
评测阶段主要看两个指标：检索器的 Recall@K 和阅读器的 Exact Match（EM）与 F1。Recall@K 衡量的是正确答案所在段落是否出现在 Top-K 候选中，EM 衡量的是抽取答案和标准答案是否完全一致，F1 则是 token 级别的重叠度。下面是一个评测脚本的骨架：
from sklearn.metrics import f1_score def evaluate_reader(model, eval_dataset, tokenizer): model.eval() em_count, f1_total = 0, 0.0 for sample in eval_dataset: inputs = tokenizer(sample["question"], sample["context"], return_tensors="pt", truncation=True, max_length=512) with torch.no_grad(): outputs = model(**inputs.to(device)) start_idx = torch.argmax(outputs.start_logits) end_idx = torch.argmax(outputs.end_logits) pred_answer = tokenizer.decode(inputs["input_ids"][0][start_idx:end_idx+1], skip_special_tokens=True) if pred_answer.strip() == sample["answer_text"].strip(): em_count += 1 f1_total += f1_score(sample["answer_text"].split(), pred_answer.split(), average="macro") print(f"EM: {em_count/len(eval_dataset):.4f}, F1: {f1_total/len(eval_dataset):.4f}")这段代码的逻辑是：对每个评测样本，用 tokenizer 编码 question 和 context，模型输出 start 和 end 的 logits，取 argmax 得到答案 span，再 decode 成文本。注意start_idx和end_idx是 token 索引，decode 时要确保不越界。如果end_idx < start_idx，说明模型输出了无效 span，这时候通常取 start_idx 对应的单个 token 作为答案。实际跑下来，FinBERT-QA 在 FiQA 上的 F1 通常在 0.6 到 0.7 之间，具体取决于检索器的 Recall 和阅读器的微调程度。如果 F1 明显低于这个区间，优先检查预处理阶段的 answer_start 对齐和 tokenizer 的 truncation 设置。
4. 避坑与排查：FinBERT-QA 复现中最容易翻车的五个地方
4.1 现象：训练 loss 正常下降但验证集 F1 始终为 0
原因：answer_start 的字符索引和 tokenizer 的 token 索引没有对齐。SQuAD 格式要求 answer_start 是字符级索引，但很多人在预处理时直接用 token 位置赋值，导致模型学到的 start 位置和真实答案完全错位。解决：用 tokenizer 的return_offsets_mapping=True获取每个 token 对应的字符区间，再把字符级 answer_start 映射到 token 级 start_position。这一步不做，后面全白搭。
4.2 现象：检索器 Recall@50 很高但阅读器 F1 很低
原因：候选段落里虽然包含答案，但段落太长或噪声太多，阅读器无法准确定位。常见情况是 chunk 切分时 max_len 设得太大（比如 500），导致一个 chunk 里混入了多个主题的内容。解决：把 chunk 的 max_len 降到 200 到 300，增加 overlap 到 50 到 80，确保每个 chunk 的语义相对集中。另外可以在检索器后面加一个段落重排序（rerank）步骤，用交叉编码器对 Top-K 做精排。
4.3 现象：GPU 显存溢出，batch size 降到 4 还是 OOM
原因：BERT 的注意力矩阵是 O(n^2) 复杂度，序列长度 512 时显存占用很大。如果同时加载了检索器和阅读器，或者用了 fp32 精度，显存很容易爆。解决：开启混合精度训练（torch.cuda.amp），把 max_length 从 512 降到 384，或者用梯度累积模拟大 batch。如果还是不够，考虑用 DistilBERT 或 ALBERT 作为阅读器底座，参数量少一半，效果损失通常在 2 到 3 个点以内。
4.4 现象：BM25 检索结果里大量无关文档排在前面
原因：金融文档里有很多模板化的法律声明和风险提示，这些内容词频高但信息量低，BM25 容易被它们干扰。解决：在索引前做停用词过滤，把「风险提示」「免责声明」「本报告仅供参考」这类模板句去掉。另外可以调整 BM25 的 b 参数，降低长文档的权重。如果业务允许，加一个基于规则的前置过滤器，把非目标类型的文档直接排除。
4.5 现象：模型在训练集上表现很好，换一批新问题就崩了
原因：过拟合。FiQA 数据集的规模有限，如果模型在训练集上跑了太多 epoch，它会记住具体的问答对而不是学到泛化的匹配能力。解决：早停（early stopping）是必须的，监控验证集 F1，连续 2 个 epoch 不涨就停。另外可以加 dropout（BERT 默认 0.1，可以调到 0.2 到 0.3），或者用数据增强，比如对问题做同义改写、对答案做回译。血泪经验是：不要看训练 loss 低就高兴，验证集才是唯一标准。
5. 进阶技巧：用集成检索和答案重排序把 F1 再拉高几个点
5.1 多路召回融合
单一检索器的召回总有盲区。BM25 擅长精确匹配，稠密检索擅长语义匹配，把两者的结果做加权融合通常能提升 Recall@K。具体做法是：BM25 返回一个排序列表，稠密检索返回另一个排序列表，用 Reciprocal Rank Fusion（RRF）把两个列表合并。RRF 的公式很简单：对每个文档，分数等于所有检索器中 1/(k + rank) 之和，k 通常取 60。这样不需要调权重，直接融合两个异构检索器的结果。我一般会先用 BM25 召回 100 个，稠密检索召回 100 个，RRF 融合后取 Top-50 送给阅读器，Recall@50 通常能比单路提升 5 到 8 个点。
5.2 答案重排序与置信度校准
阅读器输出的 start_logits 和 end_logits 可以直接用来算答案的置信度。常见做法是取 start 和 end 的 softmax 概率之和作为分数，对多个候选段落给出的答案做重排序。如果 Top-1 答案的置信度低于某个阈值（比如 0.3），可以触发「拒答」或者回退到检索器的摘要结果。下面是一个简单的重排序逻辑：
import torch.nn.functional as F def rerank_answers(model, tokenizer, question, contexts, top_n=5): """对多个候选段落分别抽取答案，按置信度重排序""" candidates = [] for ctx in contexts: inputs = tokenizer(question, ctx, return_tensors="pt", truncation=True, max_length=384) with torch.no_grad(): outputs = model(**inputs.to(device)) start_prob = F.softmax(outputs.start_logits, dim=-1) end_prob = F.softmax(outputs.end_logits, dim=-1) start_idx = torch.argmax(start_prob).item() end_idx = torch.argmax(end_prob).item() if end_idx < start_idx: end_idx = start_idx confidence = (start_prob[0][start_idx] * end_prob[0][end_idx]).item() answer = tokenizer.decode(inputs["input_ids"][0][start_idx:end_idx+1], skip_special_tokens=True) candidates.append({"answer": answer, "confidence": confidence, "context": ctx}) candidates.sort(key=lambda x: x["confidence"], reverse=True) return candidates[:top_n]这段代码的核心是confidence的计算：用 start 和 end 的联合概率作为答案的置信度。注意这里用的是乘积而不是求和，因为 start 和 end 需要同时正确才有意义。参数top_n控制返回的候选答案数量，实际部署时可以只取 Top-1，但保留 Top-5 方便做人工审核或下游任务。如果发现置信度普遍偏低（比如都低于 0.1），说明阅读器对这批数据不适应，可能需要用领域数据再做一轮微调。
5.3 一个容易被忽略的细节：特殊 token 的处理
FinBERT 的 tokenizer 会在序列首尾加 [CLS] 和 [SEP]，在 decode 答案时如果不跳过特殊 token，抽取结果里会混入这些标记。skip_special_tokens=True能解决大部分情况，但如果答案本身包含 [SEP] 或 [CLS] 的字面文本（金融文档里偶尔会有），就会被误删。更稳妥的做法是手动过滤：先 decode 完整序列，再用正则把特殊 token 去掉。另外，如果答案跨了多个 token 但中间有标点，decode 出来的文本可能和原始答案有细微差异，评测时建议用 normalize 后的文本做比较，比如统一小写、去掉多余空格和标点。从那以后我每次跑评测都强制走一遍 normalize 流程，不然 EM 和 F1 的数值会莫名其妙地低一截。希望帮到你。
本文还有配套的精品资源，点击获取
