南宫28官网,南宫28官方网站,南宫28APP下载先回到“智能投顾”本身。这个概念早在十年前就已进入公众视野。2008 年次贷危机后，传统人工投顾因销售道德风险而备受质疑，硅谷随之诞生了两家明星公司——Wealthfront 与 Betterment。有人把这次迁移称作“ToC 金融从华尔街搬到硅谷”。彼时的智能投顾几乎完全依赖“小模型”：无论是 Black-Litterman、均值 - 方差、Risk Parity 这类资产配置框架，还是打分选股、基金筛选等工具，本质都是参数有限的规则引擎。只要轻轻扭动一两个旋钮，收益曲线就可能彻底改向。这种“黑箱”被少数销售机构掌控，佣金落袋后，盈亏却由投资者独自承担。Wealthfront 与 Betterment 的创举，是把所有算法公开、回测、可复制；2013 年，美国金融业监管局甚至专门出台指引，强制要求这类公司把模型透明化。

　　国内跟进得并不慢。2014 年，行业里陆续出现“拿铁智投”“考拉智投”等原型；同年我回国加入京东，也参与了“京东智投”的雏形设计。2017 年，招商银行推出“摩羯智投”，第一次把智能投顾带进大众视野。然而十年过去，市场始终不温不火。原因并不复杂：投顾圈里常说“三分投、七分顾”，顾问与投资的差异在于“交互”。过去的做法简单粗暴——填一份风险测评，系统吐出一张组合清单，用户照单交易即可。假如王思聪和我都被定为 C5 激进型，系统给出的方案几乎一模一样；可事实上，我们的现金流、负债、储蓄习惯天差地别。没有持续对话，就无法让用户真正理解“为什么给我这个方案”，更谈不上在市场波动中每周、每月与他复盘、调仓。在大模型出现之前，这种高频、人性化、且合规的交互几乎不可能实现。

　　2023 年起，大模型的能力让上述想象落地。国内各家都在迅速拥抱：蚂蚁把原本集成在“支小宝”里的理财问答模块拆成独立品牌“蚂小财”，既满足高合规要求，又能为不同持牌机构（如广发证券、中加基金）建立专属知识边界。在我个人的横向测试里，蚂小财的幻觉比例最低，给出的解释也最易读。同花顺的“问财”则胜在数据：作为老牌数据供应商，它把大模型与 SQL、API 两种主流技术路线同时跑通，分时行情、技术指标选股都能一句话完成；只是语义理解略逊，遇到非标准化提问就容易“跑题”，幻觉也相对明显——我猜测是任务规划链路在高合规场景下容错率太低。至于京东的“京小贝”，目前仍停留在“升级后的客服问答”，距离真正解决用户问题还有一段路要走。

　　我们的做法是在对话流里埋入“意图识别”。当大模型判断用户需要更深层操作时，不再输出长篇文字，而是直接推送一张卡片——卡片背后就是原有功能页面被打散后的 API。用户点击卡片即可进入该页面，继续完成第二段交互。这样，知识不再被锁在各自孤岛，而是以 API 的形式按需注入对话；大模型不必全知全能，只要能听懂意图，再调用相应模块即可。既省了训练成本，又提高了 B 端场景的准确率，也让旧系统第一次以原生的方式被串联起来。

　　在银行场景里，大模型哪怕只错 1%，都可能让不良率直接抬升 1%，这是底线% 的准确率已经足够交差。同样一句话，交给大模型去跑量化投研，往往只给出一堆看似合理却经不起复现的结论；换成小模型，同样的 Black-Litterman 输入立刻能输出可验证的组合权重。更现实的是钱和时间：实测发现，整个链路中大模型占比越高，响应时间越长。若全程使用大模型，回答需 40–50 秒；提高小模型占比后，时间可压缩到 20 秒以内，算力成本直接减半。

　　落到工程上，我们把用户 Query 的处理拆成两步。第一步用 DeepSeek 的 Chain-of-Thought 做扩写，把口语、错别字、倒装句统统翻译成带推理链的结构化意图，省去再训专用分类器的麻烦。第二步交给任务规划 Agent：如果用户问“XX 基金怎么样”，系统自动拆成基本信息、业绩曲线、基金经理、舆情事件等子任务，再决定由谁执行——简单事实大模型直接回，数值指标甩给小模型，舆情缺位就 RAG 现抓，图表需求按模板渲染。整个链路里，原有业务规则和量化引擎原封不动，仅以 API 形式被大模型按需调用，协同而不是替代。

　　实际上，让大模型进行扩写并不需要使用参数过高的模型。例如，没有必要使用 671B 参数的模型来进行扩写，32B 的模型已经足够。我们发现，在每个节点上，如果节点有专业用途，可以使用小参数的大模型，甚至是更小参数的专训模型。例如，在任务拆解和内容分段过程中，小参数模型甚至最小的 0.5B 的大语言模型都可能解决问题。目前，我们最大的专训模型是一个 7B 的模型，用于资产配置等意图分类。因此，在每个环节都可以进行优化。

　　以最常见的 Query 为例，任务拆解后，小模型位于 Agent 之后。无论是使用 Dify 还是其他 MaaS 平台，我们发现现在的 MaaS 平台都支持代码节点或 HTTP API 节点。我们将小模型打包成服务端，直接放在每个 Agent 后面。在 Agent 上，通过提示词和小模型的介绍来确定在什么情况下调用这条链路中的小模型。输出回答后，可能直接调用小模型、查询数据，或者进行联网检索。这些结果出来后，会进行达人融合。达人融合实际上也是一个小型参数的大模型，其主要工作是对回答进行语言润色，调整结构，输出表格等，最终实现对用户问题的回答。

　　在指标查询流程中，我们目前还在使用转 SQL 的方式。但我个人认为，在数据查询过程中，转 API 的形式也是一条不错的路。在 ToB 业务中，虽然目前有一些如字节的 Data Agent 等 API 出现，但我认为通用性上还没有一套完美的 Text to SQL 解决方案。如果场景确定，Text to SQL 是很准确的实现方式。其优势在于，只要写成 SQL，查询结果一定是准确的。最终，我们将这个任务落在了选股或选基的业务场景中，通过一些指标挑选出所需的理财产品。

　　对于金融领域，训练一个通用知识大模型的成本并不高。例如，接入一个通用大模型后，上传一些知识库，编写一些提示词，并搭建一个 Agent，就可以构建一个所谓的金融行业大模型。但是，如果要进一步深入，比如要求模型在投研方面达到专精水平，特别是在撰写股票或上市公司财报方面精通所有财务指标，那么深度训练所需的算力成本将会非常高昂。在这种情况下，将这些专精任务拆分为小模型引擎会更加高效，因为这样可以大幅提高深度算力的利用效率。在相同的专业度下，通过小模型实现的深度回答所需的算力，远远低于将这些知识内化于大模型所需的算力。