1. 知识库是什么先破除三个误解1.1 定义企业知识库是对企业内部分散的知识进行采集、治理、索引并以搜索、问答、API等形式提供给员工和系统消费的软件系统。它的成熟度通常经历三个阶段阶段形态用户价值典型技术L1文档存储能找到文件网盘、Wiki、DMSL2全文检索能搜到片段Elasticsearch、BM25L3知识服务能直接回答问题RAG、Agent、图谱企业级知识库的目标是从 L1/L2 走到 L3并且在权限、治理、可运营性上达到企业标准。1.2 三个常见误解误解一知识库 文档管理系统。不是。文档管理系统解决“存和管”知识库解决“找和用”。一个装满 PDF 的网盘不是知识库。误解二知识库 向量数据库。不是。向量库只是索引层的一种存储。知识库还包含接入、解析、治理、权限、服务、评估等大量组件。把向量库当知识库等于把 MySQL 当业务系统。误解三接了大模型就有知识库。不是。大模型解决“生成”不解决“知识从哪来、是否准确、能否追溯、权限是否合规”。没有检索和治理大模型只会更流畅地编造。1.3 知识库在整个系统中的位置flowchart LR U[员工 / 业务系统 / Agent] -- KB[企业知识库] KB -- S[搜索] KB -- QA[问答 / RAG] KB -- API[知识 API] S -- U QA -- U API -- U subgraph SRC[知识来源] D1[Wiki / 文档库] D2[工单 / CRM] D3[业务数据库] D4[代码仓库] D5[网页 / 共享盘] end SRC -- KB知识库是知识的统一出口而不是又一个数据孤岛。它的价值在于把分散在各系统里的知识收敛成一致的、可追溯的、有权限的访问入口。2. 核心概念速通在进入架构之前先统一几个术语。后面的所有设计都建立在这些概念之上。概念含义为什么重要文档(Document)知识的最小来源单位如一份 PDF、一个网页权限、版本、删除都以文档为单位切块(Chunk)从文档切出的检索单元切分质量直接决定召回质量嵌入(Embedding)把文本映射为高维向量让“语义相似”可计算索引(Index)为快速检索建立的数据结构全文索引、向量索引、结构化索引召回(Recall)从索引中取出候选片段召回不到后面全白搭重排(Rerank)对候选做精细排序提升 Top-N 的准确率上下文(Context)送入大模型的证据片段决定答案是否“有据可依”引用(Citation)答案对应的原始出处可信度和可审计性的基础一个关键区分写路径(离线构建)数据源 → 解析 → 切分 → 索引。关注正确性、时效性、可重建。读路径(在线服务)提问 → 召回 → 排序 → 生成。关注延迟、准确率、可解释。两条路径必须共用同一套处理逻辑否则评估结果和线上表现会严重脱节。3. 整体架构六层 横切能力企业级知识库推荐采用分层架构层与层之间通过稳定接口解耦。这样换模型、加数据源、换索引时不会牵一发动全身。flowchart TB subgraph L1[应用层] direction LR A1[企业搜索] A2[智能问答 / RAG] A3[Copilot / Agent] A4[开放 API] end subgraph L2[服务层] direction LR S1[查询理解] S2[检索路由] S3[召回融合] S4[Rerank] S5[上下文组装] S6[生成与引用] end subgraph L3[索引层] direction LR I1[全文索引 BM25] I2[向量索引] I3[结构化索引] I4[图谱(可选)] end subgraph L4[处理层] direction LR P1[解析] P2[清洗] P3[切分] P4[富化 / 权限标注] end subgraph L5[接入层] direction LR D1[文档库 / Wiki] D2[工单 / CRM] D3[数据库] D4[代码仓库] D5[网页 / 共享盘] end subgraph X[横切能力] direction LR X1[身份与权限] X2[元数据标准] X3[审计] X4[监控与评测] end L5 -- L4 L4 -- L3 L2 -- L3 L1 -- L2 X1 -.- L2 X1 -.- L3 X2 -.- L4 X3 -.- L2 X4 -.- L2各层职责层职责关键设计应用层面向用户/系统的产品形态搜索、问答、API、Copilot服务层查询理解、召回、排序、生成可配置、可观测、可降级索引层多种索引并存支持混合检索与索引重建处理层解析、清洗、切分、富化离线在线同源接入层连接各数据源增量同步、幂等、删除同步横切权限、元数据、审计、监控从第一天就设计进每一层架构建议横切的三件事(身份权限、元数据标准、审计)是事后最难补的。不要等到“后面再加”。4. 工作流程写路径、读路径、运维闭环知识库本质上是三条流水线。绝大多数“不好用”的问题出在第一和第三条而不是检索算法。4.1 离线构建(写路径)flowchart LR A[数据源] -- B[增量采集] B -- C[文档解析] C -- D[清洗去噪] D -- E[结构化切分] E -- F[富化br/元数据 · 权限 · 实体] F -- G[Embedding] G -- H[写入索引] H -- I[蓝绿切换 / 发布]各阶段要点采集支持全量与增量。增量以updated_at游标或 CDC 为准必须幂等。解析PDF、Word、HTML、表格、扫描件分别处理。版面结构(标题层级、表格)要尽量保留。清洗去页眉页脚、导航、重复模板、乱码。洗太狠会丢语义洗太轻会污染召回。切分优先按标题层级切其次按段落最后才用定长滑窗。这是影响效果最大的一步。富化为每个 chunk 打上来源、部门、密级、有效期、权限标识。元数据决定了后续能否过滤。建索引同步写入全文索引、向量索引、结构化字段。可选图谱。发布通过别名/版本做原子切换避免用户查到“更新到一半”的数据。4.2 在线服务(读路径)flowchart TD Q[用户提问] -- U[查询理解br/改写 · 指代消解 · 多轮补全] U -- F[ACL 与时效条件下推] F -- R{检索路由} R --|精确术语 / 编号| K[全文 结构化检索] R --|语义描述| V[向量召回] R --|实体关系| G[图谱查询] K -- M[融合去重br/RRF] V -- M G -- M M -- RR[Rerank 精排] RR -- CUT[截断到上下文预算] CUT -- CTX[上下文组装br/去冗余 · 附来源] CTX -- LLM[生成答案] CTX -- RAW[直接返回片段] LLM -- OUT[答案 引用] RAW -- OUT请求时序如下sequenceDiagram autonumber participant U as 用户 participant Q as 查询服务 participant RT as 路由 participant IDX as 索引层 participant RR as Rerank participant LLM as 生成模型 U-Q: 提问 Q-Q: 改写 / 补全 / 意图识别 Q-RT: 规范化查询 用户身份 RT-IDX: 并行召回(带 ACL 过滤) IDX--RT: 多路候选集 RT-RR: 融合去重后精排 RR--Q: Top-N 证据 Q-LLM: 问题 证据 引用要求 LLM--U: 答案 出处读路径的三个原则权限在召回阶段生效不能事后再筛。召回宁多勿少排序宁精勿滥。召回和排序是两个目标分开优化。没有证据就不回答。拒答比编造更有价值。4.3 运维闭环flowchart LR A[线上查询日志] -- B[bad case 归集] B -- C{归因} C --|没召回| D[补数据 / 调切分] C --|召回错| E[调权重 / 换 Embedding] C --|排序差| F[调 Rerank] C --|答非所问| G[调 Prompt / 拒答策略] C --|内容过期| H[刷新数据源 / 下线] D -- I[更新索引] E -- I F -- I G -- I H -- I I -- J[黄金评测集回归] J -- A运营闭环是整个系统能否长期存活的关键。没有评测集的团队所有优化都只能靠“感觉好像好一点”。5. 技术选型与技术对比5.1 第一个问题一定要用向量库吗不必须。向量检索只解决“语义相似”这一类问题。知识库的真实查询是混合的检索方式擅长不擅长典型实现全文 / BM25精确术语、代码、编号、法规条款同义表达、口语化提问Elasticsearch、OpenSearch、SQLite FTS5结构化查询元数据过滤(时间/作者/部门/状态)非结构化长文本SQL、图查询知识图谱实体关系推理模糊长文本召回Neo4j、RDF向量检索语义模糊匹配、同义改写、跨语言精确 ID、否定词、数字比较FAISS、pgvector、Milvus混合检索真实企业场景的绝大多数情况增加复杂度BM25 向量 Rerank结论企业级场景默认走混合检索。纯向量在精确匹配上会输给 BM25纯关键词在同义表达上会输给向量两者互补。5.2 检索方式决策树flowchart TD A[这条查询主要想解决什么] -- B{是否包含br/精确编号 / 代码 / 条款号} B --|是| C[全文检索 / 结构化查询] B --|否| D{用户会用br/不同措辞表达吗} D --|是| E[向量检索] D --|否| F[全文检索] C -- G[与向量结果融合 Rerank] E -- G F -- G G -- H[统一返回 Top-N 引用]5.3 向量存储库 vs 数据库一个常见误区做语义检索 ≠ 必须部署向量数据库。方案适合规模运维成本过滤能力适用场景numpy 暴力检索 10 万极低强(自己写)原型、单机小知识库FAISS10 万 – 千万低(进程内库)弱离线批处理、单机服务sqlite-vec 百万极低强桌面应用、边缘部署pgvector百万 – 千万低(复用 PG)强已有 PostgreSQL 的企业Qdrant千万级中强需要独立服务、过滤复杂Milvus亿级高强大规模、多租户Elasticsearch kNN千万级中高强已有 ES想统一检索Pinecone / 云服务按需极低中无运维团队、数据可出域选型建议已有 PostgreSQL 且规模 1000 万→ 直接用pgvector少一个组件就是少一份运维。已有 Elasticsearch→ 优先用 ES 的 BM25 kNN统一检索栈。需要独立、大规模、多租户→ Qdrant 或 Milvus。数据不能出域→ 全私有化部署排除 SaaS 向量库。5.4 Embedding 模型选型企业中文场景的常见候选模型语言部署特点适用BGE-M3多语言(中英强)私有化稠密 稀疏 多向量长文本通用首选BGE-large-zh-v1.5中文私有化成熟稳定生态好纯中文、资源有限GTE 系列中英私有化阿里系中文表现好国内企业Jina Embeddings v3多语言私有化/API长上下文、任务适配多语言文档OpenAI text-embedding-3多语言API效果好、免运维数据可出域选型维度语言中文为主优先 BGE / GTE。部署合规金融、政务、医疗通常要求私有化。维度与成本维度越高存储和计算成本越高。1024 维是常见平衡点。长文本能力BGE-M3 支持 8192 token适合长文档。可替换性必须假设未来会换模型索引要能全量重建。硬性要求换 Embedding 模型意味着所有向量都要重算。设计时必须保留原始文档和切分结果支持“从零重建索引”。5.5 Rerank 模型召回负责“别漏”Rerank 负责“排对”。常见选择方案部署特点BGE-Reranker-v2-m3私有化中英强性价比高首选Cohere RerankAPI效果好数据需出域Jina Reranker私有化/API多语言Cross-Encoder 自训私有化需标注数据适合垂直领域经验值Rerank 通常能把 Top-5 的准确率提升一个可观的比例是 ROI 最高的组件之一。代价是增加几十到几百毫秒延迟需要做超时降级。5.6 文档解析工具能力适合Apache Tika格式覆盖最广Office、邮件、通用格式Unstructured版面感知、元素划分混合格式文档MinerUPDF 版面/公式/表格强学术、报告类 PDFDocling版面分析 表格企业 PDFPyMuPDF / pdfplumber轻量、可控结构化 PDF商业文档智能OCR、表格、手写扫描件、票据建议组合Tika 处理 OfficeMinerU/Docling 处理 PDFOCR 兜底扫描件。解析质量差后面所有环节都救不回来。5.7 编排框架方案定位优点风险自研服务层生产系统完全可控、易治理工作量大LangChain开发库生态丰富、灵活抽象重、版本变动快LlamaIndex数据框架索引/检索能力强黑盒较多Dify应用平台低代码、快速验证深度定制受限RAGFlowRAG 引擎解析和切分较强与现有系统集成需评估FastGPT知识库应用国内生态、开箱即用大规模治理需扩展企业级建议用开源框架做原型验证用自研服务层承载生产。框架适合“验证可行性”不适合“长期承载权限、审计、多租户”。5.8 默认推荐组合(典型私有化企业)组件推荐理由解析Tika MinerU格式覆盖 PDF 质量切分自研(按标题层级)效果最好可控全文检索Elasticsearch / OpenSearch成熟、生态好向量存储pgvector(中小)/ Qdrant、Milvus(大)按规模选择EmbeddingBGE-M3中英、长文本、可私有化RerankBGE-Reranker-v2-m3性价比高编排自研服务层权限、审计、多租户生成模型私有化 Qwen / DeepSeek 或合规 API按合规要求6. 为什么这么选决策依据技术选型不是选“最强的”而是选“约束下最合适的”。推荐用约束 → 候选 → 判定标准 → 结论的方式记录决策(类似 ADR)。6.1 为什么是混合检索而不是纯向量维度纯向量纯 BM25混合同义表达强弱强精确编号弱强强否定词 / 数字弱强强可解释性弱强中冷启动需 Embedding直接可用需 Embedding成本高低中高企业查询天然混合既有“怎么申请报销”这种语义问题也有“ERR-2041 是什么错误”这种精确问题。只做一种必然有一类查询体验很差。6.2 为什么中小规模优先 pgvector复用现有 PostgreSQL少一个运维组件支持事务、备份、监控和业务数据同栈HNSW 索引在千万级以内性能足够迁移成本低规模上来再换 Milvus/Qdrant 也不难。什么时候不该用需要亿级向量、强多租户隔离、超高 QPS 时再上专用向量库。6.3 为什么一开始不上 GraphRAG图谱能解决多跳推理(“A 的负责人所在部门的制度有哪些”)但代价是实体抽取和关系构建成本高更新维护复杂对大多数“查文档、答问题”的场景收益不明显。建议先用“混合检索 Rerank”覆盖 80% 场景确认存在明确的多跳关系需求后再引入图谱作为补充索引而不是替代。6.4 为什么保留原始文档和切分结果这是为了三个能力索引可重建换 Embedding、换向量库时可以全量重算。可追溯答案能回到原文。可调试切分效果不好时能复现和调整。如果只存向量不存原文系统就成了一次性的黑盒。7. 实现逻辑关键模块设计以下用 Python 风格伪代码说明核心逻辑重点在设计意图不追求可直接运行。7.1 数据接入增量与幂等def sync_source(source, cursor): 按更新时间增量拉取失败可重试重复执行结果一致。 docs source.fetch(sincecursor.updated_at, limit500) for doc in docs: content_hash sha256(doc.content) # 内容未变则跳过避免无谓的重新索引 if store.get_hash(doc.id) content_hash: continue pipeline.enqueue({ doc_id: doc.id, source: source.name, content: doc.content, metadata: doc.metadata, # 部门、密级、作者、有效期 acl: doc.acl, # 权限标识必须随文档一起流转 version: doc.version, deleted: doc.deleted, # 删除标记必须同步 }) store.save_hash(doc.id, content_hash) return docs[-1].updated_at if docs else cursor.updated_at三个必须做到的点幂等同一文档重复处理结果一致。删除同步源系统删了索引必须删(合规要求)。权限随行ACL 必须从源头带到每个 chunk。7.2 切分结构优先父子关联def chunk_document(doc, max_tokens800, overlap100): 优先级标题层级 段落 定长滑窗。 每个 chunk 保留父文档路径便于回溯和上下文扩展。 sections split_by_heading(doc) # 按 H1/H2/H3 切 chunks [] for sec in sections: if estimate_tokens(sec.text) max_tokens: chunks.append(make_chunk(sec, parentdoc)) else: # 过长段落再按句子边界切保留 overlap for piece in sliding_window(sec.text, max_tokens, overlap): chunks.append(make_chunk(piece, parentdoc, headingsec.heading)) return chunks为什么结构优先企业文档(制度、手册、API 文档)本身有清晰的标题层级按结构切出的 chunk 语义完整召回精度显著更高。定长切分会把一句话拦腰截断。父子块(small-to-big)思路用小块做检索(精度高)命中后返回其父段落做上下文(信息全)。这是工业界常用技巧。7.3 富化与权限标注def enrich(chunk, doc): return { **chunk, doc_id: doc.id, source: doc.source, title: doc.title, heading_path: chunk.heading_path, # 例员工手册 报销 差旅 department: doc.metadata.department, classification: doc.metadata.classification, # 密级 effective_at: doc.metadata.effective_at, expires_at: doc.metadata.expires_at, acl: doc.acl, # 关键权限随 chunk 走 version: doc.version, }元数据不是可选项。它决定了能不能按部门/密级过滤能不能按有效期剔除过期内容答案能不能给出准确的出处。7.4 索引构建多索引 蓝绿发布flowchart LR A[原始文档 切分结果] -- B[处理管线] B -- C[索引 vN(蓝)] B -- D[索引 vN1(绿)] E[别名 kb-live] -.- C E -.- D F[切换] -- Edef rebuild_index(docs): new_index create_index(fkb-{next_version()}) for chunk in process(docs): new_index.add_text(chunk.id, chunk.text) new_index.add_vector(chunk.id, embed(chunk.text)) new_index.add_metadata(chunk.id, chunk.metadata) # 校验通过后原子切换别名读流量无感迁移 new_index.verify(docs_countlen(docs)) alias_swap(kb-live, from_current, tonew_index) # 保留上一版本一段时间便于回滚 schedule_cleanup(old_index, after24h)蓝绿发布解决三个问题更新不中断、可回滚、可校验。没有它任何一次全量重建都可能造成线上事故。7.5 查询理解与路由def understand(query, historyNone, userNone): q normalize(query) if history: q resolve_pronouns(q, history) # “它的有效期是多久” intent classify_intent(q) # 精确查询 / 语义问答 / 关系查询 rewritten expand_synonyms(q) # 可选同义词扩展 return Query( textrewritten, intentintent, acl_filterbuild_acl_filter(user), # 权限条件随查询下推 time_filterbuild_time_filter(user), # 只查有权且有效的内容 )路由策略命中错误码、订单号、条款号等模式 → 走全文/结构化自然语言描述 → 走向量显式关系问题 → 走图谱(如有)不确定时 →全部并行召回交给融合层。7.6 混合召回与 RRF 融合def hybrid_recall(query, top_k50): # 权限与时效条件在检索阶段就下推而不是召回后再筛 filters query.acl_filter query.time_filter bm25_hits fulltext.search(query.text, top_ktop_k, filtersfilters) vec_hits vector.search(embed(query.text), top_ktop_k, filtersfilters) return rrf_fuse([bm25_hits, vec_hits], k60, top_n30) def rrf_fuse(result_lists, k60, top_n20): Reciprocal Rank Fusion只用名次不用分数天然规避量纲不一致。 scores defaultdict(float) for results in result_lists: for rank, hit in enumerate(results, start1): scores[hit.id] 1.0 / (k rank) return sorted(scores.items(), keylambda x: -x[1])[:top_n]为什么用 RRFBM25 分数和向量相似度量纲完全不同直接加权很难调。RRF 只看排名简单、稳健、无需调参是混合检索的默认融合方式。7.7 Rerank 与上下文组装def rerank_and_pack(query, candidates, token_budget6000): ranked reranker.rank(query.text, candidates) # 精排 packed, used [], 0 seen set() for hit in ranked: if hit.id in seen: continue if hit.doc_id in seen_docs(packed): # 同一文档限制条数 continue if used hit.tokens token_budget: break packed.append(hit) used hit.tokens seen.add(hit.id) return packed组装原则去重避免同一段内容重复喂给模型每份证据都带source / title / heading_path供引用控制 token 预算优先保留高分证据证据不足时明确拒答而不是让模型硬编。7.8 生成与引用def answer(query, evidence): if not evidence or max(e.score for e in evidence) REFUSE_THRESHOLD: return 未在知识库中找到足够依据建议补充资料或转人工。 ctx \n\n.join( f[{i1}] {e.title} / {e.heading_path}\n{e.text} for i, e in enumerate(evidence) ) result llm.generate( system只能依据给定材料回答每个结论必须标注引用编号材料不足时明确说明。, userf问题{query.text}\n\n材料\n{ctx}, ) validate_citations(result) # 校验引用编号是否真实存在 return result两个硬约束无证据不回答(拒答阈值可配置)。引用必须真实存在不能是模型编造的编号。8. 核心关键点决定成败的八件事8.1 权限必须在检索阶段生效(P0)这不是“最佳实践”是安全底线。flowchart LR U[用户身份] -- A[构建 ACL 条件] A -- B[全文检索br/(带过滤)] A -- C[向量检索br/(带过滤)] B -- D[候选集] C -- D D -- E[Rerank / 生成]错误做法先召回全部再在应用层筛掉无权文档。问题在于无权内容的元信息可能已经进入日志或缓存候选集被无关内容挤占导致有效结果变少模型可能从上下文里“推断”出不该知道的信息。正确做法把 ACL 作为过滤条件下推到每一种索引的查询里。8.2 切分质量 模型选择同一套检索切分方式不同效果可能相差一倍。优先级按标题层级切(保留heading_path)按段落 / 语义边界切定长滑窗 overlap(兜底)8.3 元数据是隐形主角权限、部门、密级 → 决定可见性有效期、版本 → 决定时效性来源、标题、路径 → 决定可追溯性。事后补元数据极其痛苦必须在接入和切分阶段就打全。8.4 没有评测集就没有优化建20–50 条真实问题的黄金集每条包含问题、期望答案、期望来源。指标建议指标含义RecallK相关片段是否进了候选MRR / nDCG排序质量Faithfulness答案是否忠于材料Context Precision / Recall上下文是否精准且完整拒答率不知道时是否老实说引用准确率引用是否指向真实来源P95 延迟用户体验每次改切分、换模型、调权重都跑一遍回归。8.5 离线与在线必须同源清洗、切分、Embedding 的逻辑必须共用一套代码。否则离线评测结果无法代表线上调试时无法复现问题版本升级时容易不一致。8.6 拒答比编造更重要企业场景里“不知道”是可接受的“一本正经地胡说”是不可接受的。做法设置相似度/重排分数阈值Prompt 明确要求“材料不足时说明”输出阶段校验引用是否真实存在。8.7 可观测性记录每次查询的完整链路query_id | 原始问题 | 改写后 | 路由 | 各路召回 | 融合结果 | 重排结果 | 最终证据 | 答案 | 延迟 | 用户反馈没有这条链路bad case 只能靠猜。8.8 内容治理是长期工程每个知识域有owner权威源唯一避免多版本并存有效期 复审周期删除同步内容质量指标(重复率、过期率、矛盾率)。9. 注意事项与常见坑#坑后果对策1权限没做或事后过滤安全事故、被迫回滚ACL 下推到检索2数据源一锅端召回全是噪音建立准入标准先治理再入库3没有评测集无法判断优化是否有效先建黄金集再优化4只上线不运营内容过期使用率归零运营闭环 owner 机制5过度工程维护成本压垮团队按规模选型能用 pgvector 不上 Milvus6只做向量精确查询体验差混合检索7切分一刀切语义断裂或噪声过多结构优先 父子块8忽略删除同步答出已作废内容合规风险删除事件 tombstone9一次全量重建线上抖动、无法回滚蓝绿索引 别名切换10只看准确率不看拒答模型过度自信阈值 引用校验11忽略解析质量表格、公式、扫描件全部丢失按格式分而治之12权限只做文档级文档内敏感段落泄露段落级权限 / 脱敏合规相关数据不出域金融、政务、医疗通常要求私有化部署。审计留痕谁查了什么、返回了什么需可追溯。删除权用户/业务要求删除时索引、缓存、日志都要处理。最小权限默认不可见按需授权。10. 分阶段落地路线不要一上来就做“全公司知识平台”。企业级项目的典型死法是“大而全地启动然后没人用”。阶段目标关键交付成功标准0. 选场景找高频、高价值、内容相对干净的场景场景定义、成功指标、数据源清单有明确的使用方和痛点1. 最小闭环单数据源、全文检索、返回片段带引用可用的搜索/问答能被真实用户使用2. 质量提升混合检索 Rerank 评测集 权限效果可度量黄金集指标达标3. 规模扩展多数据源、增量更新、多租户、审计可推广的平台能力能接入第二个场景4. 运营体系贡献机制、复审流程、bad case 闭环长期运营机制使用率与满意度稳定flowchart LR A[阶段0br/选场景] -- B[阶段1br/最小闭环] B -- C[阶段2br/质量与权限] C -- D[阶段3br/规模与治理] D -- E[阶段4br/持续运营] C -.-|指标不达标| B E -.-|bad case 回流| C推荐的首选场景客服问答、运维手册、研发文档、HR 制度。它们的共同点是查询高频、答案相对确定、内容有明确 owner。11. 自建还是采购层次建议理由基础设施(解析、索引、向量库、Rerank)采购或开源通用能力自研不划算领域层(接入、切分、权限模型、评测集、Prompt)自建这是差异化所在产品层(搜索/问答界面)视团队而定无专职团队时用成熟平台起步一句话通用能力买领域能力建。12. 附录12.1 上线检查清单数据源清单、owner、更新频率已明确增量同步与删除同步已验证解析覆盖所有主要格式(含扫描件兜底)切分策略经过评测验证每个 chunk 带完整元数据与权限标识权限在检索阶段生效且有越权测试全文 向量混合检索已启用Rerank 有超时降级黄金评测集已建立并通过回归引用可追溯到原文与版本拒答阈值已配置索引蓝绿切换与回滚演练通过审计日志可用监控告警(延迟、错误率、召回量)已配置12.2 术语表术语说明RAGRetrieval-Augmented Generation检索增强生成BM25经典全文检索排序算法Embedding文本的向量表示Chunk文档切分后的检索单元RRFReciprocal Rank Fusion多路结果融合算法Rerank对候选结果做精细重排ACLAccess Control List访问控制列表CDCChange Data Capture变更数据捕获蓝绿索引新旧索引并存、原子切换的发布方式12.3 参考方向检索BM25、稠密/稀疏混合检索、RRF模型BGE 系列、GTE 系列、Rerank 模型评估RAGAS 等 RAG 评测框架解析Apache Tika、Unstructured、MinerU、Docling存储pgvector、Qdrant、Milvus、Elasticsearch结语企业级知识库的本质不是“把文档变成向量”而是把分散的知识变成可信、可控、可运营的服务。如果只能记住三句话权限和治理是 P0检索算法是 P2。混合检索 好的切分 Rerank能覆盖绝大多数场景。知识库是产品不是项目——上线只是运营的开始。先把一个场景做深、做透、做出可度量的效果再横向复制。这比一开始就搭一个“大而全的平台”更容易成功。
