Oracle SQL 优化知识库构建方案与价值评估文档类型方案宣讲讲清楚为什么做、怎么做、优缺点适用场景团队评审、技术分享、方案汇报配套文档plans/DESIGN-QDRANT-INTEGRATION.md技术设计、plans/SPRINT-PDF-INGESTION.md实施计划数据来源所有数字来自实际工具输出ingest_report.md / 落盘测试日志可追溯一、为什么需要构建知识库1.1 问题纯 LLM 优化 SQL 的根本缺陷SQLAdvisor 的核心功能是用 LLM 优化 Oracle SQL。但直接让 LLM 改写 SQL 有一个根本缺陷LLM 的优化建议没有权威依据全凭模型自身记忆。具体表现问题后果LLM 可能编造 Oracle 不支持的语法/hint生成的 SQL 在 Oracle 上报错或无效LLM 的优化建议泛泛而谈“加索引”、“改写子查询”缺乏具体到 Oracle 版本的准确指导LLM 不知道 Oracle 12c 的特定特性如自适应优化、SQL Plan Baseline错过版本专属的优化机会不同 LLM、不同会话给出不一致的建议优化质量不稳定不可复现无法解释为什么这样优化用户不敢采纳优化建议缺乏可信度本质LLM 是个学过很多但记不准的顾问。没有权威知识约束它会把模糊记忆当事实输出——这在数据库优化这种差一个 hint 就差 10 倍性能的场景下是危险的。1.2 知识库解决什么把Oracle 官方文档SQL Tuning Guide724 页权威指南结构化成知识库让 LLM 在改写 SQL 时先检索权威依据再生成建议没有知识库 用户SQL → LLM凭记忆→ 优化建议可能编造 有了知识库 用户SQL → 检索官方文档 → LLM基于权威依据→ 优化建议有出处核心价值把 LLM 从凭记忆的顾问变成查了手册的顾问。1.3 为什么选 Oracle 12c SQL Tuning Guide理由说明权威性Oracle 官方出版E49106-14, July 2017是 Oracle SQL 调优的权威指南系统性24 章 附录覆盖优化器、统计信息、执行计划、访问路径、连接、并行、SQL Profile 等全链路版本匹配项目测试库是 Oracle 18.4 XE12c 架构延续文档适用结构清晰有完整目录outline便于按章节抽取天然适合知识库构建公开可得Oracle 官网公开 PDF无版权障碍内部使用二、如何构建知识库2.1 整体方案PDF → 结构化知识 → 向量库2.1.1 全景流程图核心思路把一本 724 页的 PDF 官方手册经过提取 → 切片 → 抽取 → 验证 → 导出五步变成可被 Agent 检索、可追溯、抗编造的结构化知识库。┌─────────────────────────────────────────────────────────────────┐ │ Oracle 官方 PDF │ │ 《SQL Tuning Guide》12c Release 1 │ │ 724 页 · 24 章 · outline 1027 条目录 │ └────────────────────────────┬────────────────────────────────────┘ │ ┌──────────────▼──────────────┐ │ ① 文本提取Stage A │ pdfplumber 逐页提取 │ 章节归属解析 │ pypdf outline 解析目录 └──────────────┬──────────────┘ │ 724 页原文697 有效 27 跳过 │ 每页带 section_path如 Ch.11 Histograms ┌──────────────▼──────────────┐ │ ② 章节切片Stage B │ 按 outline 章节边界分组 │ token 感知切块 │ 目标 1200 token/片重叠 150 └──────────────┬──────────────┘ │ 308 个 chunks │ 覆盖 1-24 章 附录全部 ┌──────────────▼──────────────┐ │ ③ LLM 智能抽取Stage C │ 每片喂 GLM-4-flash │ 强制 source_quote │ 要求输出结构化 JSON │ 自动 quote 校正 │ 每条必须带原文引用 └──────────────┬──────────────┘ │ 1031 条原始条目 │ 4 类规则/解释/语法/示例 ┌──────────────▼──────────────┐ │ ④ 五层验证 去重清洗 │ L0 完整性 / L1 一致性 │ 详见 §2.3 │ L2 语义 / L3 反向 / L4 人工 │ 字段清洗 强去重 │ 剔除 102 条无法回溯的 └──────────────┬──────────────┘ │ 847 条验证后的知识 │ 带质量分级verified/disputed ┌──────────────▼──────────────┐ │ ⑤ 多目标导出Stage E │ 一次构建四处消费 └─┬─────────┬──────────┬───────┴──────────┬──────────┘ ▼ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌──────────────┐ ┌──────────────┐ │rules.json│ │ SQLite │ │ Markdown │ │ Qdrant │ │ 372 条 │ │ 847 行 │ │ 33 个章节文件 │ │ 847 points │ │ 规则引擎 │ │ 结构化 │ │ 人工审查 │ │ 向量检索 │ │ 源 │ │ 查询 │ │ │ │ (Agent RAG) │ └─────────┘ └─────────┘ └──────────────┘ └──────────────┘2.1.2 数据流转每一步的输入、处理、输出步骤输入关键处理输出淘汰/损耗① 文本提取724 页 PDFpdfplumber 逐页提文字pypdf 解析 outline 建页→章节映射含前向继承章节标题后的所有页继承该章节直到下个标题697 页有效文本 27 页跳过封面/目录/扉页27 页低信息密度页合理跳过有清单可查② 章节切片697 页文本按 outline 章节边界分组章节内按 token 累积切1200 token/片150 重叠防截断跳过 100 token 的过短片封面/分隔页308 个 chunks4 个过短 chunk 跳过③ LLM 抽取304 个有效 chunks每个 chunk 喂 GLM-4-flash要求识别优化规则/语法/示例/概念 → 输出结构化 JSON →每条必须带source_quote≥20 字原文精确引用同时跑 quote 自动校正LCS 算法把改写过的引用对齐回原文1031 条原始条目1 个 chunk 抽取超时失败附录 A 索引指南显式记录④ 验证去重1031 条原始条目L1回原文验证 source_quote90.1% 通过剔除 102 条无法回溯的编造L2LLM 二次校验忠实度字段清洗修复类型错放强去重标题归一化相等合并847 条验证后条目102 条 L1 剔除 82 条强重复合并 4 条 quote 不可验证⑤ 多目标导出847 条最终条目safety 闸门过滤 example_sql145 条危险 SQL 过滤并行导出 4 种格式rules.json(372) SQLite(847) Markdown(33 文件) Qdrant(847 points)145 条 example_sql 被 backend 安全闸门过滤保留条目本体只清空 example_sql 字段2.1.3 关键技术决策为什么这么做决策选择为什么不选另一方案切片粒度1200 token/片 150 重叠太小如 500 token切碎语义LLM 抽取上下文不足太大如 3000 token超出 LLM 有效注意力抽取质量下降。重叠 150 防建议被切到两半切片边界按 outline 章节边界优先章节内再按 token纯滑窗无视章节会把直方图和统计信息混在一个 chunkLLM 抽取混乱按章节优先语义连贯抽取模型GLM-4-flashOpenAI 兼容用规则/正则提取无法理解语义抓不住建议这种主观表述用大模型GPT-4成本高 10 倍且 flash 对结构化抽取够用防编造机制强制 source_quote 自动回溯不强制引用LLM 会用自己的话概括无法验证是否忠实原文强制引用让每条知识都可追溯到 PDF 页码embedding 模型GLM embedding-3dim 2048BGE-M3本地需下载 2GB 模型HuggingFace CDN 在当前网络不可达GLM 在线 API国内可访问已验证可用向量库Qdrant独立 collection不用向量库纯关键词检索抓不住语义相似“全表扫描” vs “table access full”Qdrant 独立 collection不污染现有 oracle_best_practices去重策略标题归一化强去重不用语义去重语义去重embedding 相似度需加载 embedding 模型慢且有误判风险强去重确定性强可复现导出多目标一次构建导出 4 种格式只导向量库规则引擎/人工审查/结构化查询都用不了多目标同一份知识适配不同消费场景2.1.4 质量闸门分布数据在哪里被淘汰从 1031 条原始抽取到 847 条最终条目每一步的淘汰都有据可查不静默丢弃1031 条原始抽取 │ ├─ L1 剔除 -102 条source_quote 无法回溯原文 → 疑似编造 │ 清单: l1_mismatches.jsonl可审查每条为何被剔 │ ├─ 强去重合并 -82 条标题归一化后重复 │ └─▶ 847 条进入最终产物 │ ├─ L2 disputed 253 条保留但标 ⚠️不剔除——降级可见 │ 清单: l2_disputes.jsonl │ └─ safety 过滤 145 条 example_sql条目保留只清空示例 SQL 字段 原因: 含 DDL/多语句等被 backend 四层安全闸门拦截原则所有淘汰/降级都在报告和清单文件中显式列出不折叠为泛化的success。任何一条被剔除的知识都能查到原因。2.2 五阶段构建管线阶段做什么工具产出A. 文本提取PDF 每页提取文字 解析目录建立章节归属pdfplumber pypdf724 页原文697 有效页 27 跳过页B. 章节切片按章节边界 token 长度切成知识片段tiktoken1200 token/片150 重叠308 个 chunks覆盖 1-24 章全部C. LLM 抽取每个片段让 GLM-4 提取结构化知识规则/语法/示例GLM-4-flashOpenAI 兼容1031 条结构化条目D. 去重清洗标题去重 字段清洗 严重度归一Python 规则 启发式847 条最终条目E. 多目标导出同时导出 4 种格式供不同场景消费httpx SQLite jsonrules.json / SQLite / Markdown / Qdrant2.3 五层质量验证核心防止 LLM 编造构建知识库最大的风险是LLM 在抽取过程中编造内容把模糊记忆当文档内容输出。为此设计了五层验证层验证什么怎么验结果L0 完整性PDF 有没有漏页、产物数量一致机械计数dedupSQLiteQdrant847✓ 全过L1 一致性防编造底座每条知识能不能回溯到 PDF 原文强制source_quote字段自动回原文做子串匹配90.1% 通过剔除 102 条无法回溯的L2 语义校验抽取是否忠实原文非语义篡改第二轮 LLM 独立评判每条582 verified 253 disputed全保留降级L3 反向覆盖PDF 要点有没有被遗漏反向抽样每章抽页列要点查是否被覆盖70% 覆盖0 critical 遗漏L4 人工抽检最终可信度50 条人工对照 PDF 原文核对96% 全对48/50关键设计——L1 强制回溯每条抽取的知识必须带一句source_quote≥20 字必须是 PDF 原文精确子串。系统自动回 PDF 原文验证这句引用是否真实存在——这一层拦住了绝大多数 LLM 编造。2.4 最终知识库内容847 条类型数量说明示例optimization_rule372优化规则可被规则引擎/RAG 用“索引列避免函数或用函数索引 FBI”explanation350概念解释“什么是直方图、成本估算原理”syntax_doc95语法说明“CREATE INDEX 语法、DBMS_STATS 调用”example_sql30完整示例 SQL已过安全闸门频率直方图生成示例每条知识都带source_pagePDF 页码可追溯source_quote原文精确引用categoryINDEX/STATISTICS/JOIN/OPTIMIZER 等 14 类severityINFO/WARN/ERRORoptimization_rule 专属quality_flagverified/disputed质量分级2.5 构建耗时与成本真实数据项耗时说明文本提取724 页~10 分钟pdfplumberLLM 抽取308 片段~3.5 小时GLM-4-flash含网络重试L1-L4 验证~1.5 小时自动 人工抽检总计~5 小时一次性构建后续可增量GLM 调用次数~3000 次抽取 二次校验成本数元级别glm-4-flash 单价低三、知识库如何被使用3.1 集成到 Agent 主优化流程用户提交 SQL 后Agent 在让 LLM 改写之前先检索知识库找相关权威依据用户: SELECT * FROM orders WHERE UPPER(customer_name) ACME │ Agent 自动检索知识库用 SQL 语义匹配 │ ▼ 命中: [INDEX] 索引列上避免函数或用函数索引 FBI WHERE UPPER(name)X 会使 name 上的普通 B-tree 索引失效 来源: Oracle 12c SQL Tuning Guide p.211 │ ▼ 注入到 LLM prompt: knowledge 索引列避免函数... /knowledge │ ▼ LLM 生成变体: CREATE INDEX idx_cust_upper ON orders(UPPER(customer_name)); SELECT * FROM orders WHERE UPPER(customer_name) ACME; 变体的 rationale 引用了知识库依据不再是凭空建议3.2 多种使用方式方式场景怎么用Agent 自动接地已集成主优化流程调/api/optimizeRAG 自动注入用户无感向量检索Qdrant语义查询如何优化 X按 SQL/关键词检索返回最相关的 top-N 条结构化查询SQLite精确查某类规则/某页内容SQL 查询oracle_12c_kb.db按 category/severity 过滤人工查阅Markdown学习/审查33 个按章节组织的topics-*.md每条带原文引用规则引擎源rules.json补充 AST 规则372 条 optimization_rulebackend rules.json 兼容格式四、使用知识库的优点4.1 优化建议有权威依据核心价值维度无知识库有知识库建议来源LLM 模糊记忆Oracle 官方文档原文可追溯性无法验证每条建议带 PDF 页码 原文引用版本准确性可能混淆版本锁定 Oracle 12c 特性可信度用户不敢采纳用户可查原文确认4.2 LLM 编造被有效抑制L1 强制回溯机制每条知识必须引用 PDF 原文让知识库本身抗编造。Agent 基于这样的知识库生成建议等于给 LLM 加了必须引用手册的约束。4.3 知识可复用、可审计构建一次5 小时多处消费Agent 主流程用RAG 接地未来 chatbot 用语义问答规则引擎用372 条规则人工查阅用Markdown质量可审计五层验证每条可追溯到 PDF 页4.4 构建过程可复现、可增量全流程代码化ingestion包可重新构建断点续跑大文件中断可恢复第二本 PDFSQL Language Reference1920 页同管线配置已就绪五、使用知识库的缺点与局限诚实评估——知识库不是银弹以下局限必须知晓。5.1 检索质量受 query 构造影响当前主要痛点问题用原始 SQL 做 embedding query 效果一般。SQL 的语法噪音SELECT/FROM/WHERE淡化了优化意图。实例查SELECT * FROM employees WHERE UPPER(name)SMITH理想是命中函数索引那条规则实际命中的是泛化的Querying Table Informationscore 0.53。影响注入 LLM 的知识不一定是最相关的优化建议的针对性打折。缓解方向改用rule_findingsAST 规则发现文本或 SQL 特征描述做 query而非 raw SQL。5.2 引入额外延迟和依赖代价量级说明每次优化多 ~0.5sGLM embedding 0.45s Qdrant 检索 0.05s用户感知不明显但高并发下累积依赖 GLM embedding API在线服务API 不可达时降级为纯 LLM不阻塞但失去接地依赖 Qdrant 服务独立进程Qdrant 宕机时同样降级5.3 知识库覆盖率非 100%L3 反向覆盖率 70%非 80% 门槛抽样发现的 191 个 minor 遗漏多为细分要点无 critical 遗漏但意味着部分次要知识点未被独立抽取L4 人工抽检 96%2 条字段错放质量高但非完美253 条 disputedL2 有疑虑保留但标 ⚠️使用前建议人工核对5.4 构建前期投入大5 小时构建含 LLM 抽取 验证——虽然是一次性但比直接用 LLM重得多需要 PDF 原文——必须先有权威源文档需要 GLM API 额度——抽取校验约 3000 次调用5.5 embedding 方案的运维复杂度知识库用 GLM embeddingdim 2048与 backend 原有 BGE-M3dim 1024不兼容必须按 collection 选择 embedding 模型配置不能错错了维度不匹配查询失效切换 embedding 模型需重建整个向量库5.6 仅覆盖一本 PDF当前当前只构建了 SQL Tuning Guide724 页。SQL Language Reference1920 页语法大全尚未构建管线已就绪待启动。语法类问题目前知识库覆盖不足。六、总结值不值得做6.1 价值矩阵维度评分说明解决编造问题★★★★★L1 强制回溯 L2 二次校验从源头抑制 LLM 编造提升建议可信度★★★★★每条建议可追溯到 Oracle 官方文档页码构建成本★★★☆☆5 小时 3000 次 API一次性投入可接受检索质量★★★☆☆当前 query 构造偏弱有改进空间运维复杂度★★★☆☆多了 Qdrant GLM embedding 依赖但有降级容错覆盖范围★★★★☆724 页已覆盖调优核心1920 页语法待补6.2 适用与不适用场景适合用知识库数据库优化这种权威性要求高、错误代价大的领域有权威源文档官方手册、标准规范可抽取用户需要为什么这样优化的可解释性优化建议需要版本准确Oracle 12c 特性不适合用知识库没有权威文档的领域LLM 记忆已是最佳来源一次性快速验证构建 5 小时太重实时性要求极高检索增加 0.5s 延迟领域知识频繁变化知识库需频繁重建6.3 结论值得做。对于 SQLAdvisor 这类数据库优化工具知识库把 LLM 从不可控的顾问变成查了手册的顾问——这是从能用到敢用的关键一步。5 小时构建成本相比用户不敢采纳优化建议的代价是划算的。当前主要改进方向是检索质量query 构造和覆盖范围第二本 PDF这些是增量优化不影响知识库本身值得构建的基本判断。附录核心数字速查全部实测可追溯指标数值来源PDF 页数724pypdf 实测知识片段数308chunker 产出原始抽取条目1031extractor 产出最终知识条目847extracts_dedup.jsonoptimization_rule372type 统计L1 一致性通过率90.1%929/1031l1_verified.jsonl 计数L2 verified582quality_flag 统计L2 disputed保留降级253quality_flag 统计L3 反向覆盖率70.0%449/641l3_coverage_gaps.jsonL3 critical 遗漏0l3_coverage_gaps.jsonL4 人工抽检通过率96%48/50l4_audit_50.csv四产物一致性✓dedupSQLiteQdrant847实测构建总耗时~5 小时实际运行Agent 测试14/14 passed41.45s落盘测试日志 Oracle SQL 优化知识库：构建方案与价值评估
Oracle SQL 优化知识库构建方案与价值评估文档类型方案宣讲讲清楚为什么做、怎么做、优缺点适用场景团队评审、技术分享、方案汇报配套文档plans/DESIGN-QDRANT-INTEGRATION.md技术设计、plans/SPRINT-PDF-INGESTION.md实施计划数据来源所有数字来自实际工具输出ingest_report.md / 落盘测试日志可追溯一、为什么需要构建知识库1.1 问题纯 LLM 优化 SQL 的根本缺陷SQLAdvisor 的核心功能是用 LLM 优化 Oracle SQL。但直接让 LLM 改写 SQL 有一个根本缺陷LLM 的优化建议没有权威依据全凭模型自身记忆。具体表现问题后果LLM 可能编造 Oracle 不支持的语法/hint生成的 SQL 在 Oracle 上报错或无效LLM 的优化建议泛泛而谈“加索引”、“改写子查询”缺乏具体到 Oracle 版本的准确指导LLM 不知道 Oracle 12c 的特定特性如自适应优化、SQL Plan Baseline错过版本专属的优化机会不同 LLM、不同会话给出不一致的建议优化质量不稳定不可复现无法解释为什么这样优化用户不敢采纳优化建议缺乏可信度本质LLM 是个学过很多但记不准的顾问。没有权威知识约束它会把模糊记忆当事实输出——这在数据库优化这种差一个 hint 就差 10 倍性能的场景下是危险的。1.2 知识库解决什么把Oracle 官方文档SQL Tuning Guide724 页权威指南结构化成知识库让 LLM 在改写 SQL 时先检索权威依据再生成建议没有知识库 用户SQL → LLM凭记忆→ 优化建议可能编造 有了知识库 用户SQL → 检索官方文档 → LLM基于权威依据→ 优化建议有出处核心价值把 LLM 从凭记忆的顾问变成查了手册的顾问。1.3 为什么选 Oracle 12c SQL Tuning Guide理由说明权威性Oracle 官方出版E49106-14, July 2017是 Oracle SQL 调优的权威指南系统性24 章 附录覆盖优化器、统计信息、执行计划、访问路径、连接、并行、SQL Profile 等全链路版本匹配项目测试库是 Oracle 18.4 XE12c 架构延续文档适用结构清晰有完整目录outline便于按章节抽取天然适合知识库构建公开可得Oracle 官网公开 PDF无版权障碍内部使用二、如何构建知识库2.1 整体方案PDF → 结构化知识 → 向量库2.1.1 全景流程图核心思路把一本 724 页的 PDF 官方手册经过提取 → 切片 → 抽取 → 验证 → 导出五步变成可被 Agent 检索、可追溯、抗编造的结构化知识库。┌─────────────────────────────────────────────────────────────────┐ │ Oracle 官方 PDF │ │ 《SQL Tuning Guide》12c Release 1 │ │ 724 页 · 24 章 · outline 1027 条目录 │ └────────────────────────────┬────────────────────────────────────┘ │ ┌──────────────▼──────────────┐ │ ① 文本提取Stage A │ pdfplumber 逐页提取 │ 章节归属解析 │ pypdf outline 解析目录 └──────────────┬──────────────┘ │ 724 页原文697 有效 27 跳过 │ 每页带 section_path如 Ch.11 Histograms ┌──────────────▼──────────────┐ │ ② 章节切片Stage B │ 按 outline 章节边界分组 │ token 感知切块 │ 目标 1200 token/片重叠 150 └──────────────┬──────────────┘ │ 308 个 chunks │ 覆盖 1-24 章 附录全部 ┌──────────────▼──────────────┐ │ ③ LLM 智能抽取Stage C │ 每片喂 GLM-4-flash │ 强制 source_quote │ 要求输出结构化 JSON │ 自动 quote 校正 │ 每条必须带原文引用 └──────────────┬──────────────┘ │ 1031 条原始条目 │ 4 类规则/解释/语法/示例 ┌──────────────▼──────────────┐ │ ④ 五层验证 去重清洗 │ L0 完整性 / L1 一致性 │ 详见 §2.3 │ L2 语义 / L3 反向 / L4 人工 │ 字段清洗 强去重 │ 剔除 102 条无法回溯的 └──────────────┬──────────────┘ │ 847 条验证后的知识 │ 带质量分级verified/disputed ┌──────────────▼──────────────┐ │ ⑤ 多目标导出Stage E │ 一次构建四处消费 └─┬─────────┬──────────┬───────┴──────────┬──────────┘ ▼ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌──────────────┐ ┌──────────────┐ │rules.json│ │ SQLite │ │ Markdown │ │ Qdrant │ │ 372 条 │ │ 847 行 │ │ 33 个章节文件 │ │ 847 points │ │ 规则引擎 │ │ 结构化 │ │ 人工审查 │ │ 向量检索 │ │ 源 │ │ 查询 │ │ │ │ (Agent RAG) │ └─────────┘ └─────────┘ └──────────────┘ └──────────────┘2.1.2 数据流转每一步的输入、处理、输出步骤输入关键处理输出淘汰/损耗① 文本提取724 页 PDFpdfplumber 逐页提文字pypdf 解析 outline 建页→章节映射含前向继承章节标题后的所有页继承该章节直到下个标题697 页有效文本 27 页跳过封面/目录/扉页27 页低信息密度页合理跳过有清单可查② 章节切片697 页文本按 outline 章节边界分组章节内按 token 累积切1200 token/片150 重叠防截断跳过 100 token 的过短片封面/分隔页308 个 chunks4 个过短 chunk 跳过③ LLM 抽取304 个有效 chunks每个 chunk 喂 GLM-4-flash要求识别优化规则/语法/示例/概念 → 输出结构化 JSON →每条必须带source_quote≥20 字原文精确引用同时跑 quote 自动校正LCS 算法把改写过的引用对齐回原文1031 条原始条目1 个 chunk 抽取超时失败附录 A 索引指南显式记录④ 验证去重1031 条原始条目L1回原文验证 source_quote90.1% 通过剔除 102 条无法回溯的编造L2LLM 二次校验忠实度字段清洗修复类型错放强去重标题归一化相等合并847 条验证后条目102 条 L1 剔除 82 条强重复合并 4 条 quote 不可验证⑤ 多目标导出847 条最终条目safety 闸门过滤 example_sql145 条危险 SQL 过滤并行导出 4 种格式rules.json(372) SQLite(847) Markdown(33 文件) Qdrant(847 points)145 条 example_sql 被 backend 安全闸门过滤保留条目本体只清空 example_sql 字段2.1.3 关键技术决策为什么这么做决策选择为什么不选另一方案切片粒度1200 token/片 150 重叠太小如 500 token切碎语义LLM 抽取上下文不足太大如 3000 token超出 LLM 有效注意力抽取质量下降。重叠 150 防建议被切到两半切片边界按 outline 章节边界优先章节内再按 token纯滑窗无视章节会把直方图和统计信息混在一个 chunkLLM 抽取混乱按章节优先语义连贯抽取模型GLM-4-flashOpenAI 兼容用规则/正则提取无法理解语义抓不住建议这种主观表述用大模型GPT-4成本高 10 倍且 flash 对结构化抽取够用防编造机制强制 source_quote 自动回溯不强制引用LLM 会用自己的话概括无法验证是否忠实原文强制引用让每条知识都可追溯到 PDF 页码embedding 模型GLM embedding-3dim 2048BGE-M3本地需下载 2GB 模型HuggingFace CDN 在当前网络不可达GLM 在线 API国内可访问已验证可用向量库Qdrant独立 collection不用向量库纯关键词检索抓不住语义相似“全表扫描” vs “table access full”Qdrant 独立 collection不污染现有 oracle_best_practices去重策略标题归一化强去重不用语义去重语义去重embedding 相似度需加载 embedding 模型慢且有误判风险强去重确定性强可复现导出多目标一次构建导出 4 种格式只导向量库规则引擎/人工审查/结构化查询都用不了多目标同一份知识适配不同消费场景2.1.4 质量闸门分布数据在哪里被淘汰从 1031 条原始抽取到 847 条最终条目每一步的淘汰都有据可查不静默丢弃1031 条原始抽取 │ ├─ L1 剔除 -102 条source_quote 无法回溯原文 → 疑似编造 │ 清单: l1_mismatches.jsonl可审查每条为何被剔 │ ├─ 强去重合并 -82 条标题归一化后重复 │ └─▶ 847 条进入最终产物 │ ├─ L2 disputed 253 条保留但标 ⚠️不剔除——降级可见 │ 清单: l2_disputes.jsonl │ └─ safety 过滤 145 条 example_sql条目保留只清空示例 SQL 字段 原因: 含 DDL/多语句等被 backend 四层安全闸门拦截原则所有淘汰/降级都在报告和清单文件中显式列出不折叠为泛化的success。任何一条被剔除的知识都能查到原因。2.2 五阶段构建管线阶段做什么工具产出A. 文本提取PDF 每页提取文字 解析目录建立章节归属pdfplumber pypdf724 页原文697 有效页 27 跳过页B. 章节切片按章节边界 token 长度切成知识片段tiktoken1200 token/片150 重叠308 个 chunks覆盖 1-24 章全部C. LLM 抽取每个片段让 GLM-4 提取结构化知识规则/语法/示例GLM-4-flashOpenAI 兼容1031 条结构化条目D. 去重清洗标题去重 字段清洗 严重度归一Python 规则 启发式847 条最终条目E. 多目标导出同时导出 4 种格式供不同场景消费httpx SQLite jsonrules.json / SQLite / Markdown / Qdrant2.3 五层质量验证核心防止 LLM 编造构建知识库最大的风险是LLM 在抽取过程中编造内容把模糊记忆当文档内容输出。为此设计了五层验证层验证什么怎么验结果L0 完整性PDF 有没有漏页、产物数量一致机械计数dedupSQLiteQdrant847✓ 全过L1 一致性防编造底座每条知识能不能回溯到 PDF 原文强制source_quote字段自动回原文做子串匹配90.1% 通过剔除 102 条无法回溯的L2 语义校验抽取是否忠实原文非语义篡改第二轮 LLM 独立评判每条582 verified 253 disputed全保留降级L3 反向覆盖PDF 要点有没有被遗漏反向抽样每章抽页列要点查是否被覆盖70% 覆盖0 critical 遗漏L4 人工抽检最终可信度50 条人工对照 PDF 原文核对96% 全对48/50关键设计——L1 强制回溯每条抽取的知识必须带一句source_quote≥20 字必须是 PDF 原文精确子串。系统自动回 PDF 原文验证这句引用是否真实存在——这一层拦住了绝大多数 LLM 编造。2.4 最终知识库内容847 条类型数量说明示例optimization_rule372优化规则可被规则引擎/RAG 用“索引列避免函数或用函数索引 FBI”explanation350概念解释“什么是直方图、成本估算原理”syntax_doc95语法说明“CREATE INDEX 语法、DBMS_STATS 调用”example_sql30完整示例 SQL已过安全闸门频率直方图生成示例每条知识都带source_pagePDF 页码可追溯source_quote原文精确引用categoryINDEX/STATISTICS/JOIN/OPTIMIZER 等 14 类severityINFO/WARN/ERRORoptimization_rule 专属quality_flagverified/disputed质量分级2.5 构建耗时与成本真实数据项耗时说明文本提取724 页~10 分钟pdfplumberLLM 抽取308 片段~3.5 小时GLM-4-flash含网络重试L1-L4 验证~1.5 小时自动 人工抽检总计~5 小时一次性构建后续可增量GLM 调用次数~3000 次抽取 二次校验成本数元级别glm-4-flash 单价低三、知识库如何被使用3.1 集成到 Agent 主优化流程用户提交 SQL 后Agent 在让 LLM 改写之前先检索知识库找相关权威依据用户: SELECT * FROM orders WHERE UPPER(customer_name) ACME │ Agent 自动检索知识库用 SQL 语义匹配 │ ▼ 命中: [INDEX] 索引列上避免函数或用函数索引 FBI WHERE UPPER(name)X 会使 name 上的普通 B-tree 索引失效 来源: Oracle 12c SQL Tuning Guide p.211 │ ▼ 注入到 LLM prompt: knowledge 索引列避免函数... /knowledge │ ▼ LLM 生成变体: CREATE INDEX idx_cust_upper ON orders(UPPER(customer_name)); SELECT * FROM orders WHERE UPPER(customer_name) ACME; 变体的 rationale 引用了知识库依据不再是凭空建议3.2 多种使用方式方式场景怎么用Agent 自动接地已集成主优化流程调/api/optimizeRAG 自动注入用户无感向量检索Qdrant语义查询如何优化 X按 SQL/关键词检索返回最相关的 top-N 条结构化查询SQLite精确查某类规则/某页内容SQL 查询oracle_12c_kb.db按 category/severity 过滤人工查阅Markdown学习/审查33 个按章节组织的topics-*.md每条带原文引用规则引擎源rules.json补充 AST 规则372 条 optimization_rulebackend rules.json 兼容格式四、使用知识库的优点4.1 优化建议有权威依据核心价值维度无知识库有知识库建议来源LLM 模糊记忆Oracle 官方文档原文可追溯性无法验证每条建议带 PDF 页码 原文引用版本准确性可能混淆版本锁定 Oracle 12c 特性可信度用户不敢采纳用户可查原文确认4.2 LLM 编造被有效抑制L1 强制回溯机制每条知识必须引用 PDF 原文让知识库本身抗编造。Agent 基于这样的知识库生成建议等于给 LLM 加了必须引用手册的约束。4.3 知识可复用、可审计构建一次5 小时多处消费Agent 主流程用RAG 接地未来 chatbot 用语义问答规则引擎用372 条规则人工查阅用Markdown质量可审计五层验证每条可追溯到 PDF 页4.4 构建过程可复现、可增量全流程代码化ingestion包可重新构建断点续跑大文件中断可恢复第二本 PDFSQL Language Reference1920 页同管线配置已就绪五、使用知识库的缺点与局限诚实评估——知识库不是银弹以下局限必须知晓。5.1 检索质量受 query 构造影响当前主要痛点问题用原始 SQL 做 embedding query 效果一般。SQL 的语法噪音SELECT/FROM/WHERE淡化了优化意图。实例查SELECT * FROM employees WHERE UPPER(name)SMITH理想是命中函数索引那条规则实际命中的是泛化的Querying Table Informationscore 0.53。影响注入 LLM 的知识不一定是最相关的优化建议的针对性打折。缓解方向改用rule_findingsAST 规则发现文本或 SQL 特征描述做 query而非 raw SQL。5.2 引入额外延迟和依赖代价量级说明每次优化多 ~0.5sGLM embedding 0.45s Qdrant 检索 0.05s用户感知不明显但高并发下累积依赖 GLM embedding API在线服务API 不可达时降级为纯 LLM不阻塞但失去接地依赖 Qdrant 服务独立进程Qdrant 宕机时同样降级5.3 知识库覆盖率非 100%L3 反向覆盖率 70%非 80% 门槛抽样发现的 191 个 minor 遗漏多为细分要点无 critical 遗漏但意味着部分次要知识点未被独立抽取L4 人工抽检 96%2 条字段错放质量高但非完美253 条 disputedL2 有疑虑保留但标 ⚠️使用前建议人工核对5.4 构建前期投入大5 小时构建含 LLM 抽取 验证——虽然是一次性但比直接用 LLM重得多需要 PDF 原文——必须先有权威源文档需要 GLM API 额度——抽取校验约 3000 次调用5.5 embedding 方案的运维复杂度知识库用 GLM embeddingdim 2048与 backend 原有 BGE-M3dim 1024不兼容必须按 collection 选择 embedding 模型配置不能错错了维度不匹配查询失效切换 embedding 模型需重建整个向量库5.6 仅覆盖一本 PDF当前当前只构建了 SQL Tuning Guide724 页。SQL Language Reference1920 页语法大全尚未构建管线已就绪待启动。语法类问题目前知识库覆盖不足。六、总结值不值得做6.1 价值矩阵维度评分说明解决编造问题★★★★★L1 强制回溯 L2 二次校验从源头抑制 LLM 编造提升建议可信度★★★★★每条建议可追溯到 Oracle 官方文档页码构建成本★★★☆☆5 小时 3000 次 API一次性投入可接受检索质量★★★☆☆当前 query 构造偏弱有改进空间运维复杂度★★★☆☆多了 Qdrant GLM embedding 依赖但有降级容错覆盖范围★★★★☆724 页已覆盖调优核心1920 页语法待补6.2 适用与不适用场景适合用知识库数据库优化这种权威性要求高、错误代价大的领域有权威源文档官方手册、标准规范可抽取用户需要为什么这样优化的可解释性优化建议需要版本准确Oracle 12c 特性不适合用知识库没有权威文档的领域LLM 记忆已是最佳来源一次性快速验证构建 5 小时太重实时性要求极高检索增加 0.5s 延迟领域知识频繁变化知识库需频繁重建6.3 结论值得做。对于 SQLAdvisor 这类数据库优化工具知识库把 LLM 从不可控的顾问变成查了手册的顾问——这是从能用到敢用的关键一步。5 小时构建成本相比用户不敢采纳优化建议的代价是划算的。当前主要改进方向是检索质量query 构造和覆盖范围第二本 PDF这些是增量优化不影响知识库本身值得构建的基本判断。附录核心数字速查全部实测可追溯指标数值来源PDF 页数724pypdf 实测知识片段数308chunker 产出原始抽取条目1031extractor 产出最终知识条目847extracts_dedup.jsonoptimization_rule372type 统计L1 一致性通过率90.1%929/1031l1_verified.jsonl 计数L2 verified582quality_flag 统计L2 disputed保留降级253quality_flag 统计L3 反向覆盖率70.0%449/641l3_coverage_gaps.jsonL3 critical 遗漏0l3_coverage_gaps.jsonL4 人工抽检通过率96%48/50l4_audit_50.csv四产物一致性✓dedupSQLiteQdrant847实测构建总耗时~5 小时实际运行Agent 测试14/14 passed41.45s落盘测试日志