基于大语言模型知识问答应用落地实践 – 知识库构建（下）
内容提要
本文介绍了构建知识库的流程和优化经验，以及在PubMed医学数据中的具体场景。讨论了OpenSearch集群规模设计、知识库索引设计和实验步骤细节。给出了合适的OpenSearch资源配置和索引1万篇文档所需的存储量和内存用量。针对知识问答Chatbot场景，建议使用10-30GB的shard大小和8个shard。采用HNSW算法进行向量检索，并给出了内存规划方案。对索引构建实验和OpenSearch摄入测试进行了详细讨论，总结了索引构建经验和检索性能调优方法。提供了相关代码和参考文献。
延伸解读
从300篇到1万篇：小批量实验推算资源需求
文章通过索引300篇文档的小批量实验，推算出1万篇文档约产生700万条记录和150GB存储。这种按比例推算的方法，为资源规划提供了可操作的参考。但需注意，实际存储和内存占用可能因文档切分策略、向量维度等因素而变化，建议在正式部署前进行更接近真实数据规模的验证。
HNSW参数调优：召回率与构建成本的权衡
文章采用HNSW算法进行向量检索，并参考benchmark将m设为16、ef_construction设为128，以平衡召回率和构建速度。实验发现，ef_construction和m值越大，CPU利用率越高，甚至达到100%。因此，在实际应用中需根据数据规模和性能要求调整参数，避免因过度追求召回率而导致资源瓶颈。
摄入性能瓶颈：向量化与OpenSearch写入
文章将摄入流程拆分为文本切分、向量化和OpenSearch写入三个阶段，并分别测试。实验表明，通过调整客户端并发和batch size可以提高向量化吞吐，但OpenSearch写入并非线性扩展，并发过高易引发429和503错误。建议采用指数退避重试机制，并合理设置refresh_interval，以确保写入完整性和集群稳定性。
检索性能优化：Segment合并与k-NN预热
数据注入后直接查询延迟较高，文章建议进行Segment合并和k-NN索引预热。通过强制合并使每个shard仅有一个segment，可减少搜索开销；预热则能将k-NN索引加载到内存，显著提升查询速度。这些优化措施对于保证知识问答场景的实时性至关重要，但需注意合并过程可能较长，建议在低峰期执行。
Q&A
构建PubMed医学知识库时，OpenSearch集群的shard大小和数量应该如何设置？
对于知识问答Chatbot场景（搜索工作负载），建议shard大小在10-30GB范围内。以索引1万篇文档产生约150GB存储为例，shard数量应为节点数的偶数倍，如2节点集群可选8个shard，每个shard约18.75GB，符合要求。
在OpenSearch中做向量检索，HNSW算法的参数m和ef_construction应该怎么设置？
根据benchmark结论，对于当前数据规模，ef_construction设为128、m设为16已足以保证召回率。ef_construction越大索引越精确但构建越慢；m越大检索越准确但内存占用显著增加。
索引1万篇PubMed文档需要多少存储和内存？如何估算？
通过小批量实验（300篇文档产生约203k条记录、4.5GB存储）按比例推算，1万篇文档约产生700万条记录、150GB存储。内存规划需根据HNSW参数和shard数量计算，例如8个shard时，节点内存约需65GB（基于堆外内存50%和KNN限制70%推算）。
知识库索引构建实验分为哪几个阶段？如何提高向量化吞吐量？
实验分为文本切分、文本向量化和OpenSearch摄入三个阶段。提高向量化吞吐量可通过调整Glue job并行度和客户端batch size，当GPU利用率不足时提高batch size能有效提升吞吐。
OpenSearch摄入时遇到大量429或503错误怎么办？
可采取指数退避重试机制，设置较大的initial_backoff（如200秒）和max_retries（如3次），并控制客户端并发数避免过高。同时将refresh_interval设置为60s（而非-1）可减少503错误。对于偶发503，可利用Glue的重试机制。
数据摄入完成后，如何确保写入完整性并优化查询性能？
写入后建议查询文档去重数量（使用cardinality聚合，提高precision_threshold）确保完整性，并按文档名统计chunk数量检查处理质量。查询性能优化包括：执行segment合并（_forcemerge使每个shard只有一个segment）和k-NN索引预热（_knn/warmup），预热后性能明显改善。
