金融AI应用防“认知外包”：RAG与人工复核的工程实践

最近金融圈有一则消息值得技术人反复琢磨：高盛一位合伙人公开警告，华尔街大规模普及 AI 之后，金融从业者的主动思考能力可能被削弱。这看起来是一句“行业观察”，但落到做 AI 工程的人眼里，其实是一条很具体的技术提醒：当大模型和智能体被嵌入投研、风控、交易、合规这些高价值场景时，系统设计一旦只追求“快”和“省人力”，就会慢慢把人的判断力架空。

本文不是要讨论高盛的内部观点，而是从 AI 工程实践角度，拆解金融领域大模型应用的常见形态、技术架构、以及“防止认知外包”的系统设计方法。全文会包含可运行的 RAG 问答系统示例、带人工复核的 Agent 配置、审计日志表结构、以及一套防止“AI 代替人思考”的工程治理方案。无论你是刚接触 AI 应用开发的工程师，还是已经在金融科技项目里做模型落地，这篇文章都值得收藏备用。

1. 背景与核心概念：AI 普及为什么会削弱思考能力

1.1 “认知外包”现象的技术本质

“认知外包”不是心理学概念，而是 AI 系统在落地时最容易踩中的设计陷阱。当一个人工智能系统把信息的收集、整理、归纳、甚至结论生成全部完成，并且以“置信度很高”的姿态输出给用户时，用户会本能地减少对信息的质疑和交叉验证。短时间看，这提升了效率；长时间看，人的专业敏感度、判断力和质疑精神会被逐渐钝化。

在华尔街的场景里，这种风险被放得更大。一个分析师如果每天依赖大模型自动生成行业研究报告的初稿，而不去核对底层数据、不去理解推导逻辑，那么半年后他对行业的理解深度一定不如从前。这不是危言耸听，而是“自动化偏见”在专业领域的真实体现。

从工程角度看，问题出在系统设计上：太多 AI 产品只关注“输出答案”，不关注“输出依据”；只关注“自动化程度”，不关注“人类审查节点”。换句话说，不是 AI 本身会削弱思考能力，而是我们把 AI 设计成了不需要人思考的工具。

1.2 什么是 RAG、Agent 和认知边界

要讨论解决方案，先要统一几个技术概念。

RAG（Retrieval-Augmented Generation，检索增强生成）是目前企业级大模型应用中最主流的技术架构。它的核心思想是不直接让大模型凭记忆回答，而是先从企业私有的知识库中检索相关内容，再把检索结果作为上下文输入给大模型，最终生成回答。这样做的好处是答案有据可依，也能覆盖企业内部的非公开知识。

AI Agent（人工智能智能体）则是更进一步的应用形态。Agent 不只是“回答问题”，它会根据目标拆解任务、调用工具、执行操作、并根据结果调整下一步行为。比如一个投研 Agent 可以自动抓取公告、解析财务数据、生成分析摘要、再推送审批。

这两个概念之所以和“思考能力削弱”相关，是因为它们决定了 AI 的“自动权”边界。RAG 做得好，AI 是“资料员 + 草稿员”；Agent 做得过度，AI 就成了“决策者”。技术人要做的是把决策权留在人类手里。

1.3 为什么开发者也必须关注这个问题

很多开发者觉得“思考能力削弱”是管理层和业务部门的事，程序员只需要按需求写代码。但实际情况恰恰相反：系统是否保留人工审查环节、是否输出可溯源的依据、是否在关键节点设置审批流，这些都是由开发者在设计阶段决定的。

一个没有引用来源的问答机器人，不是产品经理的锅，是架构设计时漏掉了检索溯源模块。一个自动发送交易指令的 Agent，如果没有人工确认节点，也不是业务方的锅，是流程设计时没有设置安全阀。技术人在 AI 普及过程中，承担着“系统决策权分配”的关键角色。

2. 金融行业 AI 应用全景：大模型在华尔街的落地形态

2.1 文本处理类：研报摘要、公告解析、会议纪要

金融行业是文本密集型行业。一份 IPO 招股书可能上千页，一份季度财报包含大量结构化数据和非结构化叙述。传统关键词搜索和规则解析很难处理语义层面的信息抽取，大模型在这方面有明显优势。

常见的落地形态包括：

• 研报自动摘要：把几十页的券商研报压缩成 500 字核心观点。
• 公告事件解析：从上市公司公告中抽取“业绩变动”“股东增减持”“重大合同”等事件。
• 电话会议纪要整理：自动分离不同发言人、提取经营数据、生成待办事项。

这些场景的共同特点是：输出结果需要人来复核，但 AI 可以把阅读时间从 1 小时压缩到 5 分钟。

2.2 知识库问答类：私有知识域的检索增强

金融机构积累了海量内部文档：产品说明书、合规制度、历史交易案例、风控规则。员工想查找一条准确规定时，往往要在多个系统里翻找。基于 RAG 的私有知识库问答系统能解决这个问题。

这类系统的技术要点是：

1. 文档解析与切分：把 PDF、Word、Excel 转成可检索的文本块并保持语义完整。
2. 向量化存储：用 Embedding 模型把文本块转成向量，存入向量数据库。
3. 相关性检索：用户提问时，先从知识库中召回最相关的文本块。
4. 增强生成：把召回结果作为上下文交给大模型，生成最终回答。

2.3 智能体自动化类：审批、报告、监测

更高阶的应用是 Agent。它可以串联多个系统完成一个完整业务流程。例如：

• 合规审查 Agent：自动读取新业务方案，比对合规制度库，标记风险条款，生成审查意见。
• 投后管理 Agent：定期抓取被投企业的公开数据，生成投后跟踪报告，异常时自动预警。
• 交易前检查 Agent：在交易指令下达前，自动检查持仓限额、风险指标、授权范围。

Agent 的关键在于“工具调用”和“流程编排”。它需要调用数据库查询工具、API 接口、消息推送服务，并且根据中间结果决定下一步动作。

2.4 模型部署与推理：私有化与合规约束

金融行业对数据安全要求极高，核心业务数据不能直接调用外部大模型 API。因此私有化部署成为金融 AI 落地的必然选择。

部署形态通常包括：

模型选型方面，金融场景通常更看重“可控性”而非“参数规模”。参数规模小一点的模型，如果经过领域微调和检索增强，在垂直任务上的表现可能优于通用大模型。

3. 四个会“偷走思考能力”的系统设计缺陷

3.1 缺陷一：只给结论，不给依据

最典型的设计问题是：问答系统只输出答案，不展示依据来源。用户看到一段流畅且笃定的文字时，很容易忘记追问“这个结论从哪来”。当 AI 的错误结论被当作事实接受时，思考链条就断了。

改进方式是引入强制溯源机制。生成的每个结论都要附带来源文档、引用片段、相关度评分。系统应该允许用户点击“查看依据”并回溯原始文档。

3.2 缺陷二：自动化闭环从“辅助”变成“替代”

另一个常见问题是流程设计上把 AI 置于“最终决策者”的位置。比如一个报告生成 Agent，如果自动完成数据抓取、分析、撰写并且一键发送给客户，中间没有人工审核环节，那么业务人员的角色就变成了“按发送键的人”。

正确的设计是分级自动化：

• L1：AI 只做数据准备和草稿生成，人工负责内容审核。
• L2：AI 在规则明确的低风险场景下可自动执行，但保留人工抽检。
• L3：高风险场景强制人工审批，AI 只提供建议。

3.3 缺陷三：缺少人工复核与风险审批节点

Agent 系统如果追求“全自动”，就会忽略人工复核节点的设计。正确的做法是在关键路径上插入审批环节。以投资研究报告生成为例，AI 完成初稿后，应该进入“分析师复核 -> 合规审查 -> 部门负责人审批”的流程，每一步的修改都要留痕。

3.4 缺陷四：模型评估只看效率指标

技术团队在评估 AI 系统时，往往只关注“回答准确率”“响应耗时”“节省人力成本”等指标。但这些指标无法衡量“长期思考能力”的退化风险。更全面的评估体系应该加入：

• 用户对 AI 输出提出质疑的频次。
• 人工修改 AI 生成内容的比率。
• AI 输出被直接采纳的占比是否过高。
• 业务人员定期进行无 AI 辅助的独立分析测试。

这些指标看似抽象，但可以注入到系统的埋点日志中，通过数据分析量化。

4. 完整实战：构建一个带“人工复核”的金融知识问答系统

为了让上面的讨论落到代码层面，下面我们实现一个最小的金融知识问答系统。它的核心能力包括：

1. 从本地文档构建知识索引。
2. 用户提问时检索相关知识。
3. 大模型基于检索结果生成回答，并附带引用来源。
4. 系统生成“待人工复核”任务，审核通过后才算完成。

这是一个典型的 RAG + 人工复核闭环的简化版，可以直接作为金融 AI 应用的原型参考。

4.1 系统整体架构

整个系统分为 5 个模块：

用户输入 ↓ [问题理解与改写] ↓ [向量检索模块] ← → [向量数据库] ↓ [知识库文档/PDF解析] ↓ [上下文组装与大模型生成] ↓ [引用溯源与复核任务生成] ↓ [人工审核 → 发布回答]

关键点是最后一步：AI 不直接对用户输出，而是先生成“待审核回答”，由业务人员在审核工作台确认后，才正式发布。这一步就是对抗“思考能力削弱”的工程手段。

4.2 项目结构

financial-rag/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── ingest.py # 文档解析与入库 │ ├── retriever.py # 向量检索模块 │ ├── generator.py # 大模型生成模块 │ ├── audit.py # 审计日志与复核任务 │ └── models.py # 数据模型定义 ├── data/ │ └── knowledge/ # 原始知识文档 ├── config/ │ └── settings.yaml # 系统配置 └── requirements.txt

这个结构适合原型验证，生产环境可以按团队职责拆分为独立服务。

4.3 文档解析与向量入库

首先是文档导入模块app/ingest.py。这里我们用最常见的文本文件为例，实际项目中需要根据 PDF、Word 等格式接入对应解析库。

# app/ingest.py import os from typing import List def load_text_documents(directory: str) -> List[dict]: """读取目录下的所有 .txt 文件，返回文档列表。 每个文档包含两个字段： - content: 文档正文 - source: 文件路径，用于追溯引用来源 """ documents = [] for filename in os.listdir(directory): if filename.endswith(".txt"): filepath = os.path.join(directory, filename) with open(filepath, "r", encoding="utf-8") as f: content = f.read() documents.append({ "content": content, "source": filepath, }) return documents def split_text(content: str, chunk_size: int = 500, overlap: int = 50) -> List[str]: """将长文本按照固定长度切块，并保留部分重叠。 切块的核心目标是保证检索时能覆盖完整语义，避免 一个完整要点被截断成两半。 """ chunks = [] start = 0 while start < len(content): end = start + chunk_size chunks.append(content[start:end]) start = end - overlap return chunks

这个模块的逻辑很简单：读取文档、按长度切块。chunk_size 和 overlap 是 RAG 系统最基础的两个调参项。过小的 chunk_size 会导致语义不完整，过大的又会引入无关信息。

接下来是向量化入库。为了避免把代码绑死在某个特定向量数据库上，这里保留接口思路，实际使用时替换成对应的客户端即可。

# app/ingest.py（续） def build_index(documents: List[dict]): """将文档切块并写入向量库。 生产环境通常使用 Milvus、Qdrant、Elasticsearch 等。 这里只演示核心流程，不绑定具体向量库实现。 """ all_chunks = [] for doc in documents: chunks = split_text(doc["content"]) for chunk in chunks: all_chunks.append({ "content": chunk, "source": doc["source"], }) # 调用 Embedding 模型生成向量，并写入向量库 # 示例： # vectors = embed_model.encode([c["content"] for c in all_chunks]) # vector_store.add(vectors, metadata=all_chunks) print(f"共生成 {len(all_chunks)} 个文档块") return all_chunks

注意，这里不写死具体的 Embedding API，因为不同项目的模型和向量库差异很大。核心目的是让你理解索引构建的完整流程。

4.4 检索模块

检索模块是 RAG 的核心。它的任务是接收用户问题，从向量库中找出最相关的文档块。

# app/retriever.py def retrieve(query: str, top_k: int = 3) -> list: """根据问题检索最相关的知识片段。 真实实现时，需要将 query 编码为向量，然后 在向量库中执行相似度搜索。 """ # query_vector = embed_model.encode([query]) # results = vector_store.search(query_vector, top_k=top_k) # # 为了演示，这里模拟返回两条结果 results = [ { "content": "风险限额是指金融机构在开展业务时，" "针对单一客户、单一行业或单一产品设定的" "最大风险敞口上限。", "source": "data/knowledge/risk_management.txt", "score": 0.92, }, { "content": "在授权范围内开展的交易，需在交易后" "向合规部门提交台账记录。", "source": "data/knowledge/compliance_rules.txt", "score": 0.87, }, ] return results[:top_k]

这个模块在真实系统中会做几件额外的事：

• 对用户问题进行改写，使得检索效果更好。
• 使用混合检索（关键词 + 向量）提高召回率。
• 对检索结果做重排序，过滤掉与问题无关的片段。

4.5 生成模块与引用溯源

生成模块负责把检索结果交给大模型，生成回答。这里的关键是强制要求大模型在回答中标注引用编号，并且附带“不确定就拒绝回答”的约束。

# app/generator.py def build_prompt(query: str, retrieved_chunks: list) -> str: """构造大模型输入。 提示词中要求模型： 1. 只基于提供的资料回答； 2. 用 [1][2] 标注引用来源； 3. 资料不足时明确说明，不编造。 """ context = "\n\n".join( [f"[{i+1}] {chunk['content']}" for i, chunk in enumerate(retrieved_chunks)] ) prompt = f"""你是一名金融合规助理。请基于以下资料回答问题。 资料： {context} 问题：{query} 要求： 1. 只使用资料中的内容作答； 2. 在答案后面用[1]这种格式标注引用片段； 3. 如果资料不足以回答，请明确说“资料不足”，不要编造。""" return prompt def generate_answer(query: str, retrieved_chunks: list) -> dict: """调用大模型生成回答，并附带引用来源。""" prompt = build_prompt(query, retrieved_chunks) # 实际项目在这里调用大模型API或私有化部署的推理服务 # response = llm_client.chat(prompt) response = ( "根据现行合规制度，风险限额指金融机构针对单一客户、" "单一行业或单一产品设定的最大风险敞口上限[1]。\n" "授权范围内交易需在交易后向合规部门提交台账记录[2]。" ) references = [] for i, chunk in enumerate(retrieved_chunks): references.append({ "index": i + 1, "source": chunk["source"], "content": chunk["content"], "score": chunk["score"], }) return { "answer": response, "references": references, "prompt": prompt, }

这段代码体现了两个关键设计：

• 答案中强制带引用标记，用户可以看到结论来自哪段资料。
• 提示词中明确约束模型不能编造，资料不足时要拒绝回答。

4.6 人工复核与审计日志

生成回答后，系统不能直接对外发布，而是生成一条待复核任务。复核人员可以修改回答内容，也可以退回重做。整个过程写入审计日志。

# app/audit.py import datetime def create_review_task(question: str, generated: dict) -> str: """生成一条人工复核任务。 返回任务 ID，业务人员在审核工作台操作。 """ task_id = f"RV-{datetime.datetime.now().strftime('%Y%m%d%H%M%S')}" review_task = { "task_id": task_id, "question": question, "generated_answer": generated["answer"], "references": generated["references"], "status": "pending", "created_at": datetime.datetime.now().isoformat(), } # 写入业务数据库，进入审核工作台 print(f"[审核任务已创建] {task_id}") return task_id def write_audit_log(task_id: str, action: str, operator: str, detail: str = None): """写入审计日志。 生产环境应使用独立的审计日志表，且日志不可被业务人员修改。 """ log_entry = { "task_id": task_id, "action": action, "operator": operator, "detail": detail, "timestamp": datetime.datetime.now().isoformat(), } print(f"[审计日志] {log_entry}")

这个模块在真实系统中还会包含：

• 复核通过后，回答才允许推送给用户。
• 复核人修改的内容与 AI 原始内容进行差异对比。
• 审计日志链路完整记录“谁审的、改了什么、什么时候改的”。

4.7 运行与验证

完成以上模块后，可以按下面流程跑通一个最小闭环：

cd financial-rag/ pip install -r requirements.txt # 1. 准备知识文档 mkdir -p data/knowledge cat > data/knowledge/risk_management.txt << 'EOF' 风险限额是指金融机构在开展业务时，针对单一客户、单一行业或单一产品设定的最大风险敞口上限。设定风险限额应当基于对宏观经济、行业趋势及客户偿债能力的综合评估。 EOF # 2. 构建索引 python -c " from app.ingest import load_text_documents, build_index docs = load_text_documents('data/knowledge') build_index(docs) " # 3. 模拟问答与复核流程 python -c " from app.retriever import retrieve from app.generator import generate_answer from app.audit import create_review_task query = '什么是风险限额？' chunks = retrieve(query) result = generate_answer(query, chunks) task_id = create_review_task(query, result) print(result['answer']) "

预期输出会显示检索到的资料片段、生成的回答、带引用标记的答案，以及一条待审核的任务记录。整个过程表明：AI 完成了“资料检索 + 草稿生成”，但最终是否发布，决定权仍在人工审核环节。

这个最小系统证明了对抗“认知外包”的关键不是不用 AI，而是在 AI 和最终输出之间，插入“依据 + 复核”两个安全阀。

5. 工程治理：如何让 AI 保持“辅助”而非“替代”

5.1 强制引用与溯源机制

生成式 AI 在金融场景中的第一原则是“所有结论必须有出处”。这不仅是合规要求，也是维持使用者思考能力的有效手段。

具体做法包括：

• 回答中的每个关键结论都绑定知识库中的原始段落。
• 前端展示“查看出处”入口，点击后展示原文上下文。
• 检索相关度低于阈值时，明确提示“未找到充分依据”，而不是强行生成。

5.2 分级自动化与人工复核

不同的业务场景对自动化程度的容忍度不同。建议按风险等级设计自动化策略：

这个分级思路要写进系统需求文档，并在代码中通过状态机实现。

5.3 权限安全与提示词注入防护

金融 AI 系统在权限安全上有两层要求。第一层是传统的数据权限：不同角色只能检索不同范围的知识。第二层是提示词注入防护：用户可能通过精心构造的问题，诱导系统忽略约束、泄露知识库原始内容或执行未授权操作。

防护措施包括：

• 对用户输入进行敏感词和模式检测。
• 在提示词中固定系统角色，并将用户输入视为“不可信数据”。
• 对 Agent 的工具调用增加参数白名单校验。
• 所有模型输入输出都记录审计日志，便于追溯异常行为。

5.4 持续评估与反馈闭环

模型上线不是终点。团队需要建立一套持续评估机制，定期检查 AI 输出质量和人工复核情况。

建议的核心指标包括：

• 答案引用来源的覆盖率。
• 人工修改率（AI 生成内容被人工修改的比例）。
• 用户反馈不准确回答的数量。
• 人工审核的平均耗时。
• 高风险场景中人工否决 AI 建议的占比。

这些指标可以按月统计，形成趋势报告，用来判断“AI 是否正在过度替代人类判断”。

6. 常见问题与排查思路

7. 最佳实践与工程建议

7.1 技术层面的建议

• 使用 RAG 而不是纯大模型生成。领域知识必须存在可控的知识库中，而不是模型参数里。
• 将提示词模板和业务代码分离，方便不同业务线复用和迭代。
• 设计统一的重试和降级策略。大模型服务不可用时，系统要能降级为“仅检索不生成”模式。
• 对向量库定期做数据一致性检查，避免删除或更新的文档仍然被检索出来。

7.2 流程层面的建议

• 在需求评审阶段明确“自动化等级”，指定哪些环节必须人工操作。
• 建立 AI 输出质量的定期抽检机制，不能上完线就不管。
• 将所有 AI 系统纳入了统一的合规审计范围。

7.3 制度层面的建议

• 对高频使用 AI 的员工进行定期“脱 AI 化”考核。比如每月安排一次不借助 AI 工具的数据分析练习，检验独立判断能力。
• 在内部制度中明确 AI 生成内容的标注要求。即使人工深度修改过，也应该保留“由 AI 辅助生成”的记录，确保信息透明。
• 定期复盘 AI 误判案例，把典型错误沉淀成知识库中的“反例数据”，用来改进模型和提示词。

这些建议不是限制 AI 的使用，而是确保 AI 始终处于“辅助工具”的位置。技术团队有责任通过系统设计来帮助业务人员保持思考能力，而不是用“效率优先”的理由把判断权全部交给模型。

8. 总结

回到高盛那位合伙人的担忧：华尔街普及 AI 确实可能削弱金融从业者的思考能力，但这种削弱不是 AI 的必然结果，而是系统设计缺陷的副作用。当 AI 系统只给结论不给依据、自动完成全流程不设人工节点、评估指标只关注效率不关注判断力，它就会从根本上改变用户的工作习惯和认知方式。

从工程角度解决这个问题，可以总结为四个关键动作：用 RAG 给每个回答绑定可溯源的资料、用流程设计在关键路径上插入人工复核、用审计日志记录每一次 AI 辅助决策的过程、用持续评估防止自动化程度的失衡。

本文从概念到实战，给出了一个带人工复核的金融问答系统的完整原型。你可以在这个基础上，结合自己团队的向量数据库、大模型服务、审批流引擎，扩展成一个生产可用的系统。最关键的是：在设计 AI 应用时，永远要问一句，“如果模型错了，人能发现吗”。如果你已经把答案想清楚，那么这套系统的认知边界就是安全的。