RAG原理-RAG系统构建案例分析RAG 系统构建案例分析本节通过一个“基于企业文档的 LLM 问答系统”串联 RAG 从知识入库到生成答案的完整流程。核心不是让大模型记住文档而是在回答前先找出相关资料再让模型基于资料作答。一、整体架构整个系统可以拆成两条链路离线建库企业文档 → 文档解析 → 文本分块 → 向量化 → 写入向量数据库 在线问答用户问题 → 问题向量化 → 相似度检索 → 召回相关分块 → 组装 Prompt → LLM 生成答案 → 返回结果其中离线链路负责准备知识在线链路负责使用知识。二、离线阶段构建企业知识库1. 收集并解析文档企业知识往往分散在多种文件中例如文档类型常见内容PDF / Word制度、合同、产品手册PPT培训材料、方案汇报TXT / Markdown技术说明、FAQJSON / HTML结构化数据、网页内容第一步是使用对应的文档加载器提取正文同时尽量保留文件名、页码、章节等元数据方便后续引用与溯源。2. 文档分块Chunking长文档不能直接作为一个整体参与检索需要切成若干较小的文本片段Document ├── Chunk 1 ├── Chunk 2 ├── Chunk 3 └── Chunk 4分块的目的有两个让单个片段聚焦于一个相对完整的语义主题让检索结果更精确避免把大量无关内容一起交给大模型。分块不是越小越好。过大会混入无关信息过小又容易破坏上下文。实际项目通常需要结合文档结构设置块大小与重叠区间。3. 文本向量化Embedding 模型会把每个 Chunk 转换为一个向量Chunk 1 ──Embedding── Vector 1 Chunk 2 ──Embedding── Vector 2 Chunk 3 ──Embedding── Vector 3向量并不是简单的关键词集合而是文本语义在高维空间中的数值表示。语义越接近两段文本对应的向量通常也越接近。4. 写入向量数据库向量数据库通常同时保存Chunk 的向量Chunk 原文来源文件、页码、章节等元数据。推荐的数据结构可以抽象为{id:chunk-001,text:该文本片段的原始内容,vector:[0.12,-0.08,0.31],metadata:{source:employee_handbook.pdf,page:12}}三、在线阶段根据问题生成答案1. 接收用户问题用户提交自然语言问题后系统不会立刻把问题交给 LLM而是先调用与建库阶段一致的 Embedding 模型生成查询向量。Question ──Embedding── Query Vector建库和查询使用同一套向量空间非常重要否则两边的向量不可直接比较。2. 相似度检索系统使用 Query Vector 在向量数据库中查找最接近的若干 Chunk常见做法是返回 Top-K 结果。余弦相似度可表示为cosine_similarity(q, d) (q · d) / (||q|| × ||d||)这里的q是问题向量d是文档片段向量。相似度越高表示两者的语义越接近。3. 组装 Prompt召回结果不能直接视为最终答案而要与用户问题一起组成 Prompt你是一名企业知识库助手。请只根据“参考资料”回答问题如果资料不足请明确说明无法确定。 参考资料{retrieved_context} 用户问题{question}这个约束可以减少模型脱离资料自由发挥从而降低幻觉。4. 调用 LLM 生成回答LLM 接收到的内容本质上是系统指令 检索到的上下文 用户问题模型负责理解问题、综合多个片段并组织语言知识依据则主要来自检索结果。条件允许时还应把来源文件和页码一并返回让用户能够核验答案。四、完整流程伪代码下面的代码用于说明模块关系具体接口需要根据所选框架调整defbuild_knowledge_base(files,loader,splitter,embedder,vector_store):documentsloader.load(files)chunkssplitter.split_documents(documents)texts[chunk.page_contentforchunkinchunks]vectorsembedder.embed_documents(texts)metadatas[chunk.metadataforchunkinchunks]vector_store.add_embeddings(textstexts,embeddingsvectors,metadatasmetadatas,)defanswer(question,embedder,vector_store,llm,top_k4):query_vectorembedder.embed_query(question)documentsvector_store.similarity_search_by_vector(query_vector,ktop_k,)context\n\n.join(doc.page_contentfordocindocuments)promptf请仅根据以下参考资料回答问题。如果资料不足请明确说明无法确定。 参考资料{context}用户问题{question}returnllm.invoke(prompt)五、为什么要保留元数据仅保存文本和向量虽然可以完成检索但很难解释答案来源。保留元数据可以支持在答案后展示引用来源按部门、文档类型或时间过滤文档更新后定位并删除旧分块出现错误时追踪到原始材料。因此生产环境中的向量库不仅是“向量集合”也是知识治理的一部分。六、影响效果的关键环节环节常见问题优化方向文档解析表格、图片或扫描件内容丢失增加 OCR、表格解析与格式清洗文档分块语义被截断或块内信息过杂按标题、段落、句子进行结构化切分Embedding模型与领域语言不匹配选择适合中文或垂直领域的模型检索Top-K 结果相关性不足调整 K 值、过滤条件或加入重排Prompt模型忽略资料并自由发挥明确回答边界与资料不足时的行为数据更新旧知识长期留在向量库建立增量更新、版本与删除机制七、核心结论RAG 系统包含“离线建库”和“在线问答”两条链路。文档必须先被解析、分块和向量化才能进行语义检索。用户问题也要使用同一 Embedding 模型转换为向量。检索结果只是上下文最终答案仍由 LLM 结合问题生成。RAG 效果取决于整条数据链路任何环节失真都会影响最终回答。一句话总结RAG 的本质是“先检索可信知识再让大模型基于知识生成答案”。
