RAG 实战 第二章：技术选型与架构设计

本章将介绍 RAG 应用的核心技术组件，并基于智能客服助手案例的需求进行技术栈的选择和整体架构的设计。我们将深入探讨 RAG 的三大核心组成部分——检索模块、生成模块和编排优化层——以及它们各自的关键技术。随后，我们将针对我们智能客服助手的实际需求，评估并选择适合的技术栈，最终勾勒出整个系统的宏观架构蓝图。

2.1 RAG 核心组件概述

检索增强生成（RAG）系统之所以强大，在于它巧妙地结合了信息检索的精准性与大型语言模型（LLM）的生成能力。要理解 RAG，我们首先需要拆解其核心的三个模块：检索模块、生成模块以及将两者有机结合并优化的编排与优化模块。

检索模块 (Retrieval)

检索模块是 RAG 的“眼睛”和“图书馆管理员”，它的核心任务是根据用户的查询，从庞大的知识库中快速、准确地找到最相关的信息片段（通常称为“上下文”或“证据”）。

• 向量数据库（Vector Database）：

  • 概念： 向量数据库是专门设计用来存储和高效检索**向量嵌入（Vector Embeddings）**的数据管理系统。向量嵌入是将文本（或其他数据类型，如图片、音频）通过机器学习模型（即 Embedding 模型）转换成的高维数值向量，这些向量能够捕捉原始数据的语义信息，使得语义相似的数据在向量空间中距离更近。
  • 作用： 在 RAG 中，知识库中的所有文档或文档片段都会被转换成向量并存储在向量数据库中。当用户发起查询时，查询本身也会被转换成向量，然后向量数据库通过计算查询向量与存储向量的相似度（例如余弦相似度），来快速找出语义上最接近的文档片段。
  • 向量数据库的概念源于对高维向量相似度搜索（Approximate Nearest Neighbor, ANN）的需求，随着深度学习和Embedding技术的发展而兴起。代表产品包括 Faiss (Facebook AI Similarity Search), Milvus, Weaviate, Pinecone, Qdrant 等。

• 索引构建（Indexing）：

  • 概念：

    索引构建是将原始文档数据处理成可供向量数据库高效检索的格式的过程。这通常包括：

    1. 文档加载： 从各种来源（PDF、Word、网页、数据库等）读取原始文档。
    2. 文本切分（Chunking）： 将长文档切分成大小适中、语义完整的片段。这是关键步骤，片段过大可能引入噪音，片段过小可能丢失上下文。
    3. 文本嵌入（Embedding）： 使用预训练的 Embedding 模型（如 Sentence-BERT, OpenAI Embeddings）将每个文本片段转换成高维向量。
    4. 向量存储： 将这些向量及其对应的元数据（如原始文档 ID、标题、页码等）存储到向量数据库中。

  • 索引是数据库和信息检索领域的核心概念，这里是将其应用到向量数据上。

• 查询扩展（Query Expansion）：

  • 概念： 在将用户原始查询发送给检索模块之前，通过添加同义词、相关概念、澄清语境或通过 LLM 生成假设性问题（HyDE, Hypothetical Document Embeddings）来丰富原始查询，以提高检索的召回率。
  • 作用： 用户的原始查询可能不够精确或完整，导致检索结果不理想。查询扩展可以帮助捕捉用户更深层次的意图，从而召回更相关的文档。
  • 查询扩展是信息检索领域的一个经典技术。在 LLM 时代，结合 LLM 能力的查询扩展（如 HyDE）则赋予了其新的活力。

生成模块 (Generation)

生成模块是 RAG 的“大脑”和“表达者”，它接收检索到的相关信息和用户的原始查询，然后利用其强大的语言理解和生成能力，合成出流畅、准确且符合语境的答案。

• 大语言模型 (Large Language Model, LLM)：
  • 概念： LLM 是基于海量文本数据训练的深度学习模型，能够理解、生成人类语言，并执行各种复杂的语言任务，如问答、摘要、翻译、代码生成等。
  • 作用： 在 RAG 中，LLM 扮演着“阅读理解者”和“答案生成器”的角色。它接收用户查询和检索到的上下文作为输入，然后根据这些信息生成最终答案。LLM 的能力直接决定了答案的质量、流畅性和逻辑性。
  • LLM 的发展始于 Transformer 架构的提出（Vaswani et al., 2017），并随着 GPT 系列 (OpenAI), BERT (Google), LLaMA (Meta), PaLM (Google) 等模型的涌现而爆发。
• 提示工程 (Prompt Engineering)：
  • 概念： 提示工程是设计和优化输入给 LLM 的“指令”（Prompt）的过程，以引导 LLM 产生预期输出的技术。一个好的 Prompt 能够清晰地指示 LLM 的角色、任务、所需的输出格式，并提供必要的上下文和示例。
  • 作用： 在 RAG 中，提示工程至关重要。你需要将用户的查询和检索到的相关文档巧妙地组合成一个 Prompt，清晰地告诉 LLM：“根据以下信息回答这个问题：[检索到的文档]，用户的问题是：[用户查询]。”同时，可以通过 Prompt 约束 LLM 的行为，例如要求它只依据提供的信息回答，若信息不足则明确告知。
  • 提示工程随着 LLM 的兴起而成为一门新兴的技能，是与 LLM 交互的关键。

编排与优化

编排与优化模块是 RAG 的“协调者”和“改进者”，它负责管理检索和生成流程，并在必要时引入更复杂的逻辑和反馈机制，以提升整个系统的性能和鲁棒性。

• RAG 链（RAG Chain）：
  • 概念： 指的是将检索、生成等多个步骤串联起来，形成一个端到端的处理流程。这通常包括：接收用户查询 -> 查询预处理 -> 检索相关文档 -> 构建 Prompt -> 调用 LLM 生成答案 -> 答案后处理。
  • 作用： RAG 链是 RAG 系统的工作流抽象。它定义了信息流转和处理的顺序，使得整个问答过程自动化。
  • 这一概念在 LangChain、LlamaIndex 等 RAG 框架中被广泛使用，用于构建和管理复杂的 LLM 应用。
• Agent 机制：
  • 概念： Agent 是指能够进行规划、使用工具、执行动作并观察结果，从而实现更复杂任务的 LLM 应用。在 RAG 场景中，Agent 可以根据任务需求动态选择是进行检索、调用特定 API、还是执行其他逻辑。通过构建有状态的、基于图的工作流，Agent 能够实现多轮对话、自我修正和复杂问题的分解。
  • 作用： 对于复杂问题，单一的检索和生成可能不足。Agent 机制允许 RAG 系统变得更加“智能”。例如，如果用户问一个需要实时数据的问题，Agent 可能会决定先调用一个外部 API 获取实时数据，然后再结合知识库进行检索和生成。LangChain 的 LangGraph 模块是实现这类复杂 Agent 行为的强大工具。
  • Agent 机制是 LLM 应用领域的一个前沿方向，旨在赋予 LLM 更强的自主性和解决问题的能力。
• 评估与微调（Evaluation & Fine-tuning）：
  • 概念：
    • 评估： 持续监控和衡量 RAG 系统的性能，包括检索的准确性、生成答案的事实一致性、流畅性以及业务指标（如第一章所述）。
    • 微调： 根据评估结果，对系统中的某个组件（例如 Embedding 模型或小型生成模型）进行有针对性的调整和优化，以提升整体表现。这可能包括调整切分策略、优化 Prompt、甚至对 Embedding 模型进行领域适应性微调。
  • 作用： RAG 系统不是一蹴而就的，需要持续的评估和迭代优化。通过评估发现问题，通过微调解决问题，从而不断提升系统的效果和用户满意度。
  • 评估和微调是机器学习项目生命周期中的标准实践，在 RAG 领域被应用于各个组件。

2.2 技术栈选择

在明确了 RAG 的核心组件之后，接下来的关键步骤是根据我们智能客服助手的商业目标和非功能性需求（如响应速度、准确性、可扩展性、安全性、成本等），来选择合适的技术栈。市面上有众多工具和框架，选择合适的组合能事半功倍。

向量数据库：Faiss, Milvus, Weaviate, Pinecone 等的对比与选择

向量数据库是 RAG 系统的基石，其性能直接影响检索速度和准确性。选择时需考虑以下因素：数据规模、查询延迟、部署方式（云服务 vs. 私有化）、成本、以及生态系统的成熟度。

针对智能客服助手案例的选择：

考虑到内部智能客服助手可能需要处理大规模的内部知识文档，并期望具备良好的可扩展性和较低的运维负担（特别是对于初创或中型团队），我们倾向于选择托管的云向量数据库服务（如 Pinecone）或易于部署的云原生开源方案（如 Weaviate）。

• 如果团队有足够的 DevOps 资源，且对数据主权有极高要求，或数据量极其庞大需要极致的成本控制，Milvus 或自部署 Weaviate 是不错的选择。
• 对于大多数企业，尤其是希望快速上线、减少运维压力的场景，Pinecone 或 Weaviate Cloud 是更优的选项。 它们提供了强大的扩展能力和便捷的管理界面，让我们能更专注于 RAG 本身的效果优化。

Embedding 模型：OpenAI Embedding, Sentence-BERT 等

Embedding 模型负责将文本转化为高维向量，其质量直接决定了检索结果的相关性。

• OpenAI Embedding (如 text-embedding-ada-002)：
  • 优势： 业界领先的性能，开箱即用，效果通常非常优秀，尤其是在通用领域。调用方便，成本相对可控。
  • 劣势： API 调用，数据可能需要出网，存在数据隐私和安全顾虑（尽管 OpenAI 有数据使用政策），且依赖于外部服务。
• 开源 Embedding 模型（如 Sentence-BERT 系列，E5，BGE）：
  • 优势： 可私有化部署，数据不出网，成本可控（只需承担推理资源成本），模型可针对特定领域进行微调（Fine-tuning），从而获得更高的领域匹配度。
  • 劣势： 性能可能略逊于顶级的闭源模型（但在特定领域微调后可能超越），需要自行部署和管理推理服务，可能需要 GPU 资源。
  • Sentence-BERT 论文：Reimers, N., & Gurevych, I. (2019). Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. arXiv preprint arXiv:1908.10084. E5 和 BGE 则是近年来在 MTEB（Massive Text Embedding Benchmark）等基准测试中表现优异的开源模型。

针对智能客服助手案例的选择：

考虑到智能客服助手处理的是公司内部知识库，数据通常具有领域特定性和一定的敏感性。

• 初期快速验证（POC）或对数据敏感度不高的场景，可以考虑 OpenAI Embedding，因为它能快速提供高质量的通用语义理解。
• 对于正式生产环境，且数据包含敏感信息，或希望在特定领域达到最佳效果，强烈建议选择 开源 Embedding 模型并进行私有化部署。虽然需要一些部署和微调的工作，但能提供更好的数据安全和领域适应性。例如，可以基于现有开源模型（如 BGE-large-zh 或 m3e-large 等中文优化模型）在公司内部文档上进行微调。

大语言模型：GPT 系列, LLaMA, Baichuan 等的选型策略

LLM 是 RAG 的“智慧大脑”，负责理解查询和检索到的上下文，并生成最终答案。LLM 的选择是成本、性能、安全和部署灵活性的权衡。

• 云端 API 服务（如 OpenAI GPT 系列, Anthropic Claude, 百度文心一言, 阿里云通义千问）：
  • 优势： 性能强大，开箱即用，无需维护，持续更新，支持高并发。
  • 劣势： 数据隐私与安全风险（数据需出网），成本累积高（按 token 计费，大规模使用可能非常昂贵），依赖外部服务稳定性。
• 私有化部署模型（如 Meta LLaMA 系列, 智源悟道 Baichuan, 清华 ChatGLM）：
  • 优势： 数据安全可控（数据不出网），成本可控（一次性投入硬件，推理成本固定），可进行私有数据微调以获得领域更佳性能，完全自主掌控。
  • 劣势： 部署和运维复杂，需要大量计算资源（GPU），模型性能可能不如顶级闭源模型（但差距逐渐缩小），需要专门团队进行模型管理和优化。
  • LLaMA 论文：Touvron, H., Lavril, T., et al. (2023). Llama 2: Open Foundation and Fine-Tuned Chat Models. arXiv preprint arXiv:2307.09288. Baichuan、ChatGLM 等为国内知名开源大模型。

针对智能客服助手案例的选择：

考虑到智能客服助手主要处理企业内部敏感知识，且长期运行，数据安全和成本可控性是核心考量。

• 推荐策略：优先考虑私有化部署的开源大语言模型。
  • 可以选择一个在中文语境下表现良好、社区活跃的开源模型，例如 Baichuan-2-13B-Chat 或 ChatGLM3-6B。这些模型参数量适中，能够在合理硬件配置下进行部署，并通过 RAG 获得强大的问答能力。
  • 通过私有化部署，可以确保所有敏感知识都在公司防火墙内流转，极大增强数据安全性。
  • 未来还可以根据实际需求对这些开源模型进行指令微调（Instruction Fine-tuning），使其更好地适应公司内部的语料风格和特定任务。
• 如果实在缺乏私有化部署的资源和能力，且公司对数据出网有明确的合规流程，则可以考虑国内厂商提供的企业级 LLM API 服务，例如百度文心一言企业版、阿里云通义千问企业版等，它们通常会提供更严格的数据安全和隔离承诺。但仍然需要评估其数据处理政策。

框架与库：LangChain, LlamaIndex, Transformers, LangGraph 等

这些框架和库极大地简化了 RAG 系统的开发过程，提供了模块化的组件和便捷的接口。

• LangChain：
  • 优势： 强大的链（Chains）和代理（Agents）概念，能够灵活组合 LLM、外部工具和数据源，构建复杂的应用逻辑。支持多种 LLM、向量数据库和文档加载器，生态系统非常丰富。
  • 劣势： 学习曲线相对较陡峭，抽象层级较高，有时调试复杂。
  • LangChain 是由 Harrison Chase 于 2022 年底创立并迅速流行起来的 LLM 应用开发框架。
• LlamaIndex：
  • 优势： 专注于数据摄取、索引和检索，在处理非结构化数据和构建知识库方面表现出色。提供了丰富的数据加载器和索引结构，更强调从数据到 RAG 的流程优化。与 LangChain 互补性强。
  • 劣势： 在复杂链式调用和 Agent 方面不如 LangChain 灵活。
  • LlamaIndex（原名 GPT Index）也是一个为 LLM 应用构建数据框架的开源项目。
• Transformers (Hugging Face)：
  • 优势： 提供海量的预训练模型（包括 LLM 和 Embedding 模型），以及用于模型加载、推理、微调的强大工具。是底层模型操作和研究的基石。
  • 劣势： 偏底层，直接用于构建完整 RAG 应用需要较多胶水代码。
  • Hugging Face 的 Transformers 库是机器学习社区中最受欢迎的自然语言处理库之一，由 Thomas Wolf 等人于 2019 年发布。
• LangGraph：
  • 优势： 作为 LangChain 的一个强大扩展，LangGraph 专门用于构建有状态的、基于图的、可实现循环和多步决策的 Agent。 它使得 RAG 系统能够处理更复杂的交互逻辑，例如根据 LLM 的判断动态选择工具、多次检索、进行错误处理和自我修正等。对于需要高度自主性和复杂工作流的 AI 应用（如复杂的客服流程、数据分析 Agent），LangGraph 提供了强大的编排能力。
  • 劣势： 相对较新，学习曲线可能比基础的 LangChain Chain 更陡峭，对设计复杂状态图的能力有一定要求。
  • LangGraph 是 LangChain 团队在 2023 年末推出的一个新模块，旨在解决传统链式结构在复杂 Agent 场景中的局限性。

针对智能客服助手案例的选择：

为了高效开发并兼顾未来的扩展性，同时使用 LangChain 和 LlamaIndex 是目前业界的常见做法和推荐方案。

• 使用 LlamaIndex 来进行知识库的构建和管理： 负责文档加载、切分、Embedding 和索引到向量数据库的整个数据管道。它的数据抽象和索引优化能力非常适合构建高质量的知识库。
• 使用 LangChain 来编排 RAG 流程和实现更复杂的Agent逻辑： 负责接收用户查询、调用 LlamaIndex 进行检索、构建 Prompt、调用 LLM 生成答案，以及未来可能引入的多轮对话和工具调用。
• 使用 Hugging Face Transformers 来管理和加载私有化部署的 Embedding 模型和 LLM： 作为一个底层库，它能确保我们对模型有充分的控制。
• 对于需要更高级、更智能的代理行为时，可以引入 LangGraph： 例如，在多轮复杂问题解决、需要动态选择工具或进行自我修正的场景。

这种组合能够充分发挥各个框架的优势，构建一个既强大又灵活的 RAG 系统。

2.3 系统架构设计

在明确了 RAG 的核心组件和技术栈选择之后，我们需要将这些元素整合起来，形成一个完整的系统架构。本节将展示智能客服助手的整体架构图，并详细阐述各个模块的功能和交互方式。一个清晰的架构设计是系统稳定、可扩展和易于维护的基础。

智能客服助手整体架构图

为了更好地理解各个组件之间的关系，我们先来看一张智能客服助手的整体架构图（此处将以文字描述代替实际的图示，您在实际书籍中可以插入精心绘制的 Visio/Lucidchart 图）：

[用户界面/企业IM平台]
       |
       v
[API 网关 (Higress)]
       |
       +---------------------------------+
       |                                 |
       v                                 v
[后端服务 (Python/FastAPI/Flask)]    [AI 模型服务 (LLM & Embedding)]
       |                                 ^
       |                                 |
       +---------------------------------+
       |
       v
[知识库管理模块] <------------------> [向量数据库]
       ^                                 ^
       |                                 |
[数据摄取与预处理模块]                  [监控与日志系统]

核心交互流程：

1. 用户提问： 用户通过用户界面（如 Web 界面或企业内部 IM 平台，如企业微信、钉钉）发起问题。
2. API 网关： 用户请求首先通过 API 网关（Higress），进行身份验证、流量管理和 AI 特有处理。
3. 后端服务： 请求到达后端服务。后端服务是整个系统的业务逻辑核心，它编排 RAG 流程。
4. AI 模型服务（LLM & Embedding）：
   • 后端服务将用户查询发送给 AI 模型服务的 Embedding 部分，将查询向量化。
   • 向量化后的查询被发送给知识库管理模块，通过其与向量数据库交互，获取最相关的知识片段（上下文）。
   • 检索到的知识片段和用户查询被整合为 Prompt，发送给 AI 模型服务的 LLM 部分。
5. 答案生成与返回： LLM 利用其生成能力，基于 Prompt 生成最终答案。答案通过后端服务、API 网关返回给用户界面。
6. 知识库管理与数据摄取： 数据摄取与预处理模块负责收集、清洗、切分文档并生成向量，将其存入知识库管理模块，最终更新到向量数据库。这是一个独立的、异步的流程，确保知识库的时效性。
7. 监控与日志： 监控与日志系统贯穿所有模块，收集运行指标和事件日志，用于故障排查、性能优化和业务分析。

各模块功能详解

数据摄取与预处理模块

这是构建 RAG 知识库的第一步，也是一个持续运行的后台进程。

• 功能：
  • 文档加载器： 负责从各种数据源（如企业内部 SharePoint、Confluence、GitLab Wiki、本地文件系统、数据库、实时消息流等）加载不同格式（PDF、DOCX、Markdown、HTML、TXT 等）的原始文档。
  • 数据清洗与转换： 对加载的原始数据进行清洗（如去除无关字符、HTML 标签）、标准化格式、提取元数据（如文档标题、作者、发布日期、权限信息等）。
  • 文档切分（Chunking）： 将长文档切分成合适大小的语义单元。可采用固定大小切分、递归字符文本切分、或基于语义的切分策略。这是影响检索质量的关键环节。
  • 文本嵌入（Embedding）： 调用AI 模型服务中的 Embedding 部分，将切分后的文本片段转换为高维向量。
  • 增量更新与全量同步： 支持定期（如每日、每周）进行增量更新，只处理新增或修改的文档；也支持在特定情况下进行全量同步。
• 技术选型示例： Python 脚本、Celery/Kafka（用于异步处理和任务队列）、LangChain/LlamaIndex 的文档加载器和文本分割器。

知识库管理模块

这个模块负责管理向量数据库中的知识数据，并处理与元数据相关的操作。

• 功能：
  • 向量数据库接口： 提供与底层向量数据库（如 Pinecone, Weaviate）交互的抽象接口，负责向量的插入、删除、更新和查询。
  • 元数据管理： 存储和管理文档的元数据（例如，文档标题、URL、创建者、权限信息），这些元数据对于过滤检索结果和答案溯源至关重要。
  • 索引管理： 负责管理不同版本的索引，支持索引重建、备份和恢复。
• 技术选型示例： 封装向量数据库 SDK 的 Python 服务、独立的服务（如 gRPC 或 REST API）来处理与知识库相关的操作。

AI 模型服务（LLM & Embedding）

为了提高资源利用率和管理便利性，通常会将 Embedding 模型和 LLM 的推理服务部署为一个统一的 AI 模型服务。

• 功能：
  • Embedding 推理： 提供 API 接口，将输入的文本（用户查询或文档片段）转换为高维向量。
  • LLM 推理： 提供 API 接口，接收 Prompt 并返回生成好的答案。
  • 模型版本管理与负载均衡： 管理不同版本的模型，并根据负载情况进行流量分配。
• 技术选型示例：
  • 框架： Hugging Face Transformers、vLLM、TensorRT-LLM 等推理优化框架。
  • 部署： 基于 Docker 容器化，部署在 Kubernetes 集群上，利用 GPU 资源。
  • 模型： 私有化部署的开源模型（如 Baichuan-2, ChatGLM3）或通过 API 调用云服务商的 LLM。

后端服务

这是整个 RAG 系统的业务逻辑核心，负责编排 RAG 流程，并作为用户请求与底层服务的桥梁。

• 功能：
  • 请求处理： 接收来自 API 网关的用户查询。
  • RAG 流程编排：
    1. 调用 AI 模型服务进行查询向量化。
    2. 调用知识库管理模块在向量数据库中进行相似度搜索，获取最相关的知识片段。
    3. 将用户查询和检索到的知识片段构建成 Prompt。
    4. 调用 AI 模型服务的 LLM 部分生成最终答案。
  • 答案后处理： 对 LLM 返回的答案进行安全过滤、格式化等处理。
  • 多轮对话管理： 维护用户对话上下文，以便在后续轮次中提供更连贯的交互。对于复杂的、多步的 Agent 行为，可以利用 LangGraph 来编排其状态和决策流程。
• 技术选型示例： Python 语言，使用 FastAPI 或 Flask 框架，LangChain 或 LlamaIndex 库来编排 RAG 逻辑，对于复杂 Agent 可引入 LangGraph。

API 网关 (Higress)

作为所有外部请求的入口点，Higress 在这里扮演着至关重要的角色，它不仅提供基础的网关功能，更针对 AI 流量进行了优化。

• 功能：
  • 流量路由与负载均衡： 将用户请求路由到后端服务，并根据后端服务的状态进行智能负载均衡。
  • 身份认证与授权： 对用户请求进行身份验证，确保只有合法用户才能访问系统。
  • 限流与熔断： 保护后端服务，防止过载和级联故障。
  • Prompt 敏感信息擦除： 在请求转发给后端 LLM 服务前，自动识别并擦除用户 Prompt 中可能包含的敏感信息（例如个人身份信息、机密数据），大幅提升数据安全性和合规性。
  • AI 流量可观测性： 提供针对 LLM 请求的专属监控指标，如平均响应时间、Token 计数、请求成功率、错误率等，帮助团队更好地理解 AI 服务的运行状况和成本。
  • 流式传输支持： 原生支持 HTTP/2 和流式（Streaming）响应，确保 LLM 答案的实时、流畅返回，提升用户体验。
• 技术选型示例： Higress（基于 Envoy 和 Nginx），部署在 Kubernetes 或独立服务器上。

监控与日志系统

这是确保系统稳定运行和持续优化的重要组成部分。

• 功能：
  • Metrics 监控： 收集各模块的性能指标，如请求延迟、QPS（每秒查询数）、错误率、CPU/内存/GPU 利用率、向量数据库查询耗时等。
  • 日志记录： 记录所有关键操作和事件日志，包括用户查询、检索结果、LLM 调用详情、异常信息等，便于问题追踪和审计。
  • 告警系统： 根据预设阈值，在出现异常（如高错误率、低召回率、服务宕机）时及时发出告警。
  • 可视化仪表盘： 提供数据可视化界面，帮助运维人员和产品经理直观了解系统运行状况和业务趋势。
• 技术选型示例： Prometheus + Grafana（监控与可视化）、ELK Stack (Elasticsearch, Logstash, Kibana) 或 Loki + Grafana（日志管理与分析）。

通过上述模块的有机组合与协作，我们的智能客服助手将能够高效、准确、安全地为企业员工提供智能问答服务。