当前位置: 首页 > article >正文

Chat-Driven Business:灵活交互的新范式

1. 引言

一次偶然的机会,读到了CSDN上的一篇文章,自定义markdown的展示(很遗憾,时间有点久,找不到具体的链接了),当时我觉得这很有启发意义,因为我做的cli_assistant就是以markdown的形式返回的,自定义markdown的展示意味着可以有更加丰富的展示内容;

又是一次偶然的机会,在和一位销售老总聊业务功能时,我发现已有的系统功能和他的描述即相符合又相去甚远。说“符合”是因为他所描述的功能,我们的系统都支持;说相去甚远,是因为我们的系统中没有一个页面能够和他的诉求相吻合。也就是说,从用户的角度来看,实现这一功能需要经历多个页面的跳转,结合上下文输入参数,整个过程复杂且耗时,体验并不友好。

当这两个东东相互碰撞时,“Chat-Driven Business”主题便迎面向我走来。

2. 问题背景: 现有系统的局限性

2.1. 页面布局的历史渊源

页面布局的概念可以追溯到互联网的早期,甚至更早的印刷时代。在Web 1.0时代,页面是信息展示的基本单位,用户通过点击链接从一个页面跳转到另一个页面。这种设计模式在当时的技术条件下是合理的,因为它简化了信息的组织和展示。然而,随着互联网技术的发展,用户对信息获取的效率和交互体验的要求越来越高,页面布局的局限性逐渐显现。

页面布局的本质是将信息分割成多个独立的单元,每个单元(页面)负责展示特定的内容。这种设计模式在信息量较小、用户需求单一的情况下是有效的。然而,随着业务复杂度的增加,用户需要在多个页面之间频繁切换,才能获取完整的信息。这不仅增加了用户的操作负担,还降低了系统的使用效率。

2.2. 基于页面的框架的局限性

基于页面的框架通常采用从抽象到具体、从大类到细类的逻辑来组织信息。这种展示方式在理论上是合理的,因为它符合人类对事物的认知逻辑。然而,在实际的业务场景中,用户的需求往往是多维度的,涉及多个特性或大类。例如,在讨论一个销售业务时,用户可能需要同时查看销售数据、客户信息、产品库存等多个维度的信息。

在现有的页面布局下,用户需要熟悉系统的结构,并主动打开多个页面,才能获取完整的信息。这不仅要求用户具备较高的系统操作技能,还要求用户能够准确地判断需要打开哪些页面。在大多数情况下,用户可能只打开了部分页面,导致系统功能无法充分发挥。换句话说,现有的系统在大部分情况下,相比于最初的设计,可能只发挥其中的一部分价值。

此外,基于页面的框架还存在以下问题:

  • 信息割裂:信息被分散在多个页面中,用户需要手动整合,增加了认知负担。
  • 操作繁琐:用户需要在多个页面之间频繁切换,操作步骤复杂,降低了使用效率。
  • 灵活性不足:页面布局固定,无法根据用户的具体需求动态调整展示内容。

2.3. 用户需求的动态性与系统设计的静态性矛盾

用户需求的动态性与系统设计的静态性之间存在矛盾。现有的系统设计往往基于通用的业务逻辑,无法满足不同用户的个性化需求。例如,销售老总可能需要快速查看销售数据,而财务总监可能需要详细的分析报告。在现有的页面布局下,系统无法根据用户的具体需求动态调整展示内容,导致用户体验不佳。

此外,用户的需求往往是动态变化的,现有的系统设计无法快速响应这些变化。例如,在销售旺季,用户可能需要重点关注销售数据,而在淡季,用户可能需要关注库存管理。现有的系统设计无法根据业务场景的变化动态调整展示内容,导致系统功能无法充分发挥。

当然,在低代码平台的加持下,这种矛盾在一定程度上得到了缓解,但仍然不能从根本上解决这对矛盾。

3. 解决方案

随着ChatGPT(DeepSeek)等大语言模型的诞生与流行,对话式交互有可能成为解决传统页面布局局限性的有效方案。

通过对话的方式,用户可以直接输入诉求,系统则通过大模型理解用户意图,并返回相应的结果。这种交互方式不仅简化了用户操作,还打破了传统页面布局的束缚,能够根据用户的具体需求动态返回可交互的UI,从而提升系统的灵活性和用户体验。

对话式交互的核心在于用户可以通过自然语言表达需求,而无需熟悉复杂的页面结构和操作流程。例如,销售老总可以直接输入“查看本季度销售数据”,系统会自动理解并返回传统页面上的销售表格部分,没有复杂的查询条件。

当然,我也是在摸着石头过河,上面所说的,看似已经勾勒出了一个解决方案,但从理论到实践,这仅仅是迈出了第一步。如果想要真正落地,探索的旅程才刚刚开始。

下面,将从自然语言处理(NLP)、UI展示框架这两个方面,对解决方案进行进一步的讨论。
没有“页面”的束缚,对话式交互可以根据用户的输入,动态返回相关的传统交互元素(如表格、图表、表单等),从而满足用户的个性化需求。

3.1 自然语言处理(NLP)与用户意图理解

大模型的核心作用

大模型(如DeepSeek)在对话式交互中扮演着至关重要的角色。它能够分析用户的自然语言输入,并将其转化为可执行的意图。例如,当用户输入“查看上个月的销售数据”时,大模型如何准确地识别出用户的意图是“查询销售数据”,并提取关键参数“上个月”?这是我们需要解决的一个问题。

这个问题已经在我的Demo阶段,通过Deepseek大模型已经实现,并且命中率很高。

具体的方法是在Prompt中,加入业务系统的参数,以及参数的中文逻辑,然后让Deepseek去匹配相应的数据。

上下文管理

在多轮对话中,如何确保系统能够保持逻辑一致性?例如,用户在查询销售数据后,可能会进一步询问“环比增长了多少?”,系统需要结合之前的上下文给出准确的回答。如何实现这种上下文的无缝衔接,是提升用户体验的关键。

这个问题,解决方案有不少,例如“对话状态跟踪”,“记忆网络”,“上下文嵌入”。但这些方案都需要落地不断的实验和调试,才可能得到能够用于产品的结果。

意图分类与实体抽取

通过意图分类模型,系统如何将用户输入归类为具体的业务功能(如“查询数据”“生成报告”等)?同时,如何通过实体抽取技术提取关键参数(如时间范围、地区等)?这些技术的实现细节将直接影响系统的准确性和效率。

对于这些问题,我目前使用的是最简单粗暴的信息分类算法–余弦相似度,但最终可能还是需要通过微调模型,添加分类器等方式,最终,也是要经过多轮的对比和调试之后,才可能得到一个可用于商用的结果。

这个环节尤为重要,因为用户的输入最终要落实到系统的功能上,我们不可能(至少现阶段是这样)让大模型帮我们臆想出一个功能或者数据,然后将其返回给用户。而系统API是我目前认为的系统功能的最小粒度,即大模型返回的内容中所包含的数据,表单等内容,最终都是以这些API为基础返回的。

另外,还有一个重要的原因,API是可测试的

3.2 UI展示框架与Markdown渲染

如今,大模型返回的文本内容基本都采用markdown格式,因为markdown是一种成熟且可轻松转换为HTML DOM的格式。

然而,由于我们采用对话方式返回业务交互的UI元素给用户,传统的markdown格式已无法满足我们的需求。,比如:

{ "param": {...}, "api": { "url": "/business/orders", "method": "post" }, "parsingMethod": "orders" }

上述代码是我在Demo中使用的markdown内容,我需要将其渲染成一个折线图。但显然,目前的markdown解析器无法实现这一功能,因此我们需要对现有的UI框架进行进一步的定制和改造。

但这改造不仅限于markdown本身的渲染部分,还可能包括整个对话过程的展示部分。

在现阶段的Demo中,我们采用了复合推理的方式来生成最终的内容,整个过程耗时10秒钟左右。然而,由于这一推理过程对前端用户完全不可见,用户可能会在屏幕前等待5到20秒不等的时间,却没有任何实时的反馈。这种等待体验显然不够理想,尤其是在现实的业务场景中,推理过程可能会更加复杂,耗时也更长。如果用户在等待过程中没有任何视觉或交互上的反馈,他们很可能会失去耐心,进而放弃使用“Chat-Driven Business”功能。

为了优化用户体验,我们需要在推理过程中提供实时的反馈机制。以下是一些可能的解决方案:

  1. 进度指示器:在推理过程中,前端可以显示一个进度条或加载动画,告知用户系统正在处理请求。这可以帮助用户理解当前的状态,并减少等待的焦虑感。

  2. 分阶段反馈:将推理过程拆分为多个阶段,并在每个阶段完成后向前端发送部分结果。例如,可以先返回一个初步的文本响应,然后再逐步补充图表或其他复杂内容。这样,用户可以在等待最终结果的同时,先看到部分内容。

  3. 状态更新:在推理过程中,系统可以定期向前端发送状态更新,例如“当前的推理结果”、“正在分析数据”、“正在生成图表”等。这些状态信息可以帮助用户了解当前的操作进展。

  4. 交互式等待:在等待过程中,可以提供一些轻量级的交互功能,例如让用户补充缺少的参数,预览部分数据。这不仅可以减少用户的等待时间,还能增强他们的参与感。

  5. 错误提示与重试机制:如果推理过程中出现错误,系统应能及时反馈给用户,并提供重试或调整的选项。这可以避免用户因为长时间的等待而感到沮丧。

通过这些优化措施,是必要的和亟待实现的。如果没有它们,用户可能不会接受“Chat-Driven Business”这样的模式。

当然,任何方案,没有落地,都是在吹牛,不过由于我已经完成了一个简易的Demo,因此,吹牛的成分也不是100%,大概也有80%吧。

4. 应用场景

场景描述:

在系统运维的繁忙环境中,运维工程师小李正监控着众多业务系统的运行状态。突然,他注意到支付业务的性能似乎有些异常,想要快速了解支付业务的告警情况。这时,他想起了公司最近引入的对话式交互系统。

对话过程:

4.1. 用户输入
  • 小李在系统的对话框中输入:“我想知道支付业务的告警情况。”
4.2. 系统响应与实时反馈
  • 系统立即显示一个进度指示器,提示小李:“正在分析支付业务的告警数据,请稍候……”
  • 同时,系统开始调用自然语言处理(NLP)模块,解析小李的输入,识别出他的意图是“查询支付业务的告警情况”。
4.3. 分阶段反馈与推理
  • 系统首先快速返回一个初步的文本响应:“已识别到您的请求,正在调取支付业务最近5分钟的告警数据。”
  • 接着,系统调用相关的API,获取支付业务最近5分钟的告警数据,并开始生成告警图表。
  • 在图表生成过程中,系统继续向前端发送状态更新:“正在生成告警图表,请稍候……”
4.4. 图表展示与交互式等待
  • 一旦告警图表生成完毕,系统立即将其展示在对话框中,同时提供与图表相关的交互功能,如缩放、拖动等。
  • 系统还主动展示了与支付业务相关的其他业务的图表数据,如交易成功率、响应时间等,帮助小李更全面地了解支付业务的运行状态。
  • 在等待过程中,小李还可以继续输入其他指令,如:“我想看看交易成功率的趋势。”系统会根据新的指令,实时更新展示内容。
4.5. 错误处理与重试机制:
  • 如果在推理或图表生成过程中遇到错误,系统会立即显示错误提示,如:“无法获取告警数据,请检查网络连接或稍后再试。”
  • 同时,系统提供重试或调整的选项,让小李可以快速重新发起请求或修改查询条件。

5. 未来展望

通过Chat-Driven Business,并不是对现有系统和模式的彻底颠覆,而是对复杂业务场景和多维度需求的有力补充。它基于现有的IT基础设施,如后端架构、前端框架,但在交互方式和用户体验上进行了创新。对话式交互将与传统的页面布局共存,形成一种混合式的交互模式,以满足不同用户和业务场景的需求。

从投资的角度,我们可以用现有的IT技术兜底,通过Chat-Driven Business来开拓新的价值创造方式;从用户的角度,Chat-Driven Business确实为用户带来了实实在在的价值,因此,我个人觉得,这个牛可以吹起来。


http://www.kler.cn/a/588034.html

相关文章:

  • python面向对象:封装的编程案例
  • 使用easyexcel实现单元格样式设置和下拉框设置
  • coze ai assistant Task 3
  • 【Django】【vue】设计一个评论模块
  • 【人工智能基础2】Tramsformer架构、自然语言处理基础、计算机视觉总结
  • 数字人本地部署之llama-本地推理模型
  • Skema:AI 驱动的方案到 BIM 加速工具,重塑早期设计工作流
  • superset部署记录
  • 奇安信二面
  • SpringMVC(六)异常:全局捕获与错误响应
  • Android (Kotlin) 高版本 DownloadManager 封装工具类,支持 APK 断点续传与自动安装
  • 【模拟面试】计算机考研复试集训(第五天)
  • 自然语言处理 | 文本清洗的20种核心策略:从数据噪声到信息价值
  • 7、标准库的string的常见使用
  • 加固脱壳技术:DEX动态加载对抗
  • Matlab 矢量控制和SVPWM的感应电机控制
  • 二.使用ffmpeg对原始音频数据重采样并进行AAC编码
  • 【Linux】learning notes(4)cat、more、less、head、tail、vi、vim
  • 设计模式--单例模式(Singleton)【Go】
  • LLM自动化评测