当你必须用「自己的」嵌入模型时
这一篇讲怎么把非 Palantir 提供的嵌入模型接进语义搜索：用 Foundry 模型生成向量、建对象类型、再写函数做 KNN 检索。 原文也直言——这已不是推荐做法，先看清何时才值得。
https://www.palantir.com/docs/foundry/ontology/using-custom-models-to-create-a-semantic-search-workflow/
原始标题：Use custom models to create a semantic search workflow
一句话速览
当你必须用「自己的」嵌入模型时：这一篇讲怎么把非 Palantir 提供的嵌入模型接进语义搜索：用 Foundry 模型生成向量、建对象类型、再写函数做 KNN 检索。
定位：这是给「自带模型」的人看的
原文开宗明义：自定义模型已不是推荐做法。
这篇教程面向使用非 Palantir 提供的嵌入模型的场景。原文第一句就给了一个重要提醒： 自定义模型这条路已经不再是推荐的工作流（no longer a recommended workflow）， 建议优先看 Palantir 提供的模型清单与官方语义搜索教程。
文中用一个「端到端的文档搜索服务」作例子：用 Foundry 的 modeling objective 把文档嵌入成向量、存入带 vector 属性的对象类型， 再写函数用自然语言查询它。
与官方模型方案：差异对照
同样的目标，不同的「模型从哪来」。
两条路最终都落到「带 vector 属性的对象类型 + KNN 检索」，差别主要在模型从哪来、谁部署。
步骤一：用 Foundry 模型生成嵌入
import 一个开源模型，用 transform 把文本列变成 embedding 列。
从一份已解析好的数据集（含 Document_Content、Link 等元数据）出发，目标是给文本生成嵌入以便语义搜索。
- 原文示例用开源模型 all-MiniLM-L6-v2：一个通用文本嵌入模型，产出维度 384 的向量。
- 这个模型可以被任何「输出与 Foundry Ontology
vector类型兼容的向量」的模型替换。 - 模型需暴露一个 API：表格输入含一个
text字符串列；表格输出含一个embedding浮点数列。 - transform 跑完数据后返回
embedding，再把值转成 float 以匹配向量类型。
步骤二：创建对象类型
把 embedding 建成 Vector 属性，并配好维度与相似度函数。
有了含浮点向量列的数据集后，创建一个对象类型（文中名为 Document），并：
- 把
embedding属性设为 Vector 类型。 - 配置两个值：
- Dimension（维度）：即
embedding列里数组的长度（如 384）。 - Similarity Function（相似度函数）：两个对象的 embedding 之间计算距离的方法。
- Dimension（维度）：即
对象类型建好后，ObjectApiName（本例为 Document）会在配置页拿到，后续代码里用它指代该对象类型。
ModelApiName、OutputDatasetRid、
InputDatasetRid、ModelRid——保持每处一致即可。
步骤三：写函数做 KNN 检索
函数接收用户输入，用 live 部署生成向量，再跑 KNN。
最后一步是写一个函数：接收用户输入，用前面建好的 Live Modeling Deployment 生成查询向量， 然后对该对象类型跑 KNN 搜索（TSv1）。
- 函数把用户文本变成向量，再交给 nearestNeighbors 找最近邻对象。
- 文中强调：Python 函数也支持模型函数与语义搜索，但本教程未给出 Python 示例。
- 向量属性（vector properties）的修改，也可以由 Actions 和 Functions 来施加。
动手演示：该用哪种方案？
给一个场景，判断该走「官方模型」还是「自定义模型」。
下面每个场景，点「用官方模型」或「用自定义模型」来作答。原文的核心立场是：自定义已非推荐， 只有「硬要用自有模型」时才值得——用这个标尺去判断。
一页带走
延伸阅读 · 相关页面
按主题横向跳转，不必顺着目录一篇篇读。
常见问题速答 · FAQ
关于「当你必须用「自己的」嵌入模型时」，读者最常问的几个问题。