开头先从一个真实场景说起我一直觉得金融行业是大语言模型最难啃的骨头之一。原因很简单别的内容错了用户顶多骂两句投顾内容错了用户是真的会亏钱。但反过来投顾又是大语言模型最能创造价值的方向——传统投顾的服务成本高得离谱一个合格的投资顾问一天最多服务几十个客户而大语言模型可以同时面对百万级用户并且在对话中不断调整表达方式。我见过太多团队在这个方向上翻车。他们最常犯的错误是把大语言模型当成一个“更聪明的搜索引擎”问一句答一句答完就完。结果做出来的东西根本不是“千人千面”而是“千篇一律换了个话术”。真正要做出私人投顾的效果靠的不是模型本身而是围绕模型搭起来的一整套体系用户画像、知识库、推理链路、话术生成、合规审查、安全部署。这篇文章就是把这套体系拆开讲讲每一层到底怎么做、为什么这么做、以及哪些坑我踩过了不想让你再踩。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. reasoning2-3条逻辑必须引用检索材料或数据 3. risk_notice至少一条风险提示 4. followup_question一个用于进一步了解用户需求的追问 禁止输出收益承诺禁止断言未来涨跌。这套模板的核心思想是把画像标签变成模型的“角色设定”。模型不是在“给所有人回答问题”而是在“以这个特定用户的专属投顾身份回答他的问题”。语言风格这个字段尤其好用——同一个答案对喜欢数据论证的用户就多放数字和图表描述对喜欢通俗比喻的用户就多用“就像是……”的类比解释。5.3 工具调用与实时数据让模型承认自己不知道投顾场景最忌讳的是用过期数据。模型知识截止日期之外的市场走势、净值变化、费率调整模型并不知道。所以我把工具调用做成了一道强制环节凡是涉及行情、净值、费率的请求模型必须先调用查询工具拿实时数据才能生成回答。这个链路是用户提问 → 模型判断是否需要实时数据 → 如果需要生成结构化工具调用请求如query_quote(symbol005827)→ 工具返回数据 → 模型结合数据生成最终回答。实测中有一个难点模型有时会在拿了数据之后依然引用自己记忆里的旧数字。比如工具的实时数据明明显示净值跌了模型却在逻辑推理部分写了“该基金历史表现稳健”。解决方案是在提示词里强约束“所有列出的数字必须来自工具返回的数据或检索材料中明确标注的内容不得使用训练记忆中的数值。”同时在输出结构校验环节对关键数字做一次比对不一致就拦截重生成。另外一个容易被忽略的点模型要会说“不知道”。很多模型在压力下会编造信息硬答这在投顾场景是致命的。我在提示词里明确允许模型在检索结果不足时回复“根据目前可获取的信息暂时无法准确回答建议您联系人工投顾或在交易日咨询基金公司”。这句话看起来简单但能在系统层面杜绝大量幻觉。6. 合规审查、幻觉治理与本地部署投顾落地绕不开的三个现实问题6.1 幻觉治理金融场景的容错率是零前面各章其实都在铺垫一件事把幻觉控制到尽可能低。这里单独拎出来讲是因为它太重要了。我把幻觉分为两类治理。硬幻觉数字、名称、日期错了。比如把某基金的成立日期从 2019 年写成 2021 年。这一类靠“数字比对 来源引用”来治理——模型输出的每个关键数字都要能在检索材料或实时工具数据里找到对应来源找不到就触发重生成或拒答。软幻觉推理逻辑错了但单个数字都没错。比如“该基金近三年年化收益 8%因此建议满仓买入”——数字是对的但“满仓买入”这个建议本身经不起推敲。这一类治理难度更高需要两个手段配合一是 prompt 里明确限定推理边界比如“只能基于检索材料中的事实做推理不得做材料和材料之间没有依据的因果推导”二是给模型配一套“建议保守度”参数当用户风险等级偏低或信号显示情绪焦虑时自动把建议语气调得更谨慎。金融场景的幻觉治理是永远做不完的心态上要接受“最低可接受率”而不是“绝对消除”同时用流程兜底——高风险建议必须经过规则引擎或人工抽查。6.2 适当性匹配与合规审查链路投顾服务有个核心原则产品风险等级必须和用户风险承受能力匹配。做千人千面输出时这个原则很容易被“个性化”冲掉——系统为了让回答显得贴心和精准可能推荐了超出用户承受能力的产品。我的做法是在生成链路之后加一道独立于大语言模型的规则引擎校验。大语言模型负责生成自然语言建议规则引擎负责检查建议中的产品风险等级是否在用户承受范围内。检查项至少包括产品风险等级 ≤ 用户风险等级建议仓位是否符合用户流动性需求是否包含完整的风险提示语句是否包含收益承诺类禁用词。这两层分离是刻意的。大语言模型擅长生成语言不擅长做二值判断规则引擎正好相反。让模型又生成又判断既慢又容易出错。校验不过的输出直接拦截可以触发改写、降级为保守表述、或转人工服务。这一条链路跑通之后合规抽查通过率才能从“看运气”变成“稳定达标”。6.3 本地部署的现实意义数据不出域、模型可审计聊到“本地部署大语言模型”不少团队第一反应是“太贵了”“没必要”。但在金融投顾场景本地部署往往不是成本问题而是合规底线问题。原因有两条。第一用户画像、持仓、交易记录这些数据属于极敏感数据通过公网调用商业模型 API数据出境和第三方留存的问题很难回避。即便商业 API 提供商承诺“数据不留存”在严格的合规审查下依然很难被接受。第二投顾服务如果出了纠纷监管和审计需要你说明“当时那个建议是怎么生成的、依据是什么”。本地部署意味着你可以完整记录输入、检索材料、模型输出、规则校验结果的全链路日志做到可解释、可审计。这一点在外调 API 的场景里很难完全做到。本地部署的实际成本没有想象中那么可怕。推理资源按并发量估算的话一个 7B-13B 的模型在量化后单卡即可服务日活万级以内问题不大70B 模型需要多卡集群但可以通过排队策略控制峰值并发。如果既有效果要求又有成本约束一个务实的折中方案是“本地小模型 API 大模型”混合路由常规对话走本地模型复杂问题再请求云端大模型敏感用户数据先在本地做脱敏和过滤。当然考虑到数据安全和合规本地优先是趋势。提示本地部署不只是把模型权重拷到内网跑起来还包括内网知识库、内网向量检索服务、内网审计日志系统。整个链条都要在封闭网络内闭环才真正算“数据不出域”。6.4 多模态与视觉大语言模型的扩展空间这一节聊点进阶的。投顾场景里用户上传的截图、基金净值走势图、K线图、资产配置饼图——这些视觉信息用纯文本模型是处理不了的。视觉大语言模型在这里就有用武之地了用户拍一张持仓截图问“我这配置是不是太集中了”视觉模型直接读图提取持仓明细再交给文本模型做诊断和建议。不过要泼一盆冷水视觉大语言模型在金融图表上的识别精度还远不够稳定坐标轴、图例、复权方式等细节都可能识别错。我建议把它当“辅助输入通道”而非“权威数据来源”读取后必须和结构化数据接口做交叉核对逐项确认无误再进入推理环节。这里想清楚角色的边界视觉模型才有实用价值。我现在比较看好的扩展方向是“多模态投顾双录与情绪识别”和“智能研报解读”——后者让模型直接读懂图表里的趋势和拐点而不是靠人先把图表转成文字能大幅提升 RAG 知识库的覆盖效率。但这些都是锦上添花的增量前提还是前面说的文本推理链路和数据底座做得足够扎实。最后分享一点个人体会做这套系统最大的感受是“千人千面”不是靠模型一个环节完成的而是整套系统工程的结果。用户画像负责“懂用户”知识库负责“有依据”推理链路负责“讲逻辑”规则引擎负责“守底线”本地部署负责“保安全”大语言模型只是这条流水线上最显眼的一环。任何一个环节掉链子最后那个“私人投顾”的效果都会崩。我在实际项目里反复验证过把 RAG 的召回质量做扎实比换一个更大的基底模型带来的收益更明显把输出结构约束做好比在提示词里反复强调“注意安全”有效得多。这套方法论不限于金融凡是需要“个性化 强合规 高可信”的内容生成场景都可以照着这个框架来搭。