介绍
自从发布搜索端点以来,我们开发了新方法来为此任务取得更好的结果。因此,我们将从我们的文档中删除搜索端点,并在 2022 年 12 月 3 日取消所有组织对此端点的访问权限。6 月 3 日之后创建的新帐户将无法访问此端点。
我们强烈鼓励开发人员改用更新的技术,以产生更好的结果,如下所述。
当前文档
https://beta.openai.com/docs/guides/search
https://beta.openai.com/docs/api-reference/searches
选项
此处也概述了此选项。
选项 1:过渡到基于嵌入的搜索(推荐)
我们相信,通过将底层搜索系统移动到使用基于向量的嵌入搜索,大多数用例将得到更好的服务。主要原因是我们当前的系统使用二元组过滤器来缩小候选范围,而我们的嵌入系统具有更多的上下文感知。此外,一般来说,从长远来看,使用嵌入的成本会大大降低。如果您对此不熟悉,可以访问我们的嵌入指南了解更多信息。
如果您有更大的数据集(>10,000 个文档),请考虑使用 Pinecone 或 Weaviate 等矢量搜索引擎来支持该搜索。
选项 2:重新实现现有功能
如果您使用文档参数
当前的 openai.Search.create 和 openai.Engine.search 代码可以用这个片段替换(注意这只适用于非 Codex 引擎,因为它们使用不同的分词器。)
我们计划将此代码段移动到 openai.Search.create_legacy 下的 openai-python 存储库中。
如果您使用的是文件参数
作为快速回顾,以下是当前带有文件的搜索端点的高级步骤:
第一步:上传一个jsonl文件
在幕后,我们将用于文件搜索的新文件上传到弹性搜索。然后将 jsonl 的每一行作为文档提交。
每行都需要有一个“文本”字段和一个可选的“元数据”字段。
这些是我们索引的弹性搜索设置和映射:
{
"properties": {
"document": {"type": "text", "analyzer": "standard_bigram_analyzer"}, -> the “text” field
"metadata": {"type": "object", "enabled": False}, -> the “metadata” field
}
}
{
"analysis": {
"analyzer": {
"standard_bigram_analyzer": {
"type": "custom",
"tokenizer": "standard",
"filter": ["lowercase", "english_stop", "shingle"],
}
},
"filter": {"english_stop": {"type": "stop", "stopwords": "_english_"}},
}
}
之后,我们执行了标准的 Elastic search 搜索调用,并使用 `max_rerank` 来确定要从 Elastic search 返回的文档数。
第 2 步:搜索
从步骤 1 中获得候选文档后,您只需进行标准的 openai.Search.create 或 openai.Engine.search 调用即可对候选文档进行重新排序。见文件