告别“知识孤岛”：RAG赋能网络安全运营-EW帮帮网

一、背景

在网络安全运营工作中，我们积累了大量的内部知识内容，涵盖了威胁情报、事件响应流程、安全策略、合规性要求等多个方面。然而，这些知识虽然数量庞大、内容丰富，却因形式多样、结构分散，难以让每一位成员真正掌握和熟练应用。尤其在安全事件发生时，往往面临“知道有知识却找不到”的尴尬局面，影响了问题的快速定位与处置效率。

这些知识大多以 Word、PDF、Excel 等格式零散存储，传统的信息检索方式不仅难以准确理解用户的查询意图，也很难从不同格式的文档中高效提取出有价值的信息，进一步加剧了知识利用的困难。

为了解决这一问题，我们倾向于采用以RAG（检索增强生成）为核心的技术路径，通过将内部知识库与大型语言模型深度集成，实现高效、可信的智能问答服务。让沉淀的安全运营经验在关键时刻快速“被看见、被理解、被用上”，显著提升知识获取效率与响应能力。

二、什么是 RAG

RAG，全称 Retrieval-Augmented Generation，中文可以翻译为检索增强生成。它是一种结合了信息检索和大型语言模型（LLM）生成能力的技术框架。

简单来说，RAG 的目的是让大型语言模型在回答问题时，不再仅仅依赖于它训练时所学习到的通用知识，而是能够实时地、有针对性地去查找和利用外部的、更准确、更具体、甚至是最新的信息，然后再结合这些信息来生成回答。

三、RAG和模型微调的区别？

微调：在已有的预训练模型基础上，再结合特定任务的数据集进一步对其进行训练，使得模型在这一领域中表现更好（微调是考前复习，模型通过训练，消化吸收了这些知识然后给你回复）。

RAG：在生成回答之前，通过信息检索从外部知识库中查找与问题相关的知识，增强生成过程中的信息来源，从而提升生成的质量和准确性。（RAG是开卷考试，模型看到你的问题，开始翻你的知识库，以实时生成更准确的答案）。

四、RAG 架构核心流程

RAG 架构主要分为两个阶段：索引（Indexing）阶段 和 查询（Querying/Generation）阶段。

4.1 阶段一：索引阶段

这个阶段是将内部知识转化为 RAG 系统可以高效检索的格式。在这个步骤中，其效果的好坏，取决于以下几个方面共同作用的成果，索引阶段可以说是RAG实现的最关键的一步：

数据本身的质量: 原始知识文档是否清晰、准确、没有太多噪声。
文本分块策略: 是否将有意义的上下文完整地保留在块中，避免割裂关键信息。糟糕的分块会导致即使嵌入模型很好也无法生成有代表性的块向量。
嵌入模型本身的质量: 它在您的特定领域数据上生成向量的能力。
向量数据库的选择和配置: 数据库的索引类型、参数设置、硬件资源等都会影响查询的效率和准确找到最近邻向量的能力。

主要步骤有以下组成：

1. 数据采集与预处理 (Data Acquisition & Preprocessing):

- 来源: 识别所有内部知识来源，例如：

- - 威胁情报报告 (内外部来源)
  - 事件响应 Playbooks/SOPs
  - 安全策略文档
  - 合规性要求文档 (如网络安全法、等保、数据安全法等)
  - 内部 Wiki/Confluence
  - 安全工具配置文档
  - 培训材料
  - 内部知识分享笔记
  - 特定脚本或代码片段 (针对自动化任务)

- 格式: 这些数据可能以各种格式存在：PDF, DOCX, Markdown, HTML, Wiki 页面，甚至非结构化的文本文件或数据库记录。
- 清洗: 移除不相关的文本（如页眉页脚、广告、代码块中的注释等），标准化文本格式，处理特殊字符。

2. 数据加载 (Data Loading):

这是构建 RAG 应用的起点，核心环节是利用连接器 (Connectors / Loaders) 从各种数据源（如本地文件、云存储、数据库、网页、API 等）读取并提取你的非结构化或半结构化内容。数据加载的质量和范围直接影响后续检索的效果。

3. 数据分割 (Data Splitting / Chunking):

将长文档分割成更小的、有意义的文本块 (Chunks)。这是因为嵌入模型和大模型通常有输入长度限制，且小的文本块更有利于精确检索。切片的目的是将大型文档分解成更小的、易于处理的块（Chunks），这些块将被嵌入并用于检索。理想的块应该包含足够的信息来回答一个潜在的问题，但又不能太大以至于超出 LLM 的上下文窗口或稀释嵌入的语义。具体策略如下：

a. 固定大小切片

工作原理：将文档简单地切分成固定字符数或 Token 数的块。通常会带有一个固定大小的重叠 (Overlap) 部分，以便块之间保留一些连续的上下文。
优点：实现简单，易于理解和控制。生成的块大小均匀，方便批量处理。
缺点：不考虑文本结构: 容易在句子、段落甚至表格、代码的中间被截断，破坏语义完整性。即使有重叠，也可能丢失跨块的重要上下文连接。检索时可能返回不完整的句子或信息片段，导致生成质量下降。
适合的知识类型：文本结构不那么重要、内容连续性较强的文档（但通常不是最优选择）。

b. 基于分隔符切片

工作原理：根据特定的分隔符（如换行符 \n、双换行符 \n\n、句号 .、问号 ? 等）来分割文本。可以按段落、句子、行等自然语言结构进行切分。只关心你指定的分隔符在哪里。它的主要目标是根据这些符号（如句号、换行符、段落标记等）来划分文本边界，从而尊重文本原有的结构单位（句子、段落等）。至于切出来的块有多长，它不强制控制。一个很长的段落就会被切成一个很长的块。
优点：尊重文本的自然结构（句子、段落），生成的块通常具有更好的语义完整性。避免在不恰当的位置截断文本。
缺点：块大小不均匀: 有些段落可能很短，有些可能非常长，一个超长的段落会形成一个大块，可能超出 LLM 的上下文窗口或影响嵌入质量。依赖于文本的格式和分隔符的规范性，对于格式不规范的文档效果可能不好。
适合的知识类型：结构清晰、段落/句子划分明确的文档，如书籍、文章、报告等。

c. 递归切片

工作原理: 这是目前许多 RAG 框架（如 LlamaIndex, LangChain）中推荐的默认方法。它使用一个分隔符列表（如 ["\n\n", "\n", ". ", " "]），并递归地尝试切分：首先尝试使用第一个分隔符切分，如果生成的块仍然太大，则对这些大块递归地使用列表中的下一个分隔符进行切分，直到块小于指定的最大大小或用完所有分隔符。通常也结合重叠使用。既要考虑分隔符（尽可能尊重结构），但更重要的是要保证最终的每个块的长度（或大小）不超过设定的上限。它会用优先级高的分隔符先切，如果切出来的块还是太大，就递归地使用优先级低的分隔符在那个大块内部继续切，直到块的大小满足要求。长度（大小）是它一个非常重要的约束条件。
优点：

- 结合了分隔符切片的优点（尊重结构）和固定大小切片的优点（控制最大块大小）。
- 能够更好地处理不同大小的文本单元，并尽可能保持语义单元的完整性。
- 比较鲁棒，能适应多种文本结构。

缺点：

- 比简单的固定大小切片略复杂。
- 最后的切分可能仍然基于空格等细粒度分隔符，可能在句子中间截断。

适合的知识类型：绝大多数类型的文本文档。它是一种非常通用的方法，通常是开始时的首选。

d. 基于文档结构的切片

工作原理：专门为特定格式（如 Markdown, HTML, JSON, Code）设计的切片器，它们理解文档的逻辑结构（如 Markdown 的标题、列表、代码块，HTML 的标签，JSON 的键值对结构，代码的函数、类）。
优点：

- 能够按照文档的逻辑单元进行切分，保留了原生格式的重要结构信息。
- 对于特定类型的数据（如代码、表格），能够生成非常相关的块。

缺点：

- 需要针对不同格式实现不同的解析器和切片逻辑。
- 不具有通用性。
- 一个结构单元（如一个巨大的函数）可能仍然太大，需要结合其他方法（如递归）在内部进行二次切分。

适合的知识类型：带有明确结构标记的文档: 代码文件 (.py, .java 等)、Markdown 文件 (.md)、HTML 文件、JSON 数据、表格数据等。

e. 基于语义/上下文的切片

工作原理：这是一种更高级的方法，它不完全依赖固定的规则或分隔符，而是尝试理解文本的语义内容和上下文流，将语义相关的句子或段落组合成块。可能使用句子的嵌入相似度、主题模型、或更复杂的语言模型分析来确定切分点。
优点：

- 生成的块具有高度的语义凝聚力。
- 理论上可以生成最有利于检索语义相关信息的块。

缺点：

- 实现非常复杂，需要依赖额外的语义分析步骤。
- 计算成本通常更高。
- 仍然是研究和发展的活跃领域，不如前几种方法成熟和易于实现。

适合的知识类型：内容复杂、语义关联性强的文档，如研究论文、技术文档、会议记录等，其中找到与查询相关的概念比找到精确的句子或段落更重要。

4. 嵌入 (Embedding):

将自然语言转换成计算机可以理解的高维向量，通过这个过程捕获到文本背后的语义信息，简单来说就是对上传的各类知识附件进行解析。
将文本（用户查询和知识库中的文本块/文档）转换成高维度的数值向量，捕捉其语义信息。这是实现向量相似度搜索的关键。计算机无法直接理解文本的含义，但可以处理数字。通过将文本转化为向量，我们可以利用数学方法（如计算向量之间的距离或相似度）来衡量文本之间的语义相似性。一个好的嵌入模型生成的向量，应该能够准确地捕捉到原始文本块的语义信息和上下文关系。也就是说，意思相近或相关的文本块，它们生成的向量在向量空间中的距离应该非常近；意思相差很大的文本，向量距离应该很远。
技术选型 (嵌入模型):

- gte (General Text Embeddings), bge (Baichuan Global Embeddings), 都是优秀的开源或可商用模型，在通用领域表现良好，且支持中文。
- 选择考虑:

- - 性能: 在您的特定安全知识数据上进行测试评估检索效果。
  - 语言支持: 如果知识库包含多种语言，需要选择多语言模型。
  - 模型大小与速度: 影响索引和查询的速度。
  - 成本: 调用 API (OpenAI, Cohere) 或自托管开源模型的计算资源成本。
  - 许可: 确保模型许可允许您的使用场景。

5. 索引与存储 (Indexing & Vector Store):

将生成的向量与对应的文本块及元数据 (来源文档、页码等) 存储起来，并构建索引以便快速检索。
技术选型 (向量数据库/存储):

- 独立向量数据库:Weaviate, Milvus, Pinecone, Qdrant, ChromaDB, Vald 等。这些是专门为向量相似度搜索设计，通常提供高性能、高可伸缩性以及丰富的过滤和搜索功能。

选择考虑:

- 数据规模: 预计的知识库大小。
- 查询性能: 需要的检索速度 (延迟)。
- 可伸缩性: 未来数据增长的预估。
- 成本与运维: 托管、维护成本和复杂性。
- 特性: 是否需要混合搜索 (向量+关键词)、过滤等高级功能。

4.2 阶段二：查询阶段

这个阶段是接收用户查询，检索相关信息，并生成回答。

1. 用户查询 (User Query):

- 用户输入自然语言问题，例如：“发生 DDoS 攻击时，我们的第一响应步骤是什么？” 或 “现在遇到钓鱼邮件，我应该如何处理？”

2. 查询嵌入 (Query Embedding):

- 使用与索引阶段相同的嵌入模型，将用户查询转化为一个向量。

3. 检索 (Retrieval):

- 使用查询向量在向量数据库中进行相似度搜索，找到与查询语义最相关的文本块。通常会检索 Top-K 个相似度最高的块。
- 检索策略:

- - 简单的相似度搜索
  - 最大边际相关性 (MMR - Maximum Marginal Relevance): 在相似度高的结果中，选择多样性更高的，避免返回大量内容高度相似的块。
  - 混合搜索 (Hybrid Search): 结合向量搜索和关键词搜索，可以提高检索的准确性和召回率。
  - 多跳检索 (Multi-hop Retrieval): 对于复杂问题，可能需要先检索信息A，然后用信息A作为新的查询去检索信息B。

4. 重排序 (Re-ranking):

将用户查询的原始文本和初步检索到的这个较长的候选片段列表（包含文本内容）输入到重排序模型。
重排序模型对列表中的每个片段进行更精细的相关性评估，并给出新的得分或排序。
从重排序后的列表中，选择最终需要发送给大模型的、数量更少、相关性更强的片段（例如 Top-5 到 Top-10）。
这个阶段是重排序模型的核心工作，它对初步检索结果进行精选。

5. 上下文构建 (Context Augmentation):

- 将检索到的文本块作为上下文信息，与原始用户查询一起输入给大模型。
- 通常会将检索到的多个文本块拼接起来，形成一个完整的 Prompt Context。需要注意控制总长度，不超过所选大模型的上下文窗口限制。

6. 生成 (Generation):

- 将构建好的 Prompt (用户查询 + 检索到的上下文) 输入给大模型，由大模型生成最终的回答。
- 技术选型 (大模型):

- - 推荐deepseek 、chatgpt、Anthropic Claude 、Google Gemini等模型。
  - 选择考虑:

- - - 性能: 生成回答的准确性、相关性、流畅性、是否能理解并利用提供的上下文。在安全领域的理解和生成能力。
    - 上下文窗口: 越大越好，可以容纳更多的检索结果。
    - 成本: API 调用费用或自托管的硬件/算力费用。
    - 速度: 生成回答的延迟。
    - 数据隐私与安全性: 对于内部敏感知识，是否能接受将数据发送给第三方 API (商业模型)，或者是否必须选择自托管模型。
    - 微调潜力: 未来是否需要针对特定安全术语或回答风格进行微调。

- 提示词工程: 精心设计 Prompt 模板，指导大模型如何利用上下文、如何回答问题、如何处理不确定性或矛盾信息。例如：

- - “请基于以下提供的安全知识内容，回答用户的问题。如果提供的知识中找不到相关信息，请说明知识库中未包含此信息。”
  - “用户问题：[用户查询]”
  - “安全知识内容：[检索到的文本块列表]”

7. 后处理与输出 (Post-processing & Output):

- 对大模型生成的文本进行可能的后处理（如格式化、去除冗余信息）。
- 将回答呈现给用户。
- 重要: 建议在回答中引用或链接到检索到的原始知识来源，增加答案的可信度和可追溯性。

五、实现方式

笔者在近几个月使用了多款RAG 工具，给我的感受是，尽管 RAG（检索增强生成）技术在理论上极具前景，并且已经取得了显著进展，但目前整个RAG的实现和应用仍然处于一个快速发展和不断探索的阶段，对于普通用户和企业而言，确实还存在一定的应用门槛，不够“开箱即用”和“足够智能”。这个问题的产生主要原因还是现实世界的知识库远比标准数据集复杂，数据的多样性使得“一刀切”的自动化方案难以奏效。

在这里我使用一个叫做RagFlow开源的检索增强生成（RAG）引擎，可以理解成是一个 RAG 的一站式的解决方案或平台，此平台不管是易用性还是前端界面，都较为友好，可以支持线上 Demo使用（RAGFlow），也可以本地化部署（GitHub - infiniflow/ragflow: RAGFlow is an open-source RAG (Retrieval-Augmented Generation) engine based on deep document understanding.）。