AI Wealth Advice / Robo-Advisor / Best Interest Boundary Architecture 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_WEALTH_ADVICE_ROBO_ADVISOR_BEST_INTEREST_BOUNDARY_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

以下官方来源作为学习锚点。本文只把公开材料转成产品、流程、架构和证据设计语言, 不得被解读为法律意见、合规结论或适用性判断。正式项目的准确适用范围由 Legal / Compliance / Risk / Supervision 结合机构注册类型、产品类型、渠道、司法辖区和内部政策确认。

核心导读

财富建议类 AI 的核心不是“会不会解释投资概念”, 而是能否把教育、个性化建议、组合构建、交易执行、人工交接、利益冲突、披露、监督和证据做成同一个可控系统。语言模型如果直接面向客户生成建议, 它就不再只是内容体验问题, 而是进入 conduct risk、模型风险、销售合规、客户伤害和可追责边界的交叉区。

更成熟的设计不是让 AI “少说一点”, 而是让系统在运行时明确知道自己处于哪一种 advice mode: 教育解释、通用引导、个性化建议、组合建议、再平衡建议、执行辅助或必须交给持牌人员的场景。每一种 mode 都有不同输入完整性、产品宇宙、证据、披露、审批和回放要求。

问题定义

AI wealth advice 的风险来自三个错配。

第一是客户意图和系统授权错配。客户问“我应该买什么基金”时, 系统不能只依据自然语言意图决定回答深度, 还要识别机构角色、客户关系、适用渠道、客户画像完整度、产品适配规则、是否允许个性化推荐以及是否接近交易执行。

第二是推荐逻辑和客户利益错配。投资产品有费用、风险、流动性、税务、期限、集中度、适当性和冲突问题。模型如果只优化点击率、转化率或资产流入, 很容易把“客户可能接受”误当成“对客户合理”。best-interest 风格控制在这里不是口号, 而是一组可执行约束: 可推荐产品范围、排序原则、冲突处理、替代方案比较、理由证据和监督抽检。

第三是语言输出和证据链错配。生成式回答看起来像建议, 但如果不能重放当时的客户输入、画像状态、产品数据版本、规则版本、模型版本、检索来源、排序理由、披露文本和人工干预, 事后无法解释为什么给出这个建议, 也无法判断是模型幻觉、资料过期、规则缺口、渠道越权还是人工监督失效。

因此, 这类系统的架构目标不是“让客户满意地获得答案”, 而是让每一次可能影响投资决策的交互都被边界化、证据化、监督化。

核心原理/方法

Advice boundary state machine 系统必须把每次交互归入明确状态: education、general information、personalized guidance、portfolio recommendation、rebalance recommendation、execution support、human-only。状态不是文案标签, 而是运行时策略: 允许调用哪些工具、能否使用客户画像、是否允许输出产品名称、是否需要费用和风险披露、是否触发人工复核。

Investor profile as control input 客户画像不是表单收集物, 而是控制输入。至少要包含投资目标、风险承受能力、风险偏好、投资期限、流动性需要、财务约束、知识经验、税务敏感性、集中度、受限产品、重要生命周期事件和最近更新时间。画像缺失或过期时, 推荐引擎应降级为教育或澄清问题, 而不是补全缺口。

Approved universe before recommendation AI 不应在开放互联网或未治理知识库里自由挑选投资产品。产品必须先进入 approved investment universe, 具备费用、风险等级、适用客户、流动性、税务、最低持有期、披露材料、禁售条件、利益冲突和数据更新时间等元数据。没有进入产品宇宙的对象不能被个性化推荐。

Recommendation object, not free text 客户看到的是自然语言, 但系统内部必须生成结构化 recommendation object: 推荐内容、客户画像引用、产品版本、适配理由、替代方案、排除理由、费用和风险披露、冲突标记、置信边界、人工复核状态、执行权限。文本只是该对象的呈现层。

Supervision by evidence, not by trust 监督不能依赖“模型大体可靠”。监督系统需要抽样、异常触发、投诉联动、规则命中、越界话术检测、产品集中度监控和事后回放。每个高风险建议都应能重建当时的决策上下文。

系统/架构模型

能力分层

运行时流程

1. 解析渠道、客户身份、账户类型和服务授权。
2. 识别客户意图, 将交互映射到 advice boundary state。
3. 检查客户画像完整性、时效性和适用性限制。
4. 从 approved universe 拉取产品事实、费用、风险和限制条件。
5. 组合构建或产品排序只在可解释约束内运行。
6. 生成 recommendation object, 包含推荐、替代方案、排除项和披露。
7. 根据风险等级决定自动呈现、人工复核、转人工或拒绝回答。
8. 写入 evidence graph, 供监督、投诉、回放和模型再验证使用。

Recommendation object 示例

recommendation_id: rec-2026-wealth-0001
boundary_state: portfolio_recommendation
customer_context:
  profile_version: inv-profile-v17
  risk_capacity: moderate
  horizon: 7_years
  liquidity_need: medium
product_context:
  universe_version: approved-funds-2026-06
  excluded_products:
    - product_id: fund-x
      reason: concentration_limit
recommendation:
  action: rebalance
  target_allocation:
    equity_fund: 0.45
    bond_fund: 0.40
    cash_like: 0.15
evidence:
  suitability_rules: [risk_match, horizon_match, liquidity_check]
  disclosure_ids: [fee_disclosure_v4, risk_disclosure_v9]
  conflict_flags: []
control:
  human_review_required: false
  execution_allowed: separate_confirmation_required

关键机制与取舍

教育和建议的边界 教育内容可以解释概念、费用、风险和一般原则。个性化建议会使用客户画像和具体产品, 因此需要更严格证据和监督。过度保守会降低客户体验, 过度开放会把教育页面变成未经治理的推荐渠道。可行做法是用 boundary state 明确每一类回答能使用的数据和输出对象。

规则、优化器和生成模型的分工 规则适合硬约束: 禁售、画像缺失、集中度、风险等级、费用披露。优化器适合组合权重和约束满足。生成模型适合解释、澄清和呈现。把推荐排序完全交给生成模型会削弱可重放性; 把所有交互都写死又会失去对复杂客户问题的响应能力。

产品范围和商业目标的冲突 平台可能有推广产品、关联产品或高收入产品。系统不能只在前端披露冲突, 还要在排序策略里记录冲突处理方式: 是否排除、降权、展示替代方案、触发人工复核。否则披露会变成形式控制。

人工交接的深度 简单的“联系客服”按钮不是有效交接。有效交接需要 warm handoff package: 客户问题、已收集画像、系统判断、未解决风险、推荐草案、证据链接和不得继续自动化的原因。交接太早会吞噬运营能力, 太晚会让 AI 承担超出授权的建议职责。

客户理解与系统合规的张力 解释越完整, 客户越容易理解; 但披露过载会造成形式阅读。架构上应把披露拆成必显要点、上下文展开、客户确认和证据记录, 而不是把所有条款塞进一段长文。

证据与控制

控制体系要覆盖上线前和上线后。上线前关注用例分级、边界测试、幻觉测试、产品事实校验、画像缺失测试、越界诱导测试和人工复核负载。上线后关注产品集中度、转人工率、投诉率、建议撤回率、披露确认异常、越界话术、客户损失事件和规则漂移。

模型风险管理不应只评估生成质量, 还要评估系统级行为: 检索是否只使用 approved universe, 工具调用是否受边界限制, 规则版本是否与模型输出一致, recommendation object 是否能被完整回放, 新产品上线是否触发再验证。

金融零售/AI产品场景

自助投资教育 客户询问 ETF、债券基金、再平衡或费用差异。系统可以解释概念和一般比较, 但不能根据客户持仓给出“你应该买某产品”的建议。架构重点是 boundary classifier、知识来源控制和越界澄清。

Robo-advisor 组合建议 客户完成画像后获得目标组合和再平衡建议。系统必须连接画像、投资政策、产品宇宙、组合约束、披露和执行确认。关键不是推荐文案, 而是组合建议对象和证据链。

客户经理助手 AI 为一线人员整理客户情况、产品限制和可讨论主题。客户经理仍承担受控流程内的判断和沟通责任。系统需要区分“给员工的分析草稿”和“可直接发给客户的建议文本”。

退休或长期目标规划 模型可以做情景模拟和敏感性分析, 但假设、收益率、通胀、税务和提款规则必须显式版本化。输出应展示不确定性和关键假设, 而不是给出确定收益承诺。

再平衡与税务敏感账户 再平衡建议可能触发费用、税务、流动性和客户偏好问题。系统需要把成本、限制和替代路径纳入 recommendation object, 不能只按目标权重自动卖出或买入。

投诉和争议处理 客户称“AI 建议我买了不合适的产品”。如果证据图完整, 机构可以重放画像、产品事实、规则、披露、人工复核和执行确认; 如果证据缺失, 争议会退化成对聊天记录的主观解释。

反模式

最终心智模型

财富建议 AI 的成熟问题不是“AI 能不能推荐基金”, 而是“在什么业务身份、什么客户关系、什么画像质量、什么产品宇宙、什么披露和监督条件下, 哪一种推荐对象可以被生成、呈现、复核和执行”。

可上线的系统要同时回答四个问题: 边界是否清楚, 推荐是否有依据, 冲突是否被处理, 证据是否可重放。只要其中一个问题无法回答, AI 就不应被视为财富建议能力, 只能被视为尚未治理的内容生成能力。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。