检索增强生成（RAG）是当前企业构建私有知识库问答系统的主流方案。它通过先检索可信资料、再让大模型基于资料生成回答，从根源上缓解幻觉。本文面向上海技术团队，从文档切分策略、Embedding模型、向量库选型到召回重排，完整拆解一条可落地的RAG工程链路，帮助开发者避开常见的效果陷阱与性能坑。

一、为什么需要RAG：大模型的知识盲区

大模型幻觉与知识时效性

通用大模型的参数知识停留在训练截止日，且会编造不存在的法条、合同条款或内部制度。在上海企业私有化场景中，客户文档、产品手册、历史工单都不在模型训练语料里，直接提问必然产生幻觉。RAG的核心思路是先检索相关资料，再让模型基于资料作答，把答案锚定在可信文本上，并可附带来源引用，满足合规审计要求。

RAG相比微调的成本优势

微调需要准备高质量标注样本、训练与回归测试，周期以周计，且知识更新要重新训练；而RAG只需把文档灌入向量库，更新资料即更新知识。对上海开发者而言，RAG在数据频繁变动、合规要求可溯源的业务中，成本和迭代速度都明显优于微调。实践中二者常互补：微调调整语气与任务格式，RAG注入动态知识。

文档分块的元数据保留

切分时应保留文档标题路径作为元数据，例如「产品手册/安装篇/环境要求」，召回时把路径拼进上下文，让模型知道这段话出自哪一章。表格切分要保留表头，否则模型看到一堆数字不知道列名。这些细节决定答案是否专业。

二、RAG全链路：从文档到回答的五步流程

文档解析与预处理

原始资料通常是PDF、Word、扫描件混排。第一步要做版面解析：抽取标题层级、表格、图片说明，去除页眉页脚与重复水印。扫描件需走OCR并做文字纠错，表格建议转成Markdown或HTML保留行列结构。预处理质量直接决定后续召回上限，这一步在上海落地项目中往往被低估，建议预留三成工期。

文本切分策略（Chunking）

切分是RAG效果的关键旋钮。常见做法有三种：按固定长度切（如500字重叠50字）、按标点与语义边界切、按文档结构（标题或段落）切。工程建议：结构化文档优先按标题层级切，无结构长文用滑动窗口并保留10%~15%重叠。每个块控制在300~800字，过短丢失上下文，过长稀释语义；合同类长条款可按条款编号切。

Embedding维度与量化

高维向量精度好但存储贵，生产中常用向量量化（PQ/ScaNN）在召回率与内存间折中。上海团队数据量小就用全精度，向量过亿再考虑量化。查询时用nprobe控制召回速度与精度的平衡。

三、上海团队的Embedding与向量库选型

Embedding模型选择要点

Embedding把文本映射为高维向量，语义相近则向量距离近。选型看四点：中文语义表现、向量维度（768或1024维）、最大序列长度、是否支持私有化部署。上海技术团队可先用公开评测集对比几款开源模型，再用自有业务文档做抽样人工评估，避免只看榜单；query与文档最好使用同一套Embedding模型。

主流向量数据库对比

向量库负责海量向量的近似最近邻检索。轻量场景可用FAISS或Chroma；生产级可选Milvus、Weaviate或PgVector（PostgreSQL插件）。选型维度：数据量级、是否需要标量过滤、混合检索支持、运维成本。中小规模知识库直接用PgVector可显著降低运维负担；千万级以上向量再考虑Milvus这类分布式方案。

四、召回与重排：提升答案准确率

混合检索策略

纯向量检索对专有名词、编号、精确关键词召回弱。推荐混合检索：向量召回负责语义相似，BM25负责关键词精确匹配，两路结果按分数融合（如RRF倒数排名融合）。对上海企业文档中大量出现的合同编号、产品型号、法条编号，混合检索能把命中率提升一个台阶；还可按文档类型、时间做元数据过滤。

重排模型（Reranker）应用

召回阶段追求高recall，取Top 20~50条；重排阶段用Cross-Encoder模型对query与每段文档逐对打分，取Top 3~5送进大模型上下文。Reranker比向量召回更精细，但计算更贵，放在召回之后做精排是性价比最高的姿势。注意控制送入上下文的总长度，避免超出模型窗口。

五、上海落地中的工程优化与常见坑

常见问题排查清单

效果不好时按清单排查：切分是否破坏语义、Embedding语种是否匹配、召回TopK是否过小、是否开启重排、prompt是否要求模型只依据资料回答、资料本身是否有错漏。建议保留召回日志，定期用人工标注的评测集回归，把召回准确率和答案命中率量化跟踪。

性能调优建议

延迟主要来自Embedding推理与向量检索。优化手段：Embedding批量离线预计算、向量索引用HNSW并调节efSearch参数、对高频query做结果缓存。对上海高并发问答场景，缓存命中能把平均响应时间从数秒压到数百毫秒，同时降低大模型调用成本。

六、上海团队的RAG评测体系建设

评测集构建方法

用真实业务问答构建评测集：收集用户高频问题，由业务人员标注标准答案与应引用的文档块。评测指标包括召回命中率（Top5是否包含正确块）、答案忠实度（是否基于资料）、答案相关性。建议每次改动切分或召回参数后跑一遍评测集，用数据决策而非凭感觉调参。

多轮检索与Query改写

复杂问题需做Query改写：把口语化追问结合上下文改写成完整检索语句，再去向量库召回。可由小模型先做问题拆分与改写，必要时做多路并行检索。对上海客服场景，用户常说「那这个呢」，脱离上下文根本无法检索，改写环节必不可少。

成本与延迟权衡

RAG成本由Embedding调用、向量检索、Reranker、大模型生成四部分构成。可对高频问题做答案缓存，对超长文档做摘要后再送上下文。上海团队应建立每千次问答的成本看板，在准确率与成本之间找到业务可接受的平衡点。

从文档解析到切分、Embedding、向量库、混合召回与重排，RAG是一条环环相扣的工程链路。上海开发者应把它当作系统工程来打磨，持续用评测集迭代切分策略与召回参数，才能让私有知识库问答真正可用。