Case Study 01 — Enterprise Knowledge Assistant（企业知识助手）

知识库位置：FDE Knowledge Base/06 Case Studies/01-Enterprise-Knowledge-Assistant.md

Case Metadata（案例元数据）

Case ID: CS-001

Industry（行业）:
Cross-industry（跨行业）

Primary Domain（主要领域）:
Enterprise Knowledge（企业知识管理）

Case Type（案例类型）:
Reference Scenario（参考情景）

Complexity（复杂度）:
Medium（中）

Primary Technologies（主要技术）:
RAG（检索增强生成）
Hybrid Search（混合检索）
SSO（单点登录）
LLM（大语言模型）

Business Function（业务职能）:
Knowledge Management（知识管理）

Delivery Stage（交付阶段）:
End-to-End（端到端）

Status: Core
Version: v0.1

本案例为 Reference Scenario（参考情景）：用于教学和方法论说明的综合案例，并非某个真实客户项目。参见 Case Studies README（案例域使用说明）。

1. Customer Background（客户背景）

客户是一家拥有数千名员工的大型企业。

内部知识分散在：

SharePoint（微软文档协作平台）
Wiki（维基知识库）
PDF（Portable Document Format，便携式文档格式）
Policy Documents（政策文档）
Product Manuals（产品手册）
Internal Knowledge Base（内部知识库）
Department Documents（部门文档）

员工经常需要在多个系统之间搜索信息。

2. Business Problem（业务问题）

业务团队最初提出：

我们想做一个企业 ChatGPT。

FDE 在 Discovery（客户调研）后发现，真正的问题不是缺少 Chatbot（聊天机器人），而是：

员工找到可靠内部信息的成本过高。

当前流程：

Employee Question（员工提问）
↓
Search Wiki（搜索维基）
↓
Search SharePoint（搜索文档平台）
↓
Search PDF（搜索 PDF 文档）
↓
Ask Colleague（询问同事）
↓
Ask Subject Matter Expert（询问领域专家）

造成：

信息搜索耗时
重复问题大量出现
不同人员得到不同答案
专家经常被重复打断
新员工学习成本高

因此 Problem Statement（问题陈述）定义为：

Employees cannot quickly find reliable and permission-appropriate internal knowledge, resulting in wasted time and inconsistent decisions.

（员工无法快速找到可靠且权限合规的内部知识，造成时间浪费和决策不一致。）

3. Discovery（客户调研）

FDE 进行了以下调查。

Business Discovery（业务调研）

访谈：

HR（Human Resources，人力资源）
IT（信息技术部门）
Sales（销售）
Operations（运营）
Knowledge Management（知识管理团队）
一线员工

重点问题：

员工每天找哪些信息？
哪些问题频率最高？
哪些知识最难找？
哪些答案如果错误会产生较高风险？

Data Discovery（数据调研）

发现知识源包括：

SharePoint（文档平台）
Wiki（维基）
Google Drive（云端硬盘）
PDF（PDF 文档）
Internal Web Pages（内部网页）

同时发现三个关键问题。

Problem 1（问题一）

旧版本文档没有删除。

Problem 2（问题二）

部分文档权限严格。

Problem 3（问题三）

不同部门存在内容冲突。

因此项目并不是：

把所有文件 Embedding（向量化）。

而首先需要解决：

Knowledge Governance（知识治理）
+
Permission（权限）
+
Retrieval（检索）

4. Scoping（范围界定）

第一阶段没有覆盖全公司。

选择：

Department（部门）:
Internal IT Support（内部 IT 支持）

Users（用户）:
200 employees（200 名员工）

Knowledge（知识范围）:
IT policies（IT 政策）
Software guides（软件指南）
Access procedures（权限申请流程）
Internal troubleshooting（内部故障排查）

明确 Out of Scope（范围外）：

HR Confidential Documents（人力资源保密文档）
Financial Documents（财务文档）
Automatic IT Action（自动执行 IT 操作）
Employee Personal Data（员工个人数据）

Success Metrics（成功指标）

定义三层指标。

Technical（技术层）

Retrieval Quality（检索质量）
Answer Groundedness（回答事实有据性）
Citation Correctness（引用来源正确性）
Latency（延迟）

User（用户层）

Search Success Rate（搜索成功率）
User Satisfaction（用户满意度）
Repeat Usage（重复使用率）

Business（业务层）

Average Time to Find Information（平均信息查找时长）
Repeated Internal Support Questions（重复内部支持问题数）
SME Interruption Rate（领域专家被打断率，SME = Subject Matter Expert）

5. Architecture Design（架构设计）

初始方案：

Employee（员工）
↓
SSO（单点登录）
↓
Knowledge Assistant（知识助手）
↓
Query Processing（查询处理）
↓
Permission Filter（权限过滤器）
↓
Hybrid Retrieval（混合检索）
↓
Reranker（重排序器）
↓
LLM（大语言模型）
↓
Answer + Citation（回答 + 引用溯源）

知识处理流程：

Enterprise Sources（企业知识源）
↓
Document Connector（文档连接器）
↓
Parsing（解析）
↓
Metadata Extraction（元数据提取）
↓
Chunking（分块）
↓
Embedding（向量化）
↓
Search Index（检索索引）

Key Architecture Decision 1（关键架构决策一）：RAG vs Fine-tuning（检索增强生成 vs 微调）

选择：

RAG（检索增强生成）

原因：

企业知识持续变化
需要引用来源
需要快速删除旧知识
需要 Permission-aware Retrieval（权限感知检索）

关联：Decision Guide：RAG vs Direct Database Query（RAG vs 直接数据库查询）

Key Architecture Decision 2（关键架构决策二）：Vector Search Only vs Hybrid Search（纯向量检索 vs 混合检索）

Prototype（原型）初期使用纯 Vector Search（向量检索）。

发现：

产品编号、错误代码、内部缩写检索效果较差。

例如：

ERR-1024
VPN-X7
FIN-POL-23

因此改为：

Keyword Search（关键词检索）
+
Vector Search（向量检索）
+
Reranking（重排序）

Key Architecture Decision 3（关键架构决策三）：权限在哪里控制？

不采用：

Retrieve Everything（检索全部内容）
↓
Ask LLM not to reveal restricted documents
（要求 LLM 不泄露受限文档）

而采用：

User Identity（用户身份）
↓
Permission Filter（权限过滤器）
↓
Retrieval（检索）

即：

权限必须在 Retrieval（检索）之前执行。

6. Engineering Implementation（工程实现）

Document Pipeline（文档管道）

实现：

Source Connector（源连接器）
↓
Parser（解析器）
↓
Metadata（元数据）
↓
Chunker（分块器）
↓
Embedding（向量化）
↓
Indexer（索引器）

Metadata（元数据）包括：

document_id（文档编号）
source（来源）
department（部门）
owner（责任人）
version（版本）
effective_date（生效日期）
permission_group（权限组）
status（状态）

Retrieval Pipeline（检索管道）

User Query（用户查询）
↓
Query Rewrite（查询改写）
↓
Metadata Filter（元数据过滤）
↓
Hybrid Retrieval（混合检索）
↓
Reranker（重排序器）
↓
Top Context（最相关上下文）

Generation（生成）

要求：

只能根据提供内容回答
必须提供 Citation（引用溯源）
无可靠答案时明确说不知道（Abstain，拒答）
不允许根据模型已有知识推测内部政策

Observability（可观测性）

记录：

Query（查询）
Retrieved Documents（检索到的文档）
Retrieval Scores（检索得分）
Prompt Version（提示词版本）
Model（模型）
Answer（回答）
Citation（引用）
Latency（延迟）
Feedback（用户反馈）

7. Prototype（原型）

Prototype（原型）使用：

500 份文档
50 个典型问题
20 名内部用户

最初结果：

简单问题效果不错
复杂政策问题容易引用错误版本
缩写和产品编号 Retrieval（检索）较差

Prototype Troubleshooting（原型问题排查）

问题：

系统经常检索旧版政策。

诊断发现：

Index（索引）中没有：

active_version（生效版本标记）

于是增加：

status = ACTIVE（状态 = 生效）
effective_date（生效日期）
version（版本）

并在 Retrieval（检索）时过滤旧版本。

关联：RAG Retrieves Wrong Documents（RAG 检索错文档）

8. Pilot（试点）

Pilot（试点）扩展到约 100 名员工。

进行了：

User Training（用户培训）
Feedback Collection（反馈收集）
Weekly Evaluation（每周评估）
Failed Query Review（失败查询复盘）

发现新的问题：

员工经常问：

我的 VPN 权限为什么还没开？

这不是知识问题，而是实时业务状态问题。

因此系统扩展：

Question Router（问题路由器）
├─ Knowledge（知识问题）→ RAG（检索增强生成）
└─ Status（状态问题）→ IT Service API（IT 服务接口）

这是典型的：

RAG（检索增强生成）
+
Transactional API（事务型 API）

混合架构。

9. Production（生产）

上线前增加：

SSO（Single Sign-On，单点登录）
Permission-aware Retrieval（权限感知检索）
Rate Limit（限流）
Monitoring（监控）
Document Refresh Pipeline（文档刷新管道）
Feedback Dashboard（反馈看板）
Incident Runbook（事故运维手册）

并建立：

Document Owner（文档责任人）
→ Knowledge Review（知识评审）
→ Update（更新）
→ Index Refresh（索引刷新）

解决知识长期维护问题。

10. Business Outcome（业务结果）

上线后重点跟踪：

Search Time（搜索耗时）
Support Ticket Volume（支持工单量）
User Adoption（用户采用）
Answer Success Rate（回答成功率）
SME Interruptions（领域专家被打断次数）

假设内部评估发现：

Average search time（平均搜索时长）
8 min → 2 min（8 分钟 → 2 分钟）

真正重要的结论不是：

RAG Accuracy（RAG 准确率）很高。

而是：

员工获取知识的时间明显下降。

11. Challenges & Troubleshooting（挑战与问题排查）

主要挑战：

12. Key Decisions（关键决策）

Decision（决策）	Options（选项）	Choice（选择）	Why（原因）
知识接入方式	RAG vs Fine-tuning	RAG	知识持续变化、需要引用与删除
检索方式	Vector Only vs Hybrid	Hybrid + Reranking	编号/缩写需要关键词检索
权限控制位置	生成后约束 vs 检索前过滤	检索前过滤	权限必须在 Retrieval 之前执行
实时状态问题	全部塞进 RAG vs API 路由	Question Router + Transactional API	实时数据应走 API

13. Reusable Lessons（可复用经验）

Enterprise RAG（企业级 RAG）首先是 Knowledge Governance（知识治理）问题，其次才是模型问题。
权限必须在 Retrieval Layer（检索层）控制。
文档版本管理非常重要。
Semantic Search（语义检索）并不等于业务正确性。
实时数据应该通过 API，而不是全部塞进 RAG。
Citation（引用溯源）是企业知识系统的重要信任机制。