上篇介紹了構(gòu)建知識(shí)庫的大體流程和一些優(yōu)化經(jīng)驗(yàn)細(xì)節(jié)，但并沒有結(jié)合一個(gè)具體的場(chǎng)景給出更細(xì)節(jié)的實(shí)戰(zhàn)經(jīng)驗(yàn)以及相關(guān)的一些 benchmark 等，所以本文將會(huì)切入到一個(gè)具體場(chǎng)景進(jìn)行討論。

目標(biāo)場(chǎng)景：對(duì)于?PubMed?醫(yī)療學(xué)術(shù)數(shù)據(jù)中的 1w 篇文章進(jìn)行知識(shí)庫構(gòu)建，實(shí)現(xiàn)快速的注入和查詢速度。

主要討論的內(nèi)容會(huì)覆蓋 OpenSearch 集群規(guī)模設(shè)計(jì)、知識(shí)庫 Index 設(shè)計(jì)以及實(shí)驗(yàn)步驟細(xì)節(jié)。

01

資源推算

一般來說，我們需要按照以下 OpenSearch 集群的設(shè)計(jì)指導(dǎo)原則，選擇 OpenSearch 的資源配置：

• 如果偏向搜索的工作負(fù)載那么應(yīng)該使用 10-30GB 的 shard 大小，如果偏向日志的工作負(fù)載，應(yīng)該采用 30-50GB 的節(jié)點(diǎn)大??；

• 請(qǐng)嘗試將分片數(shù)量設(shè)為數(shù)據(jù)節(jié)點(diǎn)數(shù)量的偶數(shù)倍，有助于分片在數(shù)據(jù)節(jié)點(diǎn)上均勻分布；

• 每個(gè)節(jié)點(diǎn)的分片數(shù)，與 JVM 堆內(nèi)存成正比，每 GB 內(nèi)存的分片不超過 25 個(gè)；

• 每個(gè) 5 個(gè) vCPU 能對(duì)應(yīng)一個(gè)分片，比如 8 個(gè) vCPU 則最多支持 6 個(gè) shard；

• 如果有啟用 k-NN 字段，參考如下表格進(jìn)行內(nèi)存的推算。

依據(jù)目前的信息，僅僅知道所要索引的原始文檔數(shù)。由于文檔切分等中間處理過程，無法估算具體的內(nèi)存用量和存儲(chǔ)量，所以需要用小批量的實(shí)驗(yàn)數(shù)據(jù)進(jìn)行測(cè)試推演。

在小批量實(shí)驗(yàn)中嘗試索引了 300 篇文檔，通過切分共產(chǎn)生出了約 203k 條記錄，4.5GB 存儲(chǔ)量。那么按比例換算如果需要索引 1 萬篇文檔，那么會(huì)產(chǎn)生約 700w 記錄，150GB 存儲(chǔ)。如下圖所示：

從知識(shí)問答 Chatbot 場(chǎng)景出發(fā)，屬于搜索的工作負(fù)載，Shard 的大小應(yīng)在 10-30GB 范圍內(nèi)以增加搜索性能。shard 數(shù)量一般遵循節(jié)點(diǎn)數(shù)的倍數(shù)的原則，假設(shè)是 2 節(jié)點(diǎn)集群那么可以是 [2, 4, 8, 16 …]。以 150GB 存儲(chǔ)總量進(jìn)行計(jì)算，shard 可以為 8, 10, 12, 14, 16，當(dāng) shard 數(shù)為 8 時(shí)，每個(gè) shard 存儲(chǔ)量為 18.75GB，符合要求。

向量檢索方面為了同時(shí)保證 recall 和 latency，采用了 HNSW 算法。另外參考??中的 benchmark 結(jié)論，HNSW 算法中 m 值可以設(shè)定為 16。那么內(nèi)存規(guī)劃方面，依照上表公式進(jìn)行內(nèi)存占用的推算：

一般每個(gè)節(jié)點(diǎn)的堆外內(nèi)存占比 50%，根據(jù)knn.memory.circuit_breaker.limit=70%?的最佳實(shí)踐設(shè)定，那么 35% 的節(jié)點(diǎn)內(nèi)存被 KNN 占用，那么推算出整個(gè)節(jié)點(diǎn)的內(nèi)存應(yīng)為 22.9GB / 35% = 65GB。

vCPU 的規(guī)劃方面，假設(shè) shard 數(shù)為 8，乘以 1.5vCPU/Shard 的系數(shù)，vCPU 個(gè)數(shù)至少需要為 12 以上。結(jié)合如下 C 系和 R 系的實(shí)例配置信息和價(jià)格信息，綜合考慮內(nèi)存和 vCPU 的要求，選擇 C 系的 2 節(jié)點(diǎn) c6g.4xlarge 或者 R 系的 2 節(jié)點(diǎn) r6g.2xlarge。

02

索引構(gòu)建實(shí)驗(yàn)

索引構(gòu)建中需要關(guān)注的主要有三點(diǎn)：

• 數(shù)據(jù)完整性，保證所有的知識(shí)都能被查詢到，不會(huì)因?yàn)閿z入異常導(dǎo)致數(shù)據(jù)缺失。

• 構(gòu)建速度，知識(shí)召回部分可能存在反復(fù)的效果調(diào)整，需要反復(fù)多次攝入，速度對(duì)全鏈路開發(fā)調(diào)優(yōu)的效率很重要。

• 查詢性能，保證場(chǎng)景中的實(shí)時(shí)會(huì)話體驗(yàn)。

整個(gè)攝入過程，從過程上基本可以劃分為三個(gè)階段：文本切分、文本向量化以及攝入 Amazon OpenSearch。其中文本切分和文本向量化的處理是臨時(shí)性的工作負(fù)載，原則上可以提升 glue job 的并發(fā)數(shù)和 Amazon SageMaker Endpoint 背后的節(jié)點(diǎn)數(shù)來線性提高對(duì)這塊工作負(fù)載的處理速度，但 OpenSearch 屬于一個(gè)預(yù)分配的資源（注：今年即將發(fā)布的 OpenSearch Severless k-NN 向量數(shù)據(jù)庫會(huì)改變這一點(diǎn)）。后兩個(gè)部分，即向量化和 OpenSearch 攝入可能會(huì)是整個(gè)流程的瓶頸，完整流程測(cè)試不容易進(jìn)行拆解分析性能瓶頸，所以本試驗(yàn)會(huì)分別對(duì)這兩部分進(jìn)行測(cè)試。

實(shí)驗(yàn) 1 – Embedding Model 吞吐測(cè)試

1. 使用?paraphrase-multilingual-deploy.ipynb?進(jìn)行部署，部署 10 臺(tái) g4dn.xlarge 機(jī)型；

   https://github.com/aws-samples/private-llm-qa-bot/blob/main/notebooks/embedding/paraphrase-multilingual-deploy.ipynb

2. 注釋掉下游寫入 OpenSearch 造成的影響，暫時(shí)注釋掉相關(guān)代碼；

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

3. 利用?batch_upload_docs.py?啟動(dòng)多 glue job 進(jìn)行并發(fā)運(yùn)行。

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

這部分處理流程中，通過調(diào)整 glue job 的并行度與 client-side batch size 可以調(diào)整向量化這一步驟的吞吐能力。當(dāng) GPU 利用率不足時(shí)，提高 client-side batch size 能夠提高 GPU 的利用率。經(jīng)過簡(jiǎn)單測(cè)試發(fā)現(xiàn)，確實(shí)能證明這個(gè)假設(shè)，具體數(shù)據(jù)可以參考如下實(shí)驗(yàn)結(jié)果：

實(shí)驗(yàn) 2 – Amazon OpenSearch 攝入測(cè)試

1. 隨機(jī)生成向量，替換掉 Embedding 模型調(diào)用，參考如下代碼：

import numpy as np
AOS_BENCHMARK_ENABLED=True


def get_embedding(smr_client, text_arrs, endpoint_name=EMB_MODEL_ENDPOINT):
 ? ?if AOS_BENCHMARK_ENABLED:
 ? ? ? ?text_len = len(text_arrs)
 ? ? ? ?return [ np.random.rand(768).tolist() for i in range(text_len) ]
 ? ? ?
 ? ?# call sagemaker endpoint to calculate embeddings
 ? ?...
 ? ?return embeddings

左滑查看更多

2. 構(gòu)建 OpenSearch 集群以及索引，并優(yōu)化設(shè)置；

a. 構(gòu)建對(duì)應(yīng)的索引

向量字段涉及到的兩個(gè)參數(shù) ef_construction 和 m。ef_construction 指定構(gòu)建 k-NN 圖的時(shí)候的動(dòng)態(tài)列表大小，值越大其向量數(shù)據(jù)的圖更精確，但索引的速度也響應(yīng)更慢。m 指定 k-NN 中每個(gè)向量雙向鏈表的數(shù)量，越大檢索越準(zhǔn)確，但相應(yīng)內(nèi)存占用會(huì)顯著增大。參考博客<Choose the k-NN algorithm for your billion-scale use case with OpenSearch>中的 benchmark 結(jié)論 (https://aws.amazon.com/cn/blogs/big-data/choose-the-k-nn-algorithm-for-your-billion-scale-use-case-with-opensearch/)，對(duì)于當(dāng)前的數(shù)據(jù)規(guī)模，參數(shù) ef_construction:128 和 m:16 已經(jīng)足以保證召回率，另外在構(gòu)建索引時(shí)可以關(guān)注以下幾點(diǎn):

1. 添加一個(gè) publish_date 字段方便后續(xù)根據(jù)時(shí)間來刪除/更新知識(shí)；

2. 添加 idx 整型字段用于記錄對(duì)應(yīng)片段在全文中的順序，在召回時(shí)可以基于 range_search 召回相鄰上下文片段；

3. 只做過濾不做關(guān)鍵字召回的字段設(shè)置成 keyword 類型，有利于索引速度。具體可以參考如下代碼：

PUT chatbot-index
{
 ? ?"settings" : {
 ? ? ? ?"index":{
 ? ? ? ? ? ?"number_of_shards" : 8,
 ? ? ? ? ? ?"number_of_replicas" : 0,
 ? ? ? ? ? ?"knn": "true",
 ? ? ? ? ? ?"knn.algo_param.ef_search": 32,
 ? ? ? ? ? ?"refresh_interval": "60s"
 ? ? ? ?}
 ? ?},
 ? ?"mappings": {
 ? ? ? ?"properties": {
 ? ? ? ? ? ?"publish_date" : {
 ? ? ? ? ? ? ? ?"type": "date",
 ? ? ? ? ? ? ? ?"format": "yyyy-MM-dd HH:mm:ss"
 ? ? ? ? ? ?},
 ? ? ? ? ? ?"idx" : {
 ? ? ? ? ? ? ? ?"type": "integer"
 ? ? ? ? ? ?},
 ? ? ? ? ? ?"doc_type" : {
 ? ? ? ? ? ? ? ?"type" : "keyword"
 ? ? ? ? ? ?},
 ? ? ? ? ? ?"doc": {
 ? ? ? ? ? ? ? ?"type": "text",
 ? ? ? ? ? ? ? ?"analyzer": "ik_max_word",
 ? ? ? ? ? ? ? ?"search_analyzer": "ik_smart"
 ? ? ? ? ? ?},
 ? ? ? ? ? ?"content": {
 ? ? ? ? ? ? ? ?"type": "text",
 ? ? ? ? ? ? ? ?"analyzer": "ik_max_word",
 ? ? ? ? ? ? ? ?"search_analyzer": "ik_smart"
 ? ? ? ? ? ?},
 ? ? ? ? ? ?"doc_title": {
 ? ? ? ? ? ? ? ?"type": "keyword"
 ? ? ? ? ? ?},
 ? ? ? ? ? ?"doc_category": {
 ? ? ? ? ? ? ? ?"type": "keyword"
 ? ? ? ? ? ?},
 ? ? ? ? ? ?"embedding": {
 ? ? ? ? ? ? ? ?"type": "knn_vector",
 ? ? ? ? ? ? ? ?"dimension": 768,
 ? ? ? ? ? ? ? ?"method": {
 ? ? ? ? ? ? ? ? ? ?"name": "hnsw",
 ? ? ? ? ? ? ? ? ? ?"space_type": "cosinesimil",
 ? ? ? ? ? ? ? ? ? ?"engine": "nmslib",
 ? ? ? ? ? ? ? ? ? ?"parameters": {
 ? ? ? ? ? ? ? ? ? ? ? ?"ef_construction": 128,
 ? ? ? ? ? ? ? ? ? ? ? ?"m": 16
 ? ? ? ? ? ? ? ? ? ?}
 ? ? ? ? ? ? ? ?} ? ? ? ? ? 
 ? ? ? ? ? ?}
 ? ? ? ?}
 ? ?}
}

左滑查看更多

b.設(shè)置 knn 相關(guān)參數(shù)，參考《基于大語言模型知識(shí)問答應(yīng)用落地實(shí)踐 – 知識(shí)庫構(gòu)建（上）》

PUT /_cluster/settings
{
 ? ?"transient": {
 ? ? ? ?"knn.algo_param.index_thread_qty": 8,
 ? ? ? ?"knn.memory.circuit_breaker.limit": "70%"
 ? ?}
}

左滑查看更多

c.開啟多 glue job 進(jìn)行并發(fā)攝入，可以參考如下代碼：

# 注意${Concurrent_num} 不能超過
# glue job->job detail->Advanced properties->Maximum concurrency 設(shè)置中最大限制
python batch_upload_docs.py \
--bucket "${bucket_name}" \
 --aos_endpoint "${OpenSearch_Endpoint}" \
 --emb_model_endpoint "${EmbeddingModel_Endpoint}" \
 --concurrent_runs_quota ${Concurrent_num} \
 --job_name "${Glue_jobname}"

左滑查看更多

3. 部分實(shí)驗(yàn)結(jié)果明細(xì)

每輪實(shí)驗(yàn)中，調(diào)整的參數(shù)已經(jīng)用加粗字體標(biāo)注出來，供參考用于指導(dǎo)后續(xù)的數(shù)據(jù)注入中的參數(shù)調(diào)整。

實(shí)驗(yàn) 3 – 全流程攝入測(cè)試

a. 部分實(shí)驗(yàn)記錄明細(xì)

b. 初步實(shí)驗(yàn)結(jié)論

參考以上的實(shí)驗(yàn)記錄可知，1 萬篇文檔拆分成 700 萬條向量后，通過調(diào)整客戶端并發(fā)，推理端點(diǎn)的節(jié)點(diǎn)數(shù)和推理 Batch Size 可以在 1 小時(shí)左右完成攝入，且完整性沒有問題。能夠滿足大規(guī)模知識(shí)構(gòu)建的要求，如果文檔量繼續(xù)增長，可以繼續(xù)擴(kuò)展 OpenSearch 節(jié)點(diǎn)和 SageMaker Endpoint 節(jié)點(diǎn)。

03

索引構(gòu)建經(jīng)驗(yàn)總結(jié)

以往 OpenSearch 攝入時(shí)的一些最佳實(shí)踐中并不包含 knn 的情況，所以在 knn 索引存在的情況，不能完全參照之前的結(jié)論，通過以上三種不同的實(shí)驗(yàn)方式，在多次實(shí)驗(yàn)的過程中，本文得到了以下的一些實(shí)踐經(jīng)驗(yàn)和結(jié)論，供參考：

a. CPU 利用率和參數(shù) ef_construction 與 m 明顯正相關(guān)，在實(shí)驗(yàn)中使用較大的 ef_construction 和 m 時(shí)，CPU 很容易達(dá)到 100%。實(shí)驗(yàn)中，在其他參數(shù)相同的情況下，ef_construction 為 512 時(shí)，CPU 利用率會(huì)長期保持在 100%，改為 2 時(shí)，利用率基本在 20% 以下，峰值不超過 30%。

b. 客戶端并行數(shù)量與 OpenSearch 的攝入速度和負(fù)載成正相關(guān)，但并不是線性相關(guān)。多客戶端能提高攝入速度，但是客戶端數(shù)量過多，可能會(huì)導(dǎo)致大量的(429, ‘429 Too Many Requests /_bulk’)和(503, “No server available to handle the request..”)等錯(cuò)誤。

c. 指數(shù)退避重試機(jī)制能保證攝入的完整性以及因集群瞬時(shí)不可用導(dǎo)致的大面積寫入失敗，opensearch-py包中有如下攝入函數(shù), 如果并發(fā)客戶端過多，可能會(huì)導(dǎo)致CPU利用率一直位于100%，在max_retries的重試次數(shù)內(nèi)，每次會(huì)等待 initial_backoff * (attampt_idx ** 2)的時(shí)間，通過設(shè)定一個(gè)較大的initial_backoff等待時(shí)間，能避免在客戶端并發(fā)數(shù)偏大的情況下出現(xiàn)大面積429錯(cuò)誤。另外客戶端數(shù)也不能過大，否則也會(huì)更容易出現(xiàn)大量的503相關(guān)錯(cuò)誤。對(duì)于偶發(fā)的503報(bào)錯(cuò)，可以利用 glue 的 retry 機(jī)制處理，保證寫入的完整性。

# chunk_size 為文檔數(shù) 默認(rèn)值為 500
# max_chunk_bytes 為寫入的最大字節(jié)數(shù)，默認(rèn) 100M 過大，可以改成 10-15M
# max_retries 重試次數(shù)
# initial_backoff 為第一次重試時(shí) sleep 的秒數(shù)，再次重試會(huì)翻倍
# max_backoff 最大等待時(shí)間
response = helpers.bulk(client,
 ? ?doc_generator,
 ? ?max_retries=3,
 ? ?initial_backoff=200, #默認(rèn)值為 2，建議大幅提高
 ? ?max_backoff=800,
 ? ?max_chunk_bytes=10 * 1024 * 1024) #10M 社區(qū)建議值

左滑查看更多

注意：在大規(guī)模數(shù)據(jù)攝入的生產(chǎn)場(chǎng)景中，不建議使用LangChain提供的向量數(shù)據(jù)庫接口，查看其源碼可知，LangChain的默認(rèn)實(shí)現(xiàn)是單客戶端，且其內(nèi)部實(shí)現(xiàn)沒有使用指數(shù)退避Retry機(jī)制，無法保證攝入速度和完整性。

d. 寫入完成后，建議查詢文檔的去重?cái)?shù)量，確保寫入的完整性?？梢栽?OpenSearch Dashboard 的 Dev tools 中使用如下的 DSL 語句查詢文檔總數(shù)。注意 cardinality 方式的統(tǒng)計(jì)不是精準(zhǔn)統(tǒng)計(jì)值，可以提高 precision_threshold 參數(shù)值來提高其準(zhǔn)確性。

POST /{index_name}/_search
{
 ?"size": 0,
 ?"aggs": {
 ? ?"distinct_count": {
 ? ? ?"cardinality": {
 ? ? ? ?"field": "{field_name}",
 ? ? ? ?"precision_threshold": 20000
 ? ? ?}
 ? ?}
 ?}
}


=> 10000

左滑查看更多

同時(shí)可以按照文檔名統(tǒng)計(jì)對(duì)應(yīng)的 chunk 數(shù)量，可以幫助發(fā)現(xiàn)潛在文檔處理質(zhì)量問題，參考下面代碼：

GET /{index_name}/_search
{
 ?"size": 0,
 ?"aggs": {
 ? ?"distinct_values": {
 ? ? ?"terms": {
 ? ? ? ?"field": "doc_title"
 ? ? ?}
 ? ?}
 ?}
}


=>
...
"aggregations": {
 ? ?"distinct_values": {
 ? ? ?"buckets": [
 ? ? ? ?{
 ? ? ? ? ?"key": "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
 ? ? ? ?}
 ? ? ?]
 ? ?}

左滑查看更多

e. refresh_interval 設(shè)置為 -1，在其他相關(guān)參數(shù)的相同的情況下，503 報(bào)錯(cuò)明顯增加。更改為 60s 后，情況有明顯好轉(zhuǎn), 如果發(fā)生類似問題，可以做類似的調(diào)整。

04

檢索性能調(diào)優(yōu)

數(shù)據(jù)注入完畢以后，直接查詢性能是十分差的，查詢時(shí)延可能在幾秒甚至十幾秒。需要進(jìn)行一些必要的優(yōu)化。核心的主要有兩點(diǎn)：

a. Segment 合并

Segment 是 OpenSearch 中的最小搜索單元。如果每個(gè) shard 只有 1 個(gè) segment，搜索效率將達(dá)到最高。為了實(shí)現(xiàn)這個(gè)目標(biāo)，我們可以通過控制 refresh interval 來降低小 segment 的生成速度，或者手動(dòng)進(jìn)行 segment merge。這將有助于減少搜索過程中的開銷，提高搜索速度。

可以在 OpenSearch Dashboard 的 Dev tools 中通過如下的 DSL 執(zhí)行合并，整個(gè)合并過程比較長，執(zhí)行之前可以調(diào)高用于合并的線程最大值，能夠提高合并的速度。

# merge segments
POST /{index_name}/_forcemerge?max_num_segments=1?pretty


# increase max_thread_count for merge task
PUT {index_name}/_settings
{
 ?"index.merge.scheduler.max_thread_count": 8
}

左滑查看更多

合并前后可以執(zhí)行如下 DSL 來檢查當(dāng)前的 segments 情況：

GET _cat/segments/{index_name}?v&h=index,segment,shard,docs.count,docs.deleted,size

左滑查看更多

以下表格是合并 segments 后的情況，合并完成后每個(gè) shard 下僅有一個(gè) segment，數(shù)據(jù)也均勻分布，標(biāo)記刪除的數(shù)據(jù)也被清理掉了。

b. k-NN 索引 warmup

由于 k-NN 索引的性能與索引數(shù)據(jù)結(jié)構(gòu)是否緩存到內(nèi)存中密切相關(guān)，能夠提供的緩存內(nèi)容容量對(duì)性能影響很大?？梢詧?zhí)行以下 DSL 命令，對(duì) k-NN 索引進(jìn)行預(yù)熱

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

左滑查看更多

預(yù)熱執(zhí)行很快，預(yù)熱完畢以后，性能會(huì)有明顯改善?？梢缘?CloudWatch 中去查看 OpenSearch Domain 中的 KNNGraphMemoryUsagePercentage 指標(biāo)進(jìn)行確認(rèn)是否執(zhí)行完畢，如圖所示：

05

結(jié)語

本文在本系列上篇博客的基礎(chǔ)上，通過一個(gè)真實(shí)數(shù)據(jù)場(chǎng)景的實(shí)踐進(jìn)行更詳細(xì)的闡述，討論的重點(diǎn)更多放在針對(duì)大規(guī)模的文檔、更快更完整地構(gòu)建基于向量數(shù)據(jù)的知識(shí)庫上面，這對(duì)于一些行業(yè)如金融、法律、醫(yī)療等行業(yè)知識(shí)庫的構(gòu)建具備指導(dǎo)借鑒意義。

本文的第一部分對(duì)于 Amazon OpenSearch 的集群配置選擇給出了一些方法參考，第二三四部分對(duì)于數(shù)據(jù)攝入和檢索性能等方面給出了一些初步的經(jīng)驗(yàn)總結(jié)。

本系列后續(xù)還有幾篇相關(guān)博客進(jìn)一步深入闡述，其中包括：

• 《Amazon OpenSearch 向量數(shù)據(jù)庫的性能評(píng)估與選型分析》，會(huì)針對(duì) Amazon OpenSearch 作為向量數(shù)據(jù)庫，討論其優(yōu)勢(shì)及定位，在索引和查詢等方面給出更加詳細(xì)的 benchmark，給用戶更加豐富的參考信息。

• 《基于大語言模型知識(shí)問答應(yīng)用落地實(shí)踐 – 知識(shí)召回調(diào)優(yōu)》，會(huì)在知識(shí)庫構(gòu)建的前提和背景下，討論如何更好的召回對(duì)應(yīng)的知識(shí)，包括各種適用的召回手段和實(shí)踐技巧。另外，本文提到的代碼細(xì)節(jié)可以參考配套資料：

1. 代碼庫?aws-samples/private-llm-qa-bot

   https://github.com/aws-samples/private-llm-qa-bot

2. workshop?<基于 Amazon OpenSearch+大語言模型的智能問答系統(tǒng)>（中英文版本）

   https://github.com/aws-samples/private-llm-qa-bot
   

參考文獻(xiàn)：

1. Choose the k-NN algorithm for your billion-scale use case with OpenSearch

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

本篇作者

李元博

亞馬遜云科技 Analytic 與 AI/ML 方面的解決方案架構(gòu)師，專注于 AI/ML 場(chǎng)景的落地的端到端架構(gòu)設(shè)計(jì)和業(yè)務(wù)優(yōu)化，同時(shí)負(fù)責(zé)數(shù)據(jù)分析方面的 Amazon Clean Rooms 產(chǎn)品服務(wù)。在互聯(lián)網(wǎng)行業(yè)工作多年，對(duì)用戶畫像，精細(xì)化運(yùn)營，推薦系統(tǒng)，大數(shù)據(jù)處理方面有豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)。

孫健

亞馬遜云科技大數(shù)據(jù)解決方案架構(gòu)師，負(fù)責(zé)基于亞馬遜云科技的大數(shù)據(jù)解決方案的咨詢與架構(gòu)設(shè)計(jì)，同時(shí)致力于大數(shù)據(jù)方面的研究和推廣。在大數(shù)據(jù)運(yùn)維調(diào)優(yōu)、容器解決方案，湖倉一體以及大數(shù)據(jù)企業(yè)應(yīng)用等方面有著豐富的經(jīng)驗(yàn)。

湯市建

亞馬遜云科技數(shù)據(jù)分析解決方案架構(gòu)師，負(fù)責(zé)客戶大數(shù)據(jù)解決方案的咨詢與架構(gòu)設(shè)計(jì)。

郭韌

亞馬遜云科技 AI 和機(jī)器學(xué)習(xí)方向解決方案架構(gòu)師，負(fù)責(zé)基于亞馬遜云科技的機(jī)器學(xué)習(xí)方案架構(gòu)咨詢和設(shè)計(jì)，致力于游戲、電商、互聯(lián)網(wǎng)媒體等多個(gè)行業(yè)的機(jī)器學(xué)習(xí)方案實(shí)施和推廣。在加入亞馬遜云科技之前，從事數(shù)據(jù)智能化相關(guān)技術(shù)的開源及標(biāo)準(zhǔn)化工作，具有豐富的設(shè)計(jì)與實(shí)踐經(jīng)驗(yàn)。

聽說，點(diǎn)完下面4個(gè)按鈕

就不會(huì)碰到bug了！

文章來源地址http://www.zghlxwxcb.cn/news/detail-682599.html