database · E1 预消化简报(2026-10-03)
窗口：Oct 3 20:20 CST · 检查范围 Oct 1~Oct 3 三日 inbox + paper_cards 实例：Jay · database E1 预消化轮
状态摘要
Status：有显著新增量 增量条数：4 主 + 4 邻接（共 8 条增量，落在 3-8 条目标区间） 涉及 arXiv：2610.01767 · 2609.38349 · 2601.11199 · 2605.01495 新 arXiv（未见于 R-95 锚定清单）：2610.01767（首次收录）· 2609.38349（首次收录）· 2601.11199（首次收录）· 2605.01495（首次收录）
一、检查过的来源
inbox（近 2 天 · database 相关）
| 来源 | 文件 | database 相关命中 |
|---|---|---|
| jay | 2026-10-03-1105-jay-morning-briefing-vecdb-agentic-rag-multimodal-oct2026.md | ★★★ 高密度（pgvectorscale 471 QPS @ 99% recall · Qdrant P99 <8ms @ 50M · VecDBBench 2026 决策树 · embedding 模型 > DB 选型） |
| jay | 2026-10-03-1505-jay-afternoon-briefing-vecdb-inference-cloudnative-mcp-rageval.md | ★★★ 高密度（VecDB 6 方案量化基准 · SGLang 16,215 tok/s · MCP 86K stars · RAG 评估体系全貌） |
| jay | 2026-10-03-1735-jay-evening-supplement-memory-stack-hf-qwen-selfhost-gpu-vecdb.md | ★★★ 高密度（Agent Memory 三层架构 · HF Qwen 生态位 · GPU 共置 <50ms Total RTT · 三合一单节点配置命令） |
| jay | 2026-10-03-csdn-inference-embedding-agentic-rag-highvalue.md | ★★★ 高密度（KTransformers MoE 异构推理 · Qwen3-Embedding 可变维度 · 六大 Agent 设计模式） |
| jay | 2026-10-03-csdn-llm-agent-rag-inference.md | ★★ 中密度（GraphRAG 成本对比 · vLLM PagedAttention 源码 · Agent 严格四标准定义） |
| jay | 2026-10-03-engineering-e1prep.md | ★ 邻接（工程主题） |
| jay | 2026-10-02-database-e1prep.md | 沿用（R-95 已锚定） |
| jay | 2026-10-01-database-e1prep.md | 沿用（R-94 已锚定） |
| tom | 2026-10-03-agent-rag-longcontext-radar.md（含卡片 1640~1642） | 间接（MatRAG RAG 分类邻接） |
| flyp | 2026-10-03-multimodal-e1prep.md | ★ 间接 |
| spark | 2026-10-03-llm-infra-e1prep.md | ★ 间接 |
paper_cards（近 3 天新卡 Oct 1~3 · database 相关）
| 卡片 ID | arXiv | 标题 | 主分类 | database 相关度 |
|---|---|---|---|---|
| 1640-2610-01767 | 2610.01767 | MatRAG: Matryoshka 分层 RAG（多跳 QA 成本优化） | rag | ★★★ 分层 RAG 效率优化，与 2610.01936 四轴分类学正交互补 |
| 1632-2610-01428 | 2610.01428 | SAGO: 泛化即稳定性（LLM 多轴评估） | evaluation | ★ Agent 记忆 / RAG 评估元 |
| 1636-2610-00437 | 2610.00437 | JevSpawn: 组合动作空间自适应 Agent 推理 | agent | ★ Agent 架构邻接 |
| 1619-2609-38349 | 2609.38349 | MILO: 自动化 Harness 发现 | evaluation | ★ Agent 工程邻接 |
| 1626-2610-02196 | 2610.02196 | （未读 · 来源 Oct 3 candidates） | — | 待确认 |
其余 Oct 1~3 paper_cards：无其他直接 database 主分类条目；work-queue Top 15 中无 database 直接关联条目。
二、增量条目
主+ 1 · MatRAG：Matryoshka 分层 RAG — 多跳问答效率优化（arXiv:2610.01767）★★
来源：paper_cards/1640-2610-01767.md · arXiv:2610.01767v1 · 2026-10 · tom inbox 2026-10-03 candidates
要点： - 问题：多跳问答 RAG 系统面临索引成本（KG/LLM 生成摘要）和查询成本（LLM 驱动的迭代检索）的双重负担 - MatRAG 方案：将 RAG 与 Matryoshka Representation Learning（MRL）结合，通过对齐聚类的语义层次实现分层检索——粗粒度层快速过滤，精粒度层精准抽取 - 核心价值：同时降低索引阶段和查询阶段的计算成本，同时保持检索质量 - 技术定位：属于 2610.01936（RAG 四轴分类学）Efficiency 轴的具体方法论，与分层缓存/压缩策略形成互补
与活文档现有脉络的关系： - R-95 §2.4（新增 RAG 分类学）以 2610.01936 四轴为纲；MatRAG 是 Efficiency 轴在多跳场景的具体实现 - 2610.01936 Defense 轴（ImmRAG）+ Efficiency 轴（MatRAG）共同构成 RAG 系统的攻防与效率两极 - 本条增量：提供了多跳 RAG 的成本-质量帕累托优化路径，与 Naive RAG / GraphRAG / LazyGraphRAG 形成方法论对照
建议归入： - §2.4 RAG 系统分类学（新增）— Efficiency 轴：MatRAG 分层 RAG 多跳 QA 优化（arXiv:2610.01767） - 或 §2.3 AI 重塑数据库内核与 Agent 记忆 — RAG 效率优化方法论补充
arXiv：2610.01767
主+ 2 · VecDB 2026 Q4 量化基准综合数据包 — pgvector 里程碑 / Qdrant p99<8ms / Milvus GPU 吞吐之王 ★★★
来源：inbox/jay/2026-10-03-1105-jay-morning-briefing-vecdb-agentic-rag-multimodal-oct2026.md · DEV Community / Vecstore 2026-04；inbox/jay/2026-10-03-1505-jay-afternoon-briefing-vecdb-inference-cloudnative-mcp-rageval.md · ranksquire.com / salttechno.ai / alphacorp.ai 多源
要点：
- pgvector + pgvectorscale 里程碑（2026-04，DEV Community）：
- 50M 向量 / 1536 维 / 99% 召回率 → 471 QPS，p95 延迟 28ms
- 技术路径：DiskANN + Statistical Binary Quantization，向量存磁盘，HNSW 索引
- 评价：⭐⭐⭐⭐⭐ pgvector 已非"玩具级"，10M 级向量场景完全可用
- Qdrant 量化基准（2026 Q4，多源交叉）：
| 规模 | p50 延迟 | p99 延迟 | 吞吐量 | 来源 |
|------|---------|---------|---------|------|
| 1M · 1536维 | ~4ms | 25ms | ~1,200 QPS | rankswire/salttechno |
| 50M · 90% recall | — | <8ms | — | DEV Community Alpha Corp |
- Milvus GPU 吞吐数据（2026 Q4）：
- 1M · 1536维：p50=6ms，p99=18ms，QPS 20,000+
- 2.6+ 内置 BM25 全文本搜索：吞吐量是 ES 同硬件 4 倍
- 选型决策树（2026 Q4 更新版）：
延迟敏感（<10ms p99）→ Qdrant
吞吐量敏感（>10K QPS）→ Milvus GPU
零 DevOps / Serverless → Pinecone
已有 PostgreSQL 栈 + 小规模 → pgvector（<1M 向量）
已有 Elasticsearch 栈 → 先试 Weaviate 自托管
- 关键洞察：embedding 模型对检索质量的影响往往超过数据库选择本身，应优先选好 embedding 模型（DigitalApplied 2026-04 评测印证）
与活文档现有脉络的关系： - R-95 §2.1 向量数据库选型已有 pgvectorscale 471 QPS vs Qdrant 41 QPS 数据（C1 警示：厂商自测偏） - 本条增量：Qdrant <8ms p99 @ 50M（Alpha Corp 实测）与 rankswire ~25ms p99 @ 1M 数量级一致，但规模差异大；Milvus GPU 20K+ QPS 新数据补全了高吞吐场景覆盖 - ⚠️ 可信度警示：Alpha Corp 的 <8ms p99 数据需确认测试硬件配置（若为 H100 单机则可信；若为集群则不能推广到单机场景）；471 QPS 仍为 DEV Community 厂商自测
建议归入： - §2.1 向量数据库选型 — 更新 Qdrant 50M 规模 p99 数据；补充 Milvus GPU 20K+ QPS 吞吐数据；标注 embedding 模型选型优先原则
可信度：中高（多源一致性较好；Alpha Corp 50M p99 数据需核实硬件条件）
主+ 3 · GPU 共置（Colocation）架构 — VecDB + LLM 同节点部署 <50ms Total RTT 实测数据 ★★★
来源：inbox/jay/2026-10-03-1735-jay-evening-supplement-memory-stack-hf-qwen-selfhost-gpu-vecdb.md · Spheron Network Blog · 2026
要点：
- 问题：托管 RAG（Pinecone + OpenAI API）每个 query 两次外部网络调用（VecDB 约 30-250ms + LLM 约 30-250ms），跨 region 场景延迟更高
- 共置方案：vLLM + Milvus/Qdrant + TEI embedding 同 GPU 实例，所有调用走 shared memory
- 目标指标：Total round trip（embed + search + LLM TTFT）< 50ms（H100 SXM5，实测）
- 三合一单节点架构：
vLLM → 8000（LLM inference）
Milvus → 19530（management）+ 19121（GPU search）
TEI Embedder → 8080（embedding server）
Qdrant → 6333（轻量替代选项）
- Qdrant GPU HNSW 加速（v1.17+）：
- 索引构建速度提升 4x（AWS 实测）
- Multi-AZ 集群支持 99.95% SLA
- Milvus 2.6+ 关键能力：
- Storage Format V2 + nullable vector support
- GPU 加速 CAGRA 算法（10M+ 向量场景）
- vLLM 70B 模型启动命令（H100）：
bash
docker run --gpus all --ipc=host -p 8000:8000 vllm/vllm-openai \
--model meta-llama/Llama-3.3-70B-Instruct \
--dtype fp8 --gpu-memory-utilization 0.85
与活文档现有脉络的关系： - R-95 §2.6 已有推理引擎（vLLM / SGLang / TensorRT-LLM）章节；GPU 共置是推理引擎与向量库协同部署的工程实践 - 本条增量：提供了端到端延迟预算（<50ms）的具体架构方案和实测数据，是对"选型决策树"的生产工程补充 - 与 §2.1 向量库选型联动：Qdrant/ Milvus GPU 选型后，具体部署配置命令是落地路径
建议归入： - §2.6 vLLM / SGLang / TensorRT-LLM 推理引擎与 KV 缓存 — 新增节：GPU 共置部署架构（<50ms Total RTT 目标） - §2.1 向量数据库选型 — 补充 GPU 共置部署方案（作为低延迟 RAG 的落地路径）
arXiv：无（工程 blog 实测）
主+ 4 · Agent Memory 三层架构 — Memory 从 RAG 装饰器升级为第一架构原语（The AI Engineer Substack）★★
来源：inbox/jay/2026-10-03-1735-jay-evening-supplement-memory-stack-hf-qwen-selfhost-gpu-vecdb.md §一 · The AI Engineer Substack · 2026
要点： - 范式转变：2024 年 Memory = 选个向量数据库 + 做 RAG；2026 年 Memory 是独立三层架构原语 - 三层 Memory 架构： | 层级 | 定位 | 解决的问题 | 代表方案 | |------|------|-----------|---------| | L1: Context Window | 模型直接可见 | Token 预算内的高频、最近状态 | Gemini 1M、Claude 200K 原生上下文 | | L2: In-Context Memory | Agent 运行时可见 | 多轮对话、短期任务状态 | Agent prompt 内嵌 history | | L3: Long-Term Memory | 跨 session 持久化 | 跨实例共享、provider 切换后状态保留 | Mem0、Zep、Letta 专用基础设施 | - 关键工程判断：
"Context windows got massive. Gemini hit 1M+ tokens, Claude 200K. Bigger windows didn't kill the need for memory. They changed the tradeoff: what do you stuff in-context vs. what do you retrieve on demand?" - Gemini 1M token context → 可直接内嵌整本书 - 但超过 ~50K token 后推理成本和延迟显著上升 - L3 dedicated memory infrastructure 价值：跨 agent 实例共享 + 模型 provider 切换后状态保留 - 与 2610.01936 四轴分类学的对应： - L1 Context Window ↔ Efficiency 轴（最大化利用上下文） - L2 In-Context Memory ↔ Interactivity 轴（多轮对话支撑） - L3 Long-Term Memory ↔ Defense 轴（持久化状态可信度）+ Efficiency 轴（按需检索 vs 全量上下文）
与活文档现有脉络的关系： - R-95 §2.3 已有 JAM（2609.34385 · 运行时 JIT page-store）、EngramRAG（2609.32049 · CLS 双态架构）、Compaction Cliff（2608.22752 · Knowledge Triage）——这些是个体 Agent 记忆架构 - 本条增量：三层架构是从系统视角统一 L1/L2/L3 的框架性思维，使 JAM/EngramRAG/Knowledge Triage 可分别归入 L2（In-Context）或 L3（Long-Term）层——解决了个体架构设计与全局 Memory 体系的对应问题 - 与 R-95 邻接+6（Guardrails 三层护栏体系）形成对称：Memory 有三层，Guardrails 也有三层——这是 2026 Agent 架构的对称性主题
建议归入： - §2.3 AI 重塑数据库内核与 Agent 记忆 — 新增顶层框架：Agent Memory 三层架构（L1/L2/L3），作为 JAM / EngramRAG / Compaction Cliff 的归类锚点 - §2.4 RAG 分类学（新增）— 与 2610.01936 四轴交叉：三层 Memory 对应 Efficiency / Interactivity / Defense 轴
arXiv：无（Substack 高质量 newsletter）
邻接+ 5 · RAG 评估体系 2026 全貌 — 多维指标矩阵与主流工具链 ★★
来源：inbox/jay/2026-10-03-1505-jay-afternoon-briefing-vecdb-inference-cloudnative-mcp-rageval.md §五 · labelyourdata.com / braintrust.dev / evidentlyai.com / confident-ai.com · 2026
要点：
- Retrieval 指标：Precision@K / Recall@K / MRR / nDCG / Diversity
- Generation 指标：Faithfulness（⭐⭐⭐⭐⭐）/ Relevance / Citation Coverage / Hallucination Rate / Completeness
- 主流 Benchmark：RAGBench（通用）/ CRAG（上下文相关性）/ LegalBench-RAG（法律合规）/ T²-RAGBench（多轮/任务型）
- 失败根因定位（Confident AI）：
Bad Retrieval + Faithful Generation → 修索引/chunk 策略
Good Retrieval + Unfaithful Generation → 修 prompt / 换模型
- 调优优先级：阶段一（检索调优：chunk-level relevance + ranking）；阶段二（生成调优：faithfulness + relevance）；生产监控（format correctness + answer completeness）
- 工具链：Ragas（开源合成测试集）/ Galileo（20+ 内建指标）/ Braintrust（评估 + CI/CD）/ Evidently AI（生产监控）
建议归入： - §2.4 RAG 分类学（新增）— 新增评估维度子节：Retrieval + Generation 指标矩阵，主流 Benchmark 对照 - R-95 候选(κ)：RAG 评估体系作为独立追踪方向
邻接+ 6 · SD-RAG: Prompt Injection Resilient RAG — 差分隐私重整化机制（arXiv:2601.11199）★★
来源：inbox/jay/2026-10-03-1105-jay-morning-briefing-vecdb-agentic-rag-multimodal-oct2026.md § reproduction · arXiv:2601.11199（cs.CR）· 2026-01
要点： - 问题：RAG 系统面临 prompt injection 攻击（恶意文档注入恶意指令）和文档隐私泄露风险 - SD-RAG 方案：差分隐私重整化机制保护 RAG 文档隐私，无需微调 LLM - 安全定位：属于 2610.01936（RAG 四轴分类学）Defense 轴的具体防御方法，与 ImmRAG（2610.01871）攻击面形成攻防配对 - 评价：⭐⭐⭐⭐ 安全+隐私 RAG，生产场景高价值
与活文档现有脉络的关系： - R-95 主+2（ImmRAG）已录入 Defense 轴攻击面；SD-RAG 是同一轴的防御侧补充 - 两者组合：ImmRAG（识别攻击面）+ SD-RAG（提供防御机制）= Defense 轴的攻防闭环
建议归入： - §2.4 RAG 分类学（新增）— Defense 轴：ImmRAG 攻击面（2610.01871）+ SD-RAG 防御机制（2601.11199）攻防配对
arXiv：2601.11199
邻接+ 7 · FT-RAG: KDD 2026 细粒度表格推理 RAG（arXiv:2605.01495）★★
来源：inbox/jay/2026-10-03-1105-jay-morning-briefing-vecdb-agentic-rag-multimodal-oct2026.md § reproduction · arXiv:2605.01495 · SIGKDD 2026（济州岛）
要点： - 会议：SIGKDD 2026 - 方向：细粒度表格推理 RAG 框架 - 评价：⭐⭐⭐⭐ 顶会论文，工程应用价值明确；需查 GitHub 源码确认可复现性
建议归入： - §2.4 RAG 分类学（新增）— Interactivity 或 Reasoning 轴邻接：表格推理 RAG 垂直场景 - 候选追踪项：待 GitHub 源码核验后再升级为 ★★★
arXiv：2605.01495
邻接+ 8 · AI 生成代码安全风险警示 — 29.1% 潜在弱点率（Backend AI-Native 趋势）★
来源：inbox/jay/2026-10-03-1735-jay-evening-supplement-memory-stack-hf-qwen-selfhost-gpu-vecdb.md §四 · Refonte Learning / Nucamp / Mastering Backend 综合 · 2026
要点： - 数据：2026 年分析显示约 29.1% 的 AI 生成 Python 代码存在潜在安全弱点 - 典型问题：Missing input validation / Unsafe deserialization / Sloppy secrets handling - Backend 特有风险：String-concatenated SQL（注入）/ Overly permissive CORS / Logging full request bodies - 与 Agent 记忆的关系：若 Agent 记忆系统使用 LLM 生成数据库查询逻辑，29.1% 的安全弱点率是生产安全规划的输入参数
建议归入： - §2.3 AI 重塑数据库内核与 Agent 记忆 — 安全警示：LLM 生成代码的 29.1% 弱点率作为 Agent 记忆写入逻辑的风险系数
可信度：中（来源为技术教育博客，非 peer-reviewed 论文；建议作为方向性警示而非精确数字）
三、值得警惕的矛盾或待核实说法
| 编号 | 矛盾/待核实点 | 来源 | 建议行动 |
|---|---|---|---|
| C1 | Qdrant p99 <8ms @ 50M（Alpha Corp / DEV Community）vs ~25ms @ 1M（rankswire/salttechno 2026 Q4）——规模差异导致无法直接比较；Alpha Corp 测试硬件配置（单机 H100？还是集群？）未披露 | inbox/jay 2026-10-03 morning/afternoon briefing | 在活文档中明确区分"单机 H100 @ 1M"和"集群 @ 50M"数据，避免合并为单一数字 |
| C2 | pgvectorscale 471 QPS（DEV Community 2026-04 厂商自测）vs 之前 R-95 的 Qdrant 41 QPS（C1 警示：厂商自测偏）——两个数据都是厂商自测，不能直接用 471 QPS > 41 QPS 得出 pgvector 更优的结论 | inbox/jay 2026-10-03 morning briefing | 维持 C1 警示 SOP：厂商自测数据仅作方向参考；选型决策需独立第三方 benchmark |
| C3 | 29.1% AI 生成代码弱点率（技术教育博客）——来源非 peer-reviewed；统计口径和样本规模未披露 | inbox/jay 2026-10-03 evening supplement | 作为方向性警示写入活文档安全节；建议寻找学术论文或厂商安全报告支撑后再精确定量化 |
| C4 | Milvus 2.6 内置 BM25 吞吐量是 ES 同硬件 4 倍（Spheron Network blog）——自测数据，未注明测试条件和基准版本 | inbox/jay 2026-10-03 evening supplement | 与 C1/C2 合并建立"工程 blog 自测数据"可信度警示 SOP |
| C5 | GPU 共置 <50ms Total RTT 目标（H100 SXM5 实测）——未注明具体模型规模、batch size、并发数等关键参数 | inbox/jay 2026-10-03 evening supplement | 作为目标指标参考；落地时需在目标硬件上复测 |
四、可引用 arXiv 号列表
| arXiv | 主题 | 分类 | 状态 |
|---|---|---|---|
| 2610.01767 | MatRAG: Matryoshka 分层 RAG 多跳 QA 效率优化 | 主 | 新收录 |
| 2609.38349 | MILO: 自动化 Harness 发现（Agent 评估工程化） | 邻接 | 新收录 |
| 2601.11199 | SD-RAG: 差分隐私重整化 RAG 防御（Prompt Injection Resilient） | 邻接 | 新收录 |
| 2605.01495 | FT-RAG: KDD 2026 细粒度表格推理 RAG | 邻接 | 新收录 |
| 2610.01936 | Mapping the RAG Landscape: 四轴分类学（R-95 已锚定） | 主 | 续用 |
| 2610.01871 | ImmRAG: MRAG 数据提取攻击（R-95 已锚定） | 主 | 续用 |
| 2609.32259 | HeteroFold: Prefill-Free 异构模型族 KV Cache 迁移（R-95 已锚定） | 主 | 续用 |
| 2609.33485 | DISCO: Grounding-Reasoning Disaggregation（R-95 已锚定） | 主 | 续用 |
| 2609.34385 | JAM: Just-In-Time Agent Memory（R-95 已锚定） | 主 | 续用 |
| 2609.32049 | EngramRAG: CLS 双态动态拓扑 Agent 记忆（R-95 已锚定） | 主 | 续用 |
| 2608.22752 | Compaction Cliff / Knowledge Triage（R-95 已锚定） | 主 | 续用 |
| 2609.36322 | Periodic Weak Spots: KV-Cache 相位敏感性（R-95 已锚定） | 主 | 续用 |
| 2609.35629 | SANTA++: 免训练随机采样代表性 KV 选择（R-95 已锚定） | 主 | 续用 |
| 2603.20397 | Dell KV Cache 五大家族系统性综述（R-95 已锚定） | 主 | 续用 |
| 2609.31415 | KV Cache 复用准确性评估方法论质疑（R-95 已锚定） | 主 | 续用 |
| 2511.01815 | KVTC: KV Cache Transform Coding ICLR 2026（R-95 已锚定邻接） | 邻接 | 续用 |
| 2509.23202 | Mooncake ACM TOS KV-Centric Disaggregated Architecture（R-95 已锚定） | 主 | 续用 |
五、行动建议
| 优先级 | 行动 | 对应条目 |
|---|---|---|
| 高 | 以 MatRAG（2610.01767）补全 §2.4 RAG 四轴分类学 Efficiency 轴的多跳场景方法论 | 主+1 |
| 高 | 更新 §2.1 向量数据库选型：补充 Qdrant 50M p99<8ms 和 Milvus GPU 20K+ QPS 数据；强化 embedding 模型选型优先原则 | 主+2 + C1 |
| 高 | 在 §2.6 新增 GPU 共置部署架构节（<50ms Total RTT 目标 + 具体配置命令），联动 §2.1 落地路径 | 主+3 |
| 高 | 在 §2.3 新增 Agent Memory 三层架构框架（L1/L2/L3），为 JAM/EngramRAG/Compaction Cliff 提供归类锚点 | 主+4 |
| 高 | 更新 §2.4 Defense 轴：ImmRAG（2610.01871 攻击面）+ SD-RAG（2601.11199 防御机制）攻防配对 | 邻接+6 |
| 中 | RAG 评估体系（邻接+5）补充 §2.4 评估维度和 Benchmark 对照表；R-95 候选(κ)维持 | 邻接+5 |
| 中 | FT-RAG（2605.01495）作为邻接追踪项；待 GitHub 核验后升级 | 邻接+7 |
| 中 | 建立全报告统一的"工程 blog 自测数据"可信度警示 SOP（C1/C2/C4 合并） | C1+C2+C4 |
| 中 | 29.1% AI 生成代码弱点率作为 §2.3 安全警示参考（方向性，非精确值） | 邻接+8 + C3 |
六、候选(κ)状态
候选(κ)：RAG 评估体系（★第四十六维持） R-95 维持★；本轮（Oct 3）新增邻接+5（RAG 评估体系全貌）和邻接+6（SD-RAG 防御机制）均与候选(κ)直接相关：SD-RAG 提供 Defense 轴的防御方法论，RAG 评估体系提供量化验证路径——两者结合可驱动候选(κ)从 ★ 升级为 ★★，但需等待 §2.4 RAG 分类学章节正式建立后作为驱动锚点。候选(κ)★★★升级路径明确：§2.4 建章 → Defense 轴扩充 → SD-RAG + ImmRAG 攻防配对 → 评估指标矩阵 → 候选(κ)★★。
Jay · database E1 预消化轮 · 2026-10-03 20:20 CST