文章总结： 该文档详细阐述了RAG检索增强生成技术在AI安全平台中的工程实现，重点解决大模型在网络安全领域产生的幻觉问题。核心内容包括离线知识入库四步流程文档采集、文本切分、向量化和写入Milvus向量库，以及在线检索的查询向量化、相似检索和知识注入机制。文档还介绍了场景化检索接口设计、CVE知识图谱补充、Prompt工程优化等关键技术实践，并分析了RAG与微调技术的互补关系。 综合评分： 85 文章分类： 安全工具,技术标准,安全开发,AI安全,安全建设

让 AI 有据可查：RAG 检索增强与安全知识库的工程实现

河北镌远 河北镌远

河北镌远网络科技有限公司

2026年6月26日 15:00 河北

在小说阅读器读本章

去阅读

上一篇我们建立了对整个 AI 安全平台的全景认知，其中反复提到一个词：RAG。它被放在了 POC 生成、策略优化、AI 对话等几乎所有核心流程的中间环节。为什么一个看似「辅助」的检索步骤，会被摆在如此核心的位置？因为它解决的是大模型落地垂直领域时，最致命的一个问题——幻觉。       在闲聊场景里，大模型偶尔编造一点内容无伤大雅。但在网络安全场景里，一个被「编造」出来的 POC、一条凭空想象的防护规则，轻则误判漏洞、浪费排查时间，重则误伤生产系统、甚至引导工程师做出错误的安全决策。这一篇，我们就来彻底讲透：平台是如何用 RAG 给大模型装上「事实安全带」的。

01

先搞懂：RAG 到底在解决什么

RAG，全称 Retrieval-Augmented Generation，检索增强生成。名字有点拗口，但思想其实非常朴素，可以用一个类比来理解。

把大模型想象成一个知识渊博但记性不太靠谱的专家。你直接问他问题，他可能凭「大概印象」回答，有时对、有时错。而 RAG 做的事，相当于在他回答之前，先递给他几页与问题高度相关的权威资料，让他「照着资料」回答。这样一来，答案的可靠性大幅提升。

落到工程上，RAG 把整个流程拆成两条独立的链路：一条是 离线的知识入库 链路，负责把安全文档处理成可检索的向量；另一条是在线的检索生成 链路，负责在用户提问时实时检索、注入、生成。我们先看整体架构图，再分别拆解这两条链路。

图 1：RAG 检索增强生成的离线入库与在线检索双链路

02

离线链路：知识是怎么「住进」向量库的

再聪明的检索，也需要先有一个被组织好的知识库。这条离线链路的目标，就是把杂乱的安全文档（CVE 公告、CTI 威胁情报、防护手册等），转化成机器可以高效检索的形式。它分为四步。

第一步：文档采集

知识的源头是各类安全文档。平台专门维护了一套 CVE 知识库（项目中的 cve-kgrag 模块），汇集了漏洞描述、受影响组件、利用技术、防护措施等结构化信息。此外还包括各类 CTI（Cyber Threat Intelligence，网络威胁情报）文档。这些原始资料是整个知识体系的「原材料」。

第二步：文本切分

一篇完整的漏洞公告可能有几千字，但用户的一次提问往往只关心其中某个片段。如果把整篇文档作为一个检索单元，检索的精度会很差——返回的内容里大部分是无关信息。所以需要先把长文档切成若干语义相对完整的 分片（Chunk）。切分的粒度是一门学问：太大则不精准，太小则丢失上下文。平台用专门的文本切分器来平衡这两者。

第三步：向量化（Embedding）

这是 RAG 最核心的一步。机器不理解文字，但它理解数字。Embedding（嵌入） 模型的作用，就是把一段文字转换成一个高维向量（在这个平台里是1024 维），让语义相近的文字，对应的向量在空间中也彼此靠近。平台使用Qwen3-Embedding 模型来做这件事，并对向量做了 L2 归一化处理——这样后续就能用简单的点积运算来计算余弦相似度，既快又准。

第四步：写入 Milvus 向量库

切好、向量化后的知识分片，连同它们的原文和元数据（CVE 编号、类型、来源等），一起写入 Milvus 向量数据库。Milvus 是一款专为海量向量检索设计的分布式数据库，支持百万级甚至更高规模的向量存储与毫秒级检索。平台对它做了不少工程优化，比如用 HNSW（分层可导航小世界图）索引来加速近邻搜索。

工程细节：为了避免每次请求都重新初始化嵌入模型，平台用「双重检查锁（DCL）」对 OllamaEmbeddingModel 做了单例缓存；底层的 HTTP 客户端则用 static 单例 + 10 连接的连接池，复用 TCP 连接、降低延迟。这些都是从「能跑」到「跑得快」的关键。

03

在线链路：一次检索的毫秒级旅程

知识入库是「一次性」的准备工作，而在线检索则是用户每次提问都会触发的实时流程。当你输入一个像「CVE-2024-1234」这样的查询时，系统在毫秒之间完成了下面这一连串动作。

查询向量化→ 相似检索 → 知识注入

首先，用户的查询会用同一个 嵌入模型（这点很关键，必须保证查询和知识用相同的向量空间）转换成 1024 维向量。然后，这个查询向量被送进 Milvus，执行向量相似检索，找出空间中距离最近的 TopK 条知识（默认取 5 条）。最后，这 5 条最相关的知识被拼接成「参考资料」，注入到给大模型的 Prompt 里。下面这张图，把「语义相近 = 空间距离相近」这件事画了出来。

图 2：向量相似检索原理——查询向量自动「吸附」到语义相近的知识簇

如图所示，「SQL 注入」「XSS 攻击」「命令执行」这三类知识在向量空间里各自聚成一簇。当一个关于 SQL 注入的查询向量进来时，它会自动落在 SQL 注入那一簇附近，最近的几条知识被检索出来——整个过程不需要任何关键词匹配，纯靠语义的空间距离。这正是向量检索相比传统全文检索的根本优势：它理解的是「意思」，而不是「字面」。

04

面向不同场景的检索接口设计

一个值得学习的工程实践是：平台没有把 RAG 做成一个「万能但模糊」的通用检索，而是针对不同业务场景，设计了专门的检索接口。因为 POC 生成需要的知识、策略优化需要的知识、WAF 规则生成需要的知识，侧重点完全不同。

  IRagRetrievalService.java · 场景化检索接口

// 为 POC 生成检索：聚焦漏洞原理与利用方式

String retrieveForPocGeneration(String vulnId, String vulnType);

// 为策略优化检索：聚焦防护模板与最佳实践

String retrieveForStrategyOptimization(

        String vulnType, String wafBrand, String currentContent);

// 为 WAF 规则生成检索：聚焦针对特定品牌的 Bypass 防护

String retrieveForWafPolicyGeneration(

        String vulnId, String vulnType, String wafBrand);

这种「场景化检索」的设计，本质上是把检索意图显式化了。同样是检索 SQL 注入相关知识，给 POC 生成时检索的是「怎么构造 payload 触发漏洞」，给策略优化时检索的是「怎么写规则防住这类 payload」。检索的查询语句、过滤条件、甚至 TopK 的取值都可以针对场景调优。这是 RAG 从「能用」走向「好用」的一个重要分水岭。

05

不止向量：CVE 知识图谱的补充

向量检索很强大，但它有一个固有局限：它擅长找「语义相近」的内容，却不擅长表达「精确的结构化关系」。比如「CVE-2024-1234 影响了哪些组件版本」「这个漏洞的利用需要哪些前置条件」——这类问题，答案是确定的关系，而不是模糊的相似。

为此，平台在向量检索之外，叠加了CVE 知识图谱。知识图谱用「实体 + 关系」的方式，把漏洞、受影响组件、利用技术、防护措施组织成一张网络。当向量检索找到相关漏洞后，知识图谱可以进一步补充它的结构化关联信息。两者结合，既有语义检索的「广度」（找到所有相关的），又有图谱的「精度」（厘清确切的关系）。

向量检索回答「什么和它像」，知识图谱回答「它和什么有关」。前者负责召回，后者负责厘清。两套机制互补，构成了平台知识层的双引擎。

06

RAG 注入的「最后一厘米」：Prompt 工程

检索到的知识，最终要通过 Prompt 才能影响大模型的输出。这「最后一厘米」同样讲究。如果只是简单地把检索结果一股脑塞进 Prompt，模型可能会忽略它、或者被无关信息干扰。平台在 Prompt 模板里，对 RAG 内容的位置、格式、以及「如何引用」都做了精心设计。

以 POC 生成为例，平台的 Prompt 把 RAG 检索结果作为明确的「参考内容」区块注入，并在系统指令里要求模型「优先基于参考内容生成，确保 payload 真实可靠」。同时，Prompt 还约束了输出格式——必须是纯 Python、必须包含漏洞原理说明、关键 payload、判断依据和使用示例。这种结构化约束，让 AI 的输出既有知识支撑，又符合工程规范。

  AiPromptTemplates.java · RAG 知识注入

// Prompt 中的 RAG 注入（简化示意）

String prompt = AiPromptTemplates.buildOriginalPocPrompt(

        vulnInfo,      // 漏洞基础信息（CVE 描述等）

        contentList    // RAG 检索到的参考知识列表

);

// 模板内部：将 contentList 作为「参考内容」区块，

// 并约束模型「优先基于参考内容、确保 payload 真实可靠」

07

一个容易被忽视的坑：检索质量决定一切

做 RAG 的人很快会发现一个真相：RAG 系统的上限，不取决于大模型有多强，而取决于检索有多准。如果检索回来的是一堆无关或错误的知识，再强的模型也会被带偏——这叫「Garbage In, Garbage Out」。所以平台在检索质量上下了不少功夫。

● 切分质量：分片要保持语义完整，避免把一个完整的攻击步骤切成两半。

● 向量一致性：查询和知识必须用同一个嵌入模型、同样的归一化方式，否则向量空间对不齐，检索结果就是噪声。

● TopK 调优：取太少可能漏掉关键知识，取太多会引入噪声并撑爆上下文窗口。平台默认取 5，并按场景微调。

● 元数据过滤：在向量检索的基础上，结合 CVE 编号、漏洞类型等元数据做精确过滤，进一步提升相关性。

08

深入一点：为什么是 1024 维，归一化又是什么

      前面反复提到「1024 维向量」和「L2 归一化」，这两个词对非算法背景的读者可能有点陌生，但理解它们对吃透 RAG 很有帮助，我们用大白话讲清楚。

维度 可以理解为描述一段文字「特征」的角度数量。1024 维，意味着嵌入模型从 1024 个不同的角度去刻画一段文字的语义。维度越高，能表达的语义细节越丰富，但计算和存储成本也越高。1024 维是当前主流嵌入模型在「表达力」和「成本」之间的一个常见平衡点——足够精细地区分网络安全领域里那些细微但关键的语义差异（比如「SQL 注入」和「NoSQL 注入」），又不至于让向量库不堪重负。

L2 归一化 则是把每个向量的「长度」统一缩放到 1，只保留它的「方向」。为什么要这么做？因为在判断两段文字语义是否相近时，我们真正关心的是它们的「方向」是否一致，而不是「长度」。做了归一化之后，计算余弦相似度（衡量方向夹角）就退化成了简单的点积运算——一个 CPU 极其擅长的操作。这是个典型的「用数学预处理换取运行时性能」的工程技巧：入库时多做一步归一化，换来的是每一次在线检索都更快。

高维向量 + 归一化 + 点积，这套组合让「语义相似度计算」既准确又高效。RAG 能做到毫秒级检索，背后正是这些不起眼的数学选择在支撑。

09

RAG 的边界：它不是银弹

讲了这么多 RAG 的好，也得客观地说说它的边界。RAG 很强大，但它不是解决大模型所有问题的银弹，了解它的局限同样重要。

● 知识库的天花板：RAG 只能检索到知识库里「有」的内容。如果某个最新漏洞还没被收录，再好的检索也变不出来。所以知识库的持续更新，和检索算法同样重要。

● 检索与生成的割裂：检索和生成是两个独立环节，检索到了正确知识，不代表模型一定会「好好用」它。这就是为什么 Prompt 工程要花大力气去约束模型「优先基于参考内容」。

● 上下文窗口的限制：检索到的知识要塞进模型的上下文窗口，窗口大小有限，不可能无限注入。这逼着我们在「召回更多」和「保持精炼」之间做权衡。

正因为有这些边界，平台才没有把宝全押在向量检索上，而是叠加了 CVE 知识图谱做结构化补充、用场景化接口提升检索意图的精确性、用精心设计的 Prompt 模板提高知识的利用率。这种「不迷信单一技术、多手段组合」的工程态度，才是让 RAG 真正可用的关键。

10

结语

      这一篇，我们把 RAG 从概念到工程实现完整走了一遍：它通过「离线入库 + 在线检索」两条链路，把零散的安全知识转化为可检索的向量，并在大模型生成之前注入相关知识，从根本上抑制了幻觉、提升了准确性。在此基础上，平台还用场景化检索接口、CVE 知识图谱、精心设计的 Prompt 模板，把 RAG 的效果推向了生产可用的高度。

如果说大模型是这个平台的「大脑」，那么 RAG + 知识库就是它的「记忆与查证能力」——它让 AI 的每一个安全结论，都能找到依据、经得起追问。下一篇，我们会把视角转向一个更具体的业务场景：WAF 安全策略的智能优化，看看 AI 是如何读懂一份防火墙配置，并给出可落地的改进建议的。

▍附：RAG 与微调，到底该怎么选

      做垂直领域 AI 时，几乎所有团队都会面对一个灵魂拷问：要让模型掌握领域知识，到底是该用 RAG，还是该微调（Fine-tuning）模型？这是个高频问题，借这篇收尾的机会，结合平台的实践谈谈我的理解。

微调 是把知识「焊进」模型的参数里。它的优点是，模型能内化领域的语言风格、思维方式和深层模式，回答更地道、更专业；缺点是成本高、周期长，而且知识一旦焊进去就「固化」了——新出现的漏洞、新更新的情报，没法实时进入模型，得重新训练才能更新。

RAG 则是把知识放在模型「外面」的知识库里，用的时候临时检索注入。它的优点是知识更新极其灵活——往知识库里加一篇新文档，下一秒就能被检索到，无需重新训练；缺点是它改变不了模型的「底层能力」，如果模型本身不懂安全，再好的检索也只是给了它资料，它未必读得懂、用得好。

一个精炼的判断标准：需要模型掌握「领域的思维方式和深层能力」，用微调；需要模型获取「会频繁更新的事实性知识」，用 RAG。二者不是单选题，而是最佳拍档。

平台的选择正是「两者都要」：用微调打造了专业的 GWHIGC-AI-WAF-POC 模型，让它具备扎实的安全领域底层能力；再用 RAG 接入持续更新的 CVE 与威胁情报知识库，让它随时掌握最新的漏洞事实。微调解决「懂不懂安全」的能力问题，RAG 解决「知不知道最新漏洞」的时效问题。这种组合，才是垂直领域 AI 落地的成熟范式，也是这一篇我们想留给你的最重要的一条经验。

免责声明：因传播、利用本公众号“河北镌远网络科技有限公司”所提供信息而产生的任何直接或间接后果及损失，均由使用者本人自行承担，本公众号及作者不承担任何责任。本公众号所发表内容中，凡注明来源的，版权归原出处所有；无法查证版权或未注明出处的，均来自网络并系转载，转载旨在传递更多信息，版权归原作者所有。若存在侵权情况，请联系小编，我们将第一时间删除处理。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：河北镌远网络科技有限公司 河北镌远 河北镌远《让 AI 有据可查：RAG 检索增强与安全知识库的工程实现》