Palantir-语义搜索

1．语义搜索在 Foundry 中是什么、与本体的关系

• 在 “Semantic Search • Overview” 文档中指出：
  语义搜索是“基于文本的内涵意义或上下文”而非仅仅关键词匹配。
• 文档 “Document Processing” 提到：可以将 PDF 或图像等非结构化内容导入 Foundry → 提取文本 → 将文本拆 chunk → 引入到本体对象（Object）中 → 进行语义搜索。
• 在 “Using Custom Models to Create a Semantic Search Workflow” 文档中，明确提到：
  • 建立 embeddings（向量表示）
  • 创建一个对象类型（Object Type）用于承载这些 embedding 与对象引用。
• 因此，可以看到：语义搜索在 Foundry 的实现路径是 “非结构化／半结构化文本 → 对象类型实例 + 向量 embedding → 本体对象 +属性 → 搜索接口”。

所以，语义搜索并不是与本体无关的独立功能，而是深度 与本体对象类型、属性、链接 关联起来，从而让用户可以在本体语义层上做“近义／语义”检索。

2．与本体关联的关键机制 & 步骤

下面是一个典型的流程，说明语义搜索如何“嵌入”到本体中：

1）文本／文档导入 & 预处理

• • 将非结构化内容（PDF、图像等）导入 Foundry 作为 media set。
  • 用 Pipeline Builder 拆分（chunking）文本，生成更小语义单位（如每 256 字或每个段落）作为搜索单位。

2）创建或选已有对象类型 (Object Type)

• • 定义一个本体对象类型，比如 “DocumentChunk” 或 “MediaSegment”，其属性包括：原始文档引用、chunk_id、文本内容、embedding (向量) 等。
  • 这样，每一个 chunk 都成为本体中的一个对象实例。

3）生成 Embedding 向量

• • 使用 Foundry 内置或自定义模型将文本 chunk 转为 embedding 向量。文档提及 “Use Palantir-provided models …” 或 “Using custom models …”
  • 将 embedding 存为对象属性，例如 text_embedding。

4）在本体中定义属性 + 索引

• • 对象类型 “DocumentChunk” 中设置属性 text_embedding 并可能配置为可用于近邻检索（vector search）。
  • 在 Workshop、Function、或 AIP Logic 中调用近邻搜索或语义检索操作。

5）搜索/查询接口

• • 用户或应用发起查询（自然语言或关键词） → 系统将其 embedding 化 → 在对象集（本体中）做近邻查询找出最相似 chunks。
  • 返回结果可通过对象视图、链接至原始文档对象、或展示相关上下文。

6）链接回本体的其它对象类型

• • 找到相关 chunk 后，可以通过链接（Link Type）把 chunk 对象与其它本体对象（例如“Document”“Topic”“UseCase”）关联起来。
  • 这样语义搜索不仅返回文本片段，还可进一步导航到本体实体、执行工作流、触发动作。

3．为什么把语义搜索与本体关联很重要

• 统一语义层：本体定义了组织的“实体－属性－关系”模型，语义搜索把非结构化内容变为本体模型中的“对象”，使搜索结果能直接参与对象视图、链接导航、动作触发。
• 连贯上下文：搜索结果不是孤立的文本片段，而是本体对象。用户可以看到该文本片段属于哪个文档、对应哪个业务实体，增强可理解性。
• 复用和治理：通过本体管理对象类型、属性、链接、权限，语义搜索生成的对象同样纳入治理体系。
• 增强智能操作：基于本体对象的搜索结果可以触发动作 (Action Type)、修改属性、建立新链接，从而不是“找出来”就结束，而能“进一步操作”。

4．语义搜索与本体的关系

在 Foundry 中，本体（Ontology） 是企业语义层：
它定义了所有的对象类型（Object Types）、属性（Properties）、关系（Links）、动作（Actions）等。

而语义搜索的任务是：

• 从文本、PDF、图像、报告、电子邮件等非结构化内容中，
• 自动识别出其中包含的实体（如 Person、Company、Transaction、Project 等）和属性值（如 name、amount、date 等），
• 然后将这些抽取结果转化为本体对象或属性的实例化数据。

换句话说：语义搜索 + 文本抽取 ＝ “非结构化内容 → 本体实例化”。

5．典型的处理流程

文档《Document Processing》和《Semantic Search Overview》描述了这样一个流程：

1）文档导入（Unstructured Input）

• 导入 PDF、Word、邮件、报告等文件到 Foundry。
• 这些文件最初只是一堆文本和元数据（文件名、创建人、时间等）。

2）文本解析与拆块（Chunking）

• 使用 Document Processing Pipeline 或 Foundry Function 将文档分块（每 N 段或每 N 字符）。
• 每个块（chunk）作为一个“潜在对象候选”。

3）语义嵌入（Embedding）

• 为每个 chunk 计算语义向量（embedding）。
• 这让系统能够基于“语义相似度”检索文本，而不是关键词。

4）实体与属性抽取（Entity & Property Extraction）

• 利用 Foundry 提供的 NLP 模型或自定义模型，对文本块进行结构化识别：
  例如从文本中提取：
• 张三 — Person
• 三元公司 — Company
• 金额 100,000 元 — Transaction.amount
• 日期 2025-10-30 — Transaction.date
• 抽取结果被映射到 Ontology 的对应对象类型与属性。
  比如：
  • Person → Ontology.ObjectType = Person
  • Company → Ontology.ObjectType = Organization
  • amount & date → Transaction 对象的属性

5）写入本体（Ontology Writeback）

• 解析出的实体与属性通过 API 写入对应对象类型的 backing dataset；
• 或以 Link Type 的方式连接（例如 Person → worksFor → Company）。

6）语义搜索 + 关联导航（Semantic Search + Graph Navigation）

• 当用户输入一个自然语言问题（如“张三最近参与了哪些交易？”），
  系统会：
  1. 将查询转为向量（embedding）；
  2. 在所有对象实例的向量属性中进行最近邻搜索；
  3. 返回最相似的对象实例（Person、Transaction、Company 等）；
  4. 并通过 Link Type 展示对象间的语义关系。

这就形成了一个完整的语义图谱式检索过程。

6．为什么要这样做

7．一个简单的例子

语义搜索在 Foundry 中的真正目标，不只是“找文本”，而是“从文本中构建语义对象网络”。

它通过：

• 文档解析、实体识别、属性抽取；
• 将识别结果映射进本体对象类型和属性；
• 利用 embedding 向量搜索进行语义检索；
• 通过本体的对象和链接形成可导航的知识图。