构建索引的方法、装置、电子设备和存储介质

技术领域

本申请实施例涉及搜索技术，尤其涉及一种构建索引的方法、装置、电子设备和存储介质。

背景技术

用户可以通过终端设备的网页或者搜索应用程序进行信息搜索，以网页为例，用户在网页的输入框中输入文本进行搜索，这种搜索方式称为文本搜索。随着搜索技术的发展，用户还可以输入图片或视频进行搜索，终端设备会显示图片或视频的搜索结果，这种搜索方式称为向量搜索。但无论是文字搜索还是向量搜索，终端设备会将用户输入的文本、图片或视频发送至服务器，由服务器根据构建的索引得到搜索结果。其中，索引用于表征文本与文档的映射关系，或向量与文档的映射关系。

随着向量搜索的出现，文本和向量联合搜索的需求也应运而生。为了达到同时搜索文本和向量的目的，可以在服务器中集成文本搜索系统和向量搜索系统，文本搜索系统和向量搜索系统可以分别构建各自的索引。现有技术中，为了保证两个系统构建的索引的一致性，向量搜索系统采用与文本搜索系统生成索引相同的方式，依次生成包括多个索引的小文件，小文件生成后，小文件中的索引才可被搜索，在小文件达到一定数量时，对小文件中的索引文件进行合并，生成大的文件。

现有技术中向量搜索系统不断生成小文件且合并小文件的方式，构建索引的时间长、效率低。

发明内容

本申请实施例提供一种构建索引的方法、装置、电子设备和存储介质，能够节省构建索引的时间，降低构建索引消耗的资源，提高索引构建的效率。

第一方面，本申请实施例提供一种构建索引的方法，该方法可以应用于构建索引的服务器、也可以应用于服务器中的芯片。下面以应用于服务器为例对该方法进行描述，该方法中，服务器可以接收来自第一终端设备的文档，该文档是待生成索引的文档。服务器根据文档，生成第一索引和第二索引，其中，所述第一索引表征向量和所述文档的映射关系，所述第二索引表征文本与所述文档的映射关系。也就是说，本申请实施例中的第一索引为向量类型的索引，第二索引为文本类型的索引。其中，向量类型的索引指的是在用户输入搜索内容后，通过搜索内容对应的向量和第一索引，可以搜索与该搜索内容相关的文档。文本类型的索引指的是在用户输入搜索内容后，通过搜索内容的关键词和第二索引，可以搜索与该搜索内容相关的文档。

本申请实施例中，服务器在生成文档的第一索引和第二索引后，可以将所述第一索引存储至第一类型的文件集合中，将所述第二索引存储至第二类型的文件集合中，且建立所述第一索引、所述第二索引和所述文档的映射关系。本申请实施例中的第一类型的文件集合用于存储向量类型的索引，第二类型的文件集合用于存储文本类型的索引。应注意的是，本申请实施例中未对第一类型的文件集合中的文件进行合并操作，即未按照与文本类型的索引相同的方式对文件进行合并等操作，而是在生成第一索引后，第一索引即处于可用状态，处于可用状态的第一索引用于通过向量搜索与搜索内容关联的所述文档。应理解，可用状态指的是第一索引可被搜索，即第一索引生成后，即可以采用第一索引获取上述文档。

本申请实施例中构建索引的过程中，因为不需要对第一索引所在的文件进行合并，进而能够节省构建索引的时间，提高索引构建的效率。本申请实施例中还建立了第一索引、第二索引和文档的映射关系，进而能够保证第一类型的文件集合和第二类型的文件集合中的索引的一致性。

其中，述第一类型的文件集合中包括至少一个第一文件，所述第一文件用于存储第一索引，所述第二类型的文件集合中包括至少一个第二文件，所述第二文件用于存储第二索引。本申请实施例中在将第一索引存储至第一类型的文件集合中时，即为将第一索引写入第一类型的文件集合中的一个第一文件中，将第二索引存储至第二类型的文件集合中时，即为将第二索引写入第二类型的文件集合中的一个第二文件中。其中，在将第一索引写入第一类型的文件集合中的一个第一文件中时，可以将第一索引写入任一个第一文件中，在将第一索引写入第二类型的文件集合中的一个第二文件中时，可以将第二索引写入任一个第二文件中。相应的，本申请实施例需要建立文档、第一文件中的第一索引，以及第二文件中的第二索引的映射关系。

下述对本申请实施例中写入将第一索引写入第一类型的文件集合中的一个第一文件中的过程进行说明：

其中，若所述第一类型的文件集合中的第i个第一文件中已写入的索引的数量小于第一阈值，则将所述第一索引写入所述第i个第一文件中，所述i为大于或等于1的整数；若所述第i个第一文件中已写入的索引的数量等于所述第一阈值，则新建第i+1个第一文件，且将所述第一索引写入所述第i+1个第一文件中。也就是说，第一类型的文件集合中的第一文件是依次生成的，在一个第一文件中写入的第一索引的数量达到第一阈值时，再新建一个新的第一文件，在该新建的第一文件中继续写入第一索引。

下述对本申请实施例中写入将第二索引写入第二类型的文件集合中的一个第二文件中的过程进行说明：

若所述第二类型的文件集合中的第j个第二文件中已写入的索引的数量小于第二阈值，则将所述第二索引写入所述第j个第二文件中，所述j为大于或等于1的整数；若所述第j个第二文件中已写入的索引的数量等于所述第二阈值，则新建第j+1个第二文件，且将所述第二索引写入所述第j+1个第二文件中。与上述将第一索引写入第一文件的过程类似的，第二类型的文件集合中的第二文件是依次生成的，在一个第二文件中写入的第二索引的数量达到第二阈值时，再新建一个新的第二文件，在该新建的第二文件中继续写入第二索引。应注意的是，鉴于第二类型的文件集合中第二文件采用的是，不断生成小文件且合并小文件的方式，因此本申请实施例中的第二阈值小于第一阈值。

其中，因为第一类型的文件集合中的第一文件中的第一索引是实时可被搜索的，而第二类型的文件集合中的第二文件中的第二索引在达到第二阈值时，才将该第二文件从写入模式转换为只读模式，使得转换为所述只读模式的该第二文件中的第二索引处于可用状态。本申请实施例中以上述第j个第二文件为例，若所述第j个第二文件中已写入的索引的数量等于所述第二阈值，则将所述第j个第二文件从写入模式转换为只读模式，转换为所述只读模式的所述第j个第二文件中的第二索引处于可用状态，处于可用状态的第二索引用于通过文本搜索与搜索内容关联的所述文档。

在本申请实施例中一种可能的实现方式中，可以根据用户的设置，确定一个第二文件中的可写入的第二索引的数量，即第二阈值。应理解，本申请实施例中的每个第二文件中的第二阈值可以相同或者不同。其中，用户可以通过第一终端设备设置第二文件的转换时长，即第二文件中的第二索引可被搜索的时长，该转换时长为第二文件从写入模式转换为只读模式的时长。进而本申请实施例中可以根据转换时长，确定所述第二阈值，具体的，可以根据转换时长，以及一个第二索引写入的时间，确定该转换时长可以写入多少个第二索引，即第二阈值。

其中，与上述第二文件类似的，用户也可以设置第一文件中可写入的第一索引的数量，即第一阈值。或者第一阈值可以为约定的。

应注意，第二类型的文件集合中第二文件采用的是：不断生成小文件且合并小文件的方式。因此，本申请实施例中，可以对第二类型的文件集合中第二文件进行合并，其中，合并第二文件的时机可以为如下两种方式：

第一种方式为：若转换为只读模式的第二文件的占用内存达到预设内存，则将所述转换为只读模式的第二文件合并。也就是说，第二类型的文件集合中，转换为只读模式的第二文件在达到预设内存时，可以将转换为只读模式的第二文件合并成一个大文件。

第二种方式为：若当前可用负载大于预设负载，则将所述转换为只读模式的第二文件合并。也就是说，服务器可以检测运行负载，在可用负载大于预设负载时，将所述转换为只读模式的第二文件合并成一个大文件。

应注意的是，在将第二文件合并成一个大文件后，需要更新映射关系，即重新建立合并后的第二文件中的所述第二索引、第一文件中的所述第一索引和所述文档的映射关系。

在用户通过第一终端设备向服务器发送文档的过程中，若用户发现文档中有很多错误文档，想要将发送的错误文档删除，则本申请实施例还能够删除文档。其中，本申请实施例中，接收所述第一终端设备发送的删除指令后，可以删除文档。其中，所述删除指令指示删除所述文档。

本申请实施例中服务器删除的文档的方式可以为：将所述文档标记为删除状态，但实际上并不删除文档，也就是说，标记为删除状态文档不能反馈至终端设备。或者，本申请实施例中可以将所述文档标记为删除状态，且在第二类型的文件集合中的第二文件合并时，删除所述第二类型的文件集合中的所述文档，以进而达到释放文档在服务器中的占用空间的目的。

可选的，本申请实施例中针对存在大量文档需要删除的场景，还提供将向量类型的索引和文本类型的索引进行同步合并的方法。其中，第一终端设备上可以设置有同步控件，当用户选择该同步控件时，可以触发第一终端设备向服务器发送同步删除指令。在服务器接收到来自所述第一终端设备的同步删除指令后，可以根据所述同步删除指令，删除所述第一类型的文件集合中的所述文档。其中，所述同步删除指令指示将所述第二类型的文件集合中的文档删除的情况同步至所述第一类型的文件集合。也就是说，本申请实施例中，在用户的触发下，可以在第二类型的文件集合中的第二文件合并删除文档时，也可以删除第一类型的文件集合中的该文档，即使得第一类型的文件集合中的文档与第二类型的文件集合中的文档的删除保持同步。

上述讲述的均是本申请实施例中服务器构建索引的过程，下面针对本申请实施例在构建索引的过程中，如何采用构建的索引进行搜索的过程进行说明：

本申请实施例中，在用户搜索文档时，可以通过第二终端设备出入搜索内容，第二终端可以向服务器发送搜索内容，进而使得服务器根据所述搜索内容、所述第一类型的文件集合和所述第二类型的文件集合，获取搜索结果，所述搜索结果中包括所述文档。在服务器后去搜索结果是，可以向所述第二终端设备发送所述搜索结果，进而使得第二终端设备在界面上显示搜索结果，或者播放搜索结果。应理解，本申请实施例中的第二终端设备与第一终端设备可以相同或者不同。

其中，服务器在获取搜索结果的过程中，可以根据所述搜索内容和所述第一类型的文件集合，得到第一搜索结果；根据所述搜索内容和所述第二类型的文件集合，得到第二搜索结果；根据所述第一搜索结果和所述第二搜索结果，获取所述搜索结果。

因为第二类型的文件集合中第二文件采用的是，不断生成小文件且合并小文件的方式，因此本申请实施例中第二类型的文件集合中的第二索引可以部分或全部处于可用状态，而第一类型的文件集合中的第一索引实时可被搜索，即处于可用状态，因此本申请实施例中第一类型的文件集合中的第一索引全部处于可用状态。因此，本申请实施例中可以根据所述搜索内容，以及所述第一类型的文件集合中的第一索引，得到所述第一搜索结果；根据所述搜索内容，以及所述第二类型的文件集合中处于可用状态的第二索引，得到所述第二搜索结果。

鉴于本申请实施例中服务器可以根据用户的设置删除文档，当搜索内容对应的搜索结果命中删除的文档时，向所述第二终端设备发送不包括所述文档的搜索结果。

可选的，本申请实施例中为了减少服务器的工作量，可以删除根据删除的文档生成的索引，以使得服务器获取的搜索结果中不包括删除的文档。

第二方面，本申请实施例提供一种构建索引的装置，包括：收发模块，用于接收来自第一终端设备的文档；处理模块，用于根据所述文档，生成第一索引和第二索引，且将所述第一索引存储至第一类型的文件集合中，将所述第二索引存储至第二类型的文件集合中，且建立所述第一索引、所述第二索引和所述文档的映射关系，所述第一索引表征向量和所述文档的映射关系，所述第二索引表征文本与所述文档的映射关系，所述第一索引处于可用状态，处于可用状态的第一索引用于通过向量搜索与搜索内容关联的所述文档。

在一种可能的实现方式中，所述第一类型的文件集合中包括至少一个第一文件，所述第一文件用于存储第一索引。所述处理模块，具体用于将所述第一索引写入一个第一文件中。

在一种可能的实现方式中，所述第二类型的文件集合中包括至少一个第二文件，所述第二文件用于存储第二索引。所述处理模块，具体用于将所述第二索引写入一个第二文件中。

在一种可能的实现方式中，所述处理模块，具体用于建立第一文件中的所述第一索引、第二文件中的所述第二索引和所述文档的映射关系。

在一种可能的实现方式中，所述处理模块，具体用于若所述第一类型的文件集合中的第i个第一文件中已写入的索引的数量小于第一阈值，则将所述第一索引写入所述第i个第一文件中，所述i为大于或等于1的整数；若所述第i个第一文件中已写入的索引的数量等于所述第一阈值，则新建第i+1个第一文件，且将所述第一索引写入所述第i+1个第一文件中。

在一种可能的实现方式中，所述处理模块，具体用于若所述第二类型的文件集合中的第j个第二文件中已写入的索引的数量小于第二阈值，则将所述第二索引写入所述第j个第二文件中，所述j为大于或等于1的整数；若所述第j个第二文件中已写入的索引的数量等于所述第二阈值，则新建第j+1个第二文件，且将所述第二索引写入所述第j+1个第二文件中。

在一种可能的实现方式中，所述处理模块，还用于若所述第j个第二文件中已写入的索引的数量等于所述第二阈值，则将所述第j个第二文件从写入模式转换为只读模式，转换为所述只读模式的所述第j个第二文件中的第二索引处于可用状态，处于可用状态的第二索引用于通过文本搜索与搜索内容关联的所述文档。

在一种可能的实现方式中，所述收发模块，还用于接收来自所述第一终端设备的第二文件的转换时长，所述转换时长为第二文件从写入模式转换为只读模式的时长。

相应的，所述处理模块，还用于根据所述转换时长，确定所述第二阈值。

在一种可能的实现方式中，所述处理模块，还用于若转换为只读模式的第二文件的占用内存达到预设内存，则将所述转换为只读模式的第二文件合并；或者，若当前可用负载大于预设负载，则将所述转换为只读模式的第二文件合并。

所述处理模块，所述处理模块，还用于建立合并后的第二文件中的所述第二索引、第一文件中的所述第一索引和所述文档的映射关系。

在一种可能的实现方式中，所述第二类型的文件集合中包括所述文档。

所述收发模块，还用于接收所述第一终端设备发送的删除指令，所述删除指令指示删除所述文档。相应的，所述处理模块，还用于将所述文档标记为删除状态。

在一种可能的实现方式中，所述第二类型的文件集合中包括所述文档。

所述收发模块，还用于接收所述第一终端设备发送的删除指令，所述删除指令指示删除所述文档。相应的，所述处理模块，还用于将所述文档标记为删除状态，且在所述第二类型的文件集合中的第二文件合并时，删除所述第二类型的文件集合中的所述文档。

在一种可能的实现方式中，所述收发模块，还用于接收来自所述第一终端设备的同步删除指令，所述同步删除指令指示将所述第二类型的文件集合中文档的删除情况同步至所述第一类型的文件集合。

相应的，所述处理模块，还用于根据所述同步删除指令，删除所述第一类型的文件集合中的所述文档。

在一种可能的实现方式中，接收所述收发模块，还用于来自第二终端设备的所述搜索内容。相应的，所述处理模块，还用于根据所述搜索内容、所述第一类型的文件集合和所述第二类型的文件集合，获取搜索结果，所述搜索结果中包括所述文档。

所述收发模块，还用于向所述第二终端设备发送所述搜索结果。

在一种可能的实现方式中，所述处理模块，具体用于根据所述搜索内容和所述第一类型的文件集合，得到第一搜索结果；根据所述搜索内容和所述第二类型的文件集合，得到第二搜索结果；根据所述第一搜索结果和所述第二搜索结果，获取所述搜索结果。

在一种可能的实现方式中，所述处理模块，具体用于根据所述搜索内容，以及所述第一类型的文件集合中的第一索引，得到所述第一搜索结果；根据所述搜索内容，以及所述第二类型的文件集合中处于可用状态的第二索引，得到所述第二搜索结果。

在一种可能的实现方式中，所述处理模块，还用于若所述搜索结果中包括标记为删除状态的所述文档，则在所述搜索结果中过滤掉所述文档。相应的，所述收发模块，具体用于向所述第二终端设备发送不包括所述文档的搜索结果。

第三方面，本申请实施例提供一种构建索引的装置(例如芯片)，所述构建索引的装置上存储有计算机程序，在所述计算机程序被所述构建索引的装置执行时，实现如第一方面所提供的方法。

第四方面本申请实施例提供一种电子设备，该电子设备可以为下述实施例中的服务器。所述电子设备包括：处理器、存储器、收发器；所述收发器耦合至所述处理器，所述处理器控制所述收发器的收发动作；其中，存储器用于存储计算机可执行程序代码，程序代码包括指令；当处理器执行指令时，指令使所述电子设备执行如第一方面所提供的方法。

第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机存储介质存储有计算机指令，当所述计算机指令被计算机执行时，使得所述计算机执行如第一方面所提供的方法。

本申请实施例提供一种构建索引的方法、装置、电子设备和存储介质，该方法包括：根据文档，生成第一索引和第二索引，第一索引表征向量和文档的映射关系，第二索引表征文本与文档的映射关系；将第一索引存储至第一类型的文件集合中，第一索引处于可用状态，处于可用状态的第一索引用于通过向量搜索与搜索内容关联的文档；将第二索引存储至第二类型的文件集合中，且建立第一索引、第二索引和文档的映射关系。因为本申请实施例中的第一索引在生成后即处于可用状态，也就是说，本申请实施例中不需要对第一索引所在的文件进行合并，进而能够节省构建索引的时间，提高索引构建的效率。本申请实施例中还建立了第一索引、第二索引和文档的映射关系，进而能够保证第一类型的文件集合和第二类型的文件集合中的索引的一致性。

附图说明

图1为本申请实施例适用的网络架构示意图一；

图2为一种网络架构示意图；

图3为另一种网络架构示意图；

图4为构建索引的一种示意图；

图5为构建索引的另一种示意图；

图6为本申请实施例提供的构建索引的方法的一实施例的流程示意图；

图7为本申请实施例提供的构建索引的示意图一；

图8为本申请实施例提供的构建索引的方法的另一实施例的流程示意图；

图9为本申请实施提供的构建索引的示意图二；

图10为本申请实施例提供的构建索引的方法的另一实施例的流程示意图；

图11为本申请实施例提供的第一终端设备的界面示意图一；

图12为本申请实施例提供的第一终端设备的界面示意图二；

图13为本申请实施例提供的构建索引的方法的另一实施例的流程示意图；

图14为本申请实施例提供的构建索引的方法的另一实施例的流程示意图；

图15为本申请实施例提供的第二终端设备的界面变化示意图；

图16为本申请实施例提供的构建索引的装置的结构示意图一；

图17为本申请实施例提供的构建索引的装置的结构示意图二；

图18为本申请实施例提供的电子设备的结构示意图。

具体实施方式

图1为本申请实施例适用的网络架构示意图一。如图1所示，该网络架构中包括终端设备和服务器。用户可以通过终端设备的网页或者搜索应用程序进行信息搜索，服务器可以根据用户输入的搜索内容，查找与搜索内容相关的文档，进而将该与搜索内容相关的文档反馈给终端设备。应理解，此处所述的文档和下述实施例中的文档代表以文本形式、图片形式、视频形式、或几种形式结合的形式，或其他形式存在的存储对象。本申请实施例中的文档涵盖更多种形式，比如Word文档，便携式文档格式(portable document format，PDF)、超文本标记语言(hyper text markup language，HTML)、可扩展标记语言(extensible markup language，XML)、图像、视频等不同格式的文件都可以称之为文档。再比如一封邮件，一条短信，一条微博也可以称之为文档。

应理解，图1中所示的网络架构适用于本申请实施例中用户在通过终端设备进行信息搜索的网络架构，为了便于与下述为服务器提供文档的终端设备进行区别，此处的终端设备为下述实施例中所述的第二终端设备，图1中标识为第二终端设备。图1中以终端设备为智能手机为例进行说明。

本申请实施例中，终端设备可以指用户设备、接入终端、用户单元、用户站、远程终端、移动设备、用户终端、终端、无线通信设备、用户代理或用户装置。终端设备可以是手机(mobile phone)、平板电脑(pad)、带无线收发功能的电脑、蜂窝电话、无绳电话、会话启动协议(session initiation protocol，SIP)电话、个人数字助理(personal digitalassistant，PDA)、具有无线通信功能的手持设备、计算机或其它处理设备、车载设备、可穿戴设备、虚拟现实(virtual reality，VR)终端设备、增强现实(augmented reality，AR)终端设备、智慧家庭(smart home)中的无线终端、未来5G网络中的终端设备或者未来演进的公用陆地移动通信网络(public land mobile network，PLMN)中的终端设备等，本申请实施例对此并不限定。

服务器需要根据文档构建索引(build index)，进而通过已构建的索引来查找与搜索内容相关的文档。其中，索引包括正向索引(forward index)和反向索引(invertedindex)，正向索引也可以称为正排索引，反向索引也可以称为倒排索引、postings file或inverted file。

下面首先对正向索引进行说明：

在服务器中每个文档对应一个标识，如文档编号(identity document，ID)，文档的内容被表示为一系列关键词的集合。例如，服务器通过对文档1进行分词，提取了20个关键词，进而记录每个关键词在文档中的出现次数和出现位置。该20个关键词，以及记录的每个关键词在文档中的出现次数和出现位置，即为文档1的索引。通过该种方式，可以获取所有文档的索引。

下述表一为正向索引的结构示意：

表一

服务器根据正向索引在查找与搜索内容相关的文档时，需要查找所有的文档，找出包含有搜索内容或者搜索内容中的关键词的文档，再根据打分模型对得到的文档进行打分(即通过打分模型计算得到的文档与搜索内容或者搜索内容中的关键词的相似度或关联度)，根据分数排出先后顺序后呈现给用户。因为服务器在构建索引时采用的文档的数量很大，采用正向索引搜索文档的方式需要在每次搜索时，均需要搜索所有的文档，花费的时间较长，无法满足实时反馈文档的需求。

为了解决正向索引造成的搜索时间长和搜索效率低的问题，倒排索引应运而生。与正向索引不同的是，服务器将文档对应至关键词的映射转换为关键词对应至文档的映射，即每个关键词都对应着多个文档，这些文档中均出现了这个关键词。因此，服务器在采用倒排索引搜索与搜索内容相关的文档时，可以获取与该搜索内容相关联的关键词，进而将关键词对应的文档反馈至终端设备。倒排索引相较于正向索引，可以减短搜索时间、提高搜索效率。

另外，倒排索引中除了关键词，以及关键词与文档的映射关系外，还可以包括关键词在每个文档中出现的位置和频次。关键词在每个文档中出现的频次可以影响最后文档的先后排序。

下述表二为倒排索引的结构示意：

表二

如上讲述的均为文本搜索方式，即服务器在构建的索引为关键词(文本)与文档的映射关系，用户在输入搜索内容时需要输入文本形式的搜索内容，如上述图1中用户输入的“苹果”。其中，服务器在根据用户输入的文本形式的搜索内容搜索相关的文档时，可以将用户输入的搜索内容进行分词，获取搜索内容中的关键词，服务器通过计算搜索内容中的关键词与索引中的关键词的相似度，进而将相似度较高的关键词对应的文档反馈给终端设备。

可以理解的是，在服务器反馈相似度较高的关键词对应的文档时，可以对文档进行打分，进而确定文档的先后顺序(即用户在终端设备上看到的文档的排布顺序)。其中，对文档的打分可以根据打分模型、关键词在文档中出现的位置和频次确定，本实施例对此不作赘述。示例性的，服务器获取用户输入的搜索内容的关键词为“苹果”，则可以将与“苹果”相似度较高的文档反馈给终端设备。

随着搜索技术的发展，出现了新类型的搜索方式，即向量搜索方式。也就是说，用户除了输入文字进行搜索外，也可以输入图片、视频或其他非文本类型的搜索内容进行搜索。如用户在终端设备中输入一张图片，则服务器可以根据该图片反馈与该图片相关的文档。在该种向量搜索的方式中，服务器需要根据文档建立向量类型的索引，进而根据该向量类型的索引搜索相关的文档。

示例性的，服务器可以从文档中抽取向量，以向量的方式表征该文档，进而构建向量与文档的映射关系，也就是构建索引。相应的，服务器在进行搜索时，可以在用户输入的图片中抽取向量，进而计算图片的向量与索引中的向量的距离，以将与图片的向量距离最近的几个向量对应的文档反馈给终端设备。应理解，从文档中抽取向量的方式可以参照现有技术中的相关说明，在此不做赘述。

随着向量搜索方式的出现，文本和向量联合搜索的需求也应运而生，也就是说，用户在输入搜索内容时，可以同时输入文本和其他非文本的内容。示例性的，用户输入的搜索内容可以为：一张包含有A品牌的商标图片以及文本“越野车”，用户的本意是得到A品牌越野车的相关文档。

为了满足上述文本和向量联合搜索的需求，服务器可以针对文档同时建立文本类型的索引，以及向量类型的索引，进而结合两种索引共同得到与搜索内容相关的文档。图2为一种网络架构示意图。如图2所示，该网络架构中包括：终端设备、服务器、文本索引系统和向量索引系统。

其中，服务器在构建文本索引和向量索引时，服务器可以将来自终端设备的文档分别发送至文本索引系统和向量索引系统。文本索引系统根据接收到的文本构建文本索引，向量索引系统根据接收到的向量构建向量索引。在服务器接收到来自终端设备的搜索内容时，可以将搜索内容发送给文本索引系统和向量索引系统，由文本索引系统和向量索引系统分别根据其中建立的索引搜索相关的文档，进而服务器可以对两个系统分别反馈的文档进行整合，输出最终的文档。

因为文本索引系统和向量索引系统根据文档构建各自的索引，两个系统中相同的文档没有建立映射关系，服务器对两个系统分别反馈的文档进行整合时的难度大。因此在文本索引系统和向量索引系统在构建索引时，需要在两个系统中记录相同文档的唯一键，即在两个系统中通过该唯一键标识是相同的文档，进而方便了服务器对两个系统分别反馈的文档的整合。但是采用唯一键标识的方式带来了额外的空间开销。

另外，文档分别进入两个索引系统中，且文本索引系统和向量索引系统在构建索引时，构建索引的速度不同，进而导致文本索引系统和向量索引系统中的数据一致性差，进而影响输出文档的准确性。示例性的，如用户输入的搜索内容可以为：一张包含有A品牌的商标图片以及文本“越野车”，用户的本意是想得到A品牌越野车的相关文档，但鉴于两个系统的索引一致性差，得到的结果可能是单独的关于A品牌的商标的文档，或者关于越野车的文档，并不能得到用户想要得到的结果。另外，服务器还需要通过网络跟文本索引系统和向量索引系统进行交互，以实现系统的索引构建，以及搜索结果的反馈，反馈效率低。

为了解决上述图2中网络架构造成的数据一致性差和反馈效率低的问题，还提供了如图3所示的网络架构。图3为另一种网络架构示意图。如图3所示，该网络架构中包括：终端设备和服务器。与上述图2不同的是，图3中将文本索引系统和向量索引系统的功能均集成在服务器中，由服务器同时对终端设备输入的文档构建文本索引和向量索引，以避免文档进入两个独立的系统中造成数据不对齐、一致性差的问题。应理解，图3也是本申请实施例适用的网络架构。

此处为了说明图3中的终端设备与图1中的终端设备不同，图3中以终端设备为计算机为例进行说明，此处的终端设备为下述实施例中的第一终端设备，图3中标识为第二终端设备。应理解，图3中的终端设备可能的形态可以参照上述图1的相关描述。

图3所示的网络架构通过下述两种方式构建索引：

因为下述会用到文本索引的构建过程和向量索引的构建过程，此处先简述构建文本索引，以及构建向量索引的过程。其中，文本索引系统在构建文本索引时，可以根据每个文档生成对应的索引，且将索引写入小文件中，在小文件中的索引数量达到预设数量后，小文件中的索引才可被搜索(即在小文件中的索引数量达到预设数量后，小文件中的索引搜索与该索引对应的文档)，在小文件满足合并条件时，需要对小文件中的索引文件进行合并，生成大的文件。其中的合并条件可以为小文件的占用的内存达到预设内存时将小文件合并，或者在预设时长后将小文件合并。向量索引系统在构建向量索引时，可以根据每个文档生成对应的索引，且将索引写入文件中，文件中的索引实时能够被搜索。其中，关于该处构建文本索引和向量索引的具体过程还可以参考现有技术中的细节描述，此处为简述。

第一种方式：图4为构建索引的一种示意图。如图4所示，服务器在接收到文档1时，可以分别生成文本索引1和向量索引1，且将文本索引1写入小文件1中，将向量索引1写入小文件1'中。在小文件1和小文件1'中的索引数量大于预设数量时，小文件1和小文件1'中的索引才能够被搜索。相应的，服务器还可以生成小文件2和小文件2'，以及小文件3和小文件3'。

为了保证构建的索引的一致性，服务器可以采用与文本搜索系统生成索引相同的方式，在小文件中的索引数量达到预设数量后，小文件中的索引才可被搜索，另外，在小文件的数量达到一定数量后，还需要对小文件中的索引文件进行合并，生成大的文件。示例性的，服务器将小文件1和小文件2进行合并生成一个大的文件4，且将小文件1'和小文件2'进行合并生成一个大的文件4'。

应注意，根据文本索引对应的文件的合并方式，服务器可以将小文件1和小文件2中的索引进行拼接等较为简单的方法实现合并，而向量索引对应的文件并不支持采用拼接的方式合并，而是需要重新根据小文件1'和小文件2'对应的文档，重新构建向量索引，进而实现小文件1'和小文件2'的合并。这种对向量索引不断生成小文件，且进行小文件合并的方式，合并难度大、花费时间长，进而导致构建索引的时间长、构建索引的效率低；另外，服务器在构建索引的过程中可以同时对外提供搜索功能，而该种方式中服务器构建索引的过程中需要做文件合并，特别是，多个向量索引文件的合并需要消耗更大的资源，进而影响搜索效率。

第二种方式：图5为构建索引的另一种示意图。如图5所示，服务器在接收到文档1时，可以分别生成文本索引1和向量索引1，且将文本索引1和向量索引1均写入小文件1中。在小文件1中的索引数量大于预设数量时，小文件1中的索引才能够被搜索。相应的，服务器还可以生成小文件2和小文件3。

为了保证构建的索引的一致性，服务器可以采用与文本搜索系统生成索引相同的方式，在小文件中的索引数量达到预设数量后，小文件中的索引才可被搜索，另外，在小文件的数量达到一定数量后，还需要对小文件中的索引文件进行合并，生成大的文件。示例性的，服务器将小文件1和小文件2进行合并生成一个大的文件4。

该第二种方式中是将文本索引和向量索引均写入同一个文件中，但是该种方式仍存在与上述第一种方式相同的问题，即对向量索引不断生成小文件，且进行小文件合并的方式，合并难度大、花费时间长，进而导致构建索引的时间长、构建索引的效率低，消耗的资源大。

为了解决上述问题，本申请实施例中提供了一种构建索引的方法，在上述图3所示的网络架构的基础上，本申请在构建向量索引的过程中，将向量索引写入文件中，但不对文件进行合并，进而能够避免因为小文件合并造成的构建索引的时间长、构建索引的效率低的问题，且本申请实施例中还建立了文本索引和向量索引的映射关系，进而能够保证向量索引和文本索引的一致性。

应注意，本申请实施例中提供的构建索引的方法适用于构建文本索引和向量索引的场景中，还可以适用于构建文本索引和其他类型的索引(不同于向量索引)的场景中，还可以应用于构建向量索引和其他类型的索引(不同于文本索引)的场景中。

下面结合具体的实施例对本申请实施例提供的构建索引的方法进行说明。下面这几个实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。图6为本申请实施例提供的构建索引的方法的一实施例的流程示意图。如图6所示，本申请实施例提供的构建索引的方法可以包括：

S601，接收来自第一终端设备的文档。

S602，根据文档，生成第一索引和第二索引，第一索引表征向量和文档的映射关系，第二索引表征文本与文档的映射关系。

S603，将第一索引存储至第一类型的文件集合中，第一索引处于可用状态，处于可用状态的第一索引用于通过向量搜索与搜索内容关联的文档。

S604，将第二索引存储至第二类型的文件集合中，且建立第一索引、第二索引和文档的映射关系。

上述S601中，依据上述图3所示的网络架构，第一终端设备可以向服务器发送待生成索引的文档，以使服务器根据文档构建索引。相对应的，服务器接收来自第一终端设备的文档。应理解，本申请实施例中的文档的形态可以参照上述图1中的对文档的相关描述，在此不做赘述。其中，第一终端设备可以向服务器同时发送多个文档，本申请实施例中以服务器对一个文档的处理过程进行说明。

上述S602中，本申请实施例中可以根据文档生成两种不同类型的索引，分别为第一索引和第二索引。其中，第一索引表征向量和文档的映射关系，即该文档对应的向量与该文档的映射关系，第一索引可以理解为上述的向量索引。第二索引表征文本与文档的映射关系，即该文档中的文本与该文档的映射关系，第二索引可以理解为上述的文本索引。本申请实施例中的第一索引可以为分层可导航小世界图(hierarchcal navigable smallworld graphs，HNSW)类型的索引，第二索引可以为lucene类型的索引，lucene类型的索引是依据检索引擎的架构得到的索引，该检索引擎的架构即为lucene。

可选的，本申请实施例中根据文档生成第一索引的方式可以为：服务器从文档中抽取向量，以向量的方式表征该文档，进而构建向量与文档的映射关系，也就是构建第一索引。本申请实施例中根据文档生成第二索引的方式可以为：服务器抽取文档中的关键词，记录每个关键词在文档中的出现次数和出现位置，且建立该关键词与文档的映射关系，第二索引包括关键词与文档的映射关系，以及每个关键词在文档中的出现次数和出现位置。值得注意的是，本申请实施例中采用的索引方式为倒排索引。

上述S603中，本申请实施例中可以将第一索引存储至第一类型的文件集合，将第二索引存储至第二类型的文件集合中。其中，第一类型的文件集合中包括多个文件，该第一类型的文件集合中的文件均用于存储向量类型的索引，即第一索引。同理的，第二类型的文件集合中包括多个文件，该第二类型的文件集合中的文件均用于存储文本类型的索引，即第二索引。

应注意，与上述示例不同的是，上述示例在生成第一索引后，将第一索引存储至小文件且在小文件中索引的数量达到预设数量时，小文件中的索引才处于可用状态(即上述索引可被搜索)；或者在小文件中的占用内容达到预设内存时，小文件中的索引才处于可用状态。无论是上述哪种情况，第一索引均不能被实时搜索。而本申请实施例中在生成第一索引后，第一索引即处于可用状态，即第一索引可被搜索。也就是说，本申请实施例中未采用与第二索引(即上述文本索引)相同的方式存储第一索引，在第一索引生成后即处于可用状态，而不是在小文件中的索引的数量达到预设数量后才处于可用状态。因此，本申请实施例中不需要对第一索引所在的文件进行合并，进而能够节省构建索引的时间，提高索引构建的效率。

上述S604中，同理的，本申请实施例中可以将第二索引存储至第二类型的文件集合中。因为第一索引和第二索引存储在不同的文件集合中，因此为了保证两个文件集合中的索引的一致性，可以建立第一索引、第二索引和文档的映射关系，即第一索引和第二索引均可以映射至该文档。

图7为本申请实施例提供的构建索引的示意图一。如图7所示，服务器中包括第一类型的文件集合和第二类型的文件集合，第一索引可以存储在第一类型的文件集合中的文件1'中，第二索引可以存储在第二类型的文件集合的小文件3中，其中，第二类型的文件集合的小文件1和小文件2中均存储的是文本类型的索引。通过图7可知，本申请实施例中采用不断生成小文件，且合并小文件的方式存储第二索引，但采用不对文件进行合并，而是直接将第一索引存储至第一类型的文件集合中的文件1'中的方式存储第一索引。

本申请实施例提供了一种构建索引的方法，服务器同时对一个文档生成第一索引和第二索引，相较于上述图4，不需要跨系统调用，能够更快完成联合查询，且服务器在生成第一索引后，第一索引即处于可用状态，本申请实施例中未采用与第二索引(即上述文本索引)相同的方式存储第一索引，在第一索引生成后即处于可用状态，而不是在小文件中的索引的数量达到预设数量后才处于可用状态，本申请实施例中不需要对第一索引所在的文件进行合并，进而能够省去构建索引资源消耗，节省构建索引的时间，提高索引构建的效率。另外，本申请实施例中还建立了第一索引、第二索引和文档的映射关系，进而能够保证第一类型的文件集合和第二类型的文件集合中的索引的一致性。

下述实施例中针对服务器如何将第一索引存储至第一类型的文件集合，以及将第二索引存储至第二类型的文件集合的方式进行说明。图8为本申请实施例提供的构建索引的方法的另一实施例的流程示意图。如图8所示，本申请实施例提供的构建索引的方法可以包括：

S801，接收来自第一终端设备的文档。

S802，根据文档，生成第一索引和第二索引。

S803，将第一索引写入一个第一文件中。

S804，将第二索引写入一个第二文件中，且建立第一文件中的第一索引、第二文件中的第二索引和文档的映射关系。

应理解，本申请实施例中的S801-S802中的实施方式可以参照上述实施例中S601-S602中的相关描述，在此不做赘述。

上述S803和上述S804中，第一类型的文件集合中包括至少一个第一文件，第一文件用于存储向量类型的索引，即第一索引。同理的，第二类型的文件集合中包括至少一个第二文件，第二文件用于存储文本类型的索引，即第二索引。

如上述图7所示，第一类型的文件集合中包括一个第一文件，即上述文件1'，即本申请实施例中可以将第一索引写入文件1'中。第二类型的文件集合中包括三个第一文件，即文件1、文件2和文件3，本申请实施例中可以将第二索引写入文件1、文件2或文件3中。

本申请实施例中，服务器在将第一索引和第二索引写入对应的文件后，可以建立第一文件中的第一索引、第二文件中的第二索引和文档的映射关系。示例性的，假设本申请实施例将第二索引写入文件2中，即可以建立文件1'中的第一索引和文件2中的第二索引的映射关系。如下述表三所示：

表三

在本申请实施例一种可能的实现方式中，下述结合图9对本申请实施例中将第一索引写入一个第一文件，以及将第二索引写入一个第二文件的过程进行说明。图9为本申请实施提供的构建索引的示意图二。如图9所示，本申请实施例为了说明构建索引的过程，分为5个时刻对索引生成、索引写入文件、文件生成和文件合并等过程进行介绍：

在时刻1时，服务器接收到来自第一终端设备的文档1，并根据文档1生成第一索引1和第二索引1'。且服务器构建第一类型的文件集合中的第一个第一文件v1，以及构建第二类型的文件集合中的第一个第二文件f1，且将第一索引1写入第一文件v1，将第二索引1'写入第二文件f1，且建立v1中的第一索引1、f1中的第二索引1'以及文档1的映射关系。

应注意，图9中在文件中写入第一索引和第二索引采用朝向文件的箭头表示，本申请实施例中的第一索引处于可用状态，即可以被搜索，图9中采用背离第一文件的箭头表示第一索引处于可用状态，但文档1对应的第二索引1'需要在第二文件f1中写入的索引的数量大于预设数量时才处于可用状态，因此图9中的第二索引1'仅有写入第二文件f1的箭头，而没有表征第二索引1'处于可用状态的箭头。应注意，图9中索引写入文件时均采用朝向文件的箭头表示，索引处于可用状态时采用背离文件的箭头表示。

若在时刻1之后，若服务器接收到来自第一终端设备的文档2、文档3……文档n，则可以依次生成每个文档对应的第一索引和第二索引，且将每个文档对应的第一索引和第二索引分别写入第一文件v1和第二文件f1中，且建立每个文档与对应的v1中的第一索引、f1中的第二索引的映射关系。可选的，该n个文档或者n个文档中的部分文档可以是第一终端设备同时发送给服务器的，服务器可以根据同时接收到的文档，依次生成每个文档对应的第一索引和第二索引或同时生成每个文档对应的第一索引和第二索引。

假设一个第二文件中写入的第二索引的数量阈值为第二阈值，则在将生成的第二索引写入第二文件时，需要判断第二类型的文件集合中的第j个第二文件中已写入的索引的数量是否小于第二阈值，若第j个第二文件中已写入的索引的数量小于第二阈值，则继续将生成的第二索引写入第j个第二文件中，j为大于或等于1的整数。若第j个第二文件中已写入的索引的数量等于第二阈值，则新建第j+1个第二文件，且将第二索引写入第j+1个第二文件中。应理解，第二文件中写入的索引均为文本类型的索引，即第二索引。

示例性的，如一个第二文件中写入的第二索引的数量阈值为n，则在时刻2时，服务器接收来自第一终端设备的文档n+1，生成该文档n+1对应的第二索引(n+1)'。服务器判断f1中已写入的索引的数量为n个，则新建第二个第二文件f2，且将第二索引(n+1)'写入该第二个第二文件f2中。对应的，服务器接收来自第一终端设备的文档n+1，生成该文档n+1对应的第一索引(n+1)，服务器将第一索引(n+1)写入该第一个第一文件v1中。另外，服务器还建立v1中的第一索引(n+1)、f2中的第二索引(n+1)'以及文档n+1的映射关系。

其中，若第j个第二文件中已写入的索引的数量等于第二阈值，则将第j个第二文件从写入模式转换为只读模式，转换为只读模式的第j个第二文件中的第二索引处于可用状态，处于可用状态的第二索引用于通过文本搜索与搜索内容关联的文档。如上示，f1中已写入的索引的数量为n个，等于第二阈值，则可以将f1从写入模式转换为只读模式，使得f1中写入的第二索引均处于可用状态。

应理解，本申请实施例中一个第二文件中写入的索引的数量的第二阈值可以自定义设置，取决于用户需求一个第二文件的可被搜索的时长。其中，若用户需求一个第二文件的可被搜索的时长越长，则该第二阈值越大，即可以在一个第二文件中写入更多的索引；反之，若用户需求一个第二文件的可被搜索的时长越短，则该第二阈值越小，即可以在一个第二文件中写入少量的索引，就需要在下一个第二文件中写入第二索引。

可选的，本申请实施例中用户可以通过预先第一终端设备设置第二文件的转换时长，相应的，第一终端设备可以将用户设置的第二文件的转换时长发送给服务器，该第二文件的转换时长即为第二文件从写入模式转换为只读模式的时长。服务器在接收到第二文件的转换时长后，可以根据该第二文件的转换时长，确定第二阈值。具体的，服务器是根据第二文件的转换时长，以及写入一个索引所需的时长，确定一个第二文件中可写入的索引的数量，即为第二阈值。

可选的，本申请实施例中每个第二文件对应的第二阈值可以不同，用户可以预先设置每个第二文件的转换时长，或者在索引构建过程中通过第一终端设备向服务器发送每个第二文件的转换时长。上述确定第二阈值的方式为本申请实施例中的示例说明，本申请实施例中还可以采用其他方式确定第二阈值。应理解，图9中以每个第二文件对应的第二阈值均为n进行说明。

在时刻2至时刻3之间，服务器还接收到来自第一终端设备的文档n+2、文档n+3……文档2n，服务器可以依次生成每个文档对应的第一索引和第二索引，且将每个文档对应的第一索引和第二索引分别写入第一文件v1和第二文件f2，且建立每个文档与v1中的第一索引、f2中的第二索引的映射关系。应理解，图9中以每个第二文件中以从0至n表示其中的第二索引。

在时刻3时，服务器接收到来自第一终端设备的文档2n+1，根据该文档2n+1生成第一索引(2n+1)以及第二索引(2n+1)'。此时因为第二个第二文件f2中写入的第二索引的数量等于第二阈值，则服务器可以将f2从写入模式转换为只读模式，使得f2中的第二索引均处于可用状态。且服务器还可以新建第三个第二文件f3，将第二索引(2n+1)'写入f3中，将第一索引(2n+1)写入第一文件v1中，且建立文档2n+1与v1中的第一索引(2n+1)、f3中的第二索引(2n+1)'的映射关系。

此时，服务器可以对第二文件f1和f2进行合并，生成大文件f4，f4中的第二索引均处于可用状态。另外，本申请实施例中，服务器在对第二文件合并后，还需要建立合并后的第二文件中的第二索引、第一文件中的第一索引和文档的映射关系。如上述在对f1和f2进行合并后，服务器还更新映射关系，即建立每个文档与v1中的第一索引、f4中的第二索引的映射关系。应注意，本申请实施例中对第二文件进行合并的时机可如下两种方式所示：

第一种方式：若转换为只读模式的第二文件的占用内存达到预设内存，则将转换为只读模式的第二文件合并。本申请实施例中，服务器可以获取转换为只读模式的第二文件的占用内存，进而在转换为只读模式的第二文件的占用内存达到预设内存时，将转换为只读模式的第二文件合并。示例性的，如服务器确定转换为只读模式的第二文件f1和f2的占用内存达到预设内存，则可以将f1和f2合并。

第二种方式：本申请实施例中，服务器还可以获取当前可用负载，在当前可用负载大于预设负载，则将转换为只读模式的第二文件合并。示例性的，服务器检测到当前可用负载大于预设负载，则可以将转换为只读模式的f1和f2合并。

以上两种方式为本申请实施例将第二文件进行合并的示例，还可以采用其他方式确定合并第二文件，本申请实施例对此不做限制。

应理解，在第二文件合并期间，服务器可以先不删除小文件，小文件仍然对外提供可被搜索服务。示例性的，在合并f1和f2期间，f1和f2中的第二索引仍处于可用状态，在f1和f2合并成f4之后，服务器可以删除f1和f2。

与上述第二文件类似的，本申请实施例中的第一文件中写入的第一索引的数量也有限制，第一文件中写入的第一索引的数量限制为第一阈值之内。应注意，该第一阈值大于上述的第二阈值。相对应的，本申请实施例中服务器可以在将第一索引写入第一文件时，可以判断第一文件中已写入的第一索引的数量是否小于第一阈值，若第一类型的文件集合中的第i个第一文件中已写入的索引的数量小于第一阈值，则将第一索引写入第i个第一文件中，i为大于或等于1的整数。若第i个第一文件中已写入的索引的数量等于第一阈值，则新建第i+1个第一文件，且将第一索引写入第i+1个第一文件中。应理解，第一文件中写入的索引均为向量类型的索引，即第一索引。

示例性的，在时刻3至时刻4之间，服务器还接收到来自第一终端设备的文档2n+2、文档2n+3……文档3n，服务器可以依次生成每个文档对应的第一索引和第二索引，且将每个文档对应的第一索引和第二索引分别写入第一文件v1和第二文件f3，且建立每个文档与v1中的第一索引、f3中的第二索引的映射关系。

在时刻4时，服务器还接收到来自第一终端设备的文档3n+1，根据该文档3n+1生成第一索引(3n+1)以及第二索引(3n+1)'。此时因为第三个第二文件f3中写入的第二索引的数量等于第二阈值，则服务器可以将f3从写入模式转换为只读模式，使得f3中的第二索引均处于可用状态。且服务器还可以新建第四个第二文件f4，将第二索引(3n+1)'写入f4中。假设第一阈值为3n，则服务器确定第一个第一文件v1中写入的第一索引的数量大于第一阈值，则可以新建第二个第一文件v2，且将第一索引(3n+1)写入v2中，进而建立文档3n+1与v2中的第一索引(3n+1)、f4中的第二索引(3n+1)'的映射关系。

以上讲述了本申请实施例中服务器将第一索引写入一个第一文件，以及将第二索引写入一个第二文件中的过程，在时刻4之后的时刻，服务器接收来自第一终端设备的文档，可以继续按照上述图9继续在文件中写入索引。

本申请实施例中，服务器在生成第一索引后，第一索引即处于可用状态，向量类型的索引不需要和文本类型的索引同步产生大量的小文件，且进行合并的操作，极大地降低了系统资源消耗，提高了构建索引的效率，减少了构建索引的时间，相较于上述图5中的技术方案，可以减少一半的资源消耗。

在上述实施例的基础上，在用户通过第一终端设备向服务器发送文档的过程中，若用户发现文档中有很多错误文档，想要将发送的错误文档删除，则本申请实施例还能够删除文档。下述结合图10对该过程进行说明。图10为本申请实施例提供的构建索引的方法的另一实施例的流程示意图。如图10所示，本申请实施例提供的构建索引的方法可以包括：

S1001，接收第一终端设备发送的删除指令，删除指令指示删除文档。

S1002，将文档标记为删除状态。

S1003，将文档标记为删除状态，且在第二类型的文件集合中的第二文件合并时，删除第二类型的文件集合中的文档。

应理解，上述S1002和S1003是择一执行的步骤，二者不可同时执行。

上述S1001中，服务器在根据来自第一终端设备的文档构建索引的过程中，用户若需求删除已发送的文档，则可以通过第一终端设备发送删除指令。其中，该删除指令指示删除文档，示例性的，本申请实施例中以用户需求删除的文档为上述实施例中以图6中第一终端设备发送给服务器的文档为例进行说明。可选的，图11为本申请实施例提供的第一终端设备的界面示意图一。如图11所示，该第一终端设备的界面上可以显示有文档的标识，如文档1、问2等，以及删除控件。用户选择该删除控件，可以触发第一终端设备向服务器发送删除指令。应理解，在用户选择多个文档时，该删除指令中可以指示删除用户选择的多个文档。应注意，本申请实施例中对用户如何触发第一终端设备向服务器发送的删除指令不做限制。示例性的，如用户选择了文档1和文档2。

上述S1002中，应理解，服务器在根据文件生成第一索引和第二索引，且将第一索引写入第一文件，以及将第二索引写入第二文件，且建立第一文件中的第一索引、第二文件中的第二索引和文档的映射关系后，还可以存储该文档。

其中，服务器在接收到删除指令后，可以将删除指令指示的文档标记为删除状态，而不删除该文档。

S1003与S1002不同的是，该步骤中服务器在接收到删除指令后，可以将文档标记为删除状态，还在第二类型的文件集合中的第二文件合并时，删除第二类型的文件集合中的文档。应注意，因为第二类型的文件集合中的第二文件处于只读模式时，可以提供对外搜索的服务，不能对第二文件中的第二索引对应的文档进行修改，例如删除文档。在第二类型的文件集合中的第二文件合并时，第二文件处于重新写入模式，在该模式下，可以删除文档。据此，本申请实施例中可以在第二类型的文件集合中的第二文件合并时，删除第二类型的文件集合中的文档。

应理解，本申请实施例中的也可以将第一类型的文件集合中的该文档标记为删除状态。

与上述S1002相比较，删除第二类型的文件集合中的文档的方式可以释放文档在服务器中的占用空间，尤其是在文档大量删除的场景下，可以大量地释放文档在服务器中的占用空间，进而可以间接提高服务器构建索引的效率。因为删除文档释放了服务器中的占用空间，相对应的，也能够间接提高搜索效率，减少命中已删除文档的几率。

可选的，本申请实施例中针对存在大量文档需要删除的场景，还提供将向量类型的索引和文本类型的索引进行同步的方法，也就是说，本申请实施例中在删除第二类型的文件集合中的文档时也同步删除第一类型的文件集合中的该文档。

在一种可能的实现方式中，用户可以通过第一终端设备控制第一类型的文件集合和第二类型的文件集合中的文档的删除情况同步。图12为本申请实施例提供的第一终端设备的界面示意图二。如图12所示，相较于上述图11，该第一终端设备的界面上还显示有同步控件，其中，在用户选择该同步控件时，可以触发第一终端设备向服务器发送同步删除指令，其中，该同步删除指令指示将第二类型的文件集合中文档的删除情况同步至第一类型的文件集合。

本申请实施例中，当用户选择删除大量的文档后，可以选择该同步控件，或者，用户需求将第二类型的文件集合中的中文档的删除情况同步至第一类型的文件集合时，也可以选择该同步控件。相对应的，图13为本申请实施例提供的构建索引的方法的另一实施例的流程示意图。如图13所示，本申请实施例提供在上述S1003之后，还可以包括：

S1004，接收来自第一终端设备的同步删除指令，同步删除指令指示将第二类型的文件集合中文档的删除情况同步至第一类型的文件集合。

S1005，根据同步删除指令，删除第一类型的文件集合中的文档。

本申请实施例中，因为上述实施例中在删除第二类型的文件集合中的文档时，未删除第一类型的文件集合中的相同的文档，因此第一类型的文件集合中未删除的文档还占用了较大的空间。应理解，第一类型的文件集合中包括上述文档。

本申请实施例中，在有大量文档删除的场景下，也可以将第一类型的文件集合中文档删除，也就是能够释放服务器中已删除的文档占用的空间，相当于为后续搜索分配的资源相应增多，进而提高搜索效率。也就是说，服务器在接收到来自第一终端设备的同步删除指令后，可以根据该同步删除指令，删除第一类型的文件集合中的文档。

本申请实施例中删除第一类型的文件集合中的文档的一种可能的实现方式为：本申请实施例中可以根据标记为删除状态之外的文档，重新构建向量类型的索引。应注意，因为大量待删除的文档占用了较大的空间(即资源)，虽然重新构建向量类型的索引也需要消耗一部分资源，但是少于待删除的文档占用了较大的空间，因此，本申请实施例中可以以重新构建向量类型的索引为代价，删除标记为删除状态的文档。

本申请实施例中删除第一类型的文件集合中的文档的另一种可能的实现方式为：本申请实施例中可以合并待删除的文档对应的第一文件，即根据第一文件中标记为删除状态之外的文档，重新构建向量类型的索引。示例性的，如第1个第一文件中待删除的文档为500万个，第2个第一文件中待删除的文档为500万个，本申请实施例中可以将第1个第一文件和第2个第一文件进行合并，即对第1个第一文件和第2个第一文件中标记为删除状态之外的文档，重新构建向量类型的索引，以形成新的第一文件。应理解，本申请实施例中对第一文件合并所占用的资源少于待删除的文档占用了较大的空间，因此，本申请实施例中可以以合并第一文件为代价，删除标记为删除状态的文档。

本申请实施例中，用户可以通过第一终端设备指示服务器删除已构建索引的文档，服务器可以标记文档为删除状态，或者将文档为删除状态后删除文档，进而释放文档在服务器中的占用空间。另外，在大量文档删除的场景下，用户还还可以通过第一终端设备指示服务器将第二类型的文件集合中的文档删除情况同步至第一类型的文件集合，使得两个类型的文件集合中的文档删除状态保持一致，释放第一类型的文件集合和第二类型的文件集合中的空间，以为后续搜索分配更多的资源，进而提高搜索效率。

在上述实施例的基础上，结合上述图1所示的网络架构，本申请实施例在构建索引的过程中，还可以提供对外搜索服务，即采用可用状态的索引搜索用户输入的搜索内容相关的文档。图14为本申请实施例提供的构建索引的方法的另一实施例的流程示意图。如图14所示，本申请实施例提供的构建索引的方法可以包括：

S1401，接收来自第二终端设备的搜索内容。

S1402，根据搜索内容、第一类型的文件集合和第二类型的文件集合，获取搜索结果，搜索结果中包括文档。

S1403，向第二终端设备发送搜索结果。

上述S1401中，在用户通过第二终端设备搜索文档时，可以在第二终端设备上输入搜索内容。本申请实施例中的搜索内容可以为文本类型的搜索内容和/或向量类型的搜索内容。图15为本申请实施例提供的第二终端设备的界面变化示意图。如图15中的界面1501所示，界面1501上显示有搜索内容输入框，用户可以在该输入框中输入文本类型的搜索内容。另外界面上还可以显示有向量类型的搜索内容的添加控件，用户选择该添加控件可以输入向量类型的搜索内容。在用户输入文本类型的搜索内容“红色”，以及向量类型的搜索内容“一张包含有A品牌轿车的图片后，界面1501跳转至界面1502，界面1502上可以显示有用户输入的搜索内容。用户点击搜索控件后，可以触发第二终端设备向服务器发送搜索内容。应理解，界面1501中还显示有其他推荐信息，如“《XX诗词节目》于XX月XX日开播”。

上述S1402中，服务器在构建索引的过程中，若接收到来自第二终端设备的搜索内容，可以根据搜索内容、第一类型的文件集合和第二类型的文件集合，获取该搜索内容的搜索结果。本申请实施例中为了将搜索结果与上述图6中第一终端设备发送的文档结合起来，该搜索结果中可以包括上述的文档。

其中，本申请实施例中在获取搜索结果时，可以根据搜索内容和第一类型的文件集合，得到第一搜索结果，且根据搜索内容和第二类型的文件集合，得到第二搜索结果，进而将根据第一搜索结果和第二搜索结果进行整合，获取最终的搜索结果。

应理解，鉴于服务器在构建索引的过程中，第二类型的文件集合中写入的第二索引并非全部处于可用状态，如第二文件中的索引的数量未达到第二阈值，则该第二文件中的第二索引处于不可用状态。因此，本申请实施例中可以根据搜索内容，以及第二类型的文件集合中处于可用状态的第二索引，得到第二搜索结果。鉴于第一类型的文件集合中写入的第一索引全部处于可用状态，则本申请实施例中可以根据搜索内容，以及第一类型的文件集合中的第一索引，得到第一搜索结果。

本申请实施例中，服务器可以提取搜索内容中的关键词，获取搜索内容中的关键词和第二类型的文件集合中处于可用状态的第二索引中的关键词的相似度，进而将相似度大于相似度阈值的关键词对应的文档作为第一搜索结果。类似的，服务器可以抽取搜索内容的向量，获取搜索内容中的向量和第一类型的文件集合中处于可用状态的第一索引中的向量的距离，进而将距离小于距离阈值的向量对应的文档作为第二搜索结果。

可选的，本申请实施例中对第一搜索结果和第二搜索结果进行整合，获取最终的搜索结果，可以为将第一搜索结果和第二搜索结果中相同的文档作为搜索结果，或者还可以是将第一搜索结果和第二搜索结果中均包含有搜索内容的文档作为搜索结果。

应注意的是，若本申请实施例中的搜索结果中包括标记为删除状态的文档，则在搜索结果中过滤掉文档，也就是说将标记为删除状态的文档不反馈给第二终端设备。

上述S1403中，服务器在得到搜索结果后，可以将向第二终端设备发送搜索结果。第二终端设备在接收到搜索结果后，可以显示搜索结果。如图15所示，界面1502可以跳转至界面1503，该界面1503上显示有搜索结果，搜索结果包括：文档1和文档2，以及图片1。

本申请实施例中，服务器在根据文档构建索引的过程中，可以提供搜索服务，且针对用户输入的多类型的搜索内容，通过结合构建的第一类型的文件集合和第二类型的文件集合，可以对文本类型的搜索结果和向量类型的搜索结果进行整合，能够得到更为准确的搜索结果。另外，服务器在根据文档构建索引的过程中，因为向量类型的索引不需要和文本类型的索引同步产生大量的小文件且进行合并的操作，极大地降低了系统资源消耗，提高了构建索引的效率，减少了构建索引的时间，进而也能够减短索引可被搜索的时长，提高搜索速度和效率，另一方面，也因为构建索引时降低了系统资源消耗，因此有更多的资源可以用于搜索服务，也进一步能够提高搜索效率。

图16为本申请实施例提供的构建索引的装置的结构示意图一。该构建索引的装置可以为上述实施例中的服务器或服务器中的芯片或处理器等。如图16所示，该构建索引的装置包括：收发模块1601和处理模块1602。

收发模块1601，用于接收来自第一终端设备的文档；处理模块1602，用于根据文档，生成第一索引和第二索引，且将第一索引存储至第一类型的文件集合中，将第二索引存储至第二类型的文件集合中，且建立第一索引、第二索引和文档的映射关系，第一索引表征向量和文档的映射关系，第二索引表征文本与文档的映射关系，第一索引处于可用状态，处于可用状态的第一索引用于通过向量搜索与搜索内容关联的文档。

在一种可能的实现方式中，第一类型的文件集合中包括至少一个第一文件，第一文件用于存储第一索引。处理模块1602，具体用于将第一索引写入一个第一文件中。

在一种可能的实现方式中，第二类型的文件集合中包括至少一个第二文件，第二文件用于存储第二索引。处理模块1602，具体用于将第二索引写入一个第二文件中。

在一种可能的实现方式中，处理模块1602，具体用于建立第一文件中的第一索引、第二文件中的第二索引和文档的映射关系。

在一种可能的实现方式中，处理模块1602，具体用于若第一类型的文件集合中的第i个第一文件中已写入的索引的数量小于第一阈值，则将第一索引写入第i个第一文件中，i为大于或等于1的整数；若第i个第一文件中已写入的索引的数量等于第一阈值，则新建第i+1个第一文件，且将第一索引写入第i+1个第一文件中。

在一种可能的实现方式中，处理模块1602，具体用于若第二类型的文件集合中的第j个第二文件中已写入的索引的数量小于第二阈值，则将第二索引写入第j个第二文件中，j为大于或等于1的整数；若第j个第二文件中已写入的索引的数量等于第二阈值，则新建第j+1个第二文件，且将第二索引写入第j+1个第二文件中。

在一种可能的实现方式中，处理模块1602，还用于若第j个第二文件中已写入的索引的数量等于第二阈值，则将第j个第二文件从写入模式转换为只读模式，转换为只读模式的第j个第二文件中的第二索引处于可用状态，处于可用状态的第二索引用于通过文本搜索与搜索内容关联的文档。

在一种可能的实现方式中，收发模块1601，还用于接收来自第一终端设备的第二文件的转换时长，转换时长为第二文件从写入模式转换为只读模式的时长。

相应的，处理模块1602，还用于根据转换时长，确定第二阈值。

在一种可能的实现方式中，处理模块1602，还用于若转换为只读模式的第二文件的占用内存达到预设内存，则将转换为只读模式的第二文件合并；或者，若当前可用负载大于预设负载，则将转换为只读模式的第二文件合并。

处理模块1602，处理模块1602，还用于建立合并后的第二文件中的第二索引、第一文件中的第一索引和文档的映射关系。

在一种可能的实现方式中，第二类型的文件集合中包括文档。

收发模块1601，还用于接收第一终端设备发送的删除指令，删除指令指示删除文档。相应的，处理模块1602，还用于将文档标记为删除状态。

在一种可能的实现方式中，第二类型的文件集合中包括文档。

收发模块1601，还用于接收第一终端设备发送的删除指令，删除指令指示删除文档。相应的，处理模块1602，还用于将文档标记为删除状态，且在第二类型的文件集合中的第二文件合并时，删除第二类型的文件集合中的文档。

在一种可能的实现方式中，收发模块1601，还用于接收来自第一终端设备的同步删除指令，同步删除指令指示将第二类型的文件集合中文档的删除情况同步至第一类型的文件集合。

相应的，处理模块1602，还用于删除第一类型的文件集合中的文档。

在一种可能的实现方式中，接收收发模块1601，还用于来自第二终端设备的搜索内容。相应的，处理模块1602，还用于根据搜索内容、第一类型的文件集合和第二类型的文件集合，获取搜索结果，搜索结果中包括文档。

收发模块1601，还用于向第二终端设备发送搜索结果。

在一种可能的实现方式中，处理模块1602，具体用于根据搜索内容和第一类型的文件集合，得到第一搜索结果；根据搜索内容和第二类型的文件集合，得到第二搜索结果；根据第一搜索结果和第二搜索结果，获取搜索结果。

在一种可能的实现方式中，处理模块1602，具体用于根据搜索内容，以及第一类型的文件集合中的第一索引，得到第一搜索结果；根据搜索内容，以及第二类型的文件集合中处于可用状态的第二索引，得到第二搜索结果。

在一种可能的实现方式中，处理模块1602，还用于若搜索结果中包括标记为删除状态的文档，则在搜索结果中过滤掉文档。相应的，收发模块1601，具体用于向第二终端设备发送不包括文档的搜索结果。

本申请实施例提供的构建索引的装置，可以执行上述方法实施例中服务器的动作，其实现原理和技术效果类似，在此不再赘述。

可选的，图17为本申请实施例提供的构建索引的装置的结构示意图二。本申请实施例中，如图17所示，上述的处理模块1602中可以包括映射管理单元16021、第一索引管理单元16022和第二索引管理单元16023。应注意的，映射管理单元16021用于执行上述实施例中的建立映射关系的步骤。第一索引管理单元16022执行上述实施例中S602和S802中生成第一索引的步骤、S603，以及S803。第二索引管理单元16023执行上述实施例S602和S802中生成第二索引的步骤、S604中除了建立映射关系之外的步骤、以及S804中除了建立映射关系之外的步骤。

需要说明的是，应理解以上收发模块实际实现时可以为收发器、或者包括发送器和接收器。而处理模块可以以软件通过处理元件调用的形式实现；也可以以硬件的形式实现。例如，处理模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块的功能。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。

例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个专用集成电路(application specific integrated circuit，ASIC)，或，一个或多个微处理器(digital signal processor，DSP)，或，一个或者多个现场可编程门阵列(field programmable gate array，FPGA)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(centralprocessing unit，CPU)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，SOC)的形式实现。

图18为本申请实施例提供的电子设备的结构示意图。该电子设备为上述实施例中的服务器。如图18所示，该电子设备可以包括：处理器1801(例如CPU)、存储器1802、收发器1803；收发器1803耦合至处理器1801，处理器1801控制收发器1803的收发动作；存储器1802可能包含高速随机存取存储器(random-access memory，RAM)，也可能还包括非易失性存储器(non-volatile memory，NVM)，例如至少一个磁盘存储器，存储器1802中可以存储各种指令，以用于完成各种处理功能以及实现本申请的方法步骤。可选的，本申请涉及的电子设备还可以包括：电源1804、通信总线1805以及通信端口1806。收发器1803可以集成在电子设备的收发信机中，也可以为电子设备上独立的收发天线。通信总线1805用于实现元件之间的通信连接。上述通信端口1806用于实现电子设备与其他外设之间进行连接通信。

在本申请实施例中，上述存储器1802用于存储计算机可执行程序代码，程序代码包括指令；当处理器1801执行指令时，指令使电子设备的处理器1801执行上述方法实施例中终端设备的处理动作，使收发器1803执行上述方法实施例中终端设备的收发动作，其实现原理和技术效果类似，在此不再赘述。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

本文中的术语“多个”是指两个或两个以上。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。

可以理解的是，在本申请的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请的实施例的实施过程构成任何限定。