1. 背景

最近在做的落地应用是一个文旅问答助手，前后两个半月时间，想在上线前自我复盘下。

一些背景：

  • 主要场景：面向大众，提供xx市文旅方面的咨询和辅助服务，包括但不限于景点信息咨询、住宿信息咨询、客流查询、行程规划等，要求能够在问答页面跳转至小程序内对应的落地页
  • 可得数据资源：第三方提供的旅游POI信息及落地页、查询接口等
  • 落地方式：微信小程序内嵌入h5
  • 成本约束：10w以内（token消耗成本不计入）

简单描述落地方案：

  • 整体逻辑：基于对话内容，识别用户意图，基于识别结果，判断需要查询哪些知识库及接口，基于识别结果判断需要将对话分发至下游的哪一细分场景bot进而生成回复。
  • 页面反馈内容：回复内容+回复依据+相关推荐，其中回复内容为LLM输出结果；回复依据基于rag接口内容，点击后能跳转至小程序内页面；相关推荐基于意图识别或rag结果，点击后同样可拉起对应页面。

2. 过程中的碰到的和想到的问题 以及 踩的坑

2.1 城市文旅助手的职责和价值点是什么？这个项目，又需要交付怎样的结果？

在想象（或者说期待）中，旅游助手可以帮我们做行前、行中、行后的各种事项：行前了解城市信息、做规划、订机酒；行中帮我们查实时信息、定路线、查POI；行后帮我们做总结做分享，等等。它可以连接所有需要连接的信息源，知道现实世界的实际情况，了解我们的偏好和预算约束，替我们做琐碎而细致的思考。简而言之，我们希望它“可用、好用”。放下AI方面的技术暂时不谈，落地这样一个助手需要有众多的数据和算法支撑，包括但不限于吃住行游购娱相关的场所及活动的数据、各种实时数据（日期、天气、交通等）、推荐算法、最短路径算法、最大收益算法、路线规划算法等等。
而一个城市的官方文旅助手，相比纯商业或工具的旅游助手，有更多的责任和限制，而与之伴生的，其实是某种程度上的低要求。
最终在目标场景、资源和预算的权衡下，得出了“可信、可用”作为交付的目标：输出的结果需要够“正确”。具体来说，它应当能够：向公众提供社交平台难以获取的、贴近城市本身特点的可信信息；支撑官方文旅业务的运营和问答服务；提供相对完整的文旅场景信息检索服务；推荐官方的订票渠道和优惠信息。

2.2 要以怎样的逻辑来落地？Agent or 写死逻辑？需要预留多少空间？

在明确交付目标后进入需求分析、业务逻辑梳理和用例梳理，这个阶段产生了功能用例和场景用例的划分：功能用例侧重UI/UE，而场景用例侧重LLM生成的内容。也就是在这个阶段，逐渐清晰地画出bot的能力边界和基础的问答逻辑。那么用什么逻辑来落地呢？这是我面对的第一个也是最重要的抉择。我列出了以下3个方案：

  • 方案一：Agent+toolkit+knowledge base
  • 方案二：意图识别+对话路由+细分场景Agent（+tool+knowledge base）
  • 方案三：意图识别+对话路由+信息检索路由+细分场景chatbot

方案一几乎是我接到需求时的下意识反应，即使是到现在，我也相信它是对于场景来说，最正确、合理的方案。
它来自我的一些基础认知：

  • AI应用的核心价值在于“连接、汇总、探索和高效执行”：这句话在之前写对话类产品讨论的时候提过，AI应用的本质是替代人做事；
  • 卷prompt的阈值极低：除了一些方向性和短线步骤之外，仅凭设计者自己，不可能穷尽所有问题的拆解思路和回答逻辑并有效通过prompt落地；
  • Agent是对话型AI应用落地的必经之路：人无法穷尽所有问题处理的逻辑，因此，如果想提供全面完整的体验，设计者必须出让一定的控制权，让系统自己具有思考、执行和反思优化的能力，而为了做到这一点，设计者能做的，只有：选择能力合适的基础模型，准备好需要的toolkit，治理好知识库数据（当然每一个都可以进一步做优化）。

方案二则是在方案一的基础上增加一些结构来做过滤和定向分发，以此来减少消耗或提高稳定性。
而方案三相对来说是“写死逻辑”的存在了：它将信息检索和工具使用的步骤交由开发在逻辑层实现，细分场景的Agent则实际上成为了chatbot。

最终选择了方案三。难以向其他人说明这是一个多么困难的决定，而做了这个选择之后后面的一切问题都只不过是见招拆招而已。
简单讲讲选择这个方案的原因：

  • 预算和团队资源：尽管我一直坚信在谈可行性之前就把客观限制抛出来是在推卸责任，而在这个项目上，这的确是令我放弃前两者的最大原因。以Agent交付，固然可以选择平台、框架、开源项目等等来完成，而这将引入更多的未知，对于一个资金和时间预算都有限的项目来说，我无法保证能够按时交付。
  • 输出结果可控性：如前所说，Agent实际上是交出了控制权，而在这个基础上，想要实现比较好的控制，例如完全依据知识库回答、例如必须坚守怎样的底线。
  • 灵活性：这里的灵活性是面对业主多变的需求时的灵活性。一个通过控制权交换得到智能感的系统内，留给人工干预的空间是有限的（尽管有些框架可以实现human-in-the-loop的干预），如果业主需求有新增或是部署场景有新增，Agent就未必是最优解了。而方案三的解耦逻辑，在实际落地上，更方便定位问题点，也更便于项目、数据、开发的三方配合。

总得来说，对方案本身打分的话，只有50分，因为它实在过于简陋，不够“AI”，而且存在很多东西没有考虑（例如并发、防刷），也不具有产品层面的灵活。可用，也只是可用。如果不对自己hard的话，也可以说，项目预算下，这好像是我能给出的最能落地的方案了。（突然很不喜欢自己的“落地”意识）

2.3 设计怎样的RAG？需要准备怎样的知识库？进行怎样的数据治理加工？

如前面所说，确定方案后，碰到的所有的问题都不过是见招拆招而已。而碰到的第一个问题就是，该设计怎样的RAG、准备怎样的知识库。
知识库设计及数据准备的工作，主要是面向RAG的，也即从RAG出发，考虑知识库的结构和生产过程。RAG在这样的项目中面临的问题主要包括以下方面：

  • 知识chunk质量较低：最优情况下，用于RAG的数据应当做到统一表达（同一个概念有一致的表述）、逻辑清晰（概念间的关系有清楚的表达）、分布合理（关于同一个概念的所有信息集中在若干chunk内），然而现实中几乎不天然存在这样的数据。而这个项目可得的数据同时存在信息极少和信息极杂两个极端。
  • 用户提问与知识片段内容存在一定差距：用户提问与知识的表述的差异，反应在RAG过程就是以文本向量距离进行排序和筛选时，可能无法取到合适的片段。
  • 数据量有限导致的聚类失败：可用的数据量其实并不多，当以k-means聚类时，向量空间很可能无法形成有效的聚类，导致检索失败。

为了解决这些问题，我的第一个想法是建立一个完整的文旅知识图谱：一个文旅问答助手，所需要的知识应当涉及多种层次，按基础性和即时性简单分为三类：城市相关的基础信息（地理、文化、历史等）；旅游场景的静态知识（POI点位信息、经典线路等）；旅游场景的动态信息（新闻、活动、交通、景点客流等）。以这样的展开逻辑，知识图谱是最符合的形式。图谱构建完成之后，对用户的提问进行相应解析并转换为图数据库的检索语言即可。但实际情况是，我们并没有那样丰富的数据来构建一个完整合理的知识图谱，后期图谱的更新维护、与动态数据的结合也会是个问题，综合考虑ROI，这个想法被挂起。
不考虑图谱，还能以怎样的方式来实现呢？我借鉴了数仓分层的思路，分ODS、DWD和ADS三层，分别用于原始数据存档、实体信息抽取和检索应用支持。以这样的结构，设计不同层之间的数据治理逻辑，至于数据内容的差异，适时引入LLM来辅助治理。
数据治理加工后，就是对RAG过程的优化了，这里做了几件事来提升效果：

  • 重构用户的query：对用户的提问进行优化表达，使之语义更完整
  • 加工原始数据：在ADS层，对原始数据进行额外加工，使长文本的内容更加精简、语义更加明确
  • 优化排序算法：引入基于语义的重排算法

2.4 LLM的世界是弥散的无边平面

如果说这个项目有更新什么我关于LLM的印象，应当是对语言模型“没有时空概念”的特点有了更深的认知：没有额外的指令，“新旧远近”这些表述时间、空间以及概念之间的距离和次序的词，在LLM内是无法得到合适的理解和处理的，更准确地说，它只知道概念之间的远近，而不知道概念所对应的实体之间的远近。
我推测这是因为LLM的本质是符号+含义的分类和预测模型。它“倾向”抽象地理解信息，也“倾向”以对人来说make sense的表述来给出反馈。LLM的世界，是一个被无数短期预测弥散充满的平面。

2.5 那些原本计划考虑，实际落地阶段却被搁置一边的问题

  • 上下文缓存：最初拿到的约束条件里，其中一个是希望控制对话消耗。如果不改变技术路径和回答内容的限制，目前所了解的方式里，除了对话历史裁切，还有上下文缓存，而引入上下文缓存，则需要在确定模型供应商之后再做落地。
  • 账号体系：构建引入账号体系的根本目的其实是要实现对用户可得资源的控制，假设后期涉及到对话次数限制，就需要从系统层面引入账号体系。

2.6 类似的项目应当如何进行测试？

项目初期的规划中，我期待积累的除了智能助手的结构设计、知识库设计，最多的其实是测试环节设计。
我们面对的现实问题是，信息不对称和信号释放缺失。无论是LLM能力还是Agent能力，又或是这样的应用，都缺乏对自身能力的力证。测试是一个相对来说比较直观的手段。
那么，应当如何进行测试呢？目前的思路是分为功能测试、场景能力测试和RAG测试三块来测试，从而辅助进行定向评价和优化。中间的难点在于准备测试集和设定合格线。

2.7 这样的需求场景，还可能会或还可以用怎样的方式来交付？

做的过程中与领导、讨论复用、成本和标准报价。彼时在具体地讨论这个项目本身，那如果以内容或价值为核心交付物，我们还可以以怎样的方式进行交付呢？

  • 仅输出文字内容：移去LUI，将整个系统抽象为一个黑盒，对外仅提供输出的文字结果
  • 仅输出知识内容：移去系统逻辑，将知识库单独拎出，以API的方式，对外提供检索服务
  • single-Agent（基础版）：选择一个合适的平台，或基于开源项目构建平台，将复杂的逻辑简化，构建一个基础版的问答助手，能够快速更新知识库和toolkit。

2.8 如果跳出这个项目，一个旅游助手应该提供怎样的核心价值？

跳出落地思维，回归旅游助手，它应当为我提供哪些服务？

  • 介绍城市、景点、文化风俗信息
  • 找到实时、准确的信息：将博眼球的、有误导的、不真实的信息剔除，只保留真实情况
  • 连接“下一步”：订机酒、订门票、订服务
  • 额外注意事项提醒：结合时间、位置和新闻，提供个性化的提醒

（想到这里，似乎又发现了一个错位：旅游助手的本质是个人化的工具，而城市官方的旅游助手，其本质是官方的宣发工具。并非不能融合，只是这错位带来了不少特性的舍弃。）

3. 总结

其实还有很多内容想写，但都还没有实践或是没有答案，像是 “落地AI应用，应该积累怎样的知识和技术基建”，又像是“如何为不同的项目设计合理的方案”，等等，希望下一次复盘的时候能有一些思路。上面的问题是这两个月内一直反复思考的，想先在这一轮复盘中整理一下。

回顾整个过程中还是有不少收获的：

  • 完整、抽象地思考：无论是AI应用还是其他系统，能够动态完整地理解业务，抽象地进行概念设计，都是必须的
  • 从最优到最适：需要保持敏锐、不断学习、不断实践，知道解决不同的问题的最优方案是什么，也要能够基于实际约束找到最合适的落地方案，对这个过程中得到的和舍弃的内容心中有数
  • 跳出：深入是个重要能力，跳出也是。要能够跳出限制、跳出业务需求，由一个问题发散开，找到不同可能性