把一句“帮我改期”，变成有依据的办理过程

听懂了人话，为什么还需要企业数据？

语言模型可以把这句话整理成几个要点：原来有一笔预约，团体希望晚一小时，共 20 人，还需要适合轮椅通行的路线。它能够处理这类自然表达，却不能仅凭一句话知道当前预约是哪笔、明天哪些场次开放、还剩多少名额。

这些事实存放在组织的业务系统中，并且随时可能改变。昨天有名额的场次，今天可能已满；通常可以通行的路线，明天可能临时维护。要给出能用于办理的回答，助手必须读取与当前请求有关的信息。模型接到的记录、规则和说明，合起来就是这次任务的上下文。

AIP 是 Palantir 的人工智能平台，全称 Artificial Intelligence Platform。它让模型与企业数据、应用和操作相连。可以把这段协作理解为：模型负责理解表达和形成下一步请求，平台把允许使用的数据与工具提供给它，再把实际查询或操作的结果返回。

因此团队给助手设定的工作逐渐变得具体：找到这笔预约，查明可选场次与无障碍路线，提出方案，阿宁确认后再办理。此时要解决的第一个技术问题是，怎样让助手找到正确的业务记录和说明材料。

本节事实核查：官方资料 [18]

“后面一场”和“无障碍”，怎样对应到具体资料？

先看结构化的业务事实。Ontology，即业务本体，已经定义了预约、导览场次、讲解员和路线，并说明它们怎样关联。A102 预约指向原来的三点场次，场次有时间、容量和路线。助手沿这些关系查询，就能把“后面一场”落实到几个具体候选，而不是泛泛地讨论下午的活动。

再看文字材料。团体说“有成员使用轮椅”，路线说明却可能写“全程无台阶”或“轮椅可通行”。字面完全相等的搜索容易漏掉相关内容，语义检索则尝试按含义找到相近材料。关键词检索、改写查询和组合检索，也可以帮助找回需要的段落。具体方式应围绕资料和问题的特点选择。

官方将相关内容放在 OAG 文档中。OAG 是 Ontology-augmented generation，即本体增强生成；这篇官方文章主要讨论怎样检索并提供模型需要的背景材料。“OAG 文档”指介绍这些方法的文章，并不是一种专门的文件格式，也不是上传文件后自动出现正确答案的开关。

在我们的例子中，助手需要同时拿到两种信息：候选场次的当前名额，以及说明路线是否适合轮椅的材料。找到一段泛泛的无障碍介绍还不够，那段说明必须与当前候选路线有关。相反，如果资料本来就很少，能够完整放进模型上下文，也未必需要先搭建复杂检索。

现在助手已经有机会回答“哪些场次可能合适”。如果仍然答错，团队可以先查它到底读到了哪些内容：是没检索到关键段落，还是已经读到却理解错了？把这两种问题拆开，比只要求模型“再认真一点”更有帮助。接下来，怎样让它从回答问题走向真正办理？

本节事实核查：官方资料 [19]官方资料 [20]

助手说要改期时，真正执行的是谁？

工具调用就是模型请求一个已提供的功能帮助做事。例如它可以调用查询工具读取四点场次的剩余名额，调用函数计算时间是否冲突，也可以提出调用“改期预约”操作。模型组织请求，具体工具执行工作，再把结果返回给助手。

这一点让自然语言与确定的业务操作接上了。阿宁说“改到后面一场”，助手最终需要把请求整理成可检查的参数：预约 A102、目标场次的具体编号、20 人。这些值可以展示给阿宁确认，随后交给前一篇已经定义好的 Action。调用同一种操作，就能复用相应的业务规则。

在 Chatbot Studio 中，可以配置带企业信息和工具的对话助手。它的 Action 工具可以自动执行，也可以设置为需要用户确认。我们的虚构产品选择后者：先显示新日期、场次、人数与拟修改记录，阿宁确认后才提交。

确认时还要面对现实的变化。助手刚查到四点场次剩 25 个名额，但阿宁确认之前，另一位客服已经订走 12 个。正式操作再次检查只剩 13 个，于是拒绝这次 20 人改期。正确的助手应说明名额发生变化，继续寻找备选，而不是因为前面已经说过“可以”就坚持完成。

前几篇的工具在这里自然分工。Workshop 提供阿宁办理业务的页面，Chatbot Studio 提供对话入口；AIP Logic 可以复用固定处理步骤，Automate 可以在条件成立后继续推进。如果阿宁只是临时想调查“最近哪些场次经常满员”，AIP Analyst 更适合组织探索性分析。同一份数据和操作，不同入口可以承担不同工作。

查询范围和操作权限也继续适用。能查看一个场次，不等于可以修改其他场馆的预约；读取时能被保护的内容，生成摘要后也需要对应保护。AIP Logic 的行列读取控制不会自动扩展到输出或拟议编辑，后续仍需配置相应安全标记或分类权限。信息与操作怎样流动，决定了这些保护要放在哪里。

本节事实核查：官方资料 [5]官方资料 [6]官方资料 [7]官方资料 [8]官方资料 [9]官方资料 [10]官方资料 [17]

背后的模型从哪里来，为什么不只选“最聪明”的一个？

到这里，我们已经知道助手需要理解语言、读材料并请求工具。不同模型对这些任务的表现可能不同：一种擅长理解长文，一种响应较快，另一种对某种工具调用方式支持更好。模型的选择要放回这段具体办理过程，才能知道什么能力真正有用。

AIP Model Catalog 提供当前环境中 Palantir 提供模型的发现与试用入口，并显示相关可用性和生命周期信息。它主要面向大语言模型及相关类型，不是企业所有机器学习模型的总清单。区域、管理员配置和模型的生命周期，都可能影响一个模型是否能够继续使用。

组织也可以通过 BYOM，即自带模型，把选定的语言模型或模型账户注册到 AIP。它可以连接外部 REST API，也可以由 Compute Module，也就是运行自定义计算服务的模块，承载模型服务或转发逻辑。自托管表示模型运行在组织选择与管理的计算资源上，资源配置和维护也随之成为方案的一部分。

有时团队在 AIP 与外部模型之间加一层代理或联邦服务，先处理敏感内容、转换接口格式，或者根据费用、速度和可用性把请求分到不同模型。这像一个可以执行规则的中转站。Palantir 对其提供的第三方托管模型说明了提示和回答不被保留、不用于训练的相关保障；自带账户和模型则要核对实际适用的处理方与条款。

还有一些任务并不需要语言模型来计算。博物馆预测下周客流量时，可以用 Model Studio 训练预测、回归或分类等机器学习模型；语言模型再帮助解释预测结果。预测是否准确，与文字解释是否忠实，是两件可以分别检验的事。

模型接好以后，演示往往已经能给出漂亮回答。真正困难的下一步是：换一种说法、少一项信息或突然没有名额时，它还能按同一套业务要求工作吗？

本节事实核查：官方资料 [1]官方资料 [2]官方资料 [3]官方资料 [4]官方资料 [16]

怎样知道这次答得好，下次也不会乱办？

团队先把 A102 变成一组可以重复使用的案例。一个版本有足够名额；一个版本没有适合轮椅的路线；另一个版本只说“晚一点”而没有具体时间；还有一个版本试图修改无权管理的预约。它们来自同一件事的不同可能性，正好说明助手在什么地方应该继续、询问或停止。

AIP Evals 可以把这组输入交给函数或助手，按评估方法检查结果，并比较模型或版本。对于语言模型，同样输入的表达可能变化，所以还可以观察重复运行的差异。评估集是输入、预期行为和判断方法的集合，不要求所有正确回答逐字相同。

例如助手说“当前没有满足要求的场次”，并说明已查询的日期和路线条件，这可能完全正确。反过来，答案听起来非常周到，却给了不存在的场次，或者在确认前创建了预约，就是业务失败。因此团队既看回答，也看工具请求及其真实执行结果。

在本文这个产品里，平均得分还不足以覆盖重要错误。漏掉一个可选场次与未经确认改掉预约，后果不同。团队可以先允许助手生成待确认建议，用实际案例积累证据，再扩大可以自动处理的范围。每次发现一个新问题，就把它加入原来的案例中，下一次改模型或提示词时一起检查。

这些测试让团队更有把握上线，但实际使用仍会出现没见过的情况。还有些问题与答案内容无关，例如阿宁等了半天才看到结果。要理解这些问题，就需要看见一次请求在系统里经过了什么。

本节事实核查：官方资料 [11]

一次回答为什么要等这么久，又花了多少资源？

阿宁输入一句话，背后可能先查预约，再搜索路线说明，再调用计算，最后等待模型组织回答。只知道“总共用了十几秒”，很难判断应该改哪里。追踪把一次请求的步骤放到同一条时间线上，让团队看到哪一步最耗时。

Ontology 和 AIP observability 提供指标、执行历史、追踪与日志，Chatbot Studio 也提供会话执行记录。它们帮助把用户看到的体验与实际系统行为联系起来：到底是检索慢、工具请求失败，还是模型等待时间长。日志还可能包含业务内容，需要按敏感程度配置访问，不能默认原始数据的保护自动覆盖所有记录。

模型容量通常用 TPM 和 RPM 等指标表达。token 是模型处理文本的计量单位，不等于固定一个汉字或一个词；TPM 是每分钟可处理的 token 数，RPM 是每分钟可处理的请求数。一个人提交很长材料，和很多人同时提交很短问题，可能分别碰到不同限制。平台可以在环境、项目和用户等层面管理这些容量。

一次业务任务也可能消耗多次模型调用。AIP Analyst 为回答一个分析问题，可能反复查询、计算并继续调用模型。因此费用和资源应按完成一项任务的全过程理解：除了语言模型用量，还可能包括对象查询、函数和其他计算。只看最后生成多少文字，会漏掉前面已经做过的工作。

现在团队知道系统哪里慢、哪些案例失败，以及哪些步骤消耗较多，就有了具体的改进目标。下一步可以尝试优化，同时保留原来已经做到的能力。

本节事实核查：官方资料 [9]官方资料 [12]官方资料 [13]官方资料 [14]官方资料 [17]

让助手越用越好，依靠的是同一套业务事实与反馈

AIP Evolve 可以围绕一个目标组织 AI FDE 代理探索改动。AI FDE 是能够通过自然语言请求操作 Foundry 的 AI 工程助手；Evolve 协调它们检查目标资源、尝试候选方案并进行验证，再把提案和活动记录交给人审阅。

例如团队希望缩短预约助手的等待时间，同时保持已有业务案例的表现。候选方案可能调整提示词或更换模型。通过同一组案例比较，团队才能看见新方案节约了多少时间，以及有没有遗漏轮椅路线、弄错人数或改变确认流程。费用或速度的改善，要与办理质量一起理解。

回顾 A102，这套助手能够办事，并非只因为语言模型善于对话。前面已经连接了预约和场次数据，业务本体说明它们的关系，函数计算可用方案，Action 定义正式改期，流程负责后续交接。AIP 把这些已经建立的能力提供给模型，让自然语言成为使用它们的一种入口。

这也解释了分析、应用、流程和 AI 的关系。分析帮助人发现值得处理的问题；应用把办理步骤放在合适界面上；流程按条件组织跨时间的处理；AI 则理解表达多样的需求，并借助业务数据和工具参与其中。它们能够共享基础，才不必各自重新猜测什么叫预约、何时能够改期。

最后，阿宁能否更快找到合适方案、减少返工，并看清每笔预约的结果，才是这段系统建设的实际意义。新的办理记录和真实问题会继续回到分析与评估中；共同的数据定义与运行反馈，让后面的改进建立在前面的工作上。

本节事实核查：官方资料 [15]官方资料 [18]官方资料 [21]

适用边界与容易误解的地方

术语速查

上下文

完成当前任务所需的记录、规则和背景材料。

工具调用

模型请求外部功能查询信息或执行操作。

BYOM

把组织自选的模型或模型账户接入 AIP。

评估集

一组有预期行为和评分规则的测试任务。

追踪

一次请求经历哪些步骤、各花多久的运行记录。

来源与核查

对应原文

Rahul Garg · 2026-09-03 · Vanyar

1. AIP Model Catalog发现模型、生命周期与地区可用性。
2. 自带模型REST、计算模块、自托管及支持边界。
3. AIP 安全与隐私Palantir 对第三方托管模型的数据使用保障。
4. Model Studio预测、回归和分类任务。
5. Chatbot Studio企业助手、数据与工具。
6. 助手工具操作工具及用户确认配置。
7. AIP Logic函数构建及读取权限传播边界。
8. Automate条件触发自动化。
9. AIP Analyst临时分析与多次模型、查询消耗。
10. Workshop面向操作的应用界面。
11. AIP Evals测试、版本对比和运行差异。
12. Ontology 与 AIP 可观测性指标、历史、追踪与日志。
13. 日志权限日志访问需单独配置保护。
14. 模型容量管理吞吐限制、用量与成本查看。
15. AIP Evolve围绕目标探索、验证并提交优化提案。
16. 模型代理与联邦层脱敏、格式转换和模型请求路由。
17. Chatbot 会话日志结构化会话执行记录。
18. AIP 官方概览AI 与企业数据、操作、工具和治理的连接。
19. Ontology 官方概览业务对象、关系、操作、函数与安全。
20. 本体增强生成（OAG）为模型检索相关上下文的方法；并非文件格式。
21. AI FDE 官方概览通过自然语言操作 Foundry、使用工具并验证改动。

资料核对日期：2026-09-15。本文用中文概括原文观点，结合一手资料独立讲解；分析、图解和教学示例由本指南编写。主题清单用于检查议题覆盖，不表示逐项复写原文全部细节。产品能力以所在部署的当前官方文档与实际配置为准。