目标场景#xff1a;对于

上篇介绍了构建知识库的大体流程和一些优化经验细节但并没有结合一个具体的场景给出更细节的实战经验以及相关的一些

benchmark

的节点大小请尝试将分片数量设为数据节点数量的偶数倍有助于分片在数据节点上均匀分布每个节点的分片数与

JVM

依据目前的信息仅仅知道所要索引的原始文档数。

由于文档切分等中间处理过程无法估算具体的内存用量和存储量所以需要用小批量的实验数据进行测试推演。

300

50%根据knn.memory.circuit_breaker.limit70%

35%

数据完整性保证所有的知识都能被查询到不会因为摄入异常导致数据缺失。

构建速度知识召回部分可能存在反复的效果调整需要反复多次摄入速度对全链路开发调优的效率很重要。

查询性能保证场景中的实时会话体验。

整个摄入过程从过程上基本可以划分为三个阶段文本切分、文本向量化以及摄入

Amazon

OpenSearch。

其中文本切分和文本向量化的处理是临时性的工作负载原则上可以提升

glue

摄入可能会是整个流程的瓶颈完整流程测试不容易进行拆解分析性能瓶颈所以本试验会分别对这两部分进行测试。

Embedding

paraphrase-multilingual-deploy.ipynb

进行部署部署

机型https://github.com/aws-samples/private-llm-qa-bot/blob/main/notebooks/embedding/paraphrase-multilingual-deploy.ipynb注释掉下游写入

OpenSearch

造成的影响暂时注释掉相关代码https://github.com/aws-samples/private-llm-qa-bot/blob/main/code/aos_write_job.py利用

batch_upload_docs.py

进行并发运行。

https://github.com/aws-samples/private-llm-qa-bot/blob/main/code/batch_upload_docs.py

glue

的利用率。

经过简单测试发现确实能证明这个假设具体数据可以参考如下实验结果

Amazon

endpoint_nameEMB_MODEL_ENDPOINT):if

len(text_arrs)return

图的时候的动态列表大小值越大其向量数据的图更精确但索引的速度也响应更慢。

m

k-NN

中每个向量双向链表的数量越大检索越准确但相应内存占用会显著增大。

参考博客Choose

***

(https://aws.amazon.com/cn/blogs/big-data/choose-***-k-nn-algorithm-for-your-billion-scale-use-case-with-opensearch/)对于当前的数据规模参数

ef_construction:128

{knn.algo_param.index_thread_qty:

8,knn.memory.circuit_breaker.limit:

70%}

每轮实验中调整的参数已经用加粗字体标注出来供参考用于指导后续的数据注入中的参数调整。

全流程摄入测试

小时左右完成摄入且完整性没有问题。

能够满足大规模知识构建的要求如果文档量继续增长可以继续扩展

OpenSearch

索引存在的情况不能完全参照之前的结论通过以上三种不同的实验方式在多次实验的过程中本文得到了以下的一些实践经验和结论供参考

CPU

100%。

实验中在其他参数相同的情况下ef_construction

512

的摄入速度和负载成正相关但并不是线性相关。

多客户端能提高摄入速度但是客户端数量过多可能会导致大量的(429,

‘429

指数退避重试机制能保证摄入的完整性以及因集群瞬时不可用导致的大面积写入失败opensearch-py包中有如下摄入函数,

如果并发客户端过多可能会导致CPU利用率一直位于100%在max_retries的重试次数内每次会等待

initial_backoff

2)的时间通过设定一个较大的initial_backoff等待时间能避免在客户端并发数偏大的情况下出现大面积429错误。

另外客户端数也不能过大否则也会更容易出现大量的503相关错误。

对于偶发的503报错可以利用

glue

helpers.bulk(client,doc_generator,max_retries3,initial_backoff200,

#默认值为

2建议大幅提高max_backoff800,max_chunk_bytes10

1024

注意在大规模数据摄入的生产场景中不建议使用LangChain提供的向量数据库接口查看其源码可知LangChain的默认实现是单客户端且其内部实现没有使用指数退避Retry机制无法保证摄入速度和完整性。

OpenSearch

{field_name},precision_threshold:

20000}}}

ai-content/batch/PMC10000335.txt,doc_count:

42712},{key:

ai-content/batch/PMC10005506.txt,doc_count:

5279},...{key:

ai-content/batch/PMC10008235.txt,doc_count:

9},{key:

ai-content/batch/PMC10001778.txt,doc_count:

1}]}

数据注入完毕以后直接查询性能是十分差的查询时延可能在几秒甚至十几秒。

需要进行一些必要的优化。

核心的主要有两点

Segment

segment搜索效率将达到最高。

为了实现这个目标我们可以通过控制

refresh

执行合并整个合并过程比较长执行之前可以调高用于合并的线程最大值能够提高合并的速度。

merge

/{index_name}/_forcemerge?max_num_segments1?pretty#

increase

{index.merge.scheduler.max_thread_count:

左滑查看更多

_cat/segments/{index_name}?vhindex,segment,shard,docs.count,docs.deleted,size

左滑查看更多

索引的性能与索引数据结构是否缓存到内存中密切相关能够提供的缓存内容容量对性能影响很大。

可以执行以下

DSL

/_plugins/_knn/warmup/{index_name}?pretty

左滑查看更多

本文在本系列上篇博客的基础上通过一个真实数据场景的实践进行更详细的阐述讨论的重点更多放在针对大规模的文档、更快更完整地构建基于向量数据的知识库上面这对于一些行业如金融、法律、医疗等行业知识库的构建具备指导借鉴意义。

Amazon

的集群配置选择给出了一些方法参考第二三四部分对于数据摄入和检索性能等方面给出了一些初步的经验总结。

《Amazon

作为向量数据库讨论其优势及定位在索引和查询等方面给出更加详细的

benchmark给用户更加丰富的参考信息。

《基于大语言模型知识问答应用落地实践

知识召回调优》会在知识库构建的前提和背景下讨论如何更好的召回对应的知识包括各种适用的召回手段和实践技巧。

另外本文提到的代码细节可以参考配套资料

代码库

aws-samples/private-llm-qa-bothttps://github.com/aws-samples/private-llm-qa-botworkshop

Amazon

OpenSearch大语言模型的智能问答系统中英文版本https://github.com/aws-samples/private-llm-qa-bot

参考文献

https://aws.amazon.com/cn/blogs/big-data/choose-***-k-nn-algorithm-for-your-billion-scale-use-case-with-opensearch/

本篇作者

产品服务。

在互联网行业工作多年对用户画像精细化运营推荐系统大数据处理方面有丰富的实战经验。

亚马逊云科技大数据解决方案架构师负责基于亚马逊云科技的大数据解决方案的咨询与架构设计同时致力于大数据方面的研究和推广。

在大数据运维调优、容器解决方案湖仓一体以及大数据企业应用等方面有着丰富的经验。

汤市建

亚马逊云科技数据分析解决方案架构师负责客户大数据解决方案的咨询与架构设计。

亚马逊云科技

和机器学习方向解决方案架构师负责基于亚马逊云科技的机器学习方案架构咨询和设计致力于游戏、电商、互联网媒体等多个行业的机器学习方案实施和推广。

在加入亚马逊云科技之前从事数据智能化相关技术的开源及标准化工作具有丰富的设计与实践经验。

听说点完下面4个按钮