非结构化数据涵盖了电子邮件、PDF 文件、会议记录等多种形式，它们充斥在各个角落，却由于缺乏固定的格式，给传统的数据处理工具带来了巨大的挑战。而人工智能（AI）的出现，尤其是大型语言模型（LLMs），为解决非结构化数据的难题带来了新的希望。但在实际应用中，简单的检索增强生成（RAG）方法却存在诸多不足，无法满足复杂的生产级场景需求。本文将深入探讨这些问题，并详细阐述如何构建适用于生产环境的有效解决方案。
简单 RAG 为何行不通：深入剖析
RAG 作为 AI 领域的热门技术，将检索和生成相结合，理论上能够从大量数据中找到相关信息并生成答案。但在实际应用中，它存在着诸多局限性。
实际案例 1：缺乏上下文和精确性
假设在研究论文和报告的语料库中搜索 “具有战略领导经验的可再生能源专家”。简单的 RAG 系统可能会检索到包含 “可再生能源” 和 “领导” 这两个词的文档，但很可能会忽略一些关键细节。如果一篇论文讨论的是 “可持续能源战略”，但没有直接使用 “可再生能源” 这个短语，RAG 系统就可能会遗漏这篇文档，因为它过度依赖词汇的相似性。更糟糕的是，大型语言模型在生成回答时，可能会在没有核实战略角度的情况下，将 “领导” 和 “项目管理” 混淆，从而给出模糊或错误的答案。
实际案例 2：可扩展性和延迟问题
当处理数百万份文档时，比如十年的客户反馈数据，简单 RAG 系统的问题就会更加凸显。由于向量相似性过于宽泛，它可能会检索到大量不相关的文本块，这不仅会拖慢响应时间，还会让大型语言模型在筛选信息时感到困惑。例如，当询问 “客户对产品可靠性有什么看法” 时，系统可能会返回数千个提到 “产品” 和 “问题” 的文本块，但其中很多可能是关于定价或运输延迟等无关话题的。这样一来，大型语言模型很难从中提取出有用的信息，导致回答不一致或不完整。
实际案例 3：缺乏控制和可解释性
在使用简单 RAG 时，用户往往对检索和生成的内容缺乏精细的控制。如果用户要求 “显示 2023 年讨论数据隐私的法律文件”，RAG 系统可能仅仅根据向量相似性来检索文档，忽略了 “日期” 和 “主题” 等关键结构化筛选条件。最终生成的输出可能只是一个通用的摘要，难以进行验证和审计，这对于受监管的行业来说是完全不可接受的。
正确的方法：适用于生产的蓝图
那么，如何构建一个能够超越简单 RAG 和简单 AI 聊天机器人局限性的生产级解决方案呢？这需要一个全面的方法，包括使用大型语言模型结构化数据、进行文本分块以提高效率、生成向量嵌入以理解语义，以及使用混合搜索引擎进行搜索。
利用 LLMs 和提示将非结构化数据转换为结构化洞察
首先要面对的挑战是将杂乱无章的非结构化数据转化为可用的形式。这就需要借助大型语言模型和精心设计的提示。用户可以将非结构化数据输入到大型语言模型中，这些模型可以在本地托管，也可以通过像 Hugging Face Inference 这样的平台进行访问。关键在于使用有针对性的提示来引导大型语言模型的输出。
例如，对于一系列研究论文，可以设计这样的提示：“从每份文档中提取以下内容：标题、作者、出版日期、摘要（不超过 200 字）以及关键主题。将输出格式化为每个类别都有相应字段的 JSON 格式。” 大型语言模型会根据对语言的理解，对每份文档进行处理，将相关信息识别并组织成结构化的字段。
对于更复杂的情况，如客户反馈或法律合同，提示可以进一步细化。假设处理客户电子邮件，可以设计这样的提示：“对于每封电子邮件，识别发件人、收件人、日期、情感（积极、消极、中性）、主要主题（如产品问题、账单问题）以及紧急程度（高、中、低）。将结果以结构化的 CSV 格式返回。” 大型语言模型的推理引擎会分析文本，利用其预训练的知识推断语义和关系，输出清晰的、机器可读的数据。
为了优化成本和性能，用户可以使用 RunPod、vLLM 或 SGLang 等工具来托管自己的大型语言模型。在进行初始批量加载时，可以在 RunPod 上部署 vLLM，一次性处理数千份文档，并使用连续批处理来最小化内存使用和成本。SGLang 的优化推理内核可以进一步加快令牌生成速度，确保即使是大型数据集也能高效地进行结构化处理。这样的方法使得用户可以在不依赖昂贵的云 API 的情况下扩展推理能力，非常适合生产环境。
一旦大型语言模型输出了结构化数据，如 JSON 或 CSV 文件，用户就有了进一步构建的基础。每份文档现在都有了相关的元数据（如 “标题”“日期”“主题”），可以通过分块和向量化进行进一步的丰富，以实现高级搜索。
在 Elasticsearch 中存储数据：为何它是正确的选择
有了结构化数据后，下一步就是存储和索引。Elasticsearch 作为一个分布式的、基于 RESTful 的搜索和分析引擎，基于 Apache Lucene 构建，非常适合处理这种情况。
Elasticsearch 具有先进的搜索功能。它原生支持基于关键词的 Query DSL 搜索、用于向量搜索的 k 最近邻（k-NN）算法，以及通过插件或自定义配置实现的混合搜索。这意味着用户可以同时查询结构化字段（如 “2023 年的文档”）和向量空间（如 “与可持续性语义相似的内容”），这是其他系统无法如此无缝实现的。
此外，Elasticsearch 的相关性排名和优化功能也很强大。它使用像 TF-IDF 和 BM25 这样的评分算法进行词汇搜索，使用余弦相似度或 L2 距离进行向量搜索，确保结果按相关性进行排名。它还能够通过互惠排名融合（RRF）等技术将这些方法结合起来，实现混合搜索，平衡精确性和上下文。
将自然语言查询转换为 DSL、混合和语义搜索
接下来，让我们看看用户如何与这个系统进行交互。目标是让用户能够用自然语言提问，比如 “给我展示具有战略经验的可持续性专家” 或 “查找去年讨论数据隐私的文档”，并获得精确、相关的结果。
用户通过界面（如 Web 应用程序或 API）输入查询，该界面会将自然语言提示传递给大型语言模型进行处理。大型语言模型可以通过 Hugging Face、RunPod 或类似的设置进行托管，它会解释查询并将其转换为搜索引擎能够理解的格式。例如，对于 “给我展示具有战略经验的可持续性专家” 这个查询，大型语言模型可能会将其分解为 “可持续性”（语义概念）、“专家”（角色或领域）和 “战略经验”（技能或上下文）等组件。
然后，系统会生成三种类型的查询，它们协同工作：
- 关键词驱动的 DSL 查询大型语言模型为 Elasticsearch 构建一个 DSL 查询，针对结构化字段进行搜索。对于上述示例，它可能生成 {"bool": {"must": [{"match": {"topic": "sustainability"}}, {"match": {"role": "expert"}}, {"match": {"skills": "strategic experience"}}]}}。这样可以确保在 “主题” 或 “技能” 等字段上进行精确匹配，为需要特定术语的用户提供精确性。
- 语义向量查询同时，大型语言模型或专门的嵌入模型（如 Sentence-BERT）会将查询转换为向量，然后在 Elasticsearch 中用于 k-NN 搜索。对于 “可持续性与战略经验”，该向量可能会找到讨论 “绿色能源战略” 或 “可持续领导力” 的文档，即使这些确切的短语没有出现，也会根据余弦相似度进行排名。
- 混合查询真正的强大之处在于将这两种查询结合起来。Elasticsearch 的混合搜索功能允许用户合并 DSL 和向量搜索的结果，并根据相关性对每个结果进行加权。例如，可以将 DSL 查询的权重设置为 0.6（以提高精确性），将向量查询的权重设置为 0.4（以提供上下文），然后使用 RRF 融合排名。这样可以确保既获得精确匹配（如明确标记为 “可持续性” 的文档），又获得相关概念（如 “环境战略”），实现两者的优势互补。
这些查询协同工作是因为它们各自利用了不同的优势。DSL 对于结构化数据的搜索快速且精确，向量搜索对于非结构化数据的洞察灵活且具有上下文感知，而混合搜索则弥补了两者之间的差距，在准确性和相关性方面进行了优化。大型语言模型就像是一个指挥家，确保自然语言查询被智能地解析并转换为正确的搜索组合，而 Elasticsearch 则快速、大规模地执行这些搜索。
整合所有环节以获得最佳结果
这种方法的美妙之处在于它的协同效应。用户通过提示大型语言模型来结构化数据、分块并生成嵌入，这些嵌入随后在 Elasticsearch 中进行索引，以便存储和搜索。当查询进来时，大型语言模型将其转换为 DSL、向量和混合搜索的组合，Elasticsearch 实时执行这些搜索，并根据相关性对结果进行排名。例如，当用户询问 “查找 2023 年关于数据隐私的法律文件” 时，可能会通过 DSL 匹配到 “2023 年” 和 “数据隐私”，通过向量匹配到相关术语（如 “GDPR”），并通过混合排名优先显示最具上下文相关性的文档。
这并非只是理论，而是一个适用于生产的蓝图。通过在像 RunPod 这样具有成本效益的平台上使用 vLLM 或 SGLang 托管大型语言模型，使用精确的提示来结构化数据，并利用 Elasticsearch 无与伦比的搜索能力，用户可以创建一个可扩展、安全且高效的系统。这不是关于快速修复或花哨的演示，而是关于构建在现实世界中真正有效的 AI，通过每次查询将非结构化数据转化为可操作的洞察。
