「广域上下文感知」：LLM 打造真正解决问题、理解客户的数字客服的潜力

本文由葡萄牙语原文自动翻译。阅读原文

一个好的对话智能体应当以「广域上下文感知」（wide context awareness）来构建：LLM 打造理解客户、解决问题的数字客服的潜力

众所周知，很多时候人们会中途放弃聊天机器人会话、转向传统界面 — 常常是因为连「聊聊自己想解决的问题」都做不到，有时则是无聊到死（谁没经历过）。这是个经典问题，许多企业用著名的「转人工」来解决：把接力棒交给一个能更全面、更个性化地分析情况的人 — 而业务正是在这里丢掉了速度和规模。即便那些有一定解决能力（哪怕有限）的「获奖」机器人，也因为不能很好地理解客户的情境上下文，错失了大量机会 — 比如新的销售。

这不是本博客第一次谈这个话题。比如这篇文章分析了多模态渠道的组合如何有利于客户关系的定制、带来更强的认同感和更自然的对话；在多篇文章里我也基于各种技术（如 embeddings）带来了对话智能体个性化的可能性。而今天这篇文字，聚焦而详细地梳理消费客户（用户）上下文数据的技术可能 — 交付一种深入理解用户情境、明白这次会话能给他带来什么的个性化体验。

情境上下文

想想客户关系机器人的场景：客户可能带着任何售后需求而来 — 从产品或服务的问题、支付相关事宜，到单纯想升级套餐 — 服务可能性五花八门，而他劈头就要在一个入口菜单里摸索，才能按自己的具体问题得到正确接待。仅在这个「入口」时刻，他已经失去了一些耐心。最终被「转人工」，还带着「被怠慢了」的感受。而由语言模型「backed」的对话智能体，能把历史上下文、乃至真实世界正在发生的事带入那次具体会话，推断这次来访的缘由 — 不仅更自然，而且一开场就更精准。举例：如果客户最近两次咨询都在问所购套餐的限制，离开时已对某个能满足其需求的「premium」套餐有了更多了解但没买，那这次他很可能是回来购买的 — 此时欢迎语可以调整为带着这个建议来接待他。从技术视角说，这样的实现可以用一个 Redis（向量）库存放持续更新的近期服务摘要，再配合提示词工程引导智能体如何利用这个历史知识库 — 也就是如何让它为你的业务所用。

另一个让客户惊喜的可能，是在危机场景中：比如识别出他来自某个服务暂时中断的地区，调整欢迎语，提前为事故致歉，并告知问题已在处理中。当然，传统机器人也能实现这一点，但方式僵硬得多、手工得多、缺乏个性。这里的另一个优势是：在 LangChain 这样的框架中做这种构建只需寥寥几行代码（甚至零代码）— 只要你暴露一个可查询各地服务中断情况的 API，教会智能体调用它，并要求它在任何服务开始时先查一次。

还有一种危机上下文里可以调整对话「语气」的场景：借助社交网络监测服务（比如 Stilingue 提供的那种）。你可以监测网络上是否有正在发酵的事件（比如某次促销引发的危机），判断这位客户是否属于受影响群体 — 如果是，调整语气，让他一进来就知道你的公司已经知情并会帮助他。这种实时识别制造共情，必然增强消费者对品牌的认同。

反过来，当你的网络上是正面行情时，你也可以精准地给客户惊喜：把一款在某类客户画像中表现出色的产品，以个性化的方式 — 比如与他过往的服务记录相衔接 — 推荐给他。Sales up!

对你的数据的真正智能 这同样不是本博客的新话题。我多次谈过从数据库获取更全面洞察的可能性 — 而且风格不同于传统仪表盘：有了 LLM，你可以直接提问，让智能体/模型（随提示词变化）组织个性化报告。这终结了那个老问题：仪表盘交付时已经不再有用，因为假设变了。为此，有一种更高效、更全面的方式来组织信息供语言模型消费。今天大多数 GenAI 方案通过语义向量组织附加知识库：存储一段段「字符串」— 句子、段落等 — 并建立索引以高效检索。问题是，当你需要的关联要考虑不同实体之间的全局关系时，这种方法既低效又昂贵。

GraphRAG 在此登场：这种方法把构成你业务的所有实体之间的关系映射进一张图谱。例如，位于城市 Y 的画像 X 客户。当你想生成销售洞察、趋势、瓶颈等时，这种方法高效得多。因为它在得出图谱时考虑了训练库的所有变量，你获得的是业务的全局视图 — 不同于向量库那种聚焦/受限的回答。想深入了解，推荐这篇文章，出自唯一一家提供企业关系型数据库转图谱连接器的公司；或者微软团队解释两种形式差异的这篇论文。

好了各位同仁，这些技术为客户关系的转型、为企业数据库的更智能消费 — 真正产生洞察 — 打开了无数可能。相较传统方法，GenAI 应用的采用度仍然很低：谈论很多，实验集中在那些重视研发的公司。在我看来，这些技术的收益及其规模化影响，理应推动更多资源投向这些应用。不过，并非处处鲜花 — 技术市场是周期性的，让我们为下一轮变革做好准备！这正是这里的初衷 :) 回见。😎