企业要做知识库问答真正麻烦的地方往往不是“接上一个大模型接口”这么简单。更关键的是文档怎么切、怎么转成向量、怎么召回、怎么排序以及检索到的内容要如何交给模型才能让它基于资料回答而不是自己发挥。gemini-embedding-001是 Gemini API 中仍然适合纯文本场景使用的 Embedding 模型。对于企业里的制度文件、产品说明、客服 FAQ、研发规范、售前资料这类文本型知识库它可以用来做语义检索也就是让系统不只按关键词找内容而是能理解问题背后的意思。这篇文章会围绕Gemini Embedding、企业知识库问答、向量检索知识库这几个核心点拆开讲一条从数据入库到在线问答的完整 RAG 链路。重点不放在“向量数据库 大模型”这种概念介绍上而是尽量贴近真实工程落地。一、企业知识库问答为什么需要 Embedding传统关键词搜索主要依赖字面匹配。比如用户问“报销发票多久内提交”但制度里写的是“费用票据应在业务发生后 30 日内归档。”如果系统只会匹配关键词就很可能找不到这条内容。Embedding 的作用就是把文本转换成向量。换句话说系统可以通过语义相似度来判断两段话是不是在说同一件事。对于企业知识库来说Gemini Embedding 的价值主要体现在几个方面。第一它能支持语义检索。用户的问题和文档里的表达不必一模一样只要意思接近就有机会召回相关内容。第二它比较适合企业里常见的多语言或混合语言资料。很多文档里会同时出现中文、英文术语、产品型号、接口名、代码片段这种情况单靠关键词搜索并不稳定。另外它也能接入标准的 RAG 链路。生成出来的 Embedding 可以写入 Milvus、pgvector、Vertex AI Vector Search、Elasticsearch 向量字段等向量检索系统后续再配合大模型做问答。当然也要注意gemini-embedding-001主要面向文本嵌入场景。Google 也提供了更新的多模态嵌入能力可以处理文本、图片、音频、视频、文档等不同模态。但如果企业当前的知识库主要还是 PDF、Word、Markdown、网页、FAQ、代码说明这类文本资料那么gemini-embedding-001依然可以作为纯文本向量化方案的一部分。二、完整链路从文档到问答不只是“存向量”一个真正能用的向量检索知识库通常要分成两个阶段离线构建和在线问答。1. 离线阶段构建可检索知识离线阶段要做的事是把企业原始资料变成可检索、可追踪、可更新的知识单元。一般流程可以理解为原始文档 → 文档解析 → 清洗与标准化 → 文本切分 → 元数据补充 → Gemini Embedding 向量化 → 写入向量数据库 → 建立索引这里最容易被低估的其实是“解析、切分、元数据”这三步。企业文档通常不是干净的纯文本。里面可能有目录、页眉页脚、表格、图片说明、版本记录、附件编号等等。如果直接把整篇文档拿去向量化召回结果往往会很粗但如果切得太碎又容易把上下文切没了。所以知识库构建并不是简单上传文件而是要围绕最后的问答效果来设计数据结构。2. 在线阶段检索增强生成在线阶段则从用户问题开始用户问题 → 问题改写/规范化 → Gemini Embedding 向量化 → 向量检索 TopK → 元数据过滤 → Rerank 重排序 → Prompt 组装 → 大模型生成回答 → 引用来源与置信处理一个成熟的企业知识库问答系统不能只给出一个“看起来很合理”的答案。它还要告诉用户这个答案来自哪份文档、哪一段、哪个版本。没有来源引用业务部门通常很难真正信任系统输出。三、文档切分决定召回质量的第一道关口很多 RAG 项目效果不好并不一定是 Embedding 模型能力不够更多时候是文档切分策略出了问题。1. 按语义结构切而不是机械按字数切常见的切分方式有很多比如按标题层级切分适合制度、手册、说明文档按段落切分适合 FAQ、知识文章、运营文档按问答对切分适合客服知识库把代码块和说明文字分开切适合研发文档按表格行或业务对象切分适合产品参数、价格规则、流程节点。如果一份企业制度文档只是机械地“每 500 字切一段”很容易把“适用范围”“审批条件”“例外情况”拆开。这样一来检索时可能只命中了审批条件却漏掉了限制条款最后答案就会有偏差。更稳妥的做法是优先根据标题、列表、表格、FAQ 问答边界来切分然后再设置合理的最大长度和重叠窗口。这样既能保留语义完整性也不至于让单个片段过长。2. 保留上下文标题每个切片不应该只保存正文最好把标题路径也带上例如文档差旅报销制度 章节第三章 住宿标准 小节3.2 一线城市标准 正文员工因公出差至北京、上海、广州、深圳……这样做的好处很明显。第一Embedding 时语义会更完整模型更容易理解这段内容属于什么主题。第二生成答案时也能展示更清楚的来源方便用户回到原文核验。3. 元数据必须提前设计企业知识库问答经常需要按照部门、产品线、地区、时间版本等条件过滤。比如department: 人力资源部、财务部、研发部doc_type: 制度、FAQ、产品手册、接口文档product: CRM、ERP、数据平台version: v1.2、2024-10effective_date: 生效日期permission_level: 内部、部门可见、公开这些元数据不是可有可无的附加信息而是后续检索质量和权限控制的基础。比如销售人员查询产品资料时不应该召回研发内部文档新版本制度已经生效时也不能让旧版本内容覆盖新版本。四、使用 gemini-embedding-001 做向量化的关键点在 Gemini API 的 Embeddings 文档中Embedding 任务可以根据使用场景加入任务提示比如搜索、问答、事实核查、代码检索等。企业知识库问答里建议把“查询文本”和“文档文本”的构造方式区分开不要混在一起处理。1. 查询侧突出用户意图用户问题可以整理成更明确的检索输入例如task: question answering | query: 员工报销发票最晚多久提交如果是偏搜索的场景也可以采用搜索任务的表达方式。具体格式要以官方文档当前说明为准。工程上最好做成可配置项不要直接写死在业务代码里后面模型或接口规则变化时会更好维护。2. 文档侧补充标题与正文文档切片建议把标题和正文组合起来例如title: 差旅报销制度 - 发票提交时限 text: 员工应在业务发生后 30 日内提交合规票据……这通常比只向量化正文更稳定尤其是短文本切片。标题能提供主题信息让模型更容易判断这段内容到底在讲什么。3. 向量维度与数据库字段保持一致Embedding 模型输出向量之后向量数据库需要创建对应维度的索引字段。实际的向量维度、输入限制、返回格式等都要以 Gemini API 最新文档为准。在工程实现上建议把模型名、维度、索引名称、距离函数这些配置写到配置表里。这样后续要升级模型、重建索引或者切换检索方案时不至于牵一发而动全身。五、向量数据库选型不要只看“能不能存向量”企业落地向量检索知识库时常见选择包括 Milvus、pgvector、Elasticsearch/OpenSearch以及云厂商提供的向量搜索服务。选型时不能只问“能不能存向量”还要看它是否适合企业当前的规模和团队能力。维度关注点数据规模文档切片数量、更新频率、并发查询量检索能力ANN 检索、过滤查询、混合检索、距离函数运维成本是否已有数据库团队是否接受自建集群权限与隔离多租户、部门权限、数据分级可观测性查询日志、命中率、召回内容追踪更新机制增量更新、删除同步、版本回滚如果企业知识库规模不大而且团队本来就使用 PostgreSQLpgvector 会比较省事可以降低系统复杂度。要是切片数量很大、并发较高或者需要更强的向量索引能力那么 Milvus 或云上向量搜索服务会更合适。所以重点不是“哪一个数据库最好”而是它是否匹配企业的数据规模、团队技术栈、运维能力和合规要求。六、检索策略向量检索不是唯一答案向量检索很适合处理语义相似问题但企业知识库里还有大量编号、术语、型号、日期、法规条款、接口名等信息。面对这类内容如果只靠向量检索反而可能漏掉精确关键词。更推荐的方式是混合检索用户问题 → 关键词检索 BM25 → 向量检索 → 合并候选结果 → Rerank → 返回 TopN 给大模型比如用户问“API 错误码 E1027 怎么处理”这时候关键词E1027比语义相似度更重要。混合检索可以同时兼顾精确匹配和语义召回整体效果通常更稳。TopK 和阈值怎么设常见做法是先让向量检索取一个相对大的候选集比如 Top20 或 Top50然后通过 Rerank 重新排序选出最相关的 Top5 到 Top10 交给大模型。不过这个数量不能照搬。不同企业的文档粒度、模型上下文长度、回答准确率要求和成本预算都不一样最好通过测试来确定。相似度阈值也不建议只凭经验固定。更好的做法是记录每次问答过程中的关键数据用户问题召回片段相似度分数Rerank 分数最终使用片段用户反馈是否人工判定正确。这些数据看起来琐碎但它们是后续优化企业知识库问答效果的基础。没有这些记录系统出了问题也很难判断到底是切分不对、召回不准还是生成环节没约束好。七、Prompt 组装让模型基于知识回答而不是自由发挥RAG 的生成阶段一定要明确约束模型。一个基础 Prompt 可以这样设计你是企业知识库问答助手。 请仅根据给定的知识片段回答用户问题。 如果知识片段中没有答案请说明“当前知识库未找到明确依据”不要编造。 回答中请标注引用来源包括文档名和章节。 如果不同片段存在冲突请优先使用生效日期更新、版本号更高的内容。同时传给模型的上下文不应该只有正文还应包含这些信息文档名称标题路径版本号生效日期片段正文原文链接或内部文档 ID。这样生成出来的答案更容易审计用户也能顺着引用回到原文确认。对于企业场景来说这一点非常重要。八、权限、更新与审计企业场景不能忽略的三件事1. 权限控制企业知识库不是所有人都能看所有资料。权限控制至少要覆盖几个层面文档级权限部门级权限用户角色项目空间外部访客隔离。检索时应该先做权限过滤再做向量召回。这样可以避免无权限内容进入候选集也能减少后续生成阶段泄露敏感信息的风险。2. 知识更新知识库一定要支持增量更新。比较推荐的做法是给每个文档和切片维护唯一 ID例如doc_id chunk_id version当文档更新时要删除旧版本切片或者至少把它标记为失效然后再写入新版本向量。否则旧制度和新制度同时被召回模型很容易生成前后矛盾的答案。3. 日志审计企业知识库问答需要保留检索和生成日志但也不能不加限制地保存敏感原文。更合理的做法是记录系统行为比如检索了哪些片段、使用了哪些引用、用户是否反馈有效而不是把所有敏感内容都原样长期保存。对于涉及客户信息、合同、个人数据的场景还要根据企业内部合规要求做脱敏、加密和访问审计。这部分虽然不如模型效果那么显眼但真正上线后非常关键。九、效果评估不要只看 Demo 是否“能回答”一个知识库问答系统上线前至少要构建一套评测集。评测集可以从历史客服工单、内部咨询记录、制度问答中抽样再按问题类型分类例如事实查询某项政策是什么条件判断是否符合报销条件流程咨询下一步找谁审批对比问题A 版本和 B 版本有什么差异异常处理错误码、失败原因无答案问题知识库中不存在的信息。核心指标可以重点看这几类第一是召回准确率也就是正确片段有没有进入候选集。第二是排序质量正确片段是不是排在前面。第三是回答忠实度模型有没有严格依据知识片段回答。另外还要看引用准确性也就是引用来源是否真的支撑答案。最后是拒答能力。当知识库没有依据时系统能不能明确说明没有找到而不是编一个看似合理的答案。很多系统的问题并不是“模型不会回答”而是“检索没找到正确材料”或者“找到了材料但 Prompt 没把模型约束住”。所以评估时最好把检索和生成分开看分别定位问题。十、推荐的企业落地架构一个相对稳妥的企业知识库问答架构可以按下面的方式分层数据源层 OA、网盘、Confluence、飞书文档、Git、CRM、FAQ 表格 处理层 文档解析、清洗、切分、元数据抽取、权限映射 向量化层 gemini-embedding-001 生成文本向量 存储层 原文存储 元数据库 向量数据库 检索层 权限过滤 关键词检索 向量检索 Rerank 生成层 Prompt 模板 大模型回答 来源引用 运营层 日志、反馈、评测集、索引更新、质量看板这套架构的重点在于分层。Embedding 模型以后可以升级向量数据库可以替换大模型也可以调整。但文档治理、元数据、权限、评测体系这些基础能力如果一开始缺失后面再补成本会很高。结语Gemini Embedding 是起点知识工程才是关键用gemini-embedding-001构建企业知识库问答核心并不是简单地把文档转成向量。真正重要的是围绕“可检索、可引用、可更新、可审计”搭起一条完整链路。对于纯文本知识库Gemini Embedding 可以承担语义向量化的角色如果是图片、音视频、富文档等多模态场景就需要结合更新的多模态嵌入能力或者采用专门的解析方案。企业在选型时没必要一味追概念更应该先把几个基础问题想清楚数据是否干净权限是否清晰评测是否能持续。只有当文档切分、元数据、混合检索、重排序、Prompt 约束和日志反馈形成闭环向量检索知识库才能真正从 Demo 走向可用成为企业日常问答中能被信任的系统。