基于 Amazon OpenSearch Service 与 DeepSeek 构建知识库问答应用

1. 背景

在数字化转型的浪潮中，企业知识库作为组织企业内部经验的集合点，正面临着前所未有的挑战与机遇。传统知识库系统往往存在信息孤岛、检索效率低下、用户体验欠佳等痛点，难以满足现代企业对知识管理的高效需求。而生成式 AI 的崛起，为企业知识库的智能化升级提供了全新的可能。生成式 AI 凭借其强大的自然语言理解和生成能力，能够将企业内部的非结构化数据转化为可理解、可操作的知识。它不仅能够理解员工的模糊查询，提供精准的信息检索，还能基于企业知识进行上下文理解，生成符合企业语境的回答，大幅提升知识获取的效率与体验。这种能力对于加速新员工培训、提升客户服务质量、促进跨部门协作等方面具有显著价值。

然而，要充分发挥生成式 AI 的潜力，向量数据库的支持不可或缺。Amazon OpenSearch Service 作为一款强大的搜索和分析引擎，通过其向量检索能力，能够将企业文档转化为高维向量，实现语义层面的相似度匹配，突破了传统关键词搜索的局限。这使得企业能够从海量非结构化数据中快速提取相关知识，为生成式 AI 提供准确的上下文信息，从而生成更加精准、有价值的回答。

对于实现方面， Amazon OpenSearch Service 进一步简化了开发流程，提供开箱即用的连接器（ML Connector）和数据处理管道（Ingestion/Search Pipeline），允许开发者无需编写复杂代码即可调用外部模型或内置算法（如文本嵌入、分类、异常检测）。例如，通过简单的 API 配置，即可将用户查询实时转化为向量并执行混合搜索（关键词+语义），大幅提升搜索相关性。

此外，Amazon OpenSearch Service 的 Learning to Rank 功能可结合 LLM 的输出优化排序策略，让结果更贴合业务需求。这些增强能力显著降低了 AI 落地的技术门槛，开发者只需关注业务逻辑而非底层架构，从而加速智能应用的开发周期，提升整体效率。无论是构建基于知识的聊天机器人，还是实现多模态搜索，Amazon OpenSearch Service 的 ML 集成都能提供端到端的支持，让企业更专注于创新而非运维。

另外，在众多大语言模型中，国产开源模型 DeepSeek 凭借其出色的中文理解能力和推理能力，为企业知识库的本地化部署提供了理想选择。DeepSeek 模型不仅能够准确理解中文语境和行业术语，还能进行复杂的逻辑推理，帮助企业从知识库中挖掘更深层次的洞见。更为重要的是，通过本地部署 DeepSeek 模型，企业可以确保敏感数据不出境，有效规避数据安全与隐私泄露风险，符合国内日益严格的数据合规要求。

将 Amazon OpenSearch Service 与 DeepSeek 模型相结合，企业可以构建一个既智能又安全的知识库系统。这种架构不仅保障了数据主权，还能根据企业特定需求进行定制化训练，打造真正契合企业文化和业务场景的智能助手。在当今竞争激烈的商业环境中，这种基于自主可控技术栈的知识库解决方案，无疑将成为企业提升内部效能、加速创新的重要支撑。

在本文中，我们将详细探讨如何利用 Amazon OpenSearch Service 和 DeepSeek 模型在亚马逊云科技中国区快速构建一个企业级知识库应用，从技术选型、架构设计到实际部署，为您提供一套可落地的实施方案。

2. 实现架构

步骤简介：

注册 OpenSearch Model 远端连接到 SageMaker Endpoint
通过 Ingestion Pipeline 将文档数据加载到 OpenSearch
导入文档时会利用 Ingestion Pipeline 中配置的 Connector 连接到向量模型对文档内容向量化
客户端提交请求到知识库服务端
知识库服务端通过 Search Pipeline （Retrieval-augmented generation processor）发起查询请求
通过 RAG Processor 调用 Embedding model 将查询请求向量化后在知识库中检索，接着直接将召回的知识内容作为提示词发送给 LLM，返回结果

这个方案中的关键就是 Retrieval-augmented generation processor（以下简称 RAG processor），这是 OpenSearch 从 2.11 版本开始支持的一种简化 RAG 场景开发的功能。对于 RAG 场景通过包含检索增强生成处理器的搜索流水线实现，帮助我们从索引和历史记录中检索数据，并将所有信息作为上下文发送给 LLM。然后，LLM 使用动态检索的数据补充内容生成。它可以处理器拦截 OpenSearch 查询结果，从对话内存中检索对话中的先前消息，并向 LLM 发送提示。处理器收到 LLM 的响应后，会将响应保存在对话内存中，并返回原始查询结果和 LLM 响应。具体实现的流程如下图所示：

3. 方案实施步骤

3.1 前置条件

首先我们需要有两个已经在 SageMaker 中部署好的模型：1. DeepSeek Model，2. Embedding Model。在亚马逊云科技中国区部署，强烈推荐大家选择使用 ModelHub 来部署，它提供一站式的模型微调，部署，调试的无代码可视化平台，可以帮助用户快速验证微调各类开源模型的效果，方便用户快速实验和决策，降低用户微调大模型的门槛。

另外，需要一个已经部署好的 Amazon OpenSearch Service 集群。

由于在亚马逊云中国区还无法使用 Amazon OpenSearch Integration 来部署 ML Connector，因此我们将整个方案部署脚本化。我们提供了两种方式来部署：

部署方案一，通过 SageMaker Studio Notebook 来部署。获取 Notebook 代码点击下载，将代码上传到 SageMaker Studio 中。然后按照 Notebook 中的指引步骤来部署。

部署方案二，通过 Cloud Foramtion 来部署，本文将采用这种方式来介绍，如果想了解整个部署流程可以参考第一种方式。

3.2 方案部署

下载 CloudFormation 模版。
下载部署依赖文件（部署过程中会使用 Lambda 来部署 ML Connector）。将部署依赖文件上传至 S3 桶，记下 S3 的地址。
进入亚马逊云科技控制台，搜索 Cloud Formation，点击创建堆栈，选择上传模版文件，点击选择文件，选择上一步骤下载的 CloudFormation 模版文件。按照如下配置，填写部署参数。在参数 DependenciesS3Bucket 填写上面步骤上传依赖文件的 S3 桶名，DependenciesS3Key 填写存放 S3 的地址（参考下图）。

CloudFormation 部署之后，会帮我们部署以下内容：

创建相关的用户角色和权限
创建 LLM 和 Embedding model 的 ML Connector ，创建的 Connector 会设置连接到 SageMaker Endpoint 的方法。
在 OpenSearch 中的注册模型，用于关联 ML Connector 实现远程推理。
导入了一部分知识库的样例数据。
创建一个 Retrieval-augmented generation processor 的 Search Pipeline。

部署完成后，可以在 CloudFormation 的输出中看到如下信息：

从输出中，我们获得：

通过 OpenSearch 用于远程推理的 Model ID（包括 LLM 和 Embedding Model）
一个知识库的索引 opensearch_kl_index，并且导入了一部分样例数据。
一个 Search Pipeline my-conversation-search-pipeline-deepseek-zh。

这些输出是我们后续需要用到的。

3.3 方案验证

1. 远程推理

打开 OpenSearch Dashboard，在左侧菜单中找到 Dev Tool，在工具中输入如下命令，DeepSeekModelId 可以从 CloudFormation 的输出中找到。

POST _plugins/_ml/models/<DeepSeekModelId>/_predict
{  
   "parameters": {    
      "inputs": "OpenSearch Serverless 是什么，和OpenSearch集群模式有什么区别，使用 OpenSearch Serverless，还需要管理服务器资源么？"
   }
}

执行后，可以得到如下的返回，OpenSearch 通过了 ML Connector 调用了部署了 DeepSeek 的 SageMaker Endpoint 来实现了远程推理的能力。

2. RAG processor Search Pipeline

通过 CloudFormation 输出获取的 Search Pipeline 名称，在 OpenSearch 查看它的具体配置。

GET /_search/pipeline/my-conversation-search-pipeline-deepseek-zh

如下返回结果中，可以看到在 Search Pipeline 中定义了 DeepSeek Model ID、系统提示词、用户指令。

这样，在使用 Search Pipeline 查询的时候，OpenSearch 就会直接调用部署在 SageMaker 中的 DeepSeek 模型，并且将这里定义的参数带入到提交的上下文中。

3. 知识库查询

执行如下命令，我们通过 RAG Processor 来进行一次查询，在这个查询命令中，有两部分定义：

通过向量召回知识库的文档。
将相同的提问信息，同时提交给 LLM，让 LLM 结合知识库召回的内容返回答案。

GET opensearch_kl_index/_search?search_pipeline=my-conversation-search-pipeline-deepseek-zh
{
  "query": {
    "neural": {
    "text_embedding": {
        "query_text": "OpenSearch Serverless 是什么，和OpenSearch集群模式有什么区别，使用 OpenSearch Serverless，还需要管理服务器资源么？",
        "model_id": "<Embedding Model ID>",
        "k": 5
      }
    }
  },
  "size": 2,
  "_source": [
    "text"
  ],
  "ext": {
    "generative_qa_parameters": {
      "llm_model": "bedrock/claude",
      "llm_question": "OpenSearch Serverless 是什么，和OpenSearch集群模式有什么区别，使用 OpenSearch Serverless，还需要管理服务器资源么？",
      "context_size": 5,
      "timeout": 100
    }
  }
}

得到如下的返回结果，可以看到返回结果中也分了两部分，第一部分是通过向量查询从知识库索引中查询的和问题相关的文档信息，第二部分则是将知识库查询到的文档内容组合成提示词之后再通过 LLM 返回的答案。根据 DeepSeek 的思考过程就可以看出来，它是已经通过知识库召回的相关内容，进行了分析然后再做出回答。

4. Demo 应用

我们可以通过一个应用的 Demo 更直观的来展示知识问答的效果。执行如下命令，下载代码，启动应用。

git clone https://gitee.com/turk/opensearch-ds-rag-demo.git
cd opensearch-ds-rag-demo/opensearch-rag/qa_app
python3 -m venv .
source bin/activate
pip install -r requirements.txt
cp .env.example .env

修改配置文件 .env，如下根据实际的配置，设置 OpenSearch 登录相关，以及索引和 Embedding ModelID

OPENSEARCH_HOST=<opensearch-endpoint https//vpc-xx.region.com>
OPENSEARCH_PORT=443
OPENSEARCH_USER=<opensearch-user>
OPENSEARCH_PASSWORD=<opensearch-password>
OPENSEARCH_INDEX=opensearch_kl_index
OPENSEARCH_EMBEDDING_MODEL_ID=<embedding model id>

启动应用

python3 app.py

启动后，从返回的内容提示从本地 5000 端口打开 Web 页面。然后在 Web 页面继续提问相同的问题，这样就可以比较直观的看到，这次查询参考的文档信息，并且在 AI 思考过程中提到从搜索结果中的补充内容。

3.4 方案扩展 – 对话式搜索

在知识库问答应用场景中，对于 LLM 的回答，通常会需要通过多轮对话的方式来优化最终获取的结果。这时就会用到对话式搜索的方式，对话式搜索允许用你使用自然语言提问，并通过提出后续问题来完善答案。因此，对话变成了你与大型语言模型（LLM）之间的对话。为此，模型需要记住整个对话的上下文，而不是单独回答每个问题。 OpenSearch 目前支持对话历史记录的功能，对话历史记录由一个简单的类似 CRUD 的 API 组成，其中包含两种资源：记忆和消息。当前对话的所有消息都存储在一个对话记忆中。下面来介绍如何使用这个能力。

1. 在 OpenSearch Dashboard 中的 Dev Tool 中执行如下命令，创建一个对话记忆库，用于存储对话中的所有消息。

POST /_plugins/_ml/memory/
{  
    "name": "Conversation about DeepSeek Demo"
}

得到一个返回的 Memory ID

{
  "memory_id": "AIr2a5YBtkG47jT7237U"
}

2. 然后我们使用另一个 Web Demo 应用来验证多轮对话的效果

首先在原来的 .env 配置中需要增加一个参数 OPENSEARCH_MEMORY_ID=<memory-id>，这里 memory-id 就是上一步骤的返回值。

接着执行如下命令启用应用，从返回的信息中可以看到这个应用是启动在了本地的 5001 端口，通过浏览器打开这个页面。

python3 app_conversational.py

然后先提问第一个问题：OpenSearch 有支持收集日志的工具么？，得到回答之后，接着我们追问：这个工具能收集哪些日志？，可以看到它在第一个问题回答内容的基础上做出第二个问题的回答。

3. 也可以通过如下命令查询 Memory 中的记录

GET /_plugins/_ml/memory/<memory-id>/messages

4. 总结

在本文中，我们详细介绍了如何通过 Aamzon OpenSearch Service 与 DeepSeek 模型的强强联合，快速构建一个企业级知识库应用。通过提供的 CloudFormation 模板，实现了整个解决方案的一键部署，大幅简化了技术实施的复杂度，使企业能够快速启动自己的智能知识库项目。

OpenSearch RAG Processor Search Pipeline 作为本方案的核心组件，展示了其在检索增强生成（RAG）架构中的关键价值。它不仅实现了高效的向量检索，还能智能处理用户查询，提取关键信息并结合检索结果生成高质量回答，为企业知识库注入了强大的智能化能力。这种管道式的处理流程，使得整个系统能够以低延迟、高准确度的方式响应用户的各类知识需求。此外，我们还探讨了系统的高级特性，如扩展反问-对话时搜索功能，它能够在用户提问不明确时主动引导用户进行澄清，提升交互的自然度和查询的准确性。同时，通过 OpenSearch 的 memory 功能保存历史对话记录，让 LLM 能够理解上下文语境，提供连贯一致的对话体验，使知识库不再是简单的问答工具，而是一个能够进行深度交流的智能助手。

通过两个 Web Demo 应用直观地展示了解决方案的实际效果，能够清晰地了解到最终用户的体验。这些演示不仅验证了技术方案的可行性，也展示了生成式 AI 与向量检索结合后在企业知识管理中的巨大潜力。用户可以通过自然语言对话的方式，轻松获取企业知识库中的专业信息，大幅提升了知识获取的效率和体验。

基于 Aamzon OpenSearch Service 和 DeepSeek 的企业知识库解决方案，为企业提供了一条低成本、高效率的知识管理数字化转型路径，帮助企业在信息爆炸的时代更好地管理和利用自身的知识资产，提升组织的整体竞争力。随着企业对知识管理需求的不断深入，我们相信这种结合云托管服务与开源大语言模型的解决方案将有更广阔的应用前景。我们也期待与更多企业一起，探索智能知识库在各行各业的创新应用，共同推动企业知识管理的智能化革新。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您了解行业前沿技术和发展海外业务选择推介该服务。

亚马逊AWS官方博客