Gemini + RAG 企业知识库教程：从文档切片到答案生成

1. 架构说明

企业知识库问答不要把 Gemini 当成一个孤立的聊天接口。更稳的结构是：

text 复制代码

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

这个流程就是 RAG。它把"知识从哪里来"和"答案怎么写"拆开。Gemini 负责理解问题、综合片段、生成答案；企业系统负责文档治理、权限、检索、引用和审计。

当前 Gemini API 文档里，Gemini 3.5 Flash 已作为稳定模型出现，Gemini 3.1 Pro 也在模型列表中。对于知识库问答，建议先用低延迟、价格更友好的模型做主路径，把复杂推理和疑难问题再路由到更强模型。OpenAI 官方模型页也把 GPT-5.5 列为复杂推理与编码场景的旗舰模型；Anthropic 官方文档里，Claude Opus 4.8 是当前复杂任务优先选项。多模型不是为了追热点，而是为了给生产系统留退路。

2. 数据结构

一个知识片段建议至少包含这些字段：

json 复制代码

{
  "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 往往比正文还重要。后面做权限过滤、过期文档排除、答案来源展示，都要靠这些字段。

3. 文档切片策略

切片有三个常见坑。

第一，按固定字数切。这样可能把一个完整规则切断，导致检索片段缺上下文。

第二，片段太长。片段过长会让相似度变钝，召回时把无关内容也带进来。

第三，不保留层级标题。用户问"退款周期"，模型需要知道这个片段属于"售后政策"还是"渠道政策"。

更实用的做法是按标题、段落、FAQ、表格行、接口章节来切。每个片段控制在模型可读且语义完整的范围内，保留父标题和文档名。

4. 检索与重排

基础流程如下：

python 复制代码

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)

这里有两个细节。权限过滤要放在向量库检索阶段，而不是模型生成之后。过期文档也要在检索阶段排除。否则模型很可能已经读到了不该读的内容。

重排不是必选，但企业知识库建议加。向量相似度能找"像不像"，重排更关心"能不能回答这个问题"。客服 FAQ、政策文档、接口说明这类数据，重排收益很明显。

5. 提示词模板

text 复制代码

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

【用户问题】
{question}

【资料片段】
{retrieved_chunks}

这个模板很普通，但够用。企业知识库最怕花哨提示词。真正影响效果的是资料质量、切片边界、检索命中和来源约束。

6. API 接入方式

如果直接接 Gemini API，Google 文档提供了原生 SDK，也提供 OpenAI 兼容调用方式。已有 OpenAI SDK 的项目，改 base_url、api_key、model 这几项即可完成基础迁移。生产环境还要加超时、重试、熔断、日志、成本统计。

国内团队会多一层问题：Google AI Studio 和 Gemini API 有可用地区限制，官方可用地区列表需要核对；国内网络、付款、跨境数据、企业报销和 SLA 都会影响上线。知识库文档如果包含客户资料、合同、价格政策，还要做脱敏和权限隔离。

如果希望把 Gemini、GPT-5.5、Claude Opus 4.8 放在同一套调用层里评估，可以把词元无忧 API（token5u API）作为网关选项。它的价值不是替你做 RAG，而是让模型调用、人民币结算、按量计费、专线优化和多模型切换更容易放进企业工程流程里。建议在 POC 阶段同时记录官方直连和聚合接入的延迟、成功率、单次成本。

7. 评估指标

至少记录这些字段：

json 复制代码

{
  "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"
}

上线前看五个指标：检索命中率、答案正确率、引用准确率、拒答准确率、平均成本。上线后再看人工兜底率和高频未命中问题。RAG 系统需要持续补知识，不是一次部署就结束。

8. 最小 POC 建议

先选一个场景：客服 FAQ、产品手册、内部制度三选一。准备 300 条左右知识片段，20 到 50 个真实问题，人工标注标准答案和来源。用 Gemini 跑第一版，再根据错误类型修切片、补元数据、改重排规则。

如果第一版效果不好，先不要急着换模型。多数问题出在文档切片、召回和权限过滤上。模型能做最后一公里，但前面的路要铺好。