最近金融圈有一则消息值得技术人反复琢磨高盛一位合伙人公开警告华尔街大规模普及 AI 之后金融从业者的主动思考能力可能被削弱。这看起来是一句“行业观察”但落到做 AI 工程的人眼里其实是一条很具体的技术提醒当大模型和智能体被嵌入投研、风控、交易、合规这些高价值场景时系统设计一旦只追求“快”和“省人力”就会慢慢把人的判断力架空。本文不是要讨论高盛的内部观点而是从 AI 工程实践角度拆解金融领域大模型应用的常见形态、技术架构、以及“防止认知外包”的系统设计方法。全文会包含可运行的 RAG 问答系统示例、带人工复核的 Agent 配置、审计日志表结构、以及一套防止“AI 代替人思考”的工程治理方案。无论你是刚接触 AI 应用开发的工程师还是已经在金融科技项目里做模型落地这篇文章都值得收藏备用。1. 背景与核心概念AI 普及为什么会削弱思考能力1.1 “认知外包”现象的技术本质“认知外包”不是心理学概念而是 AI 系统在落地时最容易踩中的设计陷阱。当一个人工智能系统把信息的收集、整理、归纳、甚至结论生成全部完成并且以“置信度很高”的姿态输出给用户时用户会本能地减少对信息的质疑和交叉验证。短时间看这提升了效率长时间看人的专业敏感度、判断力和质疑精神会被逐渐钝化。在华尔街的场景里这种风险被放得更大。一个分析师如果每天依赖大模型自动生成行业研究报告的初稿而不去核对底层数据、不去理解推导逻辑那么半年后他对行业的理解深度一定不如从前。这不是危言耸听而是“自动化偏见”在专业领域的真实体现。从工程角度看问题出在系统设计上太多 AI 产品只关注“输出答案”不关注“输出依据”只关注“自动化程度”不关注“人类审查节点”。换句话说不是 AI 本身会削弱思考能力而是我们把 AI 设计成了不需要人思考的工具。1.2 什么是 RAG、Agent 和认知边界要讨论解决方案先要统一几个技术概念。RAGRetrieval-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 的私有知识库问答系统能解决这个问题。这类系统的技术要点是文档解析与切分把 PDF、Word、Excel 转成可检索的文本块并保持语义完整。向量化存储用 Embedding 模型把文本块转成向量存入向量数据库。相关性检索用户提问时先从知识库中召回最相关的文本块。增强生成把召回结果作为上下文交给大模型生成最终回答。2.3 智能体自动化类审批、报告、监测更高阶的应用是 Agent。它可以串联多个系统完成一个完整业务流程。例如合规审查 Agent自动读取新业务方案比对合规制度库标记风险条款生成审查意见。投后管理 Agent定期抓取被投企业的公开数据生成投后跟踪报告异常时自动预警。交易前检查 Agent在交易指令下达前自动检查持仓限额、风险指标、授权范围。Agent 的关键在于“工具调用”和“流程编排”。它需要调用数据库查询工具、API 接口、消息推送服务并且根据中间结果决定下一步动作。2.4 模型部署与推理私有化与合规约束金融行业对数据安全要求极高核心业务数据不能直接调用外部大模型 API。因此私有化部署成为金融 AI 落地的必然选择。部署形态通常包括部署方式适用场景优点注意点私有化推理服务核心交易、客户数据数据不出域、可控性强需要 GPU 资源和运维能力混合云部署非敏感业务、研发测试弹性扩缩容、成本灵活需要严格的数据分流策略专有云 本地知识库研发辅助、内部知识管理兼顾性能与安全需要统一的权限管控模型选型方面金融场景通常更看重“可控性”而非“参数规模”。参数规模小一点的模型如果经过领域微调和检索增强在垂直任务上的表现可能优于通用大模型。3. 四个会“偷走思考能力”的系统设计缺陷3.1 缺陷一只给结论不给依据最典型的设计问题是问答系统只输出答案不展示依据来源。用户看到一段流畅且笃定的文字时很容易忘记追问“这个结论从哪来”。当 AI 的错误结论被当作事实接受时思考链条就断了。改进方式是引入强制溯源机制。生成的每个结论都要附带来源文档、引用片段、相关度评分。系统应该允许用户点击“查看依据”并回溯原始文档。3.2 缺陷二自动化闭环从“辅助”变成“替代”另一个常见问题是流程设计上把 AI 置于“最终决策者”的位置。比如一个报告生成 Agent如果自动完成数据抓取、分析、撰写并且一键发送给客户中间没有人工审核环节那么业务人员的角色就变成了“按发送键的人”。正确的设计是分级自动化L1AI 只做数据准备和草稿生成人工负责内容审核。L2AI 在规则明确的低风险场景下可自动执行但保留人工抽检。L3高风险场景强制人工审批AI 只提供建议。3.3 缺陷三缺少人工复核与风险审批节点Agent 系统如果追求“全自动”就会忽略人工复核节点的设计。正确的做法是在关键路径上插入审批环节。以投资研究报告生成为例AI 完成初稿后应该进入“分析师复核 - 合规审查 - 部门负责人审批”的流程每一步的修改都要留痕。3.4 缺陷四模型评估只看效率指标技术团队在评估 AI 系统时往往只关注“回答准确率”“响应耗时”“节省人力成本”等指标。但这些指标无法衡量“长期思考能力”的退化风险。更全面的评估体系应该加入用户对 AI 输出提出质疑的频次。人工修改 AI 生成内容的比率。AI 输出被直接采纳的占比是否过高。业务人员定期进行无 AI 辅助的独立分析测试。这些指标看似抽象但可以注入到系统的埋点日志中通过数据分析量化。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, encodingutf-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, metadataall_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_ktop_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[{i1}] {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 fRV-{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 分级自动化与人工复核不同的业务场景对自动化程度的容忍度不同。建议按风险等级设计自动化策略风险等级场景举例自动化策略低风险内部知识检索、文档格式整理AI 可直接输出保留抽检中风险研究报告初稿、数据分析摘要AI 生成草稿人工审核后发布高风险交易指令、客户合同、合规结论AI 提供建议人工决策并签字这个分级思路要写进系统需求文档并在代码中通过状态机实现。5.3 权限安全与提示词注入防护金融 AI 系统在权限安全上有两层要求。第一层是传统的数据权限不同角色只能检索不同范围的知识。第二层是提示词注入防护用户可能通过精心构造的问题诱导系统忽略约束、泄露知识库原始内容或执行未授权操作。防护措施包括对用户输入进行敏感词和模式检测。在提示词中固定系统角色并将用户输入视为“不可信数据”。对 Agent 的工具调用增加参数白名单校验。所有模型输入输出都记录审计日志便于追溯异常行为。5.4 持续评估与反馈闭环模型上线不是终点。团队需要建立一套持续评估机制定期检查 AI 输出质量和人工复核情况。建议的核心指标包括答案引用来源的覆盖率。人工修改率AI 生成内容被人工修改的比例。用户反馈不准确回答的数量。人工审核的平均耗时。高风险场景中人工否决 AI 建议的占比。这些指标可以按月统计形成趋势报告用来判断“AI 是否正在过度替代人类判断”。6. 常见问题与排查思路问题现象常见原因解决思路回答内容找不到对应引用检索召回率不足或未强制引用增加混合检索、调整切块大小、提高相关度阈值AI 回答明显错误但语气笃定模型幻觉提示词约束不足强化提示词约束、增加资料不足拒绝机制人工复核流未生效流程引擎配置错误或状态机缺失检查审核节点配置确保发布接口强制校验复核状态用户绕开复核直接拿到回答前端直接调用了模型接口取消前端直连模型统一走后端审核接口提示词注入导致系统异常用户输入未被严格过滤输入校验、系统提示词加固、工具调用白名单审计日志缺失日志采集链路不完整在生成、审核、发布三个节点都埋点并落库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 应用时永远要问一句“如果模型错了人能发现吗”。如果你已经把答案想清楚那么这套系统的认知边界就是安全的。