摘要:

一名医疗器械公司员工在Palantir AIP平台上尝试复现其在Azure上使用GPT和RAG构建的客户服务引擎CoPilot，寻求改进其RAG模型在准确性和效率方面的策略，并得到了社区成员关于改进分块、检索和利用本体的建议。 

Key Takeaways:

* 一位用户尝试在Palantir AIP平台上复制其在Azure上基于RAG的CoPilot，用于客户服务，但遇到了挑战。 

* 社区成员建议使用Palantir提供的“Build with AIP”中的语义搜索示例作为起点。 

* 改进RAG的关键在于改进分块策略（例如，基于段落和字体大小）和检索方法（例如，结合语义搜索、本体搜索和关键词搜索）。,

* 可以利用Palantir Foundry建模套件来改进分块，例如使用共指消解模型。 

* 本体可以用来过滤文档，提高检索效率和准确性。 

* AIP Logic可以用来创建无代码函数，以增强本体查询和检索。 

* 用户在将新生成的文本块保存到Ontology时遇到了主键问题。 

一，医疗设备公司用户提问

我在一家医疗设备公司的服务运营部门工作，一直在 Azure 中使用 GPT3.5/4/4o 和 RAG，使用我们的产品手册构建 CoPilot。

我们已经看到了大约 70% 的响应准确率，并正在努力提高这一水平。响应准确性被认为是技术上正确的响应，可能只需要在发送之前更改格式。

6 月，我和一些同事参加了在 Palantir 伦敦办公室举行的 AIP 博览会，看到了令人印象深刻的客户服务引擎CSE。

然后，我让他们参加训练营，看看 CSE 是否可以成为我们的服务台使用的东西。

我们想展示从我们的 CRM 中提取和响应客户案例的自动化功能，本质上的想法是复制我们已经在试用的基于 RAG 的 CoPilots，将技术响应注入 CSE 生成的发回给客户的邮件中。

我使用与Azure助手相同的内容集（大约7000页）构建了一个内容管道，但系统返回的块太多，响应无效或者失败，因为块的数量太大，无法进行总结。然后我将其简化为一份文档，我们使用目录来尝试更准确地索引内容，这改善了一些，但仍然远不如基于RAG的助手。

谁能推荐一些策略，以使用流水线构建器在 Foundry/AIP 中更紧密地复制 RAG 模型？这是最好的方法吗？

Sam山姆

一，Palantir技术支持George回复

嗨，山姆，

很高兴听到您正在探索在 AIP 中构建它，并乐于提供帮助！我将从顶部开始，并尝试使这个答案尽可能全面。我怀疑开头的一些信息会是你作为过去几次 AIP 活动的参与者已经知道的信息，但希望确保这对其他找到线索的人有所帮助。

首先，我要指出您探索 RAG 是对的。这几乎可以肯定是解决这个问题的正确方法。首先，我将分享如何在 AIP 中实现 RAG，然后我们可以探索一些技术来使其变得更好。

‍‍‍‍在 AIP 中实施 RAG‍‍‍‍

在 Foundry/AIP 中，我们发布了一个名为“Build with AIP”的产品。BwAIP 是一个参考示例库，用于在平台中构建常见工作流。我们有一个名为“使用 Palantir-Provided Models 进行语义搜索”的参考示例，其中还包括一个 RAG 示例。我认为我们可以清理这个例子的名称，让它更明显。您可以在此处找到此示例的面向公众的版本 https://build.palantir.com/platform/4be57ec0-83a3-4c3b-a066-62cbfd9d1fb6。更好的是，您可以在自己的 AIP 实例中找到它。登录，打开侧边栏中的应用程序搜索，然后键入“Build with AIP”。加载 BwAIP 应用程序后，顶部会有一个搜索栏：键入 Semantic Search。单击参考示例，点击 install（安装）并等待 ~5 分钟以完成安装。

Palantir大模型平台产品AIP系列: 语义搜索

安装参考示例会部署一个带有 Pipeline Builder、Ontology Objects 和 Workshop App 的端到端工作示例。在 Workshop App 中，您可以提出问题，查看语义搜索从文档中检索一组 3 个数据块，然后在下面查看完整 RAG 实施的生成摘要。Workshop 应用程序有效地有两个目的：（1） 作为如何构建自己的语义搜索或 RAG 实施的指南，以及 （2） 作为可视化流程的 UI。在 （2） 中要记住的一个重要点是，您使用 Workshop 设置的几乎任何工作流也可以在 Foundry/AIP 之外使用我们的 Python、Typescript 和 Java OSDK 进行设置。

参考示例是完全可编辑的，因此您可以交换充满文档的媒体集，通过运行管道并询问这些文档可以回答的任何问题来重新生成嵌入。

增强 AIP 中的 RAG

增强 RAG 管道大致有两个主要关注领域：分块和检索。

Chunking分块

您已经走在使用目录改进数据索引方式的正确道路上。通常，分块的目标需要是最大化每个单独块的语义上下文。目录是通过有保证的层次结构来实现此目的的一种方法。您可以在同一域中尝试的其他技术是根据段落和字体大小进行分块。文档作者倾向于使用这样的功能来分割他们的思考（有点像我分割这个文档的方式......如果它有助于提供人类的上下文，那么它可能也有助于提供机器的上下文。

其次，分块通常会导致上下文丢失。例如，请参阅我在“在 AIP 中实现 RAG 部分”中写的三个段落。在第一个示例中，我将参考示例称为 。在随后的段落中，我没有再次使用这个标题。相反，我把它称为 “参考例子”。如果你把这个文档按段落分块，你会在后两段中丢失很多语义上下文。使用共指解析模型对数据进行预处理可能是改进块语义内容的好方法。这是构建 AIP 变得真正强大的地方之一。使用 Foundry Modeling Suite（适用于 AIP 和 Foundry 部署的开箱即用），您可以构建传统模型并将这些模型集成到您的管道中。在此处广泛查看有关建模套件的文档。然后是有关如何将模型集成到管道中的批量部署文档

Retrieval检索

对于 RAG 管道，检索通常可以解释为“哪组块最有可能包含我问题的答案？在许多传统的 RAG 工作流中，这个通用问题的实际实现是语义搜索。在参考示例中，我们使用 K 最近邻 （KNN） 算法对所有数据块执行语义搜索。根据用例，这有时就足够了，但通常不是。当我们将语义搜索与其他类型的搜索相结合时，本体的力量才真正显现出来。

本体/知识图谱搜索

我将使用您的具体示例，并假设您有一个至少包含四个对象的本体：Customers、Sales、Devices 和 Manuals。其他一些假设：

1. 内容集是设备的手册

2. 客户支持请求可以通过阅读手册来解决，但没有人阅读手册，因为它们太长且技术性太强。

3. 通过 Sales 对象，我们知道哪些客户购买了哪些设备

4. 手册（PDF 格式或类似格式）链接到设备

使用本体及其内置的语义图谱，我们可以预先过滤我们正在搜索答案的文档。这实际上是将知识图谱搜索分层在语义搜索之上。

通过遍历客户↔销售↔设备↔手册之间的链接，我们可以筛选出仅与提交支持请求的客户实际购买的设备对应的文档。仅此一项就应该大大减少幻觉的数量。相同的逻辑可以应用于过去的支持请求。该客户之前提交了哪些工单？我们过去在他们购买的设备组中遇到过哪些问题？

关键词搜索

本体带有开箱即用的关键字搜索。在某些情况下，使用普通的旧关键字搜索来增强语义搜索结果是一个强大的工具。例如，如果客户在其支持请求中键入其特定设备名称，您可以搜索包含该关键字的所有文档。当然，这会失去他们搜索的语义含义，因此它应该用于增强，而不是替换语义搜索。有几种方法可以组合搜索算法，但最流行的往往是重新排序算法，其中文档或块排名基于它在关键字搜索中的得分（出现次数 #）以及它在 KNN 相似性上的得分。或者，可以使用关键字来预先筛选搜索结果。最有效的方法通常取决于数据资产，并且需要一些修补才能找到合适的匹配项。

那么在AIP中如何做呢?

这个问题的答案通常是 AIP 逻辑。逻辑是我们针对本体编写无代码函数的工具。这些函数可以是纯粹的确定性函数，例如过滤器和并集，也可以利用 AI 能力，如使用大型语言模型进行语义搜索。学习 AIP 逻辑的最佳方法是使用更多的 AIP 构建参考示例。我建议从《Building your AIP intuition: AI assisted cricket》和《Leveraging feedback loops in AIP Logic》开始。

在 AI Assisted Cricket 中，您将学习如何使用 Logic 中的工具来查询本体，而不是依赖提示中的上下文。这可以直接转化为如何识别哪些手册/文档要传递到语义搜索逻辑板。

在 利用反馈循环 中，您将学习如何将结果重新整合到 AIP Logic 函数中。这可以转换为所生成答案的客户满意度指标（或 CS 代表批准/不批准）。

二，Palantir技术支持George回复

嗨，山姆！

George 的回答确实很全面，并提供了很多有价值的见解。我想详细阐述几点，特别是关于 Customer Service Engine （CSE） 的实施，以及如何嵌入此功能以复制基于 RAG 的模型。

• Chunking分块：将文档划分为可管理的块。

• Embedding：将每个块的内容转换为数字表示形式（向量）。

• Indexing索引：将这些嵌入内容存储到 Ontology 中，以便进行高效检索。

• Retrieval检索：使用语义搜索查找相关数据块以回答客户查询。

分块  

已经由George涵盖过。

嵌入  

一旦你对文档进行了分块，就将每个块中的文本转换为数学表示（向量）。你可以使用管道构建器表达式：文本到嵌入来实现这一点。

索引

将您的块转换为嵌入后，在本体中创建一个新的对象类型。

这里是[客户服务]文档对象类型可能的示例：

• content: 文本块的内容

• content_embedding: 文本的嵌入，定义为带有以下嵌入模型的向量类型：

• 语言建模服务模型

• OpenAI的text-embedding-ada-002

检索

对文档进行索引使其准备好进行高效的检索。为了增强生成带有相关上下文的电子邮件，请修改“Generate Response for Customer Service Alert”AIP逻辑文件：

检索模块是增强响应生成中最关键的操作。正如乔治提到的，这个模块负责根据客户的查询提取最相关的文档片段。默认情况下，我设置它返回前50个相关片段，但您可以根据用于生成答案的语言模型的能力调整此数字。

一旦您将变量“最相关文档”填充了这些相关片段，您可以将其作为输入传递给“回复客户”模块。此整合确保生成的响应丰富了精确且符合上下文的信息，从而提高整体响应的准确性。

增强检索与本体论的结合

提供的示例是语义搜索的基本版本，其中使用嵌入来查找最相关的文本段落。然而，通过利用本体论，可以显著提高检索到的文档的性能和相关性，如乔治建议的那样。这可以涉及在AIP Logic中设置确定性过滤器，以配合上述的AI语义搜索能力。

例如，如果您有与产品相关的本体对象，则可以将与本体中每个产品相关的文档子集连接起来。利用这种本体化的文档结构在您的Logic功能中查找信息时，将使检索变得更加高效和准确。

参考信息

1. Building with Palantir AIP系列: RAG/OAG的逻辑工具
   

2. Palantir 大模型产品AIP系列：RAG/OAG的数据工具

3. 在Palantir生成式人工智能平台AIP中用本体Ontoloty减少幻觉

4. Palantir 大模型产品AIP系列 - 首席架构师详析Ontology本体论驱动决策及医疗案例

5. Palantir大模型产品系列 - 使用Palantir AIP(大模型AI平台)进行构建：本体软件开发工具包

6. Palantir大模型平台产品AIP系列: 语义搜索

7. Palantir大模型产品AIP系列 - 基于本体论的软件开发

8. Palantir Foundry的能力解锁

9. Palantir Foundry在生命科学及工业领域Demo

10. 使用 Palantir Foundry 和 大模型平台AIP 解决 AI 应用程序的挑战