开头：先从一个真实场景说起
我一直觉得，金融行业是大语言模型最难啃的骨头之一。原因很简单：别的内容错了，用户顶多骂两句；投顾内容错了，用户是真的会亏钱。但反过来，投顾又是大语言模型最能创造价值的方向——传统投顾的服务成本高得离谱，一个合格的投资顾问一天最多服务几十个客户，而大语言模型可以同时面对百万级用户，并且在对话中不断调整表达方式。
我见过太多团队在这个方向上翻车。他们最常犯的错误，是把大语言模型当成一个“更聪明的搜索引擎”，问一句答一句，答完就完。结果做出来的东西根本不是“千人千面”，而是“千篇一律换了个话术”。真正要做出私人投顾的效果，靠的不是模型本身，而是围绕模型搭起来的一整套体系：用户画像、知识库、推理链路、话术生成、合规审查、安全部署。这篇文章就是把这套体系拆开，讲讲每一层到底怎么做、为什么这么做、以及哪些坑我踩过了不想让你再踩。
1. 千人千面投顾的真实挑战：大语言模型到底在解决什么
1.1 传统投顾的“千人千面”为什么只是标签分层
先说结论：过去行业里喊的“千人千面”，绝大部分是标签分层的“假千人千面”。
传统做法大概是这样的：把用户按资产规模、风险等级、年龄、持有产品分成几档，每档配一套标准话术和推荐组合。比如 30 岁、高风险偏好、有稳定收入的用户，系统就给他推成长型基金组合；55 岁、临近退休、保守型用户，就给他推债券和固收类产品。听起来很合理对不对？但用户实际体验是——“我知道系统知道我多少钱，但感觉它并不懂我”。
问题出在两个地方。第一，标签是静态的。用户昨天看到了什么内容、上周问过什么问题、最近市场波动时他的焦虑程度如何，这些信息标签体系根本捕捉不到。第二，标签是群组化的。同一风险等级的人内部差异极大，有人是“能承受波动”的高风险，有人是“嘴上说能承受但其实连跌三天就失眠”的高风险，标签体系分不出这种差别。
所以传统“千人千面”本质上还是一个漏斗式的粗筛，只是把用户切得更细了一点，距离“私人投顾”这个承诺差了很远。
1.2 大语言模型带来的三个根本变化
大语言模型的出现，让“私人投顾”第一次有了真正意义上的技术抓手。我总结下来，它带来三个根本性变化：
第一个变化是从“检索匹配”变成“生成对话”。传统系统是把你匹配到某个产品页、某篇文章，大语言模型则是针对你的问题现场生成一段分析。用户问“我现在手里有 20 万闲钱，最近有点慌，不知道要不要加仓”，传统系统只能推荐几篇文章让他自己看，大语言模型却可以结合他的持仓结构、风险偏好、当前市场状态，生成一段包含具体建议和理由的回应。
第二个变化是从“静态标签”变成“动态语义画像”。大语言模型可以在多轮对话里持续理解用户的真实意图和情绪。用户抱怨“最近跌得睡不着觉”，这本身就是一个强特征：他对回撤的容忍度跟问卷里勾选的“高风险偏好”是矛盾的。这种信息放在传统标签体系里根本没法结构化，但大语言模型可以把它纳入上下文，在后续对话中调整建议的激进程度。
第三个变化是从“统一话术”变成“个性化表达”。同一个投顾结论，面对一个金融专业的用户和面对一个完全不懂基金的小白，表达方式应该完全不同。大语言模型天然具备这种“同一结论、不同讲法”的能力，关键在于你怎么设计提示词和输出结构。
但这里必须说一句：这三个变化不会自动发生。它们依赖的是一套完整的系统设计，接下来我逐层拆解。
2. 基底模型选型与金融能力评测：通用底座为什么撑不起投顾场景
2.1 先澄清一个概念：生成式语言模型和大语言模型的关系
很多人问“生成语言模型和大语言模型是一个东西吗”，包括不少做技术的朋友也容易混淆。简单说：大语言模型是一个更宽泛的范畴，生成式语言模型是大语言模型里最主要、最成功的一类。以自回归方式训练的生成式语言模型，比如你熟悉的那些对话模型，它们做的事情就是“给定上文，预测下一个词”，一路预测下去就生成了一整段话。之所以大家平时把两者混着叫，是因为近几年出圈的大语言模型几乎都是生成式的。
在投顾场景里，我们用的是生成式语言模型的“续写+上下文理解”能力，而不是早期那种只会做填空的“语言模型”。搞清楚这个区别，对你选型有帮助——因为金融场景需要的是能长文本推理、能调用工具、能遵循复杂指令的生成式大语言模型，而不是单纯的“语言理解模型”。
2.2 金融场景对基底模型的四项硬指标
我在选基底模型的时候，基本只看四件事，跟跑分关系不大：
长上下文能力要扎实，而不是数字好看。投顾对话往往涉及多轮历史、持仓明细、研报片段，上下文动辄上万 token。有些模型宣传 32K、128K 上下文，但实测下来中间内容会“遗忘”——开头说过的风险等级，聊到后面它就不记得了。我一般会自测一个“长文信息保持”用例：把一份 2 万字的持仓报告放在前文，然后在第 3 万 token 的位置问一个关于报告里某个数字的问题，看它答得准不准。
指令遵循能力要强。投顾系统里，模型的输出要严格遵循固定 JSON 结构，便于下游做合规校验和渲染。很多模型聊起天来挺好，但让它“只输出 JSON 不要任何多余内容”的时候就翻车。这一项必须用真实任务的格式去测，而不是测那些公开的指令遵循榜单。
工具调用能力要可用。私人投顾一定要接实时行情和账户数据，这就需要模型能自己判断“该查行情了”还是“该查用户持仓了”。工具调用的准确率直接决定了系统的实用程度。划重点：工具调用不是“模型会生成一段包含工具名的文本”，而是能稳定输出结构化的调用参数，这个差距很大。
金融基础能力要过硬，但不指望它当专家。我不要求基底模型懂多少金融知识，因为知识可以靠 RAG 和微调注入。我要求的是它“不胡编”的底线意识：不懂的东西能老老实实说不知道，而不是硬编一个 3.5% 的收益率出来。
综合这四点，目前市面上可选的开源基底模型里，7B-14B 量级适合做轻量部署和冷启动，70B 量级效果明显更好，但推理成本和延迟要高出不少。商业 API 在效果上通常更省心，但数据出境和合规问题在金融场景里往往一票否决——后面第 6 章我会细讲本地部署的逻辑。
2.3 自建评测集：比起分数，更看重翻车方式
公开榜单的分数在金融场景里参考价值有限。榜单题目偏通用，考察的是“知识面广不广”，而投顾要的是“在特定场景下别出错、出错也别出大错”。
我是这么做的：从历史客服对话、投顾问答、用户投诉里抽了 300 条真实问题，整理成三个维度的评测集。第一维度是准确率：答案里的数字、日期、产品名称必须和事实一致。第二维度是合规性：涉及收益承诺、风险提示缺失、不当比较的话术一律算错。第三维度是体验感：答案是否符合用户当前的情绪和认知水平，比如对焦虑用户必须先安抚再给建议，而不是冷冰冰甩一堆数据。
这个评测集不只看总分，我更在意“翻车方式分布”。A 模型可能总体准确率稍高，但它在用户问“会不会亏本”时给出的回答里没有风险提示，这是致命问题；B 模型准确率低一些，但出错都错在“推荐的产品不够精准”这种可修正的层面，反而更让人放心。选基底模型不能只看平均分，要看错误是否集中在不可接受的区域。
3. 数据接入与用户画像：让模型真正了解“你家底”
3.1 你手里的数据比你想象的脏
做千人千面投顾，第一步不是调模型，是整理数据。我见过太多团队开开心心把模型接上线，结果发现用户画像里全是坑——年龄字段是空的、资产规模是两年前的、风险测评结果是注册时随便点的。
金融行业的数据脏是有原因的：一个用户可能在 App、柜台、人工投顾、第三方渠道留下多套信息，ID 体系还不统一；持仓数据来自交易系统，浏览行为来自埋点系统，客服记录又是另一个库，字段含义各不相同。要做用户画像，首先要做的是打通 ID 和图谱：用手机号、证件号、设备 ID 做实体对齐，把同一个用户的碎片信息合并成一张全景表。
这里分享一个经验：别一开始就追求全字段覆盖。我惯用的做法是先圈定对投顾决策影响最大的几个核心字段——风险等级、可投资资产、持仓结构、投资经验、收益目标、流动性需求、近期行为信号——把这几项先做准、做实时，比贪多求全实用得多。一个字段不准的数据，对模型的误导作用比没有这个字段还大。
3.2 用户画像标签体系是“千人千面”的地基
画像标签分三层，每层的构建方式不同：
基础属性层：年龄、职业、地域、家庭结构。这些影响的是投资期限和流动性需求。比如一个 35 岁、有两个孩子的用户，即便风险偏好高，也不适合把大部分资产放在高波动品种里。
行为特征层：历史交易频率、持仓集中度、对回撤的实际反应、浏览内容偏好。这一层的数据最有价值，因为它反映的是“真实行为”而不是“自我认知”。有个很经典的例子：用户在问卷里选“能承受 20% 回撤”，但系统记录显示他每次浮亏超过 5% 就会赎回。行为特征层能识别这种偏差，在给建议时自动保守一档。
实时意图层：用户最近问了什么、看了什么、市场发生了什么。这是大语言模型最擅长捕捉的一层，也是实现“千人千面”的关键变量。同样是问“新能源能不能买”，如果用户刚看完某只新能源基金的详情页，那他大概率是在考虑买入而非单纯好奇；如果市场刚大跌两天，他问的潜台词可能是“我要不要跑”。
这三层标签不是静态存储的，而是作为上下文实时注入模型的提示词。画像存储建议用 KV 结构或标签表，但注入提示词时要做筛选——一次对话只需要最相关的 10-20 个信号，把几百个标签全塞进去反而会稀释模型的注意力。
3.3 隐私计算与数据脱敏：敏感信息不落模型参数
金融数据天然敏感，用户资产、持仓、交易记录这些信息，不能直接拿来当语料微调模型。这里要分清两条线：模型训练时不碰真实用户数据，模型推理时只读必要的最小字段。
训练层面：如果要微调模型，用的语料必须经过严格脱敏，最好用合成数据——根据真实分布生成一些假的用户案例，让模型学会“在什么情况下怎么说话”，但不让它“记住”任何真实用户。合成数据做得够好，微调效果不会差太多，而且安全边界非常清晰。
推理层面：用户画像和持仓信息只存在于运行时上下文中，随请求结束即销毁，不写入模型记忆。技术上可以做字段级加密、脱敏展示、权限控制，关键原则是“模型服务只拿到完成任务所需的最小数据集合”。比如生成投资建议时，模型需要知道用户风险等级和持仓结构，但不需要知道用户身份证号和完整家庭住址。这些字段在注入前就应该被过滤掉。
4. RAG知识库实战：把研报、公告和合规意见装进模型的工作记忆
4.1 投顾知识库的组成：不只是研报
很多人一说到 RAG 就觉得是“把文档切碎、向量化、检索”，但投顾场景的知识库远不是这么简单。我按来源和用途把知识分成四类：
产品知识：基金合同、招募说明书、定期报告、公告。这类文档长、结构固定、数字密集，是检索的重灾区。用户问“这只基金的管理费是多少”，系统得能从几十页的招募说明书里精确找到费率那一节。
市场观点：宏观策略、行业研究、市场点评。这类内容时效性极强，一个季度前的观点很可能已不适用，必须在入库时打上时间戳，检索时按时间衰减或过滤。
合规规则：适当性管理办法、风险提示规范、产品宣传红线。这类内容是刚性的，必须确保模型在生成话术时随时能引用到——它决定了哪些话能说、哪些不能说、哪些说了必须附带什么提示。
用户历史沟通记录：用户之前问过什么、投顾之前怎么答的。这部分不是公开文档，属于机构内部知识，但它对个性化输出价值极大。比如用户三个月前问过“定投真的靠谱吗”，投顾回答过一轮，这次用户再问，系统就能基于上下文给出更有连贯性的回答。
这四类内容在 RAG 链路里的权重、新鲜度要求、切分策略都不同，不能一锅炖。
4.2 切分与向量化：对金融文档最友好的策略
金融文档的切分，比通用文档要更讲究。通用做法是按固定长度切块，比如 512 或 1024 个字符一刀切——这么做在金融场景会出大问题。举个例子：一只基金的招募说明书里，风险提示可能在第一节，产品费率在第五节，但如果用户问“这只基金风险高吗？贵不贵？”，固定切分可能把这两个信息切到不同块里，检索只能召回其中一块，另一个问题就答不了。
我现在的做法是按语义结构切分 + 重叠片段冗余。第一步用文档结构识别器把 PDF/Word 解析成章节树，按章节边界切开；第二步如果章节过长，再按段落和句子边界切开，相邻块保留 20% 左右的重叠区域；第三步把章节标题和上下文摘要作为块元数据一起存入向量库。这样检索时能够更准确地定位。
Embedding 模型的选择上，金融文本有不少专业术语和数字表达，我用开源的通用中文 embedding 模型跑出来的效果一般，后来用领域语料微调过一轮，检索召回率提升明显。实测下来，在投顾问答上的 Top-5 命中率大概从 62% 提到了 78%——这个差距在日常体验上是能感知到的。如果团队没有资源微调 embedding，至少要做一步“查询改写”，把用户的口语问题改写成检索友好的书面语句，也能显著缓解 mismatch。
4.3 混合检索与重排序：别让模型被噪声带偏
金融领域里，同样一个词在不同上下文里意思完全不同。比如“快赎”在货币基金场景是好事，在股票质押场景可能是风险信号；“杠杆”在 ETF 里是产品特性，在个股融资里是风险指标。纯向量检索对这类语义变化不够敏感，所以我用关键词检索 + 向量检索混合召回，再用重排序模型做精细筛选。
具体实现上：BM25 负责精确匹配专业名词和数字，比如“华夏XX混合C”“管理费 0.15%”；向量检索负责语义相似召回，比如“这笔钱我半年后要用”应该能匹配到“短期闲置资金理财”相关内容。两路召回合并后，经过一个 cross-encoder 重排序模型，把真正和用户问题相关的 top 3-5 块捞出来送给大语言模型。
重排序这一步看起来多了一道计算开销，但效果提升非常大。我曾经做过 A/B 对比：不加重排序时，模型经常被低相关性但高语义相似度的碎片干扰，出现答非所问的情况；加重排序后，答案准确率明显提升，幻觉率也下降了——因为喂给模型的“原材料”质量上来了。
5. 推理链路与话术生成：从“给结论”到“讲逻辑”
5.1 投顾输出的三级结构：结论、逻辑、风险
模型生成投顾回答时，不能让它自由发挥，必须用强结构约束输出。我设计了一个三级结构模板，所有面向用户的对话都必须遵循：
第一级是直接结论：用一两句话说清楚建议是什么。比如“不建议你现在追加新能源仓位”或“可以把 20% 的货币基金转为债券基金”。结论必须放在最前面，不能藏着掖着。
第二级是推理逻辑：用用户可以理解的语言解释“为什么”。这里的关键是引用检索到的具体事实，比如“当前该指数的估值分位处于近三年 78% 的高位，而你的持仓中成长风格已经占到了 40%”。逻辑链条要让用户看得懂、觉得有道理，而不是用“经综合分析”这种空话带过。
第三级是风险提示与情景说明：说明这个建议在什么条件下可能不成立，以及可能面临的最大回撤。比如“如果你选择追加，需要做好半年内最大回撤 15% 的准备；如果不追加，错过的可能是市场反弹的收益”。
这个三级结构不仅是体验设计，也是合规要求。金融投顾服务的通行原则是不能只给“好听的结论”，必须告知风险。把风险提示强制放在输出结构里，比指望模型“自觉”靠谱得多。
5.2 Prompt模板里的“个性化变量”
千人千面落到实处，靠的是 prompt 里的个性化变量注入。我的做法是把系统提示词设计成一个固定框架 + 动态槽位：
【角色】你是一名持证投顾助理，服务对象信息如下： - 风险等级：{risk_level}（实际行为修正：{behavior_adjustment}） - 可投资资产区间：{asset_range} - 持仓集中度：{concentration}，其中单一行业占比 {top_sector_pct} - 历史最大回撤承受：{max_drawdown_tolerance} - 最近行为信号：{recent_signals}（例如：3天内反复查看某产品详情页） - 语言偏好：{language_style}（例如：通俗比喻型/数据论证型/简明直接型） 【本次任务】用户提问：{user_question} 【检索材料】{rag_context} 【知识市场数据】{market_data} 【输出要求】 必须按结构化格式输出，包含： 1. conclusion（一句话结论） 2. reasoning（2-3条逻辑，必须引用检索材料或数据） 3. risk_notice（至少一条风险提示） 4. followup_question（一个用于进一步了解用户需求的追问） 禁止输出收益承诺，禁止断言未来涨跌。这套模板的核心思想是：把画像标签变成模型的“角色设定”。模型不是在“给所有人回答问题”，而是在“以这个特定用户的专属投顾身份回答他的问题”。语言风格这个字段尤其好用——同一个答案，对喜欢数据论证的用户就多放数字和图表描述，对喜欢通俗比喻的用户就多用“就像是……”的类比解释。
5.3 工具调用与实时数据：让模型承认自己不知道
投顾场景最忌讳的是用过期数据。模型知识截止日期之外的市场走势、净值变化、费率调整，模型并不知道。所以我把工具调用做成了一道强制环节：凡是涉及行情、净值、费率的请求，模型必须先调用查询工具拿实时数据，才能生成回答。
这个链路是：用户提问 → 模型判断是否需要实时数据 → 如果需要，生成结构化工具调用请求（如query_quote(symbol="005827")）→ 工具返回数据 → 模型结合数据生成最终回答。
实测中有一个难点：模型有时会在拿了数据之后，依然引用自己记忆里的旧数字。比如工具的实时数据明明显示净值跌了，模型却在逻辑推理部分写了“该基金历史表现稳健”。解决方案是在提示词里强约束：“所有列出的数字必须来自工具返回的数据或检索材料中明确标注的内容，不得使用训练记忆中的数值。”同时在输出结构校验环节，对关键数字做一次比对，不一致就拦截重生成。
另外一个容易被忽略的点：模型要会说“不知道”。很多模型在压力下会编造信息硬答，这在投顾场景是致命的。我在提示词里明确允许模型在检索结果不足时回复“根据目前可获取的信息，暂时无法准确回答，建议您联系人工投顾或在交易日咨询基金公司”。这句话看起来简单，但能在系统层面杜绝大量幻觉。
6. 合规审查、幻觉治理与本地部署：投顾落地绕不开的三个现实问题
6.1 幻觉治理：金融场景的容错率是零
前面各章其实都在铺垫一件事：把幻觉控制到尽可能低。这里单独拎出来讲，是因为它太重要了。
我把幻觉分为两类治理。硬幻觉：数字、名称、日期错了。比如把某基金的成立日期从 2019 年写成 2021 年。这一类靠“数字比对 + 来源引用”来治理——模型输出的每个关键数字，都要能在检索材料或实时工具数据里找到对应来源，找不到就触发重生成或拒答。
软幻觉：推理逻辑错了，但单个数字都没错。比如“该基金近三年年化收益 8%，因此建议满仓买入”——数字是对的，但“满仓买入”这个建议本身经不起推敲。这一类治理难度更高，需要两个手段配合：一是 prompt 里明确限定推理边界，比如“只能基于检索材料中的事实做推理，不得做材料和材料之间没有依据的因果推导”；二是给模型配一套“建议保守度”参数，当用户风险等级偏低或信号显示情绪焦虑时，自动把建议语气调得更谨慎。
金融场景的幻觉治理是永远做不完的，心态上要接受“最低可接受率”而不是“绝对消除”，同时用流程兜底——高风险建议必须经过规则引擎或人工抽查。
6.2 适当性匹配与合规审查链路
投顾服务有个核心原则：产品风险等级必须和用户风险承受能力匹配。做千人千面输出时，这个原则很容易被“个性化”冲掉——系统为了让回答显得贴心和精准，可能推荐了超出用户承受能力的产品。
我的做法是在生成链路之后加一道独立于大语言模型的规则引擎校验。大语言模型负责生成自然语言建议，规则引擎负责检查建议中的产品风险等级是否在用户承受范围内。检查项至少包括：产品风险等级 ≤ 用户风险等级；建议仓位是否符合用户流动性需求；是否包含完整的风险提示语句；是否包含收益承诺类禁用词。
这两层分离是刻意的。大语言模型擅长生成语言，不擅长做二值判断；规则引擎正好相反。让模型又生成又判断，既慢又容易出错。校验不过的输出直接拦截，可以触发改写、降级为保守表述、或转人工服务。这一条链路跑通之后，合规抽查通过率才能从“看运气”变成“稳定达标”。
6.3 本地部署的现实意义：数据不出域、模型可审计
聊到“本地部署大语言模型”，不少团队第一反应是“太贵了”“没必要”。但在金融投顾场景，本地部署往往不是成本问题，而是合规底线问题。
原因有两条。第一，用户画像、持仓、交易记录这些数据属于极敏感数据，通过公网调用商业模型 API，数据出境和第三方留存的问题很难回避。即便商业 API 提供商承诺“数据不留存”，在严格的合规审查下依然很难被接受。第二，投顾服务如果出了纠纷，监管和审计需要你说明“当时那个建议是怎么生成的、依据是什么”。本地部署意味着你可以完整记录输入、检索材料、模型输出、规则校验结果的全链路日志，做到可解释、可审计。这一点在外调 API 的场景里很难完全做到。
本地部署的实际成本没有想象中那么可怕。推理资源按并发量估算的话：一个 7B-13B 的模型在量化后单卡即可服务，日活万级以内问题不大；70B 模型需要多卡集群，但可以通过排队策略控制峰值并发。如果既有效果要求又有成本约束，一个务实的折中方案是“本地小模型 + API 大模型”混合路由：常规对话走本地模型，复杂问题再请求云端大模型，敏感用户数据先在本地做脱敏和过滤。当然考虑到数据安全和合规，本地优先是趋势。
提示：本地部署不只是把模型权重拷到内网跑起来，还包括内网知识库、内网向量检索服务、内网审计日志系统。整个链条都要在封闭网络内闭环，才真正算“数据不出域”。
6.4 多模态与视觉大语言模型的扩展空间
这一节聊点进阶的。投顾场景里，用户上传的截图、基金净值走势图、K线图、资产配置饼图——这些视觉信息用纯文本模型是处理不了的。视觉大语言模型在这里就有用武之地了：用户拍一张持仓截图问“我这配置是不是太集中了”，视觉模型直接读图提取持仓明细，再交给文本模型做诊断和建议。
不过要泼一盆冷水：视觉大语言模型在金融图表上的识别精度还远不够稳定，坐标轴、图例、复权方式等细节都可能识别错。我建议把它当“辅助输入通道”而非“权威数据来源”，读取后必须和结构化数据接口做交叉核对，逐项确认无误再进入推理环节。这里想清楚角色的边界，视觉模型才有实用价值。
我现在比较看好的扩展方向是“多模态投顾双录与情绪识别”和“智能研报解读”——后者让模型直接读懂图表里的趋势和拐点，而不是靠人先把图表转成文字，能大幅提升 RAG 知识库的覆盖效率。但这些都是锦上添花的增量，前提还是前面说的文本推理链路和数据底座做得足够扎实。
最后分享一点个人体会
做这套系统最大的感受是：“千人千面”不是靠模型一个环节完成的，而是整套系统工程的结果。用户画像负责“懂用户”，知识库负责“有依据”，推理链路负责“讲逻辑”，规则引擎负责“守底线”，本地部署负责“保安全”，大语言模型只是这条流水线上最显眼的一环。任何一个环节掉链子，最后那个“私人投顾”的效果都会崩。我在实际项目里反复验证过：把 RAG 的召回质量做扎实，比换一个更大的基底模型带来的收益更明显；把输出结构约束做好，比在提示词里反复强调“注意安全”有效得多。这套方法论不限于金融，凡是需要“个性化 + 强合规 + 高可信”的内容生成场景，都可以照着这个框架来搭。
