← 项目

企业级知识库（LLM 驱动）

把企业散落在 PDF、Word、表格、网页里的文档，变成一个能语义检索、能多跳推理、能追问出处的知识入口——不是「文档搜索框」，而是「读得懂、引得出、也敢说不知道」的企业知识层。

• LLM / RAG
• 文档理解
• 混合检索
• 向量 + BM25
• RRF 融合
• 重排
• 引用溯源
• 私有化部署

产品案例 · 企业级 AI 应用 · 2026

概览

场景与需求

企业里真正的知识问题不是「没文档」，是文档在里面，但没人找得到、也没人敢信。典型四条：

1. 格式太杂——合同是扫描 PDF、流程是 Word、台账是 Excel、制度是网页导出的 HTML，一个搜索框覆盖不了。
2. 关键词搜不到——员工问「出差超标准了怎么报销」，文档里写的是「差旅费报销标准」，字面不重合，传统全文检索直接漏掉。
3. 搜到了不敢用——模型开口就答，却给不出处；一旦编了一条制度条款，比搜不到更危险。
4. 数据不能出去——合同、研发文档、财务台账不允许上传到公有云 API，所以整条链路必须能私有化落地。

这个产品的目标就是把上面四条一次性接住：理解文档 → 找到依据 → 给出可溯源的回答，找不到依据就明说找不到。

它到底做了什么

文档入库 → 解析与结构化切块 → 向量化 + 全文索引
        → 混合召回 → 融合排序 → 重排精选 → 上下文组装
        → LLM 生成带引用的回答 → 溯源校验 → 输出 or 拒答

用户的体感是一句话：「问它，它给你答案，还告诉你这句话是从第几页第几段来的。」

难点与解法

1. 纯向量检索，在企业语料上一定不够用

向量召回擅长「意思相近」，但企业问答里大量存在精确匹配刚需：编号、型号、金额、条款号、专有名词。这些恰好是向量最弱的地方——把「GB/T 1234」和「GB/T 1235」映射到几乎同一个位置。

所以不做单一检索，做混合召回：向量检索 + 关键词检索（BM25）各出一路候选，再用 RRF（Reciprocal Rank Fusion）把两路按排名倒数融合。关键点是不做分数归一化——两路的相似度量纲根本不同，硬归一化等于引入一个假的权重；RRF 只吃排名，天然免疫这个问题。

2. 召回多不等于答得准，中间必须有一道「重排」

混合召回为了保召回率，候选池是刻意放宽的（比如 20 条），但全塞进上下文既贵又吵——噪声片段会把模型带偏。

解法是加一层 Cross-Encoder 重排：把每个候选片段和问题成对送进模型打分，而不是像向量那样各算各的再比距离。代价是慢，所以只对 Top-N 做，用它把 20 条压到 3–5 条真正相关的。召回宽松、精排严格，这两步的分工不能混。

3. 切块策略，决定了这套系统的能力上限

最省事的做法是按固定字数切——结果是表格被切断、条款被拆到两半、标题和正文分家。检索出来全是残句。

改成结构感知切块：先按文档自身的层级（标题 / 小节 / 表格 / 列表）切，只在层级内部再按长度兜底；同时给每个块带上「所属章节路径」的元信息，让一个片段在检索时还能知道自己「从哪来」。块大小也不是一个常数——长制度条文和短 FAQ 需要的粒度不同。

4. 幻觉的真正难点，不是「模型不肯承认不知道」

这是整个项目里最反直觉的一条。

直觉上的解法是「提示词里写上：不确定就说不确定」。但工程上立刻会撞到一堵墙：你没有一个可靠手段去检测它此刻是不是在编。 模型编造的条款读起来和真的条款完全一样，语气一样笃定，格式一样规范。指望模型自我报告，等于把质检交给被质检的人。

所以不从「检测」下手，从流程下手，让它想编也编不出来：

• 先检索、后生成，上下文里没有的，提示词明确禁止出现；
• 强制引用：每个结论必须挂上来源块 id，模型输出后由代码反查，引用对不上就重生成或降级；
• 允许空手而归：召回分数低于阈值时直接走拒答话术，宁可回答「文档里没有相关规定」，不产出猜测；
• 回答里保留原文片段，让用户能一眼核对，而不是只能信。

产品的态度是：一个会说「我不知道」的知识库，比一个什么都能答的聊天框有用。

5. 权限必须做在检索层，而不是展示层

企业知识库天然是多租户的：HR 的制度、研发的设计文档、财务的台账，不该互相看见。

风险在于如果只在界面上过滤，等于把不该看的文档召回到了上下文里再藏起来——模型照样可能把内容说出去。

做法是权限前置到检索：过滤条件（部门 / 角色 / 密级 / 文档标签）在查询阶段就进检索过滤，不允许越权的块进入候选池。模型看不到的东西，它就不可能说出来。

6. 把「回答质量」变成可优化的指标，而不是凭感觉

没有评测集，改切块参数、换模型、调 Top-K 全是玄学——这次感觉好了，换个问题又崩了。

所以后台里带一套评测能力：固定一批真实问题 + 人工标注的标准答案/来源文档，每次改动跑一遍，对比召回命中率和回答准确率。先能量化，才谈得上优化。

架构

                ┌───────────────  React 管理后台  ───────────────┐
                │ 文档库管理 · 切块预览 · 检索调试 · 评测看板      │
                └────────────────────┬───────────────────────────┘
                                     │ HTTP
                      ┌──────────────▼──────────────┐
                      │        FastAPI 服务端        │
                      ├─────────────────────────────┤
   入库链路            │ 解析器 → 结构切块 → 向量化   │
                      │ 索引写入（向量 + 全文）      │
                      ├─────────────────────────────┤
   查询链路            │ 查询改写 → 混合召回 → RRF    │
                      │ → Cross-Encoder 重排         │
                      │ → 上下文组装 → LLM 生成      │
                      │ → 引用校验 → 输出 / 拒答     │
                      └──────┬───────────────┬──────┘
                             │               │
                    向量数据库（embedding）  全文索引（BM25）
                             │               │
                        ┌────┴───────────────┴────┐
                        │   PostgreSQL / 对象存储   │
                        └─────────────────────────┘

检索链路（逐段拆）

适用场景

• 制度与流程问答——员工问制度条款，答案必须能点回原文
• 合同与法务文档检索——条款级精确定位，编号/金额不能错
• 研发文档与技术资料——设计文档、接口文档、规范手册的语义检索
• 售后与产品知识——手册、FAQ、工单历史沉淀为可问答知识
• 多文档综合推理——需要跨几份文档把信息拼起来才能回答的问题

其他作品

AI问答搜索

用户一句口语化的选址需求，AI 自动筛选匹配园区资源，输出文字推荐 + 多张候选园区卡片，可点开详看，也能继续追问深挖参数与入驻条件。

dsh-find-jobs — 个人求职 Agent 插件

挂在 DeepSeek Harness 上的求职 Agent——不是求职网站，也不是聊天框，而是「了解我，然后替我持续找出真正值得投的岗位」。

GEO 月度复盘报告 PPT（Skill 链）

把「拉数据 → 出大纲 → 出片」拆成三个各司其职的 Skill——AI 负责理解与撰写，Skill 负责口径与结构，代码只做确定性的事。