企业做知识库问答时，最容易犯的错误是把大模型当成一个“万能客服接口”。把用户问题直接丢给 Gemini，让模型自由发挥，短期看似能回答问题，但一旦进入真实业务场景，就会暴露很多问题：答案没有来源、权限无法控制、旧文档被误用、不同版本政策混在一起，甚至可能把内部资料回答给不该看到的人。

因此，企业知识库更合理的建设方式不是“模型直连问答”，而是采用 RAG，也就是检索增强生成。它的核心思想很简单：先从企业自己的资料中检索出相关内容，再让模型基于这些资料回答问题。

整体流程可以拆成这样：

原始文档 -> 清洗 -> 切片 -> embedding -> 向量库
用户问题 -> embedding -> 检索 -> 重排 -> 拼接上下文 -> Gemini 生成答案 -> 引用来源 -> 日志与评估

这套流程把“知识从哪里来”和“答案怎么写”分开了。Gemini 主要负责理解问题、整合上下文和生成自然语言答案；企业系统则负责文档管理、权限控制、检索召回、来源引用和效果评估。

一、知识片段不能只存正文

很多团队第一次做 RAG 时，只把文档正文切成片段，然后存入向量库。这样做在 Demo 阶段可以跑通，但不适合企业场景。因为企业知识往往带有版本、部门、权限、更新时间等信息，这些字段会直接影响答案是否可信。

一个较完整的知识片段可以设计成下面这样：

{
  "chunk_id": "faq_20260608_001",
  "doc_id": "product_manual_v6",
  "title": "企业版账号权限说明",
  "content": "管理员可以创建角色，并为角色分配菜单、数据和操作权限...",
  "source_url": "https://example.com/docs/product_manual_v6#account-role",
  "version": "v6.0",
  "department": "product",
  "security_level": "internal",
  "updated_at": "2026-06-01"
}

这里最重要的不只是 content，而是 version、department、security_level、updated_at 这些元数据。比如用户问“企业版是否支持角色权限”，系统不仅要找到相关内容，还要判断这是不是当前有效版本，用户有没有权限查看，答案最后能不能展示来源链接。

如果这些字段在一开始没有设计好，后续想补权限、补审计、补版本治理，成本会很高。

二、文档切片要保持语义完整

RAG 效果好不好，很大程度不取决于模型，而取决于切片。常见错误有三类。

第一类是按固定字数切片。比如每 500 字切一次，看起来很整齐，但可能把一个完整规则拆成两半。用户问退款周期时，检索到的片段只有“7 个工作日内处理”，却没有上文的适用条件，模型就容易答错。

第二类是片段过长。片段越长，向量相似度越容易变钝，系统可能把很多无关内容一起召回，导致模型读到噪声。

第三类是不保留标题层级。企业文档通常有章节结构，同样是“权限”，可能属于账号权限、数据权限、菜单权限或审批权限。如果切片时丢掉标题，模型很难判断上下文边界。

更实用的做法是按标题、段落、FAQ、表格行、接口章节来切片。每个片段既要短到方便检索，又要保留完整语义。对于产品手册，可以按章节和小标题切；对于客服 FAQ，可以按一问一答切；对于接口文档，可以按接口路径、参数说明和错误码拆分。

三、检索阶段就要做权限过滤

企业知识库最忌讳“先把资料给模型，再让模型决定能不能回答”。权限控制必须发生在检索阶段，而不是生成之后。

一个简化的问答流程可以这样写：

def answer(question, user):
    query_vec = embed(question)

    candidates = vector_db.search(
        vector=query_vec,
        top_k=20,
        filters={
            "security_level": {"$in": user.allowed_levels},
            "status": "active"
        }
    )

    reranked = rerank(question, candidates)[:5]
    prompt = build_prompt(question, reranked)

    return call_gemini(prompt)

这里有两个关键点。

第一，top_k=20 表示先从向量库中召回 20 个候选片段，给后续重排留下空间。第二，rerank(question, candidates)[:5] 表示重排后只取前 5 个最相关片段进入提示词。这样既能减少无关上下文，也能控制 Token 成本。

权限过滤和状态过滤也要放在 vector_db.search 阶段。例如 security_level 必须匹配用户允许访问的范围，status 必须是 active。如果过期文档、内部资料、草稿资料已经进入模型上下文，再要求模型“不要泄露”，风险就已经产生了。

四、提示词越稳定越好

企业知识库的提示词不需要花哨，核心目标是约束模型只基于检索资料回答，并且在资料不足时明确拒答。

可以使用下面这种模板：

你是企业知识库问答助手。
请只根据〖资料片段〗回答用户问题。
如果资料不足，请说明“当前知识库没有足够信息”，不要编造。
回答后列出引用来源，格式为：文档名 + 版本 + 链接。

〖用户问题〗
{question}

〖资料片段〗
{retrieved_chunks}

这个模板的重点不是“让模型更聪明”，而是让答案更可控。企业知识库真正需要的是准确、可追溯、可拒答，而不是生成一段看起来很流畅但来源不明的内容。

如果资料片段中没有答案，模型应该回答“当前知识库没有足够信息”，而不是根据常识猜测。拒答能力也是 RAG 系统的重要指标。

五、模型接入不只是调用 API

在模型选择上， Gemini 3.5 Flash、Gemini 3.1 Pro、GPT-5.5、Claude Opus 4.8 等模型组合思路：低延迟、价格友好的模型可以承担主路径，复杂推理和疑难问题再交给更强模型处理。这个思路的关键不是追求模型数量，而是让系统在延迟、成本、稳定性和复杂任务能力之间有调整空间。

如果团队已经有多模型评估需求，也可以在 POC 阶段把 TreeRouter 作为一个大模型 API 聚合接入层，用于对比不同模型的延迟、成功率和单次调用成本；但 RAG 的核心仍然是文档治理、检索质量和权限控制，而不是简单换一个模型入口。

生产环境还需要补充超时、重试、熔断、日志和成本统计。尤其是企业知识库中可能包含客户资料、合同条款、价格政策等敏感内容，接入任何外部模型之前，都要先做脱敏、权限隔离和合规评估。

六、上线前必须建立评估日志

RAG 系统不能只看“能不能回答”，还要看“答得对不对、来源准不准、成本高不高”。每次问答最好记录完整日志，例如：

{
  "question": "企业版是否支持角色权限？",
  "retrieved_chunk_ids": ["faq_20260608_001", "manual_20260601_028"],
  "answer": "...",
  "source_count": 2,
  "latency_ms": 2830,
  "model": "gemini-3.5-flash",
  "input_tokens": 4200,
  "output_tokens": 560,
  "cost": 0.0,
  "human_feedback": "accepted"
}

这里的 retrieved_chunk_ids 可以帮助排查检索是否命中正确资料，source_count 用来判断引用是否充分，latency_ms 反映响应速度，input_tokens 和 output_tokens 则用于计算成本。

上线前至少要关注五个指标：检索命中率、答案正确率、引用准确率、拒答准确率、平均成本。上线后还要继续观察人工兜底率和高频未命中问题。RAG 不是一次性项目，而是一个持续维护的知识工程。

七、最小 POC 怎么做

企业第一次落地不建议一上来覆盖所有资料。更合理的方式是先选一个边界清晰的场景，比如客服 FAQ、产品手册或内部制度。

POC 阶段可以准备 300 条左右知识片段，再选取 20 到 50 个真实问题，由人工标注标准答案和引用来源。然后用 Gemini 跑第一版，观察错误主要来自哪里。

如果答案不好，不要第一时间换模型。很多 RAG 问题并不是模型能力不足，而是切片边界不合理、元数据缺失、召回不准、重排缺失或权限过滤不到位。先修文档结构，再调检索参数，最后再评估模型替换，通常更符合工程落地规律。

总结

Gemini + RAG 企业知识库的核心，不是把大模型接进系统，而是建立一套“可检索、可追溯、可评估、可治理”的知识问答流程。

真正稳定的企业知识库应该做到：文档切片语义完整，知识片段带有版本和权限字段，检索阶段完成访问控制，重排后只把高相关片段交给模型，提示词严格约束答案来源，并通过日志持续评估命中率、正确率和成本。

模型负责最后一公里的表达，RAG 工程负责前面九公里的可靠性。只有把文档治理、检索质量、权限控制和评估体系一起做好，企业知识库才能从 Demo 走向真正可用的生产系统。