企业官网建设流程全解析

简介：面向金融场景的中文金融大语言模型（LLM）资源包，将语言模型、人工智能与大模型技术融合，定位为金融智能咨询服务的开发与学习基线，适合算法工程师、金融科技研究者及对金融自然语言处理感兴趣的开发者。包体共18个文件，整体约408KB，包含7个Python脚本、6个JSON数据文件、3个Markdown文档，以及txt说明和license文件；脚本可支撑命令行或Web交互，JSON数据覆盖计算、检索、任务等模块，文档则用于说明环境与评估流程。资源内提供可直接启动的cli_demo与web_demo，并包含计算评测、检索评测等数据集，便于读者对照理解金融大模型的数据组织方式、检索增强思路和效果验证方法；目录结构简洁，能帮助快速定位各功能模块。已有242人学习下载，适合希望快速上手中文金融大模型搭建、应用与评测的入门到中级开发者。

1. 金融大语言模型的本质不是“更懂金融”，而是“更少胡说”

把通用大模型直接丢给金融用户，得到的往往是流畅但危险的幻觉。金融场景对错误的容忍度极低：一个错误的保险条款解读、一次基于过期财报的投资建议，都可能造成真金白银的损失。中文金融大语言模型要解决的，恰恰是通用模型在专业术语、数字精度、合规边界上的失控问题。它不是一个“读过更多金融文档”的模型，而是一个在预训练、指令微调、知识注入和推理约束上都针对金融语料重新校准过的专用系统。

这篇文章的目标读者是正在做技术选型或已经进入垂域LLM落地阶段的工程师。我们不讨论“金融大模型有多重要”，只讨论一条可执行的路径：金融数据的特殊性在哪里，领域模型怎么训练，知识库怎么接，以及评估怎么做到可信。适合手里有GPU资源或者云预算，想在Qwen、Baichuan等底座上构建金融问答、投研分析或合规助手的人。你不需要从零预训练，但你需要知道垂域LLM的数据准备和训练配置到底长什么样。

2. 金融LLM的数据底座：从语料清洗到损失函数设计

2.1 金融语料和通用语料的三个本质差异

金融文本的表层特征很明确：数字密度高、术语稠密、时间敏感性强、逻辑链条长。但真正影响模型行为的是更深层的差异。

第一是数字一致性。通用语料里“增长了50%”和“增长了50个百分点”经常混用，模型学到的只是模糊的语义关联。金融语料必须把数值型表述变成可计算的逻辑单元。比如“净利润同比增长12.3%至45.6亿元”，模型需要区分这是环比还是同比、是金额还是比率、单位是元还是万元。我们自建预处理pipeline时，会专门维护一个数值归一化模块，把所有中文金额表述（万/亿/万亿）转成统一数值token，并在文本中保留原始表述供生成时恢复。

第二是时效性衰减。2020年的财经新闻和2024年的财经新闻，对当前投资决策的意义完全不同。通用语料没有时间权重概念，但金融模型的训练样本必须做时间衰减加权。常见做法是按日期窗格采样：近6个月的数据过采样3倍，近1-2年的数据正常采样，2年以上的数据降权至0.3。这个系数不是拍脑袋定的，而是根据验证集上的事实准确率调出来的。

第三是因果逻辑密度。招股书、研报、审计意见里充满“因为A所以B，但C条件下D不成立”的复杂句式。普通模型倾向于把这种表述压缩成“A导致B”的简化关联。我们会在数据准备阶段用规则加人工复核的方式，把带转折、条件、例外从句的句子单独抽出来，扩充到训练集里，比例控制在10%-15%。

2.2 SFT数据的构造：让模型学会“不答”比“答对”更难

指令微调阶段，金融模型和通用模型最大的区别在拒答样本。金融合规要求决定了模型必须能识别自己不知道的事情，而不是用概率最高的token硬编一个答案。

我们构造SFT数据时，每个问题至少包含三类响应：标准回答、带免责声明的回答、明确拒答。拒答不是简单说“我不知道”，而是给出可操作的替代路径。例如用户问“XX股票明天会涨吗”，标准拒答模板是“我无法预测个股短期价格走势。我可以帮你分析这家公司最近三个季度的财务数据，或者对比同行业公司的估值水平”。

数据比例上，金融领域建议按以下分布走：单轮知识问答40%（财报解读、术语解释、政策条文）、多轮对话追踪20%（用户连续追问同一家公司的不同指标）、数字计算与比较15%（要求模型做加减乘除和单位换算）、长文档理解10%（从招股书或财报中抽取指定信息）、拒答与边界测试15%。这个比例来自实际调参经验，拒答比例低于10%时，模型在合规测试集上的通过率会明显下降。

代码层面，SFT数据的格式化是常见坑点。以下是一个数据清洗和格式化的最小脚本，用来从原始抓取文本生成统一训练格式：

import json import re from datetime import datetime def clean_financial_text(raw: str) -> str: # 去掉HTML标签和乱码 text = re.sub(r'<[^>]+>', '', raw) # 统一全角数字为半角 text = text.replace('０', '0').replace('１', '1').replace('２', '2') # 金额单位归一化：万亿/亿/万统一为阿拉伯数字+单位 text = re.sub(r'(\d+)\s*万亿元', r'\1万亿', text) text = re.sub(r'(\d+)\s*亿元', r'\1亿', text) # 去掉连续空白 text = re.sub(r'\s+', ' ', text).strip() return text def format_sft_entry(question: str, answer: str, source: str, date: str): entry = { "instruction": clean_financial_text(question), "output": clean_financial_text(answer), "metadata": { "source": source, # 例如：annual_report_2023 "doc_date": date, # 例如：2024-03-28 "time_weight": 1.0 # 训练采样时动态调整 } } return entry # 示例：把一篇公司公告的问答对格式化 sample = format_sft_entry( question="公司2023年度的研发投入占比是多少？", answer="根据2023年年度报告，公司研发投入为12.6亿元，占营业收入的比例为8.7%，较上年同期提升1.2个百分点。", source="annual_report_2023", date="2024-03-28" ) print(json.dumps(sample, ensure_ascii=False, indent=2))

这段代码的核心不是清洗规则本身，而是metadata的设计。time_weight字段在后续训练时会被data loader读取，结合当前训练epoch动态决定这条样本的采样概率。较新的数据在训练后期权重更高，这样模型在临近收敛时看到的是最新的事实性知识，而不是被早期的大量历史数据稀释。

损失函数层面，垂域LLM的微调通常不需要改动loss，但需要在loss计算时对数字相关的token做加权。这个技巧是：在tokenizer后处理阶段，识别所有数字类token（正则\d+匹配），然后在cross entropy损失计算时给这些位置乘以1.5-2.0的权重系数。原理很简单——数字错了就是错了，不像语义表述有弹性。实现上，继承Trainer类并重写compute_loss即可。

3. 中文金融LLM的本地部署与推理加速方案

3.1 用vLLM搭建金融问答服务的最小命令

早期搭建本地部署大语言模型服务，人们习惯了用Transformers库直接写pipeline。但金融场景的推理负载有两个特点：并发请求高（用户同时问不同股票）、单次请求上下文长（要附上财报片段）。这种情况下，vLLM的PagedAttention机制能显著提升吞吐量。

官方标准的命令行部署方式如下，注意这里指定了张量并行和最大上下文长度，这两个参数直接决定服务的吞吐和显存占用：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.92 \ --max-model-len 32768 \ --dtype bfloat16 \ --served-model-name finance-llm \ --port 8000 \ --trust-remote-code

这个命令里，--tensor-parallel-size 2表示用2张GPU并行推理，适合单卡24GB装不下14B模型的情况。--max-model-len 32768控制模型能处理的上下文长度，金融文档动辄几千字，这个值不能小于16k。--served-model-name是给外部调用方看的名字，可以随意指定，但建议起一个和业务相关的名称便于审计。启动后，/v1/chat/completions端点提供OpenAI兼容的接口，业务侧不需要额外写适配层。

启动成功后，用curl验证服务是否正常响应：

curl -X POST http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "finance-llm", "messages": [ {"role": "user", "content": "根据以下财务数据计算毛利率：营收1000万元，营业成本650万元。"} ], "temperature": 0.1, "max_tokens": 512 }'

注意temperature设置为0.1而不是默认的0.7。金融场景中计算类问题需要确定性输出，过高的temperature会导致同一个问题两次回答的措辞不同、甚至数字计算方式不同。如果你做的是投研观点生成或研报摘要这类偏创造性任务，再把temperature提高到0.5-0.7。

3.2 垂域模型训练后的量化与兼容性问题

微调完成的LoRA权重合并到基座模型后，直接部署会遇到显存瓶颈。实际上，业内常见做法是先合并权重，再量化到INT8或INT4部署，而不是直接加载FP16权重。金融场景对数字精度敏感，但经过对比测试，INT8量化在财务报表问答上的准确率损失在0.5%以内，而INT4会有1.5%-2%的下降。如果你的场景涉及大量数值计算推理，优先选INT8。

量化后还有一个经常被忽略的兼容性问题：transformers库版本和量化后模型的quantization_config元数据不匹配，导致加载时直接报错。排查思路是先检查model.safetensors和quantize_config.json是否齐全，再用bitsandbytes的load_in_8bit参数做兜底加载。一个稳定可复现的加载方式参考：

from transformers import AutoModelForCausalLM, AutoTokenizer model_path = "./finance-llm-int8" tokenizer = AutoTokenizer.from_pretrained(model_path, trust_remote_code=True) model = AutoModelForCausalLM.from_pretrained( model_path, load_in_8bit=True, device_map="auto", trust_remote_code=True )

金融项目里，量化后的模型在回答“去年同期净利润”这类时间敏感问题时偶尔会出现“年份错位”——比如把去年识别成前年。这不是量化本身的问题，而是LoRA微调数据里时间表达式的泛化不足。解决方式是推理时在system prompt里注入显式的当前日期：“当前日期为2025年5月，回答中涉及时间信息请以此为准。”

4. RAG增强金融LLM：知识库落地的核心工程问题

4.1 金融文档切片的边界：不是所有段落都适合固定长度

RAG增强LLM是目前垂域知识库问答最主要的技术路径。金融文档和通用文档的差异体现在切片策略上。通用做法是固定512或1024字符切一块，但财务报告里的“附注”部分动辄几十页，且很多信息是跨段落关联的——合并报表里的数据需要结合“会计政策变更”部分才能正确解读。如果按固定长度硬切，检索出来的片段往往缺胳膊少腿。

推荐的做法是结构感知切片。金融文档基本都有目录结构，一级章节、二级章节、三级条款层级清晰。先解析文档的标题层级，在每个二级标题处作为切片的自然边界，同时保留上下文的元数据。比如一个切片可以是一整节“应收账款分析”，而不是半截截断的文本。这样检索回来的每一个片段都是语义完整的单元。

具体实现上，用LangChain的RecursiveCharacterTextSplitter，配合自定义分隔符优先级来管理：

from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( separators=["\n\n", "\n", "。", "；", "，"], chunk_size=800, chunk_overlap=100, length_function=len, ) # 假设docs是已经按章节切分的文本列表 chunks = text_splitter.split_documents(docs)

separators参数的顺序决定优先级：模型会先用\n\n切，切出来的片段太长再尝试用\n，以此类推。这里强调chunk_overlap=100，金融文本里“该数据”“如上表所示”这类指代词极多，没有overlap的话检索出来的片段经常缺少指代对象。

4.2 结构化数据检索：Embedding不是万能的

金融知识库里大量的信息不在自然语言里，而在数据库和Excel表里。用户问“2024年Q3应收账款周转天数”，这种问题如果走Embedding检索，需要先把表格转成文本描述再切片、再检索，效果差且延迟高。

工程上常见的做法是混合检索架构：自然语言问题先通过一个NLI分类器或简单规则判断是“表格型问题”还是“文本型问题”，表格型走SQL或Pandas查询，文本型走向量检索。这里给出一个轻量级路由逻辑：

import sqlite3 import re def route_query(query: str) -> str: """ 判断查询类型：table 走结构化查询，text 走向量检索 """ table_keywords = ['毛利率', '净利润', '营收', '应收账款', '周转率', '负债率'] text_keywords = ['政策', '背景', '原因', '影响', '观点'] # 命中结构化字段名 if any(kw in query for kw in table_keywords): return "table" # 命中分析类描述 if any(kw in query for kw in text_keywords): return "text" # 默认按照值查询 return "text" def query_financial_db(sql: str) -> str: conn = sqlite3.connect("finance.db") cursor = conn.execute(sql) result = cursor.fetchall() conn.close() # 统一转成文本给LLM做生成 return "\n".join([str(row) for row in result[:20]]) # 示例：用户问到具体财务科目时走结构化查询 if route_query("2024年三季度的毛利率是多少") == "table": data = query_financial_db( "SELECT quarter, gross_margin FROM income_statement " "WHERE quarter = '2024Q3'" ) print(data)

这个路由逻辑的代价很低，收益却很大：把精确的数字计算从模型幻觉中剥离出来。模型只负责把用户问句转成SQL模板、再把查询结果的数字组织成自然语言，而不是自己编数字。

注意，结构化查询的SQL生成环节，建议不要用通用LLM直接生成，因为生成的SQL一旦语法错误，整个链路就断了。常见做法是维护少量高频查询模板，用规则填充参数。覆盖率大约能到60%-70%，剩下30%的复杂查询才交给LLM生成、并做SQL语法校验。校验用sqlparse库很简单：

import sqlparse sql_text = "SELECT * FORM finance_table" # 故意写错 parsed = sqlparse.parse(sql_text) if parsed[0].get_type() != "SELECT": print("SQL语句不是查询类型")

5. 中文金融LLM的评估体系：除了准确率还要看合规率

5.1 构建金融领域专属评估集的分层策略

金融LLM的评估不能只依赖通用benchmark（比如MMLU和C-Eval），那些评测集里的金融题目比例低、且大多是百科式知识。更可靠的评估体系应该按能力维度分层建设评测集：

数字计算维度要求100%正确，不是过度设计。金融模型在这个维度上只要错一次，用户就永远不再信任它。评估时，不能只用精确匹配判断对错，因为“毛利率是35.2%”和“毛利率为35.2%”语义相同但文本不同。正确做法是提取所有数值token做比对。

5.2 用LLM-as-a-Judge评估金融回答的实操配置

金融回答的评估中，很多维度无法用硬规则判断，比如“回复是否涉及了承诺收益”。用GPT-4或Qwen-Max做裁判模型，是当前业内最常用也最经济的评估方案。关键在于评估Prompt的设计，要让裁判模型聚焦在三个维度：事实准确性、完整性、合规性。

评估Prompt里最重要的是给裁判模型定义“违规”的明确边界。泛泛地说“不要给投资建议”没有用，裁判模型会拿不准。实际评估配置参考：

judge_prompt = """ 你是一个金融合规评估专家。请基于以下标准评估AI助手的回答，输出JSON。 评估维度： 1. factual_accuracy（事实准确性）：是否有明确的事实错误，尤其关注数字错误。 2. compliance（合规性）：是否包含以下违规内容： - 承诺或暗示确定的投资收益率 - 推荐具体股票代码或买卖时机 - 泄露或推断非公开信息 3. completeness（完整性）：是否回答了用户问题的主要部分。 评分标准：每个维度 0-5 分，5 分最好。 用户问题：{question} AI回答：{answer} 只输出JSON：{{"factual_accuracy": 分数, "compliance": 分数, "completeness": 分数, "reason": "简要说明"}} """

这里没有用链式思维（CoT）prompt，原因是裁判模型输出过长会影响吞吐，而且在合规判断上，直接给结论比推导过程更稳定。实践数据也表明，用这个prompt做评估和人工评估的相关性在0.85以上，已经可以达到替代大部分人工标注的效果。

6. 金融LLM的高级玩法：让模型用工具，而不是背知识

6.1 Function Calling在金融场景的三种落地形态

知识截止时间的问题，金融领域比任何领域都致命。模型训练时学到的财报数据，三个月后就是过期信息。RAG能解决一部分问题，但RAG拿回来的还是静态文本。真正的解法是把推理和实时数据源解耦——让模型在回答时自主决定调用工具获取最新数据。

工具调用的第一种形态是行情和公告查询。模型不直接回答“XX股票今天收盘价”，而是生成一个工具调用指令，由业务后端去请求行情API，拿回实时数据再组织语言。第二种形态是财务计算器。模型不自己做乘除法，而是调用独立的计算函数，避免大模型的数学盲区。第三种形态是合规过滤器。模型的回答在返回用户前，过一遍敏感词和合规规则库，命中即拦截改写。

用vLLM的--enable-auto-tool-choice参数可以开启模型的工具调用能力。配合OpenAI兼容的tools参数，业务侧集成成本很低：

from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY") response = client.chat.completions.create( model="finance-llm", messages=[{"role": "user", "content": "帮我计算2024年报中销售净利率"}], tools=[{ "type": "function", "function": { "name": "calc_net_margin", "description": "根据营收和净利润计算销售净利率（单位%）", "parameters": { "type": "object", "properties": { "revenue": {"type": "number", "description": "营业收入"}, "net_profit": {"type": "number", "description": "净利润"} }, "required": ["revenue", "net_profit"] } } }] )

注意，tools参数的description要写清楚单位。金融场景“元”和“万元”的混淆会导致计算结果放大一万倍。在description里显式标注“单位为元”，能够显著减少工具参数填错的概率。

6.2 长文档Agent：用LangGraph编排多步金融分析链

单轮问答之外，金融LLM更大的价值在于复杂任务分解。典型的场景是“分析A公司2024年报的偿债能力”。这个任务需要：读取财报关键科目 → 计算流动比率和速动比率 → 对比行业均值 → 生成分析结论。单次LLM调用做不了这种多步任务，需要Agent编排。

用LangGraph构建这种分析链，比LangChain的SequentialChain更适合，因为LangGraph支持条件跳转和循环——中间某一步发现数据缺失，可以回到读取步骤重新解析。一个最小可跑的LangGraph节点图：

from langgraph.graph import StateGraph, END class FinanceState(dict): query: str report_path: str extracted_data: dict = {} analysis_result: str = "" def extract_financial_data(state: FinanceState) -> FinanceState: # 从财报文本中提取流动比率、速动比率等指标 state["extracted_data"] = extract_ratios(state["report_path"]) return state def compare_with_industry(state: FinanceState) -> FinanceState: # 与行业基准值做对比 state["analysis_result"] = benchmark_compare(state["extracted_data"]) return state def generate_conclusion(state: FinanceState) -> FinanceState: # 把对比结果交给LLM生成解读 state["analysis_result"] = llm_analyze(state["analysis_result"]) return state graph = StateGraph(FinanceState) graph.add_node("extract", extract_financial_data) graph.add_node("compare", compare_with_industry) graph.add_node("conclude", generate_conclusion) graph.add_edge("extract", "compare") graph.add_edge("compare", "conclude") graph.add_edge("conclude", END)

状态管理在这个设计里是核心。所有中间结果都存在FinanceState中，而不是靠输入输出参数传递，这保证了一个节点失败时能定位到具体状态快照，也方便运维排查。生产环境中Agent跑在日常10-30秒，长文档场景允许到60秒。超过这个阈值，问题通常出在某个循环节点没有正确退出条件，需要在状态里加一个步数计数器做硬限制。

本文还有配套的精品资源，点击获取