员工守则智能问答 Agent 技术选型
创建日期:2026-07-16 场景:本公司员工守则/规章制度智能问答 核心结论:采用 Baseline RAG(Hybrid 检索 + Rerank + 结构化切片),不采用 GraphRAG
一、需求分析
| 维度 | 说明 |
|---|---|
| 知识来源 | 员工守则、规章制度、管理办法、FAQ(待确认文档形态:Word/PDF/Confluence) |
| 问题类型 | 80% 精确事实查询(年假天数、报销限额、考勤规则、入职流程、福利标准) |
| 硬性要求 | 回答必须标注条款出处(可溯源),员工能核对原文 |
| 潜在要求 | 按岗位/部门权限隔离(不同岗位可见不同守则) |
| 更新频率 | 守则随政策调整频繁变更,需支持增量更新 |
二、核心选型:Baseline RAG vs GraphRAG
结论:用 Baseline RAG,不上 GraphRAG
GraphRAG(微软)流程:切 TextUnit → LLM 抽实体/关系 → Leiden 层次聚类成社区 → 生成社区摘要。查询分 Global/Local/DRIFT/Basic 四种模式。
GraphRAG 的优势在两类问题上:
- 连点成线:答案需跨多篇文档、通过共享属性串联才能综合
- 全局主题概括:对整个数据集做整体性总结
为什么员工守则场景用不上 GraphRAG
| 维度 | 员工守则实际情况 | 谁占优 |
|---|---|---|
| 问题类型 | 精确事实查询为主 | Baseline RAG 主场 |
| 索引成本 | GraphRAG 用 LLM 抽实体+社区摘要,token 消耗是 RAG 的 10-100 倍 | Baseline 便宜 |
| 更新频率 | 守则经常改,GraphRAG 改一条可能要重算社区 | Baseline 增量更新便宜 |
| 全局推理需求 | 员工很少问"制度全景如何" | GraphRAG 优势用不上 |
| 可溯源 | 需标注条款号,向量检索天然带原文片段 | Baseline 更直接 |
GraphRAG 唯一对守则有价值的场景:守则里大量交叉引用(如"按《差旅管理办法》第三章执行")。但这用轻量手段就能解决(交叉引用映射表,或检索时召回同章节/引用链),不必上完整 GraphRAG。
三、技术架构
员工守则文档(Word/PDF/Confluence)
↓
文档解析(结构化,保留章节层级+表格)
↓
结构化切片(按章/节/条款,保留条款号、标题、metadata)
↓
Embedding(bge-m3,中英多语言)
↓
向量库(Qdrant / Milvus 生产,Chroma 起步)
↓
检索:Hybrid = BM25 关键词 + 向量语义
↓
Rerank(bge-reranker-v2-m3,召回 top20 → 取 top5)
↓
LLM(DeepSeek-V3 / GLM)生成回答
↓
回答 + 强制标注出处条款号(如"依据《员工守则》第5.2条")四、各组件选型
1. 文档解析
- PDF/Word:Unstructured / PyMuPDF / python-docx
- 表格单独处理:守则常有表格(报销标准表、假期天数表),必须结构化解析,不能当普通文本
- 推荐 RAGFlow 自带的深度解析(对规章/表格还原最好)
2. 切片策略(关键)
- 按文档结构切,不按固定 chunk_size 硬切
- 每个条款作为一个 chunk,保留层级路径(如"第五章 考勤管理 > 5.2 请假流程")
- chunk 大小:按条款语义边界,通常 200-800 token
- metadata 必填:所属章节、条款号、文档名、版本号、生效日期、适用部门(用于权限过滤)
3. Embedding 模型
| 模型 | 说明 |
|---|---|
| bge-m3(推荐) | 中英多语言,中文最强一档,支持稠密+稀疏+多向量,本地部署免费 |
| bge-large-zh-v1.5 | 纯中文,轻量备选 |
| (商用)OpenAI text-embedding-3 | 效果好但要 API 费+出境 |
4. 向量库
| 方案 | 适用 |
|---|---|
| Qdrant(推荐生产) | 性能好,支持 payload 过滤(权限隔离),Rust 写 |
| Milvus | 大规模分布式 |
| Chroma | 起步/Demo,轻量零配置 |
5. 检索:Hybrid(必须)
- 员工守则专有名词/条款号多(如"五险一金""G3职级""第5.2条"),纯向量检索会漏
- BM25 关键词 + 向量语义 混合,初始权重建议 BM25 0.3 / 向量 0.7,按效果调
- 召回 top 20 → rerank 取 top 5
6. Rerank
- bge-reranker-v2-m3(推荐),中英,本地部署
7. LLM
- DeepSeek-V3(用户已有 hermes/ccs 接入经验),性价比高,中文好
- 备选:GLM-5(本公司若有 GLM 接入)
8. 出处引用(硬要求)
- Prompt 强制 LLM 在每个事实后标注来源条款号
- 返回结构:
{answer, citations: [{doc, section, clause_no, snippet}]}
五、成熟方案对比(不想从零搭)
| 方案 | 特点 | 适合 |
|---|---|---|
| RAGFlow(InfiniFlow,国内开源) | 深度文档解析,表格/规章结构化还原好,自带 hybrid+rerank | 首推,守则类文档解析最强 |
| MaxKB | 企业知识库开箱即用,多用户权限,接微信/钉钉/飞书 | 快速上线+企业 IM 集成 |
| FastGPT | 可视化 RAG 工作流,灵活 | 需定制检索流程 |
| Dify | 通用 LLM 应用平台 | 已有 Dify 基础 |
| 自建 | 最大灵活,成本最低(只付 LLM/embedding) | 长期可控,有技术力 |
建议:起步用 RAGFlow(省文档解析的坑),验证效果后视需要迁自建。
六、成本估算(粗略)
假设:100 篇守则,平均 5000 字 = 50 万字;日均 1000 次问答。
| 项目 | 成本 |
|---|---|
| 索引 embedding | bge-m3 本地部署 = 免费;API 约 ¥0.5 一次性(可忽略) |
| 单次问答 LLM | 输入 ~2000 token + 输出 ~500 token,DeepSeek 约 ¥0.008/问 |
| 月度 LLM(1000问/天) | 约 ¥240/月 |
| 基础设施 | 一台 4C8G 服务器(Qdrant+DeepSeek API 调用)即可起步 |
成本极低,瓶颈在文档质量和切片/检索效果调优,不在算力。
七、落地路线
| 阶段 | 周期 | 内容 |
|---|---|---|
| Phase 1 验证 | 1 周 | RAGFlow 部署 + 导入样例守则 + 验证检索/回答效果 |
| Phase 2 调优 | 1-2 周 | 切片策略调优、Hybrid 权重调参、Rerank 接入、出处引用 |
| Phase 3 增强 | 按需 | 权限隔离、多轮对话、前端集成(企业微信/钉钉/网页) |
八、风险与对策
| 风险 | 对策 |
|---|---|
| 切片不当导致答案断裂 | 严格按条款语义边界切,保留层级路径 |
| 专有名词/条款号召回不准 | Hybrid 检索(BM25 不可省) |
| 守则更新未同步 | 增量更新流程:文档变更 → 重解析受影响条款 → 重 embedding |
| 越权访问敏感守则 | metadata 标适用部门,检索时按用户部门过滤 |
| LLM 编造(幻觉) | Prompt 强制"只能基于检索到的条款回答,无依据则说不知道" |
九、后续待确认
- 守则文档形态(Word/PDF/Confluence/飞书文档)?
- 大致多少篇、有无大量表格?
- 是否需要按岗位权限隔离?
- 接入渠道(网页/企业微信/钉钉)?
- 本公司是否有可用的 LLM 接入(DeepSeek/GLM/自建)?
确认后可直接进入 Phase 1。
十、补充:LLM Wiki(Karpathy 预编译模式)——第三条路
注:初版只对比了 Baseline RAG 与 GraphRAG,漏了实际更贴合的 LLM Wiki(nashsu/llm_wiki,基于 Karpathy LLM Wiki 模式)。此章补齐。
本质:预编译 vs 查询时检索
| Baseline RAG | GraphRAG | LLM Wiki | |
|---|---|---|---|
| 核心 | 查询时向量检索+LLM | 查询时图谱增强 | 预先 LLM 编译成 wiki,查询读 wiki |
| 哲学 | 每次重新推导 | 每次图谱增强 | compile once, query many |
| 知识形态 | 切片+embedding | 实体/关系图 | 人可读 markdown+wikilink+图谱(Obsidian 兼容) |
| 跨文档推理 | 弱 | 强 | 强(wikilink+4 信号图谱) |
| 可审计 | 差 | 差 | 好(markdown 人可读,法务/领导能审) |
| 编译成本 | 低 | 高 | 中(一次性,SHA256 增量缓存) |
为什么员工守则很适合 LLM Wiki
- 守则相对稳定(政策文档)→ 预编译划算,不用每次查询重新推导
- 需深度理解+关联(制度引用、适用范围)→ wikilink + 知识图谱(4 信号:直接链接/来源重叠/Adamic-Adar/类型亲和 + Louvain 社区发现)强,还能发现"惊喜连接""知识缺口"
- 可溯源+可审计 → wiki 页带
sources: [],且 markdown 人可读 - 中文生成、Obsidian 兼容(HR 可直接维护)
- MCP Server(127.0.0.1:19828)+ 现成 Claude Code skill(
npx skills add nashsu/llm_wiki_skill)→ 直接接入现有 Claude Code 工作流 - 支持 DeepSeek
<think>、增量缓存、Deep Research(Tavily/SerpApi/SearXNG)
部署形态决定方案(关键决策点)
- 个人 / HR / 小团队 / 给 Claude Code agent 当知识源:LLM Wiki 直接上,优于 Baseline RAG
- 全公司员工 web/IM 自助问答(服务化):LLM Wiki 是桌面应用定位,需服务化——可作"知识编译层"(守则→wiki),问答层另搭薄服务读 wiki,或用 RAGFlow/自建 RAG
结论修正
- 若问答系统是个人/小团队/agent 知识源定位 → 首选 LLM Wiki(深度理解+可审计+接 Claude Code)
- 若全公司服务化 → LLM Wiki 编译层 + RAG 服务层组合,或纯 RAGFlow