使用Dify构建智能投顾问答系统的初步尝试-开发者社区

使用Dify构建智能投顾问答系统的初步尝试

在金融服务领域，客户对投资建议的咨询需求持续增长——从“什么是定投？”到“如何配置一个年化6%收益的稳健组合？”，问题种类繁多、专业性强。传统客服模式下，这类服务高度依赖人工投顾，不仅成本高昂，还面临知识更新慢、响应不及时、服务质量参差等问题。而随着大语言模型（LLM）能力的跃升，越来越多机构开始探索用AI替代或辅助人工提供专业投顾问答服务。

但现实是：直接调用GPT或通义千问等大模型API，并不能立刻产出合规、准确、可落地的回答。幻觉频发、缺乏行业语境、无法接入私有数据……这些问题让许多项目停留在POC阶段。真正需要的，是一个既能发挥LLM强大生成能力，又能融合企业内部知识、满足金融级安全与合规要求的工程化平台。

正是在这种背景下，我们选择了Dify——一款开源的低代码LLM应用开发框架，尝试搭建一套具备生产潜力的智能投顾问答系统。经过几轮迭代，我们不仅实现了分钟级原型构建，还在测试中观察到了显著的服务质量提升。以下是我们从技术选型、架构设计到实际部署的完整实践过程。

为什么是 Dify？

市面上并不缺少AI开发工具，但从金融场景的实际需求出发，Dify有几个关键特质让它脱颖而出：

它不是简单的聊天界面封装，而是支持可视化工作流编排的全栈式平台；
原生集成RAG（检索增强生成），能轻松对接企业知识库；
支持函数调用（Function Calling）和Agent机制，为未来智能化扩展留足空间；
提供完整的版本管理、环境隔离与权限控制，符合企业级交付标准。

换句话说，它把原本分散在Prompt工程、向量检索、API集成、日志监控等多个环节的工作，统一在一个可视化的操作界面上。产品经理可以参与调试提示词，算法工程师可以注册自定义工具，运维团队也能看到清晰的调用链路——这种协作效率，在传统开发模式下几乎难以想象。

系统是怎么跑起来的？

我们的目标很明确：用户输入一个问题，系统能结合公司内部投研资料、产品说明书和实时市场数据，给出专业、合规、个性化的回答。整个流程看似简单，背后却涉及多个模块的协同运作。

当用户在前端提问“偏保守型投资者该如何配置资产？”时，Dify会按如下路径处理请求：

接收输入：通过Web UI或API入口捕获自然语言问题；
路由判断：根据意图识别结果进入“投资建议”工作流；
知识检索：
- 将问题编码为向量，在FAISS向量数据库中搜索最相关的文档片段；
- 匹配《稳健型资产配置策略》《固收+产品白皮书》等材料中的相关内容；
上下文注入：将检索结果作为背景知识插入Prompt模板；
模型推理：调用Qwen-Max生成回答，过程中遵循预设的角色设定与输出规范；
后处理与返回：过滤敏感表述，结构化输出建议，并回传至前端。

整个流程平均耗时约1.8秒（P95），完全满足线上服务的SLA要求。更重要的是，所有步骤都可以在Dify的画布式编辑器中以拖拽方式完成，无需编写大量胶水代码。

graph TD A[用户提问] --> B{是否需检索?} B -->|是| C[向量化问题] C --> D[FAISS向量库匹配] D --> E[获取Top-K相关段落] E --> F[构造增强Prompt] B -->|否| F F --> G[调用LLM生成] G --> H[后处理: 过滤/结构化] H --> I[返回答案]

这个流程图看起来像极了传统微服务架构的数据流，但它完全由非技术人员在图形界面上“拼”出来的。比如，“向量化问题”对应的是“知识检索节点”，“调用LLM生成”则是“大模型推理节点”。每个节点都有参数配置面板，支持条件分支、变量传递和错误重试，逻辑清晰且易于维护。

RAG 是怎么发挥作用的？

很多人以为，只要把PDF扔进知识库，AI就能自动变聪明。但我们发现：知识库的质量直接决定了系统的上限。

初期我们上传了上百份PDF格式的投研报告，结果发现检索效果很差——模型经常引用无关段落，甚至出现张冠李戴的情况。排查后发现问题出在三个环节：

文档解析质量差：原始PDF包含页眉、页脚、图表标题等噪声信息；
文本切片不合理：采用固定长度切片（如每512字符一段），导致语义断裂；
嵌入模型不匹配：使用通用中文Embedding模型，对金融术语表征能力弱。

针对这些问题，我们做了以下优化：

使用Unstructured工具进行PDF清洗，去除广告、页码等干扰内容；
引入基于句子边界的语义分割策略，确保每段文本保持完整语义；
换用专用于金融领域的微调Embedding模型（如FinBERT），提升关键词召回率；
对高频查询建立缓存索引，减少重复计算开销。

实际效果对比：在“REITs税收优惠政策”这类专业问题上，准确率从最初的62%提升至91%。

现在，每当有新政策发布（如资管新规修订），我们只需将更新后的文件重新上传，系统即可实时生效，无需重新训练或重启服务。这种动态更新能力，是传统规则引擎或静态FAQ系统根本做不到的。

如何实现个性化推荐？

标准化回答只能解决通用问题，真正的价值在于“千人千面”的服务能力。例如，同样是问“该怎么投资”，风险偏好为“保守型”的客户和“进取型”的客户理应得到完全不同建议。

Dify 的变量注入机制让我们轻松实现了这一点。我们在用户登录时将其画像信息（如风险等级、持有产品、投资年限）通过API传入Dify，在Prompt中动态渲染个性化指令：

{% if user.risk_level == 'conservative' %} 请重点推荐中低风险产品，如国债、货币基金、银行理财等。 {% elif user.risk_level == 'balanced' %} 可配置部分债券基金与混合型产品，比例建议为7:3。 {% else %} 可适当引入权益类资产，如沪深300指数基金、科技主题ETF等。 {% endif %}

不仅如此，我们还接入了CRM系统的KYC数据接口，允许Agent在对话中主动查询用户持仓情况。比如当用户说“我想调整我的组合”时，系统会先调用内部API拉取其当前资产分布，再据此提出优化建议。

这已经不再是单纯的问答机器人，而是一个具备上下文感知能力的轻量级智能代理（Agent）。虽然目前功能还比较简单，但它为未来的自动化投资诊断、动态调仓提醒等功能打下了基础。

外部系统是怎么打通的？

为了让回答更具实用性，我们必须让AI“看得见”真实世界的数据。比如用户问：“易方达消费行业股票基金今天的净值是多少？” 如果只靠知识库存储历史数据，显然无法满足时效性要求。

为此，我们在Dify中注册了一个自定义函数get_fund_net_value()，用于调用第三方基金行情接口：

import requests from typing import Dict def get_fund_net_value(fund_code: str) -> Dict: """ 调用第三方基金接口获取最新净值 Args: fund_code: 基金代码（如'000001'） Returns: 包含净值和日期的字典 """ url = f"https://api.fund.eastmoney.com/netvalue/{fund_code}" headers = {"Authorization": "Bearer YOUR_API_KEY"} try: response = requests.get(url, headers=headers, timeout=5) data = response.json() return { "fund_code": fund_code, "net_value": data["netValue"], "date": data["date"], "success": True } except Exception as e: return {"success": False, "error": str(e)}

该函数被注册为Dify中的“工具”（Tool），并在工作流中启用自动调用。当用户提问包含“净值”“今天多少钱”等关键词时，Agent会识别意图并触发该函数，将返回结果作为上下文再次送入LLM，最终生成自然语言回复。

这种方式既保证了数据实时性，又避免了将原始API暴露给前端的风险。更重要的是，整个集成过程不需要修改核心逻辑，只需在Dify后台完成函数注册和权限绑定即可。

此外，Dify还提供了标准RESTful API，方便我们将AI引擎嵌入到App、微信公众号或网银系统中：

curl -X POST "http://dify.yourcompany.com/v1/completions" \ -H "Authorization: Bearer <API-KEY>" \ -H "Content-Type: application/json" \ -d '{ "inputs": { "query": "什么是定投？适合哪些人群？" }, "response_mode": "blocking" }'

这套接口已成功接入公司移动端App的智能客服模块，日均调用量超过3000次，故障率为零。

我们踩过哪些坑？有哪些经验教训？

尽管整体进展顺利，但在落地过程中我们也遇到了不少挑战，总结出几点值得警惕的设计考量：

1. 知识库不是越多越好

盲目导入大量文档反而会导致噪声干扰。我们曾一次性上传三年内的全部会议纪要，结果模型频繁引用非公开观点，引发合规风险。后来我们建立了严格的准入机制：仅允许经法务审核的正式文件入库，并设置访问权限分级。

2. Prompt必须遵守金融合规底线

即使是AI生成的内容，也必须规避“保本高收益”“稳赚不赔”等误导性表述。我们在系统角色设定中强制加入合规声明，并通过正则规则过滤输出中的敏感词。所有建议都需附带“市场有风险，投资需谨慎”等标准提示语。

3. 模型选择要权衡成本与性能

早期我们使用GPT-4 Turbo，效果确实出色，但单次调用成本高达0.03元。后来切换为阿里云百炼平台上的Qwen-Max，在中文金融任务上的表现相差无几，成本下降60%以上。现在我们还设置了AB测试通道，持续评估不同模型的效果差异。

4. 安全与权限不可忽视

所有API密钥实行分级管理，普通测试环境仅开放读权限；涉及客户数据的操作（如导出对话记录）需二次认证；所有日志加密存储，满足GDPR与《个人信息保护法》要求。

它真的带来了改变吗？

上线两个月后，我们收集了一些初步数据：

原本需要两周开发周期的功能模块，现在平均2小时内即可完成原型验证；
针对常见投资问题的首次回答准确率提升至87%，较人工客服提高25个百分点；
7×24小时在线响应，覆盖长尾客户需求，预计每年节省人力成本超80万元；
团队协作效率明显改善，产品经理可直接参与提示词优化，无需反复找算法工程师改代码。

更深远的影响在于组织能力的变化。过去，AI项目往往由少数算法专家主导，业务部门只能被动接受成果。而现在，借助Dify的可视化界面，一线投顾人员也能参与到知识库建设和案例测试中，真正实现了“业务驱动AI”。

结语

这次尝试让我们意识到：Dify 不只是一个开发工具，更是一种新的生产力范式。它降低了AI应用的技术门槛，让更多非算法背景的人才能参与到智能化建设中来；它推动了从“写代码”到“配流程”的转变，让复杂系统变得可观察、可调试、可协作。

对于传统金融机构而言，面对AI浪潮，与其等待颠覆，不如主动拥抱变革。而像Dify这样的工程化平台，正是帮助它们迈出第一步的理想跳板。未来的智能投顾，或许不再只是“回答问题”的机器人，而是能够理解用户、连接数据、执行动作的真正意义上的“数字员工”。

这条路才刚刚开始。

使用Dify构建智能投顾问答系统的初步尝试