docs: 优化 RAG 和敏感词过滤文档，更新依赖版本

  - RAG 文档：移除重复标题，调整 ANN 段落位置，统一标点格式
  - 敏感词过滤：新增 AC
  自动机代码示例，补充生产实践建议（白名单、线程池、Unicode 注意事项）
  - 架构图从 SVG 格式更换为 PNG
  - 升级 vuepress-theme-hope 及相关插件到 rc.105/rc.127

Author: Snailclimb

docs/ai/rag/rag-basis.md

@@ -8,8 +8,6 @@ head:
       content: RAG,检索增强生成,LLM,知识库,Embedding,语义检索,向量检索,企业知识库
 ---
 
-# RAG 基础概念面试题总结
-
 去年面字节的时候，面试官问我：“你们项目里的知识库问答是怎么做的？” 我说：“直接调 OpenAI 的 API，把文档塞进去让模型自己读。”
 
 空气突然安静了三秒。我看到面试官的眉头皱了一下，才意识到事情不对——当时我们项目的文档有 20 多万字，每次请求都超 Token 上限，而且模型根本记不住上周刚更新的接口文档。

docs/ai/rag/rag-vector-store.md

@@ -8,8 +8,6 @@ head:
       content: RAG,向量数据库,向量索引,HNSW,IVFFLAT,pgvector,ANN,Embedding,相似度搜索
 ---
 
-# RAG 向量数据库面试题
-
 前段时间面某大厂的时候，面试官问我：“你们 RAG 系统的向量检索怎么做的？”，我说：“用 MySQL 存 Embedding，查询时遍历计算相似度。”
 
 空气突然安静了五秒。我看到面试官的嘴角抽了一下，才意识到问题大了——当时我们知识库有 50 多万条 Chunk，每次查询都要全表扫描，平均响应时间 3 秒+，用户早就跑光了。
@@ -94,24 +92,24 @@ RAG 知识库动辄几十万 ~ 亿级 Chunk，向量数据库支持**亿级向
 
 ![向量索引算法分类](https://oss.javaguide.cn/github/javaguide/ai/rag/rag-vector-index-algorithms.png)
 
-### 1. 精确最近邻（Exact Nearest Neighbor, ENN）算法
+当我们谈论向量索引时，绝大多数时候谈论的都是 **ANN 算法**。
+
+选择并调优一个合适的 ANN 索引，是决定 RAG 或向量搜索系统最终性能和成本的关键，带来的性能提升可以达到百倍甚至千倍以上。
+
+### 1. 精确最近邻（Exact Nearest Neighbor，ENN）算法
 
 - **目标：** 保证 **100%** 找到最相似的那个向量。
 - **代表：** 像 KD-Tree、VP-Tree 这类传统的空间树结构。
 - **问题：** 它们在低维空间（比如 10 维以内）效果很好，但在 AI 领域动辄几百上千维的**高维空间**中，它们的性能会急剧下降，遭遇**维度灾难**，最终退化成和暴力搜索差不多的效率。
 
-### 2. 近似最近邻（Approximate Nearest Neighbor, ANN）算法
+### 2. 近似最近邻（Approximate Nearest Neighbor，ANN）算法
 
 - **目标：** 这是现代向量检索的核心。它做出了一个非常聪明的**工程权衡**：**放弃 100% 的准确性，换取查询速度几个数量级的提升**。它不保证一定能找到那个最相似的，但能保证以极大概率（比如 99%）找到的向量，也已经足够相似了。
 - **代表：** 这类算法是现在的主流，主要有三大流派：
   - **基于图的（Graph-based）：** 如 **HNSW**。它把向量组织成一个复杂的多层网络图，查询时像导航一样在图上行走，速度极快，召回率非常高，是目前综合表现最好的算法之一。
   - **基于量化的（Quantization-based）：** 如 **IVF_PQ**。它通过聚类和压缩技术，把海量向量压缩成很小的数据，极大地降低了内存占用，非常适合超大规模的场景。
   - **基于哈希的（Hashing-based）：** 如 **LSH**。它通过特殊的哈希函数，让相似的向量有很大概率落入同一个哈希桶，从而缩小搜索范围。
 
-所以，当我们谈论向量索引时，我们绝大多数时候谈论的都是 **ANN 算法**。
-
-选择并调优一个合适的 ANN 索引，是决定一个 RAG 或向量搜索系统最终性能和成本的关键，带来的性能提升确实可以达到百倍甚至千倍以上。
-
 ## 有哪些向量索引算法？
 
 在向量数据库与 RAG（检索增强生成）应用中，索引算法直接决定了系统的召回率、响应延迟和资源消耗。
@@ -185,14 +183,14 @@ pgvector 0.5+ 的 HNSW 索引在执行元数据过滤时，采用**混合过滤
 
 **HNSW（图索引）**
 
-- **原理**：构建多层图结构。查询像在“高速公路”上行驶，先大跨度跳跃，再局部精细搜索
+- **原理**：构建多层图结构，查询像在“高速公路”上行驶，先大跨度跳跃，再局部精细搜索
 - **优点**：检索速度极快，召回率非常稳定且高
-- **缺点**：**“内存消耗大”**，除了原始向量，还要存储大量节点间的连接关系；索引构建非常慢
+- **缺点**：”内存消耗大”，除了原始向量，还要存储大量节点间的连接关系；索引构建非常慢
 
 **IVFFLAT（倒排聚类）**
 
-- **原理**：利用 K-Means 将向量空间切分成多个“桶”。查询时先找最近的几个桶，只在桶内进行暴力搜索
-- **优点**：**“内存友好”**，结构简单，索引构建速度比 HNSW **快 4-32 倍**（取决于 `nlist` 参数和硬件）
+- **原理**：利用 K-Means 将向量空间切分成多个桶，查询时先找最近的几个桶，只在桶内进行暴力搜索
+- **优点**：内存友好，结构简单，索引构建速度比 HNSW **快 4-32 倍**（取决于 `nlist` 参数和硬件）
 - **缺点**：检索速度略慢于 HNSW（在高精度要求下）；如果数据分布改变，需要重新训练聚类中心
 
 | 特性           | HNSW（图索引）                     | IVFFLAT（倒排聚类）                 |

docs/database/redis/redis-stream-mq.md

@@ -218,6 +218,6 @@ sequenceDiagram
 
 我的 [《SpringAI 智能面试平台+RAG 知识库》](https://javaguide.cn/zhuanlan/interview-guide.html)项目就是用的 Redis Stream 作为消息队列。在我的项目的场景下，它几乎是最合适的选择，完全够用了。
 
-![系统架构](https://oss.javaguide.cn/xingqiu/pratical-project/interview-guide/interview-guide-architecture-diagram.svg)
+![系统架构图](https://oss.javaguide.cn/xingqiu/pratical-project/interview-guide/interview-guide-architecture-diagram.png)
 
 ![AI 智能面试平台效果展示](https://oss.javaguide.cn/xingqiu/pratical-project/interview-guide/page-resume-history.png)

docs/open-source-project/machine-learning.md

@@ -98,7 +98,7 @@ AgentScope 提供了 Python 和 Java 版本，二者核心能力完全对齐！
 
 > **提示**：架构图采用 draw.io 绘制，导出为 svg 格式，在 Github Dark 模式下的显示效果会有问题。
 
-![](https://oss.javaguide.cn/xingqiu/pratical-project/interview-guide/interview-guide-architecture-diagram.svg)
+![系统架构图](https://oss.javaguide.cn/xingqiu/pratical-project/interview-guide/interview-guide-architecture-diagram.png)
 
 ### AI 工作流编排系统