简介面向金融领域问答与信息检索研究者的 FinBERT-QA 完整实现包,针对 FiQA 数据集任务2,解决从金融段落中检索候选答案并重排序的问题。系统使用 Lucene 检索前50个候选,再以预训练 BERT 微调后重排,在 nDCG、MRR、Precision 三项指标上平均提升约20%;模型基于 Huggingface 库完成从 TensorFlow 到 PyTorch 的转换与迁移,步骤可供迁移学习参考。压缩包共62个文件,大小142.71MB,以 pickle 数据/模型、py 训练推理脚本、tsv 语料、ipynb 分析笔记为主,另含 Dockerfile、sh 索引构建脚本、requirements.txt 等,便于复现环境。代码覆盖数据生成、模型微调、预测、评估全流程,配有 retriever 索引与两大 notebook 分析,并提供 data/raw、id_to_text、qa_lstm_tokenizer、rank、data_pickle 等中间产物,还附 README 与 Dockerfile 环境说明,目录结构清晰。已有2089人学习,适合自然语言处理、信息检索方向学生与金融科技从业者深入理解预训练模型在金融领域段落重排中的实际应用,可直接在本地复现实验效果。1. 金融问答的拦路虎是预训练阶段留下的「语言代沟」先讲一个我实际踩过的坑做财报问答原型时直接把通用中文 BERT 接进来拿公开问答数据微调了一轮就以为能上生产。结果模型在「报告期营收同比增长了多少」这种问题上开始吞吞吐吐要么答成年份要么从研报里扯出一段不相干的话。问题不在微调在预训练——通用 BERT 学的是维基、网页、书籍里的语言分布而金融文本里有大量「扣非净利润」「递延所得税负债」「归母营收增速」这样的术语组合通用模型对这些词的上下文语义是模糊的。FinBERT-QA 的核心就是先把预训练这一步从通用语料拉到金融语料上让 BERT 真正「读得懂」财报和研报再去做问答。这篇文章我会从领域继续预训练、标注数据构造、切分策略、微调闭环、典型翻车点到最后的置信度拦截完整讲一遍可以照做的方案适合手里有金融文档、想自己搭问答能力的开发团队。2. FinBERT 的领域预训练为什么先让模型「读懂」财报再谈问答2.1 通用 BERT 和金融文本的「语言代沟」BERT 这类预训练语言模型本质上是在大规模文本上做掩码预测学到的是词与词之间的共现规律。通用语料里出现过「净利润增速」但没怎么出现过「归母净利润增速」这种财报高频表达。你把一个句子里的词随机 mask 掉让模型猜原文通用模型给出的候选词往往是常识语义候选而金融语料里正确的候选是「同比」「环比」「符合预期」这类带着财报口吻的表达。这个差距不是换个任务结构能弥补的。问答任务里模型需要判断「问题中的实体」与「上下文中的实体」是否指向同一件事这依赖预训练阶段建立的语义关联。金融文档里同一个公司名可能出现在公告、研报、新闻三种文体里指代方式完全不同通用模型很难把这些表达串起来。所以 FinBERT 的思路很直接用金融语料继续做掩码语言模型训练让参数往金融语境的方向再走一段。这一步在工业界通常叫领域继续预训练或者叫 DAPT做法和 BERT 原始预训练完全一致只是换掉训练语料。需要注意的是继续预训练不是简单地拿金融文本跑一遍就行。语料清洗、长度配比、学习率、训练轮数都对最终下游效果有影响而且这些参数之间互相牵制。下面我先给出一个可复用的语料清洗脚本再讲训练参数怎么定。2.2 领域语料清洗从财报公告到 MLM 输入继续预训练的第一步是拿到干净的金融语料。我一般会从三个来源收集上市公司公告、券商研报正文、财经新闻。这三个来源的写作风格差异很大公告里套话多研报里分析句多新闻里口语化表达多一些混在一起能避免模型只学会一种文体。清洗时重点做四件事去标签、统一全角半角、按句切分、去重和过滤太短的片段。import re import html import unicodedata def clean_financial_text(text: str) - list[str]: # 去除 HTML / XML 标签公告和研报经常带格式标记 text re.sub(r[^], , text) # 反转义常见实体例如 amp; 转回 text html.unescape(text) # 统一全角半角数字和百分号尤其重要 text unicodedata.normalize(NFKC, text) # 按中文句末标点切句保留引号内部完整句子 segments re.split(r(?[。;])\s*, text) # 过滤过短片段、纯数字行、纯表格噪声 segments [s.strip() for s in segments if 8 len(s.strip()) 512 and not re.fullmatch(r[\d\s%.\-—], s.strip())] return segments # 使用示例遍历原始文件逐段写入训练语料 raw_folder corpus/raw out_file corpus/fin_pretrain.txt with open(out_file, w, encodingutf-8) as f: for path in list_raw_files(raw_folder): for seg in clean_financial_text(read_file(path)): f.write(seg \n)为什么按句切而不是直接按段落切因为 MLM 训练是按固定长度窗口采样的如果语料里一个段落长达几千字采样时会从段落中间截断导致大量半句话。按句切完后每行是一个完整句模型每次采样都能拿到语义完整的样本。长度过滤下限设 8 个字符是为了把「营收增长」「净利润下降」这类短句也保留下来这类短句恰恰是财报里最常见的判断句式上限设 512 是为了之后切块不浪费太多 token。全角半角统一这里要特别留意因为后续标注答案的 start 偏移量是按字符数算的全角半角混用会让偏移量对不上这是很隐蔽的坑。2.3 继续预训练的三个参数纪律先短后长、小步验证、语料去重训练脚本本身不复杂关键是三个参数纪律。第一先短后长。先用 128 token 的窗口训练一个 epoch 验证语料质量和 loss 走势再把窗口拉到 512 做正式训练。短窗口收敛快、显存占用小适合排查语料里的脏数据长窗口能建模跨句依赖但对显存要求高。第二学习率要克制。继续预训练一般用 5e-5 到 1e-4 之间的学习率比微调阶段的 2e-5 到 3e-5 略大但不要直接上 1e-4 以上否则模型会在金融语料上「失忆」把通用语料学到的知识冲掉。第三语料一定要去重。很多公开的财经文本集里重复内容严重同一个新闻被转载几十次不去重的话模型会在重复文本上过拟合loss 看起来降得很快但下游问答一点不涨。我习惯把清洗好的语料先做一个全局去重再用 MinHash 做近似去重把转载改写的版本也去掉。这一步不做的话后面所有训练都可能建在虚假的收敛之上。训练轮数方面语料量大比如超过几千万句的时候跑 1 个 epoch 就够语料量小几百万句以内可以跑 3 个 epoch但必须同时监控一个下游任务的指标变化而不是只看 MLM loss。只看 MLM loss 很容易陷入「自欺欺人」的境地——loss 在降问答 F1 却在掉这在继续预训练里非常常见。from transformers import Trainer, TrainingArguments model BertForMaskedLM.from_pretrained(bert-base-chinese) # 换成你的基础模型 args TrainingArguments( output_dirfinbert-adapted, per_device_train_batch_size32, learning_rate5e-5, warmup_ratio0.1, num_train_epochs3, save_strategyepoch, logging_steps200, fp16True, # 显存允许就开训练速度提升明显 ) trainer Trainer( modelmodel, argsargs, train_datasetmlm_dataset, ) trainer.train()这段代码里的 mlm_dataset 需要预先对语料做 tokenize 和动态掩码。动态掩码的意思是每个 epoch 重新随机 mask 不同的 token而不是在数据集构造时固定 mask 位置。这样能有效缓解数据量不足的问题是继续预训练里最值得花的功夫。fp16 在金融语料上通常没问题但如果你用的是老显卡建议先关掉跑一个 step 验证 loss 没有变成 NaN 再开。3. 抽取式问答的数据准备把财报切进 512 token 的窗口3.1 抽取式问答的数据形态start/end 标注是怎么对齐的FinBERT 做问答最自然的是抽取式问答。模型接收一个问题和一段上下文输出两个位置答案在上下文中的起始 token 和终止 token。训练数据的核心就是一个四元组问题文本、上下文文本、答案文本、答案在上下文里的起始字符偏移量。这个偏移量是标注工具给出的字符级别坐标必须精确落到上下文里。比如「公司实现营业收入 50.12 亿元同比增长 12.3%」答案「50.12 亿元」的起始偏移是 8从第 0 个字符数起。数字类答案最怕的就是偏移量差一个字符因为50.12 亿元和50.12亿元在偏移上会完全不同。训练时要把字符偏移转换成 token 偏移转换过程依赖 tokenizer 的 offset_mapping。这个映射记录了每个 token 对应原文本的字符区间有了它才能把字符级 start 安全地转换到 token 级 start。如果答案正好落在某个 token 的中间比如50.和12 亿被拆成两个 token处理逻辑是start 取第一个覆盖答案起始位置的 tokenend 取最后一个覆盖答案结束位置的 token。简单说就是前闭后闭确保答案区间不会少掉任何一个子 token。def build_qa_feature(question, context, answer_text, answer_start, tokenizer): enc tokenizer( question, context, max_length512, truncationonly_second, # 只截断上下文不截断问题 return_offsets_mappingTrue, paddingmax_length, ) offsets enc[offset_mapping] start_char, end_char answer_start, answer_start len(answer_text) start_tok end_tok None for i, (s, e) in enumerate(offsets): if s start_char e: start_tok i if s end_char e: end_tok i # 如果答案没有完整落在上下文中丢弃这条样本 if start_tok is None or end_tok is None: return None return { input_ids: enc[input_ids], attention_mask: enc[attention_mask], token_type_ids: enc[token_type_ids], start_positions: start_tok, end_positions: end_tok, }这里有两个容易出错的细节。第一truncationonly_second必须显式指定否则默认策略可能截断 question 而不是 context导致问题信息丢失。第二偏移量的比较用了s start_char e这是为了处理 start_char 正好落在两个 token 间隙的情况而 end 侧用s end_char e保证答案最后一个字符确实被 end token 覆盖。这样处理后还需要再检查一遍start_tok end_tok如果答案因为截断被切掉了尾部这条样本要直接丢弃而不是强行修正。3.2 金融长文档切分让答案完整落在一个窗口里BERT 的输入长度上限是 512 token而一份财报有几千字一份研报甚至上万字。切分策略直接决定答案能不能完整落在某个窗口里。如果按固定长度硬切很容易把答案从中间拦腰截断如果完全不切512 token 放不下长文档。我的做法是先在句子边界上切再保留窗口之间的重叠。重叠的意义在于答案可能跨句子出现比如「公司实现营业收入 50.12 亿元」这句话里答案从「营业收入」延伸到「50.12 亿元」中间隔着标点如果窗口间完全没有重叠这个跨句答案就会掉进缝隙里。重叠也不是越大越好。stride 设成 128意味着窗口之间保留了大约 1/4 的重叠同一个答案片段可能出现在两个训练样本里。这会让模型在预测时对重叠区域的 token 更「熟悉」但不会造成严重的过拟合因为问题文本是不同的模型需要结合问题来判断哪段文本才是答案。真正要避免的是把窗口切得太碎导致模型只能看到答案片段而看不到完整的上下文句这种情况模型会把局部文本误判成答案。def split_context_for_qa(document, tokenizer, max_len480, stride128): sentences split_sentences(document) # 按句末标点切分 windows, cur, cur_len [], [], 0 for sent in sentences: sent_len len(tokenizer.encode(sent)) if cur_len sent_len max_len and cur: windows.append(.join(cur)) # 从头部弹出句子直到剩余内容低于 max_len - stride while cur and cur_len max_len - stride: old cur.pop(0) cur_len - len(tokenizer.encode(old)) cur.append(sent) cur_len sent_len if cur: windows.append(.join(cur)) return windowsmax_len 设 480 而不是 512是为了给 CLS、SEP 以及问题文本留出空间。如果你的问题本身很长超过 64 token可以把 max_len 再调小一点保证 question context 拼接后不超过 512。按句子切分能最大程度保证窗口内语义完整代价是窗口长度不整齐但这在训练里完全不是问题padding 会统一长度。需要注意的是这里按句切分的逻辑和 2.2 节清理语料时的切分逻辑可以复用但切分粒度不同预训练语料需要句子作为独立样本问答的 context 需要保留原始标点和换行因为答案的字符偏移是按照原始文档计算的标点被改掉会让偏移量对不上。3.3 样本量策略几百条和几千条训练方式完全不一样金融问答标注成本高大多数团队实际能拿到的标注数据只有几百到几千条。样本量决定了你能走多远。如果只有几百条标注数据我建议只微调顶层或者干脆用 LoRA 之类的参数高效微调方法冻结大部分底层参数只训练少量新增参数学会问答映射。因为金融领域继续预训练已经让模型理解了领域语言问答能力本身是一个「任务技能」几百条样本足以让顶层学会 start/end 预测的基本模式但要小心过拟合。如果样本量到了几千条可以放开全参数微调但要把训练轮数控制住。金融文档模板化严重很多样本长得很像模型很容易记住模板而不是学会回答问题。我常用的策略是对问题做轻度增强把疑问句改写、把同义实体替换比如「营收」换成「营业收入」这样模型被迫去理解语义对齐而不是记住字面。一个容易被忽视的事实是抽取式问答对「答案不在上下文里」的情况天然不敏感标注数据里如果全是「有答案」的样本模型上线后遇到「没有答案」的问题就会硬挑一个片段。所以标注时一定要留出一部分「无答案」样本或者用答案置信度来兜底——这个我在最后一章会详细讲。4. 解锁 FinBERT 的问答能力训练闭环与三条调参主线4.1 为什么抽取式是金融问答的第一选择先明确一个选择标题里写的是「金融领域问答」BERT 类模型做问答有两种主流形态一种是 SQuAD 风格的抽取式问答输出答案是上下文里的一个连续片段另一种是生成式让模型自由组织语言输出答案。金融场景里绝大多数问题——「去年营收是多少」「研发费用占比是多少」「前五大客户集中度是多少」——答案都在原文里躺着抽取式模型天然适合。生成式模型虽然灵活但会在数字上出错而金融领域数字错了就是事故。我见过很多团队一上来就上生成式大模型理由是「抽取式太弱了不够智能」。但落到生产环境抽取式有三个不可替代的优势可解释性极强答案可以直接追溯到原文位置方便合规审计训练成本低几百条标注就能跑出可用效果推理快部署一台普通 GPU 就能扛住中等规模查询。生成式适合的金融场景是「总结一下这份研报的核心观点」这类开放题这类问题答案不唯一和「问答」是两个任务。如果你的需求确实是开放题可以做成两段式先抽取关键片段再让生成模型基于片段做总结不要把生成的担子全压在 BERT 上。4.2 用 BertForQuestionAnswering 跑通最小训练闭环确认走抽取式路线后训练闭环其实非常成熟。模型输出两个向量start_logits 和 end_logits长度都是序列长度。训练时对这两个向量分别计算交叉熵然后求和作为最终 loss。实际推理时把 start 和 end 两个概率相乘取乘积最大的区间作为答案。下面是最小可运行的训练脚本骨架可以直接替换成你的数据集。from transformers import BertForQuestionAnswering, AdamW # base_model 替换为 2.3 节继续预训练得到的 finbert-adapted 目录 model BertForQuestionAnswering.from_pretrained(finbert-adapted) optimizer AdamW(model.parameters(), lr3e-5) # train_dataset 中每个样本包含 # input_ids, attention_mask, token_type_ids, start_positions, end_positions model.train() for epoch in range(3): for batch in train_dataloader: outputs model(**batch) # outputs.loss 已包含 start_loss end_loss outputs.loss.backward() optimizer.step() optimizer.zero_grad() # 每 200 步记录一次 loss观察是否下降这段脚本里token_type_ids容易被新手遗漏。BERT 在问答任务里用两个 segment第一个 segment 放问题第二个 segment 放上下文。token_type_ids 告诉模型哪些 token 属于问题、哪些属于上下文这是问答任务里非常重要的信号。如果你用的框架在 tokenizer 返回时没有包含 token_type_ids一定要手动构造问题部分全 0上下文部分全 1。训练时也不要把两个 segment 的顺序搞反模型对「哪边是问题、哪边是上下文」是有强先验的一旦反了效果会断崖式下跌。微调的超参范围其实很窄我建议在一个小验证集上多试几组重点看三组参数学习率、训练轮数、batch size。有一个经验值是金融数据集越小学习率越要保守。几百条数据时用 2e-5几千条数据时可以用到 3e-5 到 4e-5。batch size 方面QA 任务对 batch size 的敏感度中等16 和 32 差距不大但不要小于 8否则梯度噪声太大会让训练不稳定。参数建议值说明learning_rate2e-5 ~ 5e-5越小越稳越小越慢num_train_epochs2 ~ 4样本少取大样本多取小train_batch_size16 ~ 32显存不够时用梯度累积max_seq_length512长文本靠切分不靠增长doc_stride128控制窗口重叠率4.3 三条调参主线lr、doc_stride、max_seq_length第一条主线是学习率。很多翻车案例是学习率设太高模型在第三个 epoch 后 start/end 预测逐渐偏离正确答案表现为验证 F1 先升后崩。如果你观察到这个现象先把学习率降到 2e-5再跑一遍。第二条主线是 doc_stride。这个参数控制相邻窗口的重叠程度直接影响模型能看到多少「跨句上下文」。stride 太小答案落在窗口边界的情况增加stride 太大同一段文本反复出现在多个窗口里模型训练时对这段文本过拟合。我一般让 stride 是 max_seq_length 的 1/4 左右也就是 128。第三条主线是 max_seq_length。别贪心512 是上限但不是每段文本都要撑到 512。短文本截断到实际长度可以减少 padding 带来的无效计算长文本按 3.2 节的逻辑切分即可强行塞进 512 只会让模型忽略后半段内容。这里有个容易被忽视的关联如果 doc_stride 设得小、窗口数量多一个长文档会被切成十几个样本同一个答案片段可能在两个窗口里都出现但标注答案只来自原始文档的偏移量。你需要在构造样本时保证只有一个窗口包含完整答案其他窗口要么切掉了答案头部要么切掉了答案尾部不能出现同一答案在多个窗口里都是完整的。否则模型会学会「看到相似上下文就输出相似位置」而不是真正理解问题。5. 避坑金融问答训练中最容易翻车的五个场景5.1 答案总被切成半截span 标注与切分窗口不对齐现象模型输出的答案经常差最后一个字比如「50.12 亿」少了「元」或者「同比增长 12.3」少了「%」。原因有两个一是构建训练样本时 end token 计算用了前闭后开导致最后一个字符没有被 end token 覆盖二是切分窗口时答案恰好被截断但样本没有被丢弃模型学了「半个答案」的错误样本。解决训练样本构造时必须用前闭后闭的 token 区间并且对每条样本检查答案是否完整落在窗口内不完整就直接丢弃。这个检查不能省尤其当文档切分逻辑调整后一定要重新跑一遍样本统计看看有多少样本被丢弃了。5.2 模型对数字不敏感F1 高但金额抄错现象验证集 F1 超过 80%但抽样看结果凡是涉及数字的答案经常差一位数或者小数点位置错位。原因数字在 BERT 的 tokenizer 里经常被拆成多个 token比如50.12可能被拆成50、.、12模型对单个数字 token 的注意力不够集中。解决tokenize 之后专门检查数字类答案的 token 跨度如果一个答案被拆成太多 token可以在损失函数里对数字 token 的预测错误加大权重或者在标注阶段把数字类答案统一清洗成规范格式。另外评估指标不要只看 F1要单独统计「数字完全正确」的比例这个指标才是金融场景真正关心的。5.3 无答案问题被硬答模型学会了「不管怎样都要输出一段」现象用户问「公司去年有没有重大诉讼」文档里根本没有相关信息模型却从上下文里挑出一段「公司不存在重大诉讼」或者完全无关的营收描述。原因训练数据里没有无答案样本模型从未见过「CLS 位置代表无答案」这种输出模式。解决在标注数据里加入 5% 到 10% 的无答案样本用 CLS token 的输出作为无答案判断。具体做法是把 start 和 end 都指向 CLS token模型会学会在「没有答案」时给出低置信度的 CLS 位置预测。上线时再配合置信度阈值拦截效果会好很多。5.4 领域继续预训练后下游效果反而变差灾难性遗忘现象继续预训练后的模型拿去微调问答效果还不如直接用通用 BERT 微调。原因继续预训练时学习率太高或者轮数太多模型在金融语料上过度拟合把通用语言知识覆盖掉了。这是一个非常反直觉但高频出现的坑。解决继续预训练阶段每跑完一个 epoch就在下游问答任务上快速验证一次如果发现问答指标不再提升甚至下降立即停止训练并回退到上一个 checkpoint。不要迷信「预训练一定有用」继续预训练的正确打开方式是带着下游任务一起验证。5.5 样本增强反而让模型更差模板化增强的副作用现象对训练数据做同义词替换增强后模型 F1 反而下降。原因金融文本里「营收」「营业收入」这类同义词替换看似无害但财报里「营业收入」是一个会计科目和「营收」在正式语境下指向相同在另一些语境下可能范围不同。无脑替换会破坏模型学到的精确语义边界。解决做增强前先做一个简单测试——把原始样本里的同义词替换掉人工看一遍模型在验证集上的表现是否稳定。如果增强带来的是噪声而不是多样性就缩小替换范围只对问题做改写不动上下文里的关键术语。6. 落地前的一个硬核技巧给答案加置信度校验与长度拦截模型训练完并不等于可以上线。金融问答最怕的不是答错而是答错的时候还显得很有信心。我建议在推理层加一道置信度拦截把 start_logits 和 end_logits 分别过 softmax 变成概率然后对每个合法的 start end 区间计算联合概率同时限制答案最大长度。只有联合概率超过阈值的答案才返回给用户否则返回「未找到可靠答案」。这个拦截能让低质量预测在到达用户之前就被挡下来是投入生产前性价比最高的一步。import torch def extract_answer_with_confidence(model, tokenizer, question, context, max_answer_len30): inputs tokenizer(question, context, return_tensorspt) with torch.no_grad(): outputs model(**inputs) start_logits, end_logits outputs.start_logits, outputs.end_logits start_prob torch.softmax(start_logits, dim-1) end_prob torch.softmax(end_logits, dim-1) # scores[i][j] 答案从 i 开始、到 j 结束的联合概率 scores start_prob.unsqueeze(-1) * end_prob.unsqueeze(-2) # 约束1start end mask torch.triu(torch.ones_like(scores), diagonal0) # 约束2答案长度不超过 max_answer_len mask torch.tril(mask, diagonalmax_answer_len) scores scores.masked_fill(mask 0, -1e9) best scores.argmax().item() start_tok best // scores.shape[-1] end_tok best % scores.shape[-1] confidence scores.reshape(-1)[scores.reshape(-1).argmax()].item() answer tokenizer.decode(inputs[input_ids][0][start_tok:end_tok 1]) return answer, confidence, start_tok, end_tok这段代码使用了两个矩阵约束triu保证起始位置不晚于结束位置tril限制答案长度不超过 30 个 token。这两个约束能过滤掉大量「从文章开头跨到结尾」的离谱答案。阈值怎么定我建议拿一批真实用户问题跑一遍画出置信度和答案正确率的分布曲线通常会在 0.3 到 0.6 之间找到一个拐点。低于拐点的答案宁可让用户重新提问也不要硬答。上线后还要持续监控平均置信度——如果某天平均置信度突然下降很可能是文档切分逻辑改了或者数据分布变了。我现在的习惯是任何金融问答模型上线前都要过一遍这道置信度关卡再配合人工抽检。这一关看着简单却是我踩了无数次「答错但自信」的坑之后才沉淀下来的经验。希望帮到你。本文还有配套的精品资源点击获取
简介面向金融领域问答与信息检索研究者的 FinBERT-QA 完整实现包,针对 FiQA 数据集任务2,解决从金融段落中检索候选答案并重排序的问题。系统使用 Lucene 检索前50个候选,再以预训练 BERT 微调后重排,在 nDCG、MRR、Precision 三项指标上平均提升约20%;模型基于 Huggingface 库完成从 TensorFlow 到 PyTorch 的转换与迁移,步骤可供迁移学习参考。压缩包共62个文件,大小142.71MB,以 pickle 数据/模型、py 训练推理脚本、tsv 语料、ipynb 分析笔记为主,另含 Dockerfile、sh 索引构建脚本、requirements.txt 等,便于复现环境。代码覆盖数据生成、模型微调、预测、评估全流程,配有 retriever 索引与两大 notebook 分析,并提供 data/raw、id_to_text、qa_lstm_tokenizer、rank、data_pickle 等中间产物,还附 README 与 Dockerfile 环境说明,目录结构清晰。已有2089人学习,适合自然语言处理、信息检索方向学生与金融科技从业者深入理解预训练模型在金融领域段落重排中的实际应用,可直接在本地复现实验效果。1. 金融问答的拦路虎是预训练阶段留下的「语言代沟」先讲一个我实际踩过的坑做财报问答原型时直接把通用中文 BERT 接进来拿公开问答数据微调了一轮就以为能上生产。结果模型在「报告期营收同比增长了多少」这种问题上开始吞吞吐吐要么答成年份要么从研报里扯出一段不相干的话。问题不在微调在预训练——通用 BERT 学的是维基、网页、书籍里的语言分布而金融文本里有大量「扣非净利润」「递延所得税负债」「归母营收增速」这样的术语组合通用模型对这些词的上下文语义是模糊的。FinBERT-QA 的核心就是先把预训练这一步从通用语料拉到金融语料上让 BERT 真正「读得懂」财报和研报再去做问答。这篇文章我会从领域继续预训练、标注数据构造、切分策略、微调闭环、典型翻车点到最后的置信度拦截完整讲一遍可以照做的方案适合手里有金融文档、想自己搭问答能力的开发团队。2. FinBERT 的领域预训练为什么先让模型「读懂」财报再谈问答2.1 通用 BERT 和金融文本的「语言代沟」BERT 这类预训练语言模型本质上是在大规模文本上做掩码预测学到的是词与词之间的共现规律。通用语料里出现过「净利润增速」但没怎么出现过「归母净利润增速」这种财报高频表达。你把一个句子里的词随机 mask 掉让模型猜原文通用模型给出的候选词往往是常识语义候选而金融语料里正确的候选是「同比」「环比」「符合预期」这类带着财报口吻的表达。这个差距不是换个任务结构能弥补的。问答任务里模型需要判断「问题中的实体」与「上下文中的实体」是否指向同一件事这依赖预训练阶段建立的语义关联。金融文档里同一个公司名可能出现在公告、研报、新闻三种文体里指代方式完全不同通用模型很难把这些表达串起来。所以 FinBERT 的思路很直接用金融语料继续做掩码语言模型训练让参数往金融语境的方向再走一段。这一步在工业界通常叫领域继续预训练或者叫 DAPT做法和 BERT 原始预训练完全一致只是换掉训练语料。需要注意的是继续预训练不是简单地拿金融文本跑一遍就行。语料清洗、长度配比、学习率、训练轮数都对最终下游效果有影响而且这些参数之间互相牵制。下面我先给出一个可复用的语料清洗脚本再讲训练参数怎么定。2.2 领域语料清洗从财报公告到 MLM 输入继续预训练的第一步是拿到干净的金融语料。我一般会从三个来源收集上市公司公告、券商研报正文、财经新闻。这三个来源的写作风格差异很大公告里套话多研报里分析句多新闻里口语化表达多一些混在一起能避免模型只学会一种文体。清洗时重点做四件事去标签、统一全角半角、按句切分、去重和过滤太短的片段。import re import html import unicodedata def clean_financial_text(text: str) - list[str]: # 去除 HTML / XML 标签公告和研报经常带格式标记 text re.sub(r[^], , text) # 反转义常见实体例如 amp; 转回 text html.unescape(text) # 统一全角半角数字和百分号尤其重要 text unicodedata.normalize(NFKC, text) # 按中文句末标点切句保留引号内部完整句子 segments re.split(r(?[。;])\s*, text) # 过滤过短片段、纯数字行、纯表格噪声 segments [s.strip() for s in segments if 8 len(s.strip()) 512 and not re.fullmatch(r[\d\s%.\-—], s.strip())] return segments # 使用示例遍历原始文件逐段写入训练语料 raw_folder corpus/raw out_file corpus/fin_pretrain.txt with open(out_file, w, encodingutf-8) as f: for path in list_raw_files(raw_folder): for seg in clean_financial_text(read_file(path)): f.write(seg \n)为什么按句切而不是直接按段落切因为 MLM 训练是按固定长度窗口采样的如果语料里一个段落长达几千字采样时会从段落中间截断导致大量半句话。按句切完后每行是一个完整句模型每次采样都能拿到语义完整的样本。长度过滤下限设 8 个字符是为了把「营收增长」「净利润下降」这类短句也保留下来这类短句恰恰是财报里最常见的判断句式上限设 512 是为了之后切块不浪费太多 token。全角半角统一这里要特别留意因为后续标注答案的 start 偏移量是按字符数算的全角半角混用会让偏移量对不上这是很隐蔽的坑。2.3 继续预训练的三个参数纪律先短后长、小步验证、语料去重训练脚本本身不复杂关键是三个参数纪律。第一先短后长。先用 128 token 的窗口训练一个 epoch 验证语料质量和 loss 走势再把窗口拉到 512 做正式训练。短窗口收敛快、显存占用小适合排查语料里的脏数据长窗口能建模跨句依赖但对显存要求高。第二学习率要克制。继续预训练一般用 5e-5 到 1e-4 之间的学习率比微调阶段的 2e-5 到 3e-5 略大但不要直接上 1e-4 以上否则模型会在金融语料上「失忆」把通用语料学到的知识冲掉。第三语料一定要去重。很多公开的财经文本集里重复内容严重同一个新闻被转载几十次不去重的话模型会在重复文本上过拟合loss 看起来降得很快但下游问答一点不涨。我习惯把清洗好的语料先做一个全局去重再用 MinHash 做近似去重把转载改写的版本也去掉。这一步不做的话后面所有训练都可能建在虚假的收敛之上。训练轮数方面语料量大比如超过几千万句的时候跑 1 个 epoch 就够语料量小几百万句以内可以跑 3 个 epoch但必须同时监控一个下游任务的指标变化而不是只看 MLM loss。只看 MLM loss 很容易陷入「自欺欺人」的境地——loss 在降问答 F1 却在掉这在继续预训练里非常常见。from transformers import Trainer, TrainingArguments model BertForMaskedLM.from_pretrained(bert-base-chinese) # 换成你的基础模型 args TrainingArguments( output_dirfinbert-adapted, per_device_train_batch_size32, learning_rate5e-5, warmup_ratio0.1, num_train_epochs3, save_strategyepoch, logging_steps200, fp16True, # 显存允许就开训练速度提升明显 ) trainer Trainer( modelmodel, argsargs, train_datasetmlm_dataset, ) trainer.train()这段代码里的 mlm_dataset 需要预先对语料做 tokenize 和动态掩码。动态掩码的意思是每个 epoch 重新随机 mask 不同的 token而不是在数据集构造时固定 mask 位置。这样能有效缓解数据量不足的问题是继续预训练里最值得花的功夫。fp16 在金融语料上通常没问题但如果你用的是老显卡建议先关掉跑一个 step 验证 loss 没有变成 NaN 再开。3. 抽取式问答的数据准备把财报切进 512 token 的窗口3.1 抽取式问答的数据形态start/end 标注是怎么对齐的FinBERT 做问答最自然的是抽取式问答。模型接收一个问题和一段上下文输出两个位置答案在上下文中的起始 token 和终止 token。训练数据的核心就是一个四元组问题文本、上下文文本、答案文本、答案在上下文里的起始字符偏移量。这个偏移量是标注工具给出的字符级别坐标必须精确落到上下文里。比如「公司实现营业收入 50.12 亿元同比增长 12.3%」答案「50.12 亿元」的起始偏移是 8从第 0 个字符数起。数字类答案最怕的就是偏移量差一个字符因为50.12 亿元和50.12亿元在偏移上会完全不同。训练时要把字符偏移转换成 token 偏移转换过程依赖 tokenizer 的 offset_mapping。这个映射记录了每个 token 对应原文本的字符区间有了它才能把字符级 start 安全地转换到 token 级 start。如果答案正好落在某个 token 的中间比如50.和12 亿被拆成两个 token处理逻辑是start 取第一个覆盖答案起始位置的 tokenend 取最后一个覆盖答案结束位置的 token。简单说就是前闭后闭确保答案区间不会少掉任何一个子 token。def build_qa_feature(question, context, answer_text, answer_start, tokenizer): enc tokenizer( question, context, max_length512, truncationonly_second, # 只截断上下文不截断问题 return_offsets_mappingTrue, paddingmax_length, ) offsets enc[offset_mapping] start_char, end_char answer_start, answer_start len(answer_text) start_tok end_tok None for i, (s, e) in enumerate(offsets): if s start_char e: start_tok i if s end_char e: end_tok i # 如果答案没有完整落在上下文中丢弃这条样本 if start_tok is None or end_tok is None: return None return { input_ids: enc[input_ids], attention_mask: enc[attention_mask], token_type_ids: enc[token_type_ids], start_positions: start_tok, end_positions: end_tok, }这里有两个容易出错的细节。第一truncationonly_second必须显式指定否则默认策略可能截断 question 而不是 context导致问题信息丢失。第二偏移量的比较用了s start_char e这是为了处理 start_char 正好落在两个 token 间隙的情况而 end 侧用s end_char e保证答案最后一个字符确实被 end token 覆盖。这样处理后还需要再检查一遍start_tok end_tok如果答案因为截断被切掉了尾部这条样本要直接丢弃而不是强行修正。3.2 金融长文档切分让答案完整落在一个窗口里BERT 的输入长度上限是 512 token而一份财报有几千字一份研报甚至上万字。切分策略直接决定答案能不能完整落在某个窗口里。如果按固定长度硬切很容易把答案从中间拦腰截断如果完全不切512 token 放不下长文档。我的做法是先在句子边界上切再保留窗口之间的重叠。重叠的意义在于答案可能跨句子出现比如「公司实现营业收入 50.12 亿元」这句话里答案从「营业收入」延伸到「50.12 亿元」中间隔着标点如果窗口间完全没有重叠这个跨句答案就会掉进缝隙里。重叠也不是越大越好。stride 设成 128意味着窗口之间保留了大约 1/4 的重叠同一个答案片段可能出现在两个训练样本里。这会让模型在预测时对重叠区域的 token 更「熟悉」但不会造成严重的过拟合因为问题文本是不同的模型需要结合问题来判断哪段文本才是答案。真正要避免的是把窗口切得太碎导致模型只能看到答案片段而看不到完整的上下文句这种情况模型会把局部文本误判成答案。def split_context_for_qa(document, tokenizer, max_len480, stride128): sentences split_sentences(document) # 按句末标点切分 windows, cur, cur_len [], [], 0 for sent in sentences: sent_len len(tokenizer.encode(sent)) if cur_len sent_len max_len and cur: windows.append(.join(cur)) # 从头部弹出句子直到剩余内容低于 max_len - stride while cur and cur_len max_len - stride: old cur.pop(0) cur_len - len(tokenizer.encode(old)) cur.append(sent) cur_len sent_len if cur: windows.append(.join(cur)) return windowsmax_len 设 480 而不是 512是为了给 CLS、SEP 以及问题文本留出空间。如果你的问题本身很长超过 64 token可以把 max_len 再调小一点保证 question context 拼接后不超过 512。按句子切分能最大程度保证窗口内语义完整代价是窗口长度不整齐但这在训练里完全不是问题padding 会统一长度。需要注意的是这里按句切分的逻辑和 2.2 节清理语料时的切分逻辑可以复用但切分粒度不同预训练语料需要句子作为独立样本问答的 context 需要保留原始标点和换行因为答案的字符偏移是按照原始文档计算的标点被改掉会让偏移量对不上。3.3 样本量策略几百条和几千条训练方式完全不一样金融问答标注成本高大多数团队实际能拿到的标注数据只有几百到几千条。样本量决定了你能走多远。如果只有几百条标注数据我建议只微调顶层或者干脆用 LoRA 之类的参数高效微调方法冻结大部分底层参数只训练少量新增参数学会问答映射。因为金融领域继续预训练已经让模型理解了领域语言问答能力本身是一个「任务技能」几百条样本足以让顶层学会 start/end 预测的基本模式但要小心过拟合。如果样本量到了几千条可以放开全参数微调但要把训练轮数控制住。金融文档模板化严重很多样本长得很像模型很容易记住模板而不是学会回答问题。我常用的策略是对问题做轻度增强把疑问句改写、把同义实体替换比如「营收」换成「营业收入」这样模型被迫去理解语义对齐而不是记住字面。一个容易被忽视的事实是抽取式问答对「答案不在上下文里」的情况天然不敏感标注数据里如果全是「有答案」的样本模型上线后遇到「没有答案」的问题就会硬挑一个片段。所以标注时一定要留出一部分「无答案」样本或者用答案置信度来兜底——这个我在最后一章会详细讲。4. 解锁 FinBERT 的问答能力训练闭环与三条调参主线4.1 为什么抽取式是金融问答的第一选择先明确一个选择标题里写的是「金融领域问答」BERT 类模型做问答有两种主流形态一种是 SQuAD 风格的抽取式问答输出答案是上下文里的一个连续片段另一种是生成式让模型自由组织语言输出答案。金融场景里绝大多数问题——「去年营收是多少」「研发费用占比是多少」「前五大客户集中度是多少」——答案都在原文里躺着抽取式模型天然适合。生成式模型虽然灵活但会在数字上出错而金融领域数字错了就是事故。我见过很多团队一上来就上生成式大模型理由是「抽取式太弱了不够智能」。但落到生产环境抽取式有三个不可替代的优势可解释性极强答案可以直接追溯到原文位置方便合规审计训练成本低几百条标注就能跑出可用效果推理快部署一台普通 GPU 就能扛住中等规模查询。生成式适合的金融场景是「总结一下这份研报的核心观点」这类开放题这类问题答案不唯一和「问答」是两个任务。如果你的需求确实是开放题可以做成两段式先抽取关键片段再让生成模型基于片段做总结不要把生成的担子全压在 BERT 上。4.2 用 BertForQuestionAnswering 跑通最小训练闭环确认走抽取式路线后训练闭环其实非常成熟。模型输出两个向量start_logits 和 end_logits长度都是序列长度。训练时对这两个向量分别计算交叉熵然后求和作为最终 loss。实际推理时把 start 和 end 两个概率相乘取乘积最大的区间作为答案。下面是最小可运行的训练脚本骨架可以直接替换成你的数据集。from transformers import BertForQuestionAnswering, AdamW # base_model 替换为 2.3 节继续预训练得到的 finbert-adapted 目录 model BertForQuestionAnswering.from_pretrained(finbert-adapted) optimizer AdamW(model.parameters(), lr3e-5) # train_dataset 中每个样本包含 # input_ids, attention_mask, token_type_ids, start_positions, end_positions model.train() for epoch in range(3): for batch in train_dataloader: outputs model(**batch) # outputs.loss 已包含 start_loss end_loss outputs.loss.backward() optimizer.step() optimizer.zero_grad() # 每 200 步记录一次 loss观察是否下降这段脚本里token_type_ids容易被新手遗漏。BERT 在问答任务里用两个 segment第一个 segment 放问题第二个 segment 放上下文。token_type_ids 告诉模型哪些 token 属于问题、哪些属于上下文这是问答任务里非常重要的信号。如果你用的框架在 tokenizer 返回时没有包含 token_type_ids一定要手动构造问题部分全 0上下文部分全 1。训练时也不要把两个 segment 的顺序搞反模型对「哪边是问题、哪边是上下文」是有强先验的一旦反了效果会断崖式下跌。微调的超参范围其实很窄我建议在一个小验证集上多试几组重点看三组参数学习率、训练轮数、batch size。有一个经验值是金融数据集越小学习率越要保守。几百条数据时用 2e-5几千条数据时可以用到 3e-5 到 4e-5。batch size 方面QA 任务对 batch size 的敏感度中等16 和 32 差距不大但不要小于 8否则梯度噪声太大会让训练不稳定。参数建议值说明learning_rate2e-5 ~ 5e-5越小越稳越小越慢num_train_epochs2 ~ 4样本少取大样本多取小train_batch_size16 ~ 32显存不够时用梯度累积max_seq_length512长文本靠切分不靠增长doc_stride128控制窗口重叠率4.3 三条调参主线lr、doc_stride、max_seq_length第一条主线是学习率。很多翻车案例是学习率设太高模型在第三个 epoch 后 start/end 预测逐渐偏离正确答案表现为验证 F1 先升后崩。如果你观察到这个现象先把学习率降到 2e-5再跑一遍。第二条主线是 doc_stride。这个参数控制相邻窗口的重叠程度直接影响模型能看到多少「跨句上下文」。stride 太小答案落在窗口边界的情况增加stride 太大同一段文本反复出现在多个窗口里模型训练时对这段文本过拟合。我一般让 stride 是 max_seq_length 的 1/4 左右也就是 128。第三条主线是 max_seq_length。别贪心512 是上限但不是每段文本都要撑到 512。短文本截断到实际长度可以减少 padding 带来的无效计算长文本按 3.2 节的逻辑切分即可强行塞进 512 只会让模型忽略后半段内容。这里有个容易被忽视的关联如果 doc_stride 设得小、窗口数量多一个长文档会被切成十几个样本同一个答案片段可能在两个窗口里都出现但标注答案只来自原始文档的偏移量。你需要在构造样本时保证只有一个窗口包含完整答案其他窗口要么切掉了答案头部要么切掉了答案尾部不能出现同一答案在多个窗口里都是完整的。否则模型会学会「看到相似上下文就输出相似位置」而不是真正理解问题。5. 避坑金融问答训练中最容易翻车的五个场景5.1 答案总被切成半截span 标注与切分窗口不对齐现象模型输出的答案经常差最后一个字比如「50.12 亿」少了「元」或者「同比增长 12.3」少了「%」。原因有两个一是构建训练样本时 end token 计算用了前闭后开导致最后一个字符没有被 end token 覆盖二是切分窗口时答案恰好被截断但样本没有被丢弃模型学了「半个答案」的错误样本。解决训练样本构造时必须用前闭后闭的 token 区间并且对每条样本检查答案是否完整落在窗口内不完整就直接丢弃。这个检查不能省尤其当文档切分逻辑调整后一定要重新跑一遍样本统计看看有多少样本被丢弃了。5.2 模型对数字不敏感F1 高但金额抄错现象验证集 F1 超过 80%但抽样看结果凡是涉及数字的答案经常差一位数或者小数点位置错位。原因数字在 BERT 的 tokenizer 里经常被拆成多个 token比如50.12可能被拆成50、.、12模型对单个数字 token 的注意力不够集中。解决tokenize 之后专门检查数字类答案的 token 跨度如果一个答案被拆成太多 token可以在损失函数里对数字 token 的预测错误加大权重或者在标注阶段把数字类答案统一清洗成规范格式。另外评估指标不要只看 F1要单独统计「数字完全正确」的比例这个指标才是金融场景真正关心的。5.3 无答案问题被硬答模型学会了「不管怎样都要输出一段」现象用户问「公司去年有没有重大诉讼」文档里根本没有相关信息模型却从上下文里挑出一段「公司不存在重大诉讼」或者完全无关的营收描述。原因训练数据里没有无答案样本模型从未见过「CLS 位置代表无答案」这种输出模式。解决在标注数据里加入 5% 到 10% 的无答案样本用 CLS token 的输出作为无答案判断。具体做法是把 start 和 end 都指向 CLS token模型会学会在「没有答案」时给出低置信度的 CLS 位置预测。上线时再配合置信度阈值拦截效果会好很多。5.4 领域继续预训练后下游效果反而变差灾难性遗忘现象继续预训练后的模型拿去微调问答效果还不如直接用通用 BERT 微调。原因继续预训练时学习率太高或者轮数太多模型在金融语料上过度拟合把通用语言知识覆盖掉了。这是一个非常反直觉但高频出现的坑。解决继续预训练阶段每跑完一个 epoch就在下游问答任务上快速验证一次如果发现问答指标不再提升甚至下降立即停止训练并回退到上一个 checkpoint。不要迷信「预训练一定有用」继续预训练的正确打开方式是带着下游任务一起验证。5.5 样本增强反而让模型更差模板化增强的副作用现象对训练数据做同义词替换增强后模型 F1 反而下降。原因金融文本里「营收」「营业收入」这类同义词替换看似无害但财报里「营业收入」是一个会计科目和「营收」在正式语境下指向相同在另一些语境下可能范围不同。无脑替换会破坏模型学到的精确语义边界。解决做增强前先做一个简单测试——把原始样本里的同义词替换掉人工看一遍模型在验证集上的表现是否稳定。如果增强带来的是噪声而不是多样性就缩小替换范围只对问题做改写不动上下文里的关键术语。6. 落地前的一个硬核技巧给答案加置信度校验与长度拦截模型训练完并不等于可以上线。金融问答最怕的不是答错而是答错的时候还显得很有信心。我建议在推理层加一道置信度拦截把 start_logits 和 end_logits 分别过 softmax 变成概率然后对每个合法的 start end 区间计算联合概率同时限制答案最大长度。只有联合概率超过阈值的答案才返回给用户否则返回「未找到可靠答案」。这个拦截能让低质量预测在到达用户之前就被挡下来是投入生产前性价比最高的一步。import torch def extract_answer_with_confidence(model, tokenizer, question, context, max_answer_len30): inputs tokenizer(question, context, return_tensorspt) with torch.no_grad(): outputs model(**inputs) start_logits, end_logits outputs.start_logits, outputs.end_logits start_prob torch.softmax(start_logits, dim-1) end_prob torch.softmax(end_logits, dim-1) # scores[i][j] 答案从 i 开始、到 j 结束的联合概率 scores start_prob.unsqueeze(-1) * end_prob.unsqueeze(-2) # 约束1start end mask torch.triu(torch.ones_like(scores), diagonal0) # 约束2答案长度不超过 max_answer_len mask torch.tril(mask, diagonalmax_answer_len) scores scores.masked_fill(mask 0, -1e9) best scores.argmax().item() start_tok best // scores.shape[-1] end_tok best % scores.shape[-1] confidence scores.reshape(-1)[scores.reshape(-1).argmax()].item() answer tokenizer.decode(inputs[input_ids][0][start_tok:end_tok 1]) return answer, confidence, start_tok, end_tok这段代码使用了两个矩阵约束triu保证起始位置不晚于结束位置tril限制答案长度不超过 30 个 token。这两个约束能过滤掉大量「从文章开头跨到结尾」的离谱答案。阈值怎么定我建议拿一批真实用户问题跑一遍画出置信度和答案正确率的分布曲线通常会在 0.3 到 0.6 之间找到一个拐点。低于拐点的答案宁可让用户重新提问也不要硬答。上线后还要持续监控平均置信度——如果某天平均置信度突然下降很可能是文档切分逻辑改了或者数据分布变了。我现在的习惯是任何金融问答模型上线前都要过一遍这道置信度关卡再配合人工抽检。这一关看着简单却是我踩了无数次「答错但自信」的坑之后才沉淀下来的经验。希望帮到你。本文还有配套的精品资源点击获取
