1. 引言
检索增强生成（Retrieval-Augmented Generation, RAG）已成为提升大语言模型（LLM）内容生成准确性的关键策略，可有效对抗幻觉和其他不准确现象。为了实现 RAG 的高效扩展，必须构建合适的数据架构。数据流方法为此提供了坚实的基础，确保 LLM 能够持续接收丰富、可靠的数据，从而生成精确的结果。此方法还促进了数据与应用团队的独立运作与扩展，加速了创新的步伐。
诸如 GPT 和 Llama 等基础性 LLM，虽然在广泛的主题上能够生成合理的回应，但它们也会产生内容错误。正如 Forrester 所指出，公共 LLM 常常因为依赖公开的互联网数据而产生不相关或错误的结果。此外，这些模型忽略了存储在客户数据库、ERP 系统、公司 Wiki 和其他内部数据源中的公司数据。为了提高准确性并释放商业价值，公司必须整合这些未被利用的数据。
RAG 使得数据团队能够将提示（Prompt）与公司特定领域的数据实时关联，为 LLM 提供了额外的背景信息。这种增强的上下文感知能力，使得 LLM 更有可能在数据中识别正确的模式，从而提供准确、相关的响应。这对于企业关键用例，如语义搜索、内容生成或智能辅助等，至关重要，因为这些应用场景要求输出必须基于精确且最新的信息。
2. 直接在公司特定数据上训练 LLM 的挑战
在 GenAI 领域，创建基础模型（foundation model）的黄金标准是通过训练具有数十亿参数的 Transformer 模型，这通常需要巨大的计算资源和成本。例如，OpenAI 曾透露，训练 GPT-4 的成本超过 1 亿美元。尽管小语言模型和成本较低的训练方法的研究取得了初步成果，但这些方法尚未成熟到能够广泛推广和商业化。微调（fine-tuning）现有模型是一种资源密集度较低的替代方案，但需要深入的专业知识来确保正确实施。
LLM 的民主化优势在于它们为广泛的用户提供了 AI 技术的访问。然而，如果需要聘请一个由博士组成的专家团队来微调模型，这种优势就会大打折扣。
RAG 提供了一个平衡的解决方案，但必须谨慎实施，确保提供准确和最新的信息，并且能够在不同应用程序和团队之间扩展。为了理解为什么事件驱动的架构是这种情况的最佳选择，我们需要了解 GenAI 应用程序开发的四种模式。
2.1 数据增强（Data Augmentation）
数据增强要求应用程序能够提取相关上下文信息，通常通过向量数据库检索编码在文本中的语义相似信息来实现。这涉及到从多个数据源聚合数据，并将其划分为可管理的、保留原始意义的块。这些数据块随后被嵌入到向量数据库中，以便与提示结合使用。
事件驱动的架构在此过程中发挥着关键作用，因为它能够实时地从企业的不同数据源集成信息，确保提供给 LLM 的信息是可靠和及时的。传统的 ETL 管道，依赖批处理操作，往往会导致信息过时。事件驱动架构确保了对操作数据存储的任何更改都能及时反映到向量存储中，从而用于上下文化的提示。将数据组织为流数据产品还提高了可重用性，使得数据转换可以作为可组合的组件，支持多个 LLM 应用程序的数据增强。
代码示例：数据分块与嵌入
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
# 初始化文本分割器
splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
separators=["\n\n", "\n", ".", " "]
)
# 模拟文档加载
raw_text = "这是一段关于公司内部政策的重要文档..."
docs = splitter.create_documents([raw_text])
# 生成嵌入向量
embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2")
vector_store.add_documents(docs, embeddings=embeddings)
2.2 推理（Inference）
推理过程涉及使用前几步准备的数据来精心设计提示，并处理 LLM 的响应。当用户输入提示时，应用程序会从向量数据库或类似服务中收集相关上下文，以生成最佳响应。
应用程序如 ChatGPT 通常需要几秒钟来生成响应，这在分布式系统中是一个显著的延迟。事件驱动的方法允许这种通信在服务和团队之间异步进行。在事件驱动的架构中，服务可以基于功能进行分解，使得应用开发团队和数据团队可以独立工作，优化性能和准确性。
此外，通过采用分解的专用服务而非单体服务，这些应用程序可以独立部署和扩展。这有助于缩短产品上市时间，因为新的推理步骤可以作为消费者组快速实例化，组织也可以模板化基础设施以加速这些步骤的实现。
代码示例：动态提示构建
import os
from langchain.prompts import PromptTemplate
# 定义提示模板
template = """根据以下上下文回答问题：
上下文：{context}
问题：{question}
回答："""
PROMPT = PromptTemplate(template=template, input_variables=["context", "question"])
# 执行推理
response = llm.predict(prompt=PROMPT.format(context=retrieved_context, question=user_query))
2.3 工作流（Workflow）
在复杂的任务自动化中，推理代理和步骤常常以序列的形式相互链接，后续的 LLM 调用依赖于前一个响应。这种方法对于完成多步骤过程至关重要，其中单一的 LLM 调用无法独立完成任务。此外，将问题分解为一系列简单问题，可以提高现代 LLM 的响应质量，尽管这一趋势正在逐步演变。
以下示例工作流展示了如何通过数据流平台实现 Web 开发团队与后端系统工程师的独立工作，每个团队可以根据特定需求进行扩展。数据流平台促成了技术、团队和系统之间的有效解耦。
在实际架构中，可以使用 Apache Kafka 或 Pulsar 作为消息总线。当用户提交请求时，触发一个事件，该事件被路由到不同的微服务进行处理。例如，一个服务负责检索，另一个负责生成，第三个负责合规检查。这种松耦合设计允许团队并行开发和测试各自的组件。
2.4 后处理
尽管我们采取了预防措施，LLM 可能仍然产生不准确的结果。因此，我们必须建立一种机制来验证输出并执行业务规则，以避免潜在的错误造成影响。
通常，LLM 工作流和依赖项的变化速度远远快于业务规则的确定。在上述示例中，我们再次看到了数据流平台解耦的优势：合规团队可以独立于构建 LLM 应用程序的团队来定义规则，验证 LLM 输出的合规性。
后处理阶段可以包括正则表达式过滤、关键词黑名单匹配、以及人工审核队列。对于高风险场景，建议引入置信度评分机制，只有高置信度的结果才自动发布。
3. 技术栈推荐与实施建议
为了构建高效的 RAG 系统，选择合适的技术栈至关重要。以下是推荐的组件组合：
- 向量数据库：推荐使用 Milvus、Pinecone 或 Elasticsearch。它们支持高维向量检索和混合搜索。
- 消息队列：Apache Kafka 适用于高吞吐量的事件流处理，适合实时数据更新。
- 编排框架：LangChain 或 LlamaIndex 可用于简化 RAG 流程的开发。
- 模型服务：可以通过 vLLM 或 TGI 部署开源模型，降低推理延迟。
数据安全与治理
在企业环境中，数据隐私是首要考虑因素。实施 RAG 时需遵循以下原则：
- 权限控制：确保检索到的数据仅对授权用户可见。可以在检索层加入身份验证令牌。
- 数据脱敏：在嵌入之前，对敏感信息（如 PII）进行掩码处理。
- 审计日志：记录所有查询和生成的内容，以便追溯和合规审查。
4. 结论
RAG 是一个强大的工具，用于提升 LLM 的准确性，并使得生成式 AI 应用程序适用于企业场景。然而，RAG 并非万能钥匙。它需要配合恰当的架构和数据传输机制，使得团队能够在不重复造轮的情况下构建多个生成式 AI 应用程序，同时确保符合企业的数据治理和质量标准。
数据流模型是满足这些需求的最直接和高效的方法，它使团队能够充分发挥 LLM 的潜力，为企业创造新的价值。随着技术与业务的融合，人工智能技术正增强这一融合过程，有效利用 AI 的公司将在竞争中获得优势，通过 AI 增强和简化流程。
采用通用的运营模式来开发 RAG 应用程序，企业可以快速推出首个用例，同时加快后续交付速度，并降低成本。这种模式为企业在生成式 AI 领域的成功奠定了基础。通过合理的事件驱动设计和模块化架构，企业可以构建既灵活又安全的大模型应用生态。
