AI引擎如何驱动智能助手?5个技术架构要点

不少企业选智能助手时,习惯先问"用的哪个大模型"。这个问法本身就把问题问偏了。模型更像发动机,而助手能不能真正把事办成,取决于引擎怎么把这台发动机接进传动系统。同一个模型,接法不同,出来的助手完全是两个物种:一个只会聊天,一个能查数据、能走流程、能在权限允许的范围内把动作落下去。下面从架构层面拆五个要点,顺序大致就是一次请求在系统里走过的路径。 一、入口不是分类器,是路由器 最容易被低估的一层是意图处理。早期做法是训练一个意图分类模型,把用户输入映射到有限的几个标签上。这套思路在客服场景里够用,一旦放到开放的办公场景就崩了:员工问的东西五花八门,标签体系永远追不上。 现在更常见的做法是把入口做成路由:先由语义层判断这次请求属于哪一类任务——是纯知识问答、需要调数据、需要触发流程,还是需要多步协同。路由的意义在于它决定了后续走哪条链路,而不是急着给用户一个答案。路由器判错,后面的检索和工具调用全是白费;判对了,即使用的小模型,体验也能撑住。 二、检索层决定答案的边界 大模型的参数里没有你公司的报销标准、合同模板和产线工单。想把助手从"通识聊天"拉到"懂业务",靠的是检索增强这条线:把企业文档、数据库、业务系统接口组织成可被召回的知识源,在生成之前先把相关片段找出来。 这里真正的工程量不在向量库选型,而在切分和召回策略。文档切太碎,上下文断了;切太大,噪声压过信号。业务数据还涉及结构化查询,单一向量检索解决不了,通常要和关键词检索、SQL 查询做混合召回,再由排序层筛一遍。检索层的质量基本决定了助手的天花板——召回不到的东西,模型再强也编不出来,只会顺着语言惯性给你一个像模像样的错答案。 三、从"会说"到"会做":工具调用与流程编排 智能助手和聊天机器人的分水岭在这一层。工具调用让模型能发起外部动作:查一条订单状态、创建一张工单、往日历里塞一个会议。技术上通常通过函数调用协议实现,模型输出结构化参数,由引擎负责校验、执行、把结果回填进上下文。 难点在编排。一个真实任务往往要串好几步,中间某一步失败怎么办、要不要重试、参数缺失时是追问用户还是按默认值走、敏感操作是否需要人工确认——这些都不是模型能自己决定的,得在引擎侧定义状态机和兜底策略。做得粗糙的助手,单步演示很流畅,三步以上就开始丢状态、重复调用、或者在没有权限的情况下硬闯。 四、记忆要分层,不能只堆上下文窗口 上下文窗口越做越大,有人就干脆把所有历史塞进去。这条路在成本和稳定性上都走不远:token 费用随轮次线性上涨,而且无关历史会稀释当前任务的注意力。 更合理的做法是把记忆分层。会话级的短期上下文,只保留当前任务相关的内容;任务级的状态,记录流程走到哪一步、已经拿到哪些参数;长期偏好则单独抽取沉淀,比如某个用户习惯用哪种格式的报表、常查哪几个科目。三层各自有不同的存储周期和更新策略,引擎负责在合适的时机把它们组装进 prompt。分层做得好,助手在长周期使用中会显得"记得住事",而不是每轮都从零开始。 五、数据隔离与训练边界:架构里的地基 前四层解决的是能力问题,这一层解决的是能不能被企业采用的问题。企业数据接进助手,天然要面对两个疑问:数据会不会流出边界,以及会不会被拿去训练。 工程上的应对是多租户隔离、字段级权限校验、调用链路审计,以及明确的数据流向控制。这些是架构设计里就要定下来的硬约束,没法靠后期打补丁。万达宝LAIDFU(来福)在这一点上的做法是把边界写进机制:不训练 LLM,不使用客户数据进行训练,也不转售给他人。这个选择对模型的迭代速度没有帮助,但它让企业在接入内部数据时少了一层顾虑——尤其对制造、贸易这类数据敏感度高的行业,这条约束常常比多几个功能点更有分量。 把五层放在一起看,前三层决定助手的能干程度,第四层决定它能陪企业走多远,第五层决定它有没有资格进场。选型时如果只盯着底层模型的名字,相当于只看了发动机的排量,却没过问变速箱、底盘和刹车是不是配套。真正的差距,往往就藏在这些不显眼的地方。