基于LangChain与AWS Bedrock构建企业级RAG智能问答系统实战-编程阁

1. 项目概述：基于LangChain、Amazon Bedrock和OpenSearch的RAG系统

最近在折腾一个企业知识库的智能问答项目，核心需求是把一堆分散的PDF、Word文档、网页内容变成能“对话”的智能体。传统的基于关键词的搜索，用户得自己提炼关键词，结果还不一定准；而直接上大语言模型（LLM）吧，模型本身的知识是静态的，回答不了你公司内部最新的产品手册或者项目文档里的内容，还容易“一本正经地胡说八道”（幻觉问题）。

这时候，检索增强生成（RAG）就成了一个非常务实的选择。简单来说，RAG就是让LLM在回答问题时，先去你的专属知识库里“查资料”，然后基于查到的相关资料来组织答案。这样既保证了答案的相关性和准确性，又赋予了LLM实时获取外部知识的能力。

我这次实践参考并深度改造了AWS官方的一个示例项目，它巧妙地结合了三个核心组件：LangChain作为编排框架，Amazon Bedrock提供强大的基础模型，Amazon OpenSearch Serverless作为向量检索数据库。这个组合拳打下来，不仅性能稳定，而且因为完全构建在AWS托管服务之上，运维复杂度大大降低。接下来，我就把这个从零搭建、踩坑、调优的全过程拆开揉碎了分享给你。

2. 核心架构与组件选型解析

2.1 为什么是RAG？解决LLM的“知识盲区”与“幻觉”

在深入技术栈之前，我们必须先理解为什么RAG是当前企业级AI应用的首选架构之一。大语言模型虽然在通用知识上表现惊人，但它存在两个致命短板：

知识滞后性：模型的训练数据有截止日期，无法知晓之后发生的事件或发布的文档。比如，你无法直接问ChatGPT你公司上周刚更新的财务政策。
领域特异性缺失：模型缺乏对特定企业、垂直行业的私有知识的理解。它不懂你公司的产品代号、内部流程缩写或客户案例细节。
幻觉与溯源困难：模型可能生成听起来合理但完全错误的内容，且你无法验证其信息源。

RAG通过将“检索（Retrieval）”和“生成（Generation）”解耦，优雅地解决了这些问题。其工作流可以概括为：

索引阶段：将私有文档切块、编码为向量（嵌入），存入向量数据库。
查询阶段：当用户提问时，将问题也编码为向量，在向量数据库中查找语义最相似的文本块（上下文）。
生成阶段：将找到的上下文和用户问题一起拼接成提示（Prompt），送给LLM，指令其“基于以下上下文回答问题”。

这样一来，LLM的答案就有了依据，并且我们可以要求它引用来源，实现了答案的可解释性和可控性。

2.2 组件深度选型：LangChain, Bedrock 与 OpenSearch Serverless

这个项目的技术选型体现了现代AI应用开发的典型思路：用框架管理复杂性，用托管服务保证稳定与扩展。

#### 2.2.1 LangChain：AI应用的“粘合剂”与“调度中心”

LangChain不是一个模型，而是一个框架。你可以把它想象成乐高积木的底板和连接件。它提供了标准化的接口（如LLM，Embeddings，VectorStore）和丰富的“链（Chain）”与“代理（Agent）”模式，让我们能像搭积木一样组合不同的模块。

在这个项目中，LangChain的核心价值在于：

标准化抽象：无论底层用的是Bedrock的Claude还是Titan模型，通过LangChain的BedrockLLM封装，调用方式都是统一的。换模型可能只需要改一行配置。
文档加载与处理：内置了PyPDFLoader，DocxLoader，WebBaseLoader等，能轻松处理多种格式的原始文档。
文本分割策略：提供了RecursiveCharacterTextSplitter、TokenTextSplitter等，这是影响RAG效果的关键环节，后面会详细讲。
检索链封装：提供了RetrievalQA这样的高层链，把向量检索、提示组装、LLM调用整个流程打包好，极大简化了开发。

注意：LangChain更新迭代很快，API有时会有变动。建议在项目开始时锁定一个较稳定的版本（例如langchain==0.0.340），并在虚拟环境中开发，避免依赖冲突。

#### 2.2.2 Amazon Bedrock：企业级基础模型的“超市”

Amazon Bedrock是AWS推出的全托管服务，它集成了多家顶尖AI公司的基础模型（FM），如Anthropic的Claude、AI21 Labs的Jurassic、Cohere的Command，以及亚马逊自家的Titan。你可以把它理解为一个“模型即服务（MaaS）”平台。

选择Bedrock而非直接调用OpenAI API或部署开源模型，主要基于以下几点考量：

安全与合规：数据在AWS网络内流动，无需将敏感的企业文档发送到外部API端点，满足严格的数据治理要求。
统一管理与成本控制：所有模型的调用通过统一的AWS API和计费体系，方便管理和预测成本。
免运维：无需关心模型的部署、扩缩容、GPU驱动等底层基础设施问题。
模型多样性：可以根据任务特点（创意写作、逻辑推理、代码生成）选择最合适的模型，甚至未来可以轻松切换。

在这个项目中，我主要使用了Anthropic Claude Instant（快速、性价比高）和Claude 3 Haiku/Sonnet（能力更强）进行生成，使用Amazon Titan Embeddings模型进行文本向量化。

#### 2.2.3 Amazon OpenSearch Serverless：专为向量搜索优化的“记忆库”

向量数据库是RAG的“记忆”核心。我们需要一个能高效存储和检索高维向量（通常是768或1024维）的数据库。OpenSearch（及其Serverless版本）不仅支持传统的全文检索，还通过k-NN插件原生支持向量相似度搜索。

选择OpenSearch Serverless版本的理由：

真正的Serverless：无需预置或管理集群容量。你只需要创建集合（Collection），它根据实际的数据存储量和查询流量自动伸缩，按实际使用量付费。对于流量波动大的应用（如内部工具，可能白天查询多，晚上少），成本效益极高。
集成与安全：天然与AWS生态系统集成，通过IAM角色控制访问权限，VPC内网访问保障网络安全，与Bedrock同处一个云环境，数据传输延迟低。
混合搜索能力：除了纯向量搜索，还支持将关键词搜索（BM25）分数与向量相似度分数进行混合（Hybrid Search），在实践中能有效提升检索质量，尤其是当查询中包含具体名称、代号时。

3. 实战搭建：从零构建RAG流水线

理论讲完，我们进入实战环节。我会假设你有一个AWS账号，并具备基本的Python和AWS CLI配置知识。

3.1 环境准备与基础设施部署

#### 3.1.1 AWS权限与Bedrock模型访问

首先，确保你的IAM用户或角色有足够的权限。你需要：

bedrock:InvokeModel(调用Bedrock模型)
bedrock:ListFoundationModels(查看可用模型)
aoss:*(创建和管理OpenSearch Serverless资源，生产环境建议细化)
s3:*(如果你的文档存放在S3，需要读取权限)

关键一步：在AWS Bedrock控制台，你需要对你计划使用的模型（如Claude系列， Titan Embeddings）“请求模型访问（Request model access）”。这是一个点击按钮的操作，但必须做，否则调用会失败。

#### 3.1.2 创建OpenSearch Serverless向量集合

我们通过AWS CLI来创建，这比控制台更可重复。

# 1. 创建加密策略（可选但推荐） aws opensearchserverless create-security-policy \ --name vector-search-encryption-policy \ --type encryption \ --policy '{"Rules":[{"Resource":["collection/rag-collection"],"ResourceType":"collection"}],"AWSOwnedKey":true}' # 2. 创建网络策略（允许从你的VPC或特定IP访问） aws opensearchserverless create-security-policy \ --name vector-search-network-policy \ --type network \ --policy '[{"Rules":[{"ResourceType":"collection","Resource":["collection/rag-collection"]}],"AllowFromPublic":true}] # 注意：生产环境应将"AllowFromPublic"设为false，并配置具体的VPC或IP规则。 # 3. 创建数据访问策略（指定哪个IAM角色可以访问集合） # 首先，创建一个信任策略文件 trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::YOUR_ACCOUNT_ID:root" }, "Action": "sts:AssumeRole" } ] } # 创建IAM角色 aws iam create-role \ --role-name os-serverless-rag-role \ --assume-role-policy-document file://trust-policy.json # 创建数据访问策略，关联该角色 aws opensearchserverless create-access-policy \ --name vector-search-data-policy \ --type data \ --policy '[{"Rules":[{"ResourceType":"collection","Resource":["collection/rag-collection"],"Permission":["aoss:*"]}],"Principal":["arn:aws:iam::YOUR_ACCOUNT_ID:role/os-serverless-rag-role"]}]' # 4. 终于，创建向量集合！ aws opensearchserverless create-collection \ --name rag-collection \ --type VECTORSEARCH

创建完成后，记下返回的arn和dashboardUrl（即OpenSearch的终端节点）。集合初始化需要几分钟，状态变为ACTIVE后才可使用。

3.2 文档处理与向量化：决定RAG效果的“基石”

这是整个流程中最关键、最需要精心设计的部分。垃圾输入，必然导致垃圾输出。

#### 3.2.1 文档加载与文本分割的艺术

LangChain提供了多种加载器。这里以PDF和网页为例：

from langchain.document_loaders import PyPDFLoader, WebBaseLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 加载PDF pdf_loader = PyPDFLoader("path/to/your/document.pdf") pdf_docs = pdf_loader.load() # 加载网页 web_loader = WebBaseLoader(["https://example.com/page1", "https://example.com/page2"]) web_docs = web_loader.load() # 合并所有文档 all_docs = pdf_docs + web_docs

接下来是文本分割。直接整篇文档塞进去效果很差，因为上下文窗口有限，且会引入无关噪音。分割的目标是得到语义相对完整、大小适中的“块（Chunk）”。

text_splitter = RecursiveCharacterTextSplitter( # 按字符递归分割，优先尝试 \n\n, 然后 \n, 再空格，最后单个字符 separators=["\n\n", "\n", " ", ""], chunk_size=1000, # 每个块的最大字符数 chunk_overlap=200, # 块之间的重叠字符数，避免语义被割裂 length_function=len, ) split_docs = text_splitter.split_documents(all_docs) print(f"原始文档数：{len(all_docs)}， 分割后块数：{len(split_docs)}")

实操心得：chunk_size和chunk_overlap是超参数，需要根据你的文档类型和模型上下文窗口调整。
chunk_size：一般设置在500-1500之间。技术文档可小些（800），叙述性文章可大些（1200）。Bedrock Claude的上下文窗口很大（如100K），但检索时我们只取top-k个块，所以单个块不宜过大，要保证信息密度。
chunk_overlap：通常设为chunk_size的10%-20%。这是防止一个完整的句子或关键概念被切到两个块边缘的“缓冲带”，对保证检索上下文连贯性至关重要。
测试方法：随机采样一些分割后的块，人工阅读，检查是否保持了语义完整性。一个糟糕的分割会把一个问题描述和它的答案分到两个块里。

#### 3.2.2 向量嵌入与存储

我们将使用Bedrock的Titan Embeddings模型将文本块转化为向量。

import boto3 from langchain.embeddings import BedrockEmbeddings from langchain.vectorstores import OpenSearchVectorSearch # 初始化Bedrock客户端和嵌入模型 bedrock_runtime = boto3.client(service_name='bedrock-runtime', region_name='us-east-1') embeddings = BedrockEmbeddings( client=bedrock_runtime, model_id="amazon.titan-embed-text-v1" # 使用Titan Embeddings模型 ) # OpenSearch Serverless 连接配置 opensearch_endpoint = "your-collection-endpoint.us-east-1.aoss.amazonaws.com" # 替换为你的dashboardUrl index_name = "rag-index" # 创建向量存储并批量插入文档 # 注意：首次运行，这会创建索引并插入所有文档，耗时较长 vector_store = OpenSearchVectorSearch.from_documents( documents=split_docs, embedding=embeddings, opensearch_url=f"https://{opensearch_endpoint}:443", http_auth=None, # Serverless使用IAM认证，这里留空，依赖boto3的凭证 use_ssl=True, verify_certs=True, connection_class=requests.aws4auth.AWS4Auth, # 关键：使用IAM签名 index_name=index_name, engine="faiss", # OpenSearch Serverless 推荐使用 faiss 引擎 vector_field="embedding", text_field="text", )

踩坑记录：认证问题连接OpenSearch Serverless时，最大的坑是认证。不能使用传统的用户名密码，必须使用AWS Sigv4签名。OpenSearchVectorSearch的http_auth参数需要传入一个requests_aws4auth.AWS4Auth对象。确保你的环境（如Lambda、EC2或本地配置了AWS CLI）有正确的IAM凭证。如果遇到403错误，十有八九是这里的问题。

3.3 检索与生成链的组装

文档入库后，我们就可以组装核心的问答链了。

from langchain.llms import Bedrock from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate # 1. 初始化LLM（这里使用Claude Instant，速度快，成本低） llm = Bedrock( client=bedrock_runtime, model_id="anthropic.claude-instant-v1", model_kwargs={ "max_tokens_to_sample": 3000, "temperature": 0.1, # 低温度，让答案更确定、更基于上下文 "top_p": 0.9, } ) # 2. 定义提示模板 - 这是控制LLM行为的关键！ prompt_template = """ Human: 请仅根据以下提供的上下文信息来回答问题。如果上下文信息不足以回答问题，请直接说“根据提供的信息，我无法回答这个问题”，不要编造信息。 上下文： {context} 问题：{question} 请用中文提供详细、准确的答案。如果答案涉及步骤或列表，请清晰地列出。 Assistant: """ PROMPT = PromptTemplate( template=prompt_template, input_variables=["context", "question"] ) # 3. 初始化检索器 # 这里使用向量存储自带的.as_retriever()方法，可以配置搜索参数 retriever = vector_store.as_retriever( search_type="similarity", # 相似度搜索 search_kwargs={"k": 5} # 检索最相似的5个文本块 ) # 4. 组装检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", # “stuff”模式将检索到的所有上下文塞进提示，简单直接 retriever=retriever, chain_type_kwargs={"prompt": PROMPT}, return_source_documents=True # 非常重要！返回源文档用于溯源 ) # 5. 进行查询 query = "我司最新的差旅报销政策是什么？" result = qa_chain({"query": query}) print("答案：", result["result"]) print("\n--- 来源文档 ---") for i, doc in enumerate(result["source_documents"]): print(f"[来源{i+1}] {doc.metadata.get('source', 'N/A')} - 片段: {doc.page_content[:200]}...")

4. 高级优化与效果提升技巧

基础流程跑通只是第一步。要让RAG系统真正可用、好用，还需要一系列优化。

4.1 检索优化：从“相似”到“相关”

单纯的向量相似度搜索有时会失灵，比如查询“怎么申请假期”，可能检索到的是“年假制度历史沿革”而不是“假期申请流程”。

#### 4.1.1 混合搜索（Hybrid Search）结合关键词搜索（BM25）和向量搜索，取长补短。OpenSearch支持配置混合搜索。在LangChain中，可以配置retriever的search_type为"similarity_score_threshold"并组合其他条件，或者使用更高级的SelfQueryRetriever（需要元数据过滤）。更直接的方式是利用OpenSearch的复合查询DSL。

# 示例：在创建vector_store时，可以后续通过自定义查询来实施混合搜索 # 但LangChain对OpenSearch Serverless的混合搜索封装有限，有时需要直接使用OpenSearch Python Client from opensearchpy import OpenSearch, RequestsHttpConnection from requests_aws4auth import AWS4Auth # 建立直接连接 auth = AWS4Auth(...) # 配置你的认证 client = OpenSearch( hosts=[{'host': opensearch_endpoint, 'port': 443}], http_auth=auth, use_ssl=True, verify_certs=True, connection_class=RequestsHttpConnection ) # 构建混合查询DSL hybrid_query = { "query": { "hybrid": { "queries": [ { "match": { "text": {"query": query, "boost": 0.3} # 关键词查询，权重0.3 } }, { "knn": { "embedding": { "vector": query_embedding, # 需要先获取查询的向量 "k": 5 }, "boost": 0.7 # 向量查询，权重0.7 } } ] } } } response = client.search(index=index_name, body=hybrid_query)

#### 4.1.2 查询重写与扩展在将用户查询送入向量数据库前，先对其进行优化。例如，使用一个轻量级LLM（如Claude Haiku）对原始查询进行同义改写或问题分解。

改写：“报销咋弄？” -> “差旅费用报销的具体流程和所需材料是什么？”
分解：“介绍一下项目A的架构和部署步骤” -> 分解为“项目A的架构是什么？”和“项目A的部署步骤有哪些？”两个子查询，分别检索后再综合。

这能显著提升检索的召回率（Recall）。

4.2 提示工程与上下文管理

检索到的上下文如何有效地交给LLM，同样影响最终答案的质量。

#### 4.2.1 超越“Stuff”：更智能的上下文处理模式我们之前用的chain_type="stuff"是最简单的，把所有上下文拼在一起。如果检索到的文档总长度超过模型上下文限制，就会失败。还有两种更高级的模式：

map_reduce：先将每个检索到的文档单独生成一个答案（Map），再将这些答案汇总成一个最终答案（Reduce）。适合处理大量文档，但成本高，可能丢失细节。
refine：迭代处理文档。用第一个文档生成初始答案，然后用后续文档不断去“精炼（Refine）”这个答案。能产生连贯、深入的答案，但速度慢。

对于大多数问答场景，stuff模式配合合理的chunk_size和k值已经足够。如果文档块很多，可以考虑使用refine。

#### 4.2.2 元数据过滤在存储文档时，可以附加元数据，如{“source”: “员工手册.pdf”, “page”: 12, “department”: “HR”}。在检索时，可以要求只检索特定来源、特定部门的文档，实现更精准的答案。在创建retriever时，可以传入一个search_kwargs包含过滤器：

retriever = vector_store.as_retriever( search_kwargs={ "k": 5, "filter": {"term": {"metadata.department": "Engineering"}} # 只检索工程部的文档 } )

4.3 评估与迭代：没有度量，就没有改进

如何知道你的RAG系统好不好？不能只靠感觉。

人工评估（黄金标准）：构建一个测试集，包含50-100个真实用户可能问的问题，并准备好标准答案或期望的答案要点。定期运行测试集，人工评判答案的准确性（是否基于上下文）、完整性（是否回答了问题的所有部分）和有用性。
自动评估指标：
- 检索相关性：计算检索到的Top-k文档中，有多少是真正相关的（需要人工标注）。
- 答案忠实度：生成的答案有多少内容是基于检索到的上下文的，而不是LLM自己编造的。可以用另一个LLM来判断。
- 答案相关性：生成的答案与问题的匹配程度。
A/B测试：如果你有用户流量，可以部署两个不同版本（例如，不同的chunk_size或不同的提示模板），通过用户反馈或对话完成率来评估哪个更好。

5. 生产环境部署与运维考量

将原型部署为7x24小时可用的服务，还需要考虑更多。

5.1 架构设计：Serverless与微服务

一个典型的生产架构可能如下：

前端：一个Web应用（如React）或聊天界面。
API层：使用Amazon API Gateway接收用户查询。
业务逻辑层：使用AWS Lambda函数（Python）来承载我们上面编写的LangChain RAG链。Lambda无服务器，自动伸缩，按调用付费，非常适合这种间歇性、有波动的AI工作负载。
向量数据库：Amazon OpenSearch Serverless，如前所述。
模型服务：Amazon Bedrock，全托管。
文档更新管道：当有新文档加入时，可以触发一个Lambda函数或使用AWS Glue作业，自动执行文档加载、分割、向量化并更新OpenSearch索引。这个管道可以由Amazon S3（存放原始文档）的PUT事件触发。

5.2 成本监控与优化

Bedrock成本：主要来自Token消耗。区分输入Token和输出Token费用。Claude Instant比Claude 3便宜很多。在满足需求的前提下，选用性价比高的模型。监控Bedrock的CloudWatch指标和成本分析报告。
OpenSearch Serverless成本：分为计算单元（OCU）费用和存储费用。计算单元根据搜索和索引的流量自动伸缩。优化检索逻辑，避免不必要的查询；设置合理的索引生命周期策略，归档或删除旧数据。
Lambda成本：关注执行时间和内存配置。优化代码性能（如缓存嵌入模型结果），选择合适的内存大小（CPU性能随内存增加而提升，可能反而降低总成本）。

5.3 安全与权限

最小权限原则：为Lambda函数、Glue作业等分配仅需的最小IAM权限。
网络隔离：将Lambda、OpenSearch部署在私有子网，通过VPC端点访问Bedrock，避免数据在公网传输。
数据加密：确保OpenSearch集合启用加密（默认启用AWS托管密钥）。Bedrock的传输和静态数据加密由AWS负责。
访问控制：API Gateway可以配置API Key、Cognito用户池或JWT授权，控制前端对后端API的访问。

5.4 监控与告警

利用Amazon CloudWatch：

应用指标：在Lambda代码中记录自定义指标，如查询延迟、检索文档数量、LLM响应时间、每次查询的Token消耗。
业务指标：记录每日问答次数、热门问题、无法回答（“我无法回答”）的比例。
设置告警：当错误率升高、平均延迟超过阈值或成本异常时触发告警。

6. 常见问题与故障排查实录

在实际搭建和运行中，你几乎一定会遇到以下问题：

#### 6.1 连接与认证问题

症状：ConnectionError,403 Forbidden当连接OpenSearch Serverless时。
排查：
1. 检查IAM角色权限：角色必须附加正确的数据访问策略。
2. 检查网络策略：确保你的调用源IP或VPC在允许范围内。
3. 检查AWS凭证：在Lambda中确保执行角色正确，在本地确保aws configure配置正确，且具有有效期内的临时令牌（如果使用SSO等）。
4. 检查代码中的端点（Endpoint）是否正确，是否包含https://前缀和端口443。

#### 6.2 检索效果不佳

症状：LLM回答“根据提供的信息，我无法回答这个问题”，或者答案明显与文档无关。
排查：
1. 检查检索结果本身：打印出result[“source_documents”]，人工查看检索到的文本块是否真的与问题相关。如果不相关，问题在检索阶段。
2. 调整文本分割：尝试减小chunk_size，增加chunk_overlap。检查分割是否破坏了句子结构。
3. 调整检索数量：增加search_kwargs={“k”: 5}中的k值，比如到8或10，提供更多上下文。
4. 检查嵌入模型：尝试不同的嵌入模型（如amazon.titan-embed-text-v2，如果可用）。确保查询时使用的嵌入模型与建索引时是同一个。
5. 尝试混合搜索：如果查询中包含具体名称、代号，开启关键词搜索可能会有奇效。

#### 6.3 LLM答案质量差或出现幻觉

症状：答案模糊、答非所问，或开始编造不存在的信息。
排查：
1. 强化提示词：在提示模板中明确强调“仅根据上下文”，并使用更严厉的语气，如“如果上下文没有明确提及，你必须回答‘我不知道’”。
2. 降低Temperature：将LLM的temperature参数设为0.1或更低，减少随机性。
3. 检查上下文是否充足：可能检索到的文档块信息量不足。尝试优化检索（见上一点），或者考虑在索引阶段，除了存储文本块，还存储其摘要或相邻块，以提供更丰富的背景。
4. 启用源溯源：务必设置return_source_documents=True，并在前端展示答案来源。这不仅能增加可信度，也能帮你快速定位是哪个文档块导致了错误信息。

#### 6.4 性能与延迟问题

症状：查询响应时间过长（如>10秒）。
排查：
1. 分阶段计时：在代码中记录嵌入查询、向量检索、LLM生成各阶段耗时。
2. 向量检索慢：检查OpenSearch Serverless集合的OCU配置是否过小；检查k值是否过大；考虑对向量索引使用HNSW算法（如果OpenSearch版本支持并已配置）。
3. LLM生成慢：尝试换用更快的模型（如Claude Instant v1）；减少max_tokens_to_sample，限制答案长度。
4. Lambda冷启动：如果使用Lambda，冷启动时加载LangChain和模型客户端可能很慢。可以考虑使用Lambda Provisioned Concurrency（预置并发）或使用容器镜像部署以包含依赖，减少冷启动时间。也可以将嵌入模型客户端放在Lambda函数外部初始化。

搭建一个高质量的RAG系统是一个持续迭代的过程，没有一劳永逸的“银弹”。从基础的流水线搭建，到持续的检索优化、提示工程和效果评估，每一步都需要根据你的具体数据和业务需求进行精细调优。这个基于AWS全托管服务的方案，为你提供了一个稳定、可扩展的起点，让你能将更多精力集中在业务逻辑和效果提升上，而不是基础设施的运维泥潭中。