
新员工入职第一天,HR告诉他:“公司有AI使用规范,你先看一下。”
他打开公司文档库,搜索“AI规范”,返回37个结果:
他花了三小时,打开十几个文档,才拼凑出完整信息。
这个场景暴露了企业AI知识管理的三个工程问题:
问题 | 技术表现 |
|---|---|
文档分散 | 无统一元数据索引,多存储源并存 |
版本混乱 | 无版本控制机制,命名规范缺失 |
权限不清 | 无RBAC权限模型,授权流程黑盒 |
整体架构:
text
┌─────────────────────────────────────────────┐
│ 接入层 │
│ Web端 │ 移动端 │ API Gateway │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ 服务层 │
├─────────────────────────────────────────────┤
│ 文档服务 │ 版本服务 │ 权限服务 │ 搜索服务 │
└─────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ 存储层 │
│ OSS(文档存储) │ MySQL(元数据) │ ES(全文检索) │
└─────────────────────────────────────────────┘在具体实现上,有企业采用 ZGI 作为知识管理平台的底座,其文档服务、版本控制、权限体系覆盖了上述全部能力。
核心数据模型(简化版):
sql
-- 文档元数据表
CREATE TABLE document (
id BIGINT PRIMARY KEY,
title VARCHAR(255),
version VARCHAR(32), -- 语义版本号
status VARCHAR(32), -- draft/review/published/archived
author_id BIGINT,
department VARCHAR(64), -- 所属部门
created_at DATETIME,
updated_at DATETIME
);
-- 文档版本关联表
CREATE TABLE document_version (
id BIGINT PRIMARY KEY,
doc_id BIGINT,
version VARCHAR(32),
oss_path VARCHAR(512),
changelog TEXT,
created_at DATETIME
);
-- 权限策略表(RBAC扩展)
CREATE TABLE policy (
id BIGINT PRIMARY KEY,
resource_type VARCHAR(64), -- document/folder/tag
resource_id BIGINT,
role VARCHAR(64), -- manager/editor/viewer
subject_type VARCHAR(64), -- user/department/role
subject_id VARCHAR(128)
);设计目标: 解决“哪个版本是当前有效版”的问题。
版本号规范:
采用语义版本号 + 状态标识:
<major>.<minor>.<patch>-<status>示例:
3.2.0-published:当前有效版本3.1.2-archived:已归档的历史版本4.0.0-draft:草稿版本,生产中不可见版本状态流转:
text
draft → review → published → archived
↓
rejected → draftAPI设计示例:
text
# 获取有效版本
GET /api/documents/{id}/active
→ { version: "3.2.0-published", content_url: "..." }
# 获取版本历史
GET /api/documents/{id}/versions
→ [{ version: "3.2.0", status: "published" },
{ version: "3.1.2", status: "archived" }]
# 发布新版本
POST /api/documents/{id}/versions
Body: { version: "3.3.0", content: "...", changelog: "增加DeepSeek模型说明" }版本存储策略:
{doc_id}/{version}/路径存储设计目标: 实现“不同角色、不同部门看到不同内容”。
RBAC扩展模型:
实体类型 | 示例 | 说明 |
|---|---|---|
用户 | user:zhangsan | 系统用户 |
部门 | dept:marketing | 组织单元 |
角色 | role:editor | 权限集合 |
资源 | doc:ai-spec | 被保护对象 |
策略 | policy:1 | 角色-资源关联 |
权限规则示例(JSON格式):
json
{
"policies": [
{
"resource": "doc:ai-spec",
"role": "viewer",
"subject": "dept:marketing",
"effect": "allow"
},
{
"resource": "doc:ai-spec",
"role": "editor",
"subject": "dept:it",
"effect": "allow"
},
{
"resource": "doc:ai-spec",
"role": "admin",
"subject": "user:admin",
"effect": "allow"
}
]
}权限校验流程:
text
1. 用户发起请求 GET /documents/{id}
2. 网关解析JWT,获取用户身份(user_id/dept/roles)
3. 权限引擎查询该文档的策略
4. 匹配用户身份与策略规则
- 用户是否在白名单?
- 部门是否匹配?
- 角色是否满足?
5. 返回200或403中间件实现示例(伪代码):
python
def auth_middleware(request):
user = get_user_from_token(request.token)
doc = get_document(request.doc_id)
policies = get_policies(doc.id)
for policy in policies:
if check_policy(user, policy):
return next()
return HTTPResponse(403, "无权限访问")设计目标: 用户输入关键词,快速定位到正确的文档和章节。
索引字段:
字段 | 类型 | 说明 |
|---|---|---|
title | text | 标题 |
content | text | 正文 |
tags | keyword | 标签 |
department | keyword | 所属部门 |
status | keyword | 状态(仅published可搜) |
搜索优先级:
API示例:
GET /api/search?q=AI规范&department=marketing
→ {
"docs": [
{ "title": "AI工具使用规范", "version": "3.2.0", "score": 0.95 },
{ "title": "数据安全红线", "version": "2.1.0", "score": 0.82 }
]
}某企业上线该系统后:
指标 | 上线前 | 上线后 |
|---|---|---|
文档查找耗时 | 3-4小时 | <10分钟 |
版本歧义投诉 | 每月8次 | 0次 |
权限申请时长 | 2天 | 2小时 |
企业AI知识管理系统不是简单的文档库,而是一个包含版本控制、权限体系、全文搜索的完整工程系统。
核心设计要点:
本文基于企业知识管理系统建设实践整理。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。