企业官网建设流程全解析

简介：检索增强生成（RAG）是一种将大语言模型的通用知识与外部知识库相结合的技术架构，其核心原理是通过向量化检索，为模型提供精准、实时的外部信息，从而有效缓解大模型的“幻觉”问题，并实现知识的动态更新。这一技术为构建专业、可靠的垂直领域智能应用提供了可行路径，尤其在医疗、法律、金融等对准确性和时效性要求极高的场景中价值显著。本文以医疗健康问答为具体应用场景，深入剖析了基于LangChain、Chroma等主流开源工具链，从文档处理、混合检索到提示工程与本地化部署的完整RAG实现闭环，并分享了在文本分割、Embedding模型选型及效果评估等关键环节的实战经验与调优心得。

1. 项目缘起：为什么一个“高分毕设”值得深挖？

最近在整理资料时，翻到了一个之前指导过的学生项目，标题是“基于 RAG 与大模型技术的医疗问答系统”。这个项目当时拿了高分，学生也顺利毕业了。但说实话，当时更多是把它当作一个教学案例，一个“交差”的作业。直到最近，随着 RAG 技术在各种场景下的落地讨论越来越热，特别是看到很多朋友在尝试构建自己的知识库应用时反复踩坑，我才重新审视了这个项目。我发现，这个看似简单的“毕设”，其实完整地走通了一个从零到一的 RAG 应用闭环，里面涉及的很多细节和思考，恰恰是现在很多初级开发者甚至一些团队在实践中最容易忽略的。

这个项目不是一个炫技的庞然大物，它的价值在于“麻雀虽小，五脏俱全”，并且每一步都踩在了“实用”和“可复现”的点上。它没有用最前沿但还不稳定的框架，也没有堆砌复杂但用不上的功能，而是用最主流的开源工具链，清晰地展示了如何将大模型的“通识”能力与特定领域的“专业知识”结合起来。对于想入门 RAG、想做一个能真正跑起来的垂直领域问答应用的朋友来说，这个项目的骨架和思路，可能比很多天花乱坠的教程更有参考价值。今天，我就把这个项目的核心设计、关键实现步骤，以及那些在代码里不会写的“踩坑心得”拆解出来，希望能帮你绕过一些弯路。

2. 核心架构拆解：RAG 在医疗问答中如何“各司其职”

这个系统的核心目标很明确：让一个通用的大模型（比如当时用的 Qwen 系列）能够回答专业的医疗健康问题。直接让大模型回答，它可能会基于训练数据“编造”或给出模糊、过时的建议，这是医疗场景绝对不允许的。RAG 的引入，就是为了解决这个“幻觉”和“知识更新”的问题。

整个系统的架构可以清晰地分为三个层次：知识处理层、检索增强层和问答生成层。很多初学者容易把 RAG 简单理解为“向量搜索 + 大模型”，但实际上，每一层都有大量细节决定了最终效果的上限。

2.1 知识处理层：从原始文档到可检索的“知识片段”

这是整个流程的基石，也是后期效果不佳时最需要回溯检查的环节。我们的知识源是一些公开的、结构相对清晰的医疗百科、疾病指南文档（格式包括 PDF、TXT、HTML）。这一步的目标是把这些非结构化的文档，变成大模型能高效“消化”的格式。

2.1.1 文档加载与解析：格式是第一个拦路虎

我们使用了LangChain的DocumentLoader系列工具。这里第一个坑就来了：不同格式的文档解析质量天差地别。

• PDF：如果是文本型 PDF，PyPDFLoader基本够用。但很多医疗文档是扫描版图片 PDF，这就需要先用 OCR（如paddleocr）识别，再加载。我们当时就遇到了几份扫描版的体检报告解读，直接加载出来是乱码。
• HTML/网页：使用BeautifulSoupHtmlLoader，重点在于配置好tags来剔除导航栏、广告等噪音，只保留正文内容。一个技巧是，观察目标网站的 HTML 结构，通常正文内容都在<article>、<main>或特定的<div class="content">标签里。

2.1.2 文本分割（切块策略）：比想象中更关键

这是本项目的一个重点调优项。简单的按字符数或句子分割会破坏语义的完整性。比如，“高血压患者应遵医嘱服用降压药，同时注意低盐饮食。” 如果刚好在“降压药”这里切断，后半句“同时注意低盐饮食”就失去了主语，检索和模型理解都会出问题。

我们采用了递归字符分割与重叠窗口相结合的策略：

1. 首选按段落分割：利用\n\n进行初步分割，保留自然段落。
2. 递归细化：对于过长的段落，再按标点符号（。！？；）进行二次分割，尽量保证每个“块”是一个完整的语义单元。
3. 设置重叠窗口：每个文本块末尾的 100-200 个字符，会作为下一个文本块的开头。这确保了即使分割点不够理想，关键信息也不会被完全割裂，在检索时能提供更连贯的上下文。例如，关于“糖尿病饮食”的说明可能跨了两个块，重叠部分能帮助模型更好地理解前后关联。

注意：重叠不是越大越好。过大的重叠会导致检索出大量重复内容，挤占有限的上下文窗口，并且增加 embedding 和存储的成本。需要根据文档的平均长度和语义密度进行权衡。

2.2 检索增强层：如何让系统“精准回忆”

处理好的文本块，需要转换成计算机能理解的形式（向量），并建立索引，以便快速查找。这里我们选择了Chroma作为向量数据库，主要是因为它轻量、易用，且和LangChain集成良好。

2.2.1 向量化模型选型：平衡效果与效率

Embedding 模型的选择直接决定了检索的准确性。当时对比了text-embedding-ada-002(OpenAI)、bge-large-zh(智源) 和m3e-base。

• text-embedding-ada-002：效果很好，但需要网络调用，有延迟、成本和隐私考虑。
• bge-large-zh与m3e-base：都是优秀的开源中文模型。bge-large-zh在权威评测上排名靠前，但模型更大（1.3B参数）；m3e-base则更轻量（约 300M 参数），且在中文社区数据上训练充分。
• 我们的选择：考虑到部署简便性和响应速度，最终选择了m3e-base。对于医疗领域专有名词，它的表现足够可靠，并且可以在 CPU 上快速运行，降低了毕设项目的环境配置门槛。如果对精度要求极高，可以尝试用医疗文献微调bge模型，但那属于进阶操作了。

2.2.2 检索策略：不仅仅是“相似度”

最简单的检索是计算用户问题与知识库所有文本块的向量余弦相似度，取 Top-K。但这在医疗问答中容易出问题。比如用户问“我头疼流鼻涕怎么办？”，单纯向量相似度可能会检索出“偏头痛的治疗”和“感冒的症状”，但后者显然更相关。

我们引入了混合检索策略：

1. 向量检索：作为主力，捕捉语义相似性。
2. 关键词检索（BM25）：作为补充。对于一些特定的医学术语、药品名（如“阿司匹林”、“CT检查”），关键词匹配非常精准快速。我们将两种检索方式的结果进行加权融合（如 70% 向量分 + 30% 关键词分），再重新排序，有效提升了召回结果的相关性。

2.3 问答生成层：让大模型“好好说话”

检索到相关的知识片段后，如何交给大模型生成最终答案，这里面的“包装”艺术很重要。

2.3.1 提示词工程：给模型明确的“角色”和“任务”

直接扔给模型“这是背景知识，请回答问题”是远远不够的。我们设计了系统提示词（System Prompt），核心包含：

• 角色定义：“你是一个专业的医疗健康助手，基于提供的权威医学知识进行回答。”
• 能力边界限定：“你只能根据提供的参考信息回答问题。如果信息不足或未涵盖用户问题，你必须明确告知‘根据现有资料无法给出确切建议，请咨询专业医生’。”
• 回答格式要求：“回答应清晰、有条理，优先分点说明。避免使用绝对化词汇。”
• 安全警告：“所有内容仅供参考，不能替代专业医疗诊断。”

2.3.2 上下文构建与历史管理

我们将检索到的 Top-3 个相关文本块，连同用户当前问题，以及简短的对话历史（最近2轮），一起构建成最终的提示词提交给大模型。这保证了回答的连贯性。例如，用户先问“感冒有什么症状？”，再问“该怎么治疗？”，模型能结合历史知道用户仍在讨论感冒。

2.3.3 大模型本地化部署：性价比之选

当时 ChatGPT API 成本较高且存在合规风险，因此选择了本地部署。我们使用了Qwen2-7B-Instruct模型，通过llama.cpp进行量化（如 q4_k_m）后，在消费级显卡（如 RTX 3060 12GB）甚至大内存 CPU 上都能流畅运行。用FastAPI包装成 HTTP 服务，供后端调用。这套组合在效果、成本和部署难度上取得了很好的平衡。

3. 关键实现步骤与代码要点

下面我以核心代码片段为例，说明几个关键环节的实现。请注意，这不是完整的源码，而是剥离了业务逻辑后的技术骨架。

3.1 知识库构建流水线

# 示例：使用 LangChain 构建知识库 from langchain_community.document_loaders import PyPDFLoader, TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载文档 loaders = [PyPDFLoader("path/to/medical_guide.pdf"), TextLoader("path/to/symptoms.txt")] documents = [] for loader in loaders: documents.extend(loader.load()) # 2. 分割文本 text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, # 每个块大约500字符 chunk_overlap=100, # 重叠100字符 separators=["\n\n", "\n", "。", "！", "？", "；", "，", "、", " "] ) chunks = text_splitter.split_documents(documents) # 3. 初始化嵌入模型 embed_model = HuggingFaceEmbeddings( model_name="moka-ai/m3e-base", # 使用 M3E 模型 model_kwargs={'device': 'cpu'}, # 指定设备 encode_kwargs={'normalize_embeddings': True} # 归一化，有利于相似度计算 ) # 4. 创建并持久化向量库 vector_db = Chroma.from_documents( documents=chunks, embedding=embed_model, persist_directory="./chroma_medical_db" # 指定持久化目录 ) vector_db.persist() # 保存到磁盘

关键点：chunk_size需要根据你选用的大模型上下文窗口和文档特点调整。对于长文档、细节多的内容，块可以小一些；对于概述性内容，块可以大一些。m3e-base模型对中文支持友好，且device='cpu'的配置让没有 GPU 的环境也能运行。

3.2 混合检索器的实现

# 示例：结合向量检索和关键词检索 from langchain.retrievers import BM25Retriever, EnsembleRetriever from langchain_community.retrievers import BM25Retriever as LangchainBM25Retriever from langchain_community.vectorstores import Chroma # 假设已有 vector_db (Chroma) 和文本块列表 `texts_for_bm25` (纯字符串列表) # 1. 初始化向量检索器 vector_retriever = vector_db.as_retriever(search_kwargs={"k": 5}) # 2. 初始化 BM25 检索器 # 注意：LangChain 的 BM25Retriever 需要传入 Document 对象列表，我们提前准备好 from langchain.schema import Document bm25_docs = [Document(page_content=text) for text in texts_for_bm25] bm25_retriever = BM25Retriever.from_documents(bm25_docs) bm25_retriever.k = 5 # 3. 创建混合检索器 ensemble_retriever = EnsembleRetriever( retrievers=[vector_retriever, bm25_retriever], weights=[0.7, 0.3] # 权重可调 ) # 使用混合检索器进行查询 query = "糖尿病患者可以吃水果吗？" relevant_docs = ensemble_retriever.get_relevant_documents(query)

关键点：EnsembleRetriever是 LangChain 提供的一个很方便的组件。权重参数weights=[0.7, 0.3]需要根据实际测试效果调整。对于术语性强的问题，可以适当提高 BM25 的权重。

3.3 基于 FastAPI 的问答服务端

# app.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel from langchain.chains import RetrievalQA from langchain.prompts import PromptTemplate from langchain_community.llms import LlamaCpp # 假设使用 llama.cpp 加载的模型 app = FastAPI(title="医疗问答系统API") # 加载本地模型 (示例，需提前用 llama.cpp 量化并加载模型) llm = LlamaCpp( model_path="./models/qwen2-7b-instruct-q4_k_m.gguf", n_ctx=4096, # 上下文长度 temperature=0.1, # 低温度，让回答更确定 verbose=False ) # 加载之前构建的向量库 embed_model = HuggingFaceEmbeddings(model_name="moka-ai/m3e-base") vector_db = Chroma(persist_directory="./chroma_medical_db", embedding_function=embed_model) retriever = vector_db.as_retriever(search_kwargs={"k": 3}) # 定义更专业的提示模板 prompt_template = """你是一个专业的医疗健康助手。请严格根据以下提供的参考信息来回答问题。 如果参考信息中没有足够的内容来回答用户的问题，请直接说“根据现有资料无法给出确切建议，请咨询专业医生”。不要编造信息。 参考信息： {context} 用户问题：{question} 请基于参考信息，给出专业、清晰、有条理的回答：""" PROMPT = PromptTemplate(template=prompt_template, input_variables=["context", "question"]) # 创建检索问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", # 最简单的方式，将所有检索到的文档“堆叠”进上下文 retriever=retriever, chain_type_kwargs={"prompt": PROMPT}, return_source_documents=True # 返回源文档，便于调试 ) class QueryRequest(BaseModel): question: str chat_history: list = [] # 可选的对话历史 @app.post("/ask") async def ask_question(request: QueryRequest): try: # 这里可以加入对 chat_history 的处理，例如拼接进最终问题或上下文 result = qa_chain({"query": request.question}) return { "answer": result["result"], "source_documents": [doc.page_content[:200] + "..." for doc in result["source_documents"]] # 返回部分源文本 } except Exception as e: raise HTTPException(status_code=500, detail=str(e))

关键点：

1. llama.cpp加载量化模型极大地降低了硬件门槛。
2. temperature=0.1在医疗等严肃领域很重要，能减少模型的随意发挥。
3. chain_type="stuff"是最直接的方式，但当检索到的文档总长度超过模型上下文时，需要使用map_reduce、refine等其他策略，这在本项目中通过控制chunk_size和k值来避免。
4. 返回source_documents对于调试和增加回答的可信度至关重要。

4. 从“能跑”到“好用”：项目优化与踩坑实录

把流程跑通只是第一步，要让系统真正“可用”，我们遇到了不少问题，也做了一系列优化。

4.1 效果评估：如何知道系统回答得好不好？

这是毕设项目从“演示”走向“实用”的关键一步。我们不能只靠人工看几个例子。

4.1.1 构建测试集我们手动整理了约100个 Q-A 对作为测试集。问题涵盖常见病症状、用药咨询、保健知识等。每个问题都对应知识库中确切的答案片段。

4.1.2 设计评估指标

• 答案相关性：生成的答案是否与标准答案在核心信息上一致？（人工评分：1-5分）
• 幻觉率：答案中是否出现了知识库中不存在的信息？（统计百分比）
• 拒答能力：当问及知识库外的问题（如“我得了癌症怎么治？”）时，系统是否能正确拒绝回答？（统计百分比）
• 检索准确率：返回的源文档是否真正包含了答案？（通过检查source_documents判断）

通过这个简单的评估框架，我们量化了调整chunk_size、overlap、检索权重、提示词等参数带来的效果变化，让优化有了依据。

4.2 常见问题与调优手段

问题一：答案看起来相关，但细节错误或模糊。

• 排查：检查检索到的源文档。发现有时检索到的文档只是“擦边”相关，比如问“高血压用药”，检索到的是“高血压概述”，里面只有一句“需要药物治疗”，没有具体药名。
• 解决：
  1. 优化分割策略：尝试按“章节标题”或“问答对”格式进行更精细的分割，确保每个文本块信息浓度更高。
  2. 调整检索数量：将k从 3 增加到 5，给模型更多上下文来综合判断。
  3. 强化提示词：在提示词中明确要求“如果参考信息中没有提到具体药物名称，请说明信息不足”。

问题二：对于组合型问题（如“感冒和流感有什么区别？”），回答不全面。

• 排查：发现检索结果可能只偏向“感冒”或“流感”一方。
• 解决：
  1. 查询改写：在检索前，用一个小模型（或规则）将复杂问题拆解成多个子问题（如“感冒的症状是什么？”、“流感的症状是什么？”），分别检索后再合并上下文提交给大模型。
  2. HyDE 技术尝试：让大模型先根据问题“假设”一个答案，用这个假设答案的向量去检索，有时能检索到更匹配的对比性文档。这在项目中进行了实验，效果有提升但增加了复杂度。

问题三：响应速度慢。

• 瓶颈分析：使用 profiling 工具发现，时间主要耗在：1. 嵌入模型计算查询向量；2. 大模型生成答案。
• 解决：
  1. 缓存：对常见问题（如“发烧怎么办？”）的查询向量和检索结果进行缓存。
  2. 模型量化：将Qwen2-7B从q4_k_m尝试更激进的量化（如q2_k），速度提升明显，但需要评估精度损失是否在可接受范围。
  3. 异步处理：将检索和生成设计为异步流水线。

4.3 安全与伦理考量：医疗领域的红线

这是本项目贯穿始终的紧箍咒。

1. 能力边界声明：在系统界面和每一次回答的末尾，都强制添加免责声明：“本回答基于公开医学资料生成，仅供参考，不能替代专业医师诊断。如有不适，请及时就医。”
2. 输入过滤：对用户输入进行简单的关键词过滤和意图识别，对于明显涉及急症、重症、自杀倾向等问题，直接触发预设的安全回复，引导用户拨打急救电话或寻求专业帮助。
3. 输出审核：虽然无法做到实时人工审核，但在测试阶段，我们对大量输出进行了审查，确保其语气谨慎、避免绝对化建议（如“必须”、“绝对不行”），多用“通常建议”、“可以考虑”等表述。

5. 项目扩展与进阶思考

这个毕设项目提供了一个坚实的起点。如果你想在此基础上深入，以下几个方向值得探索：

1. 知识图谱增强 RAG单纯的向量检索是“模糊匹配”，而医疗知识中存在大量实体（疾病、药品、症状）和明确关系（并发症、禁忌症、治疗方案）。可以尝试从文本中抽取实体关系构建小型知识图谱。在检索时，先进行实体识别和链接，再从图谱中获取精准的三元组信息，与向量检索到的文本片段一起作为上下文喂给大模型。这能极大提升对复杂推理问题的回答能力。

2. 智能体（Agent）工作流引入当前系统是“一次检索+一次生成”的管道。可以引入智能体概念，让系统具备“思考-行动”能力。例如：

• 用户问：“我头痛且血压高，该挂哪个科？”
• 智能体可以规划：第一步，检索“头痛的可能原因”；第二步，检索“高血压的注意事项”；第三步，综合信息，推理出“建议先挂神经内科，同时监测血压，心内科也可能相关”。这使系统能处理多步骤复杂查询。

3. 多模态能力集成医疗场景中，影像（X光、CT）、图表（化验单）是重要信息源。未来可以探索多模态大模型（如 LLaVA）或专门的视觉编码器，将图片信息也转化为向量，与文本向量一起构建多模态知识库，实现“根据皮疹图片判断可能疾病”等功能。

4. 持续学习与知识更新医疗知识日新月异。需要设计一个流程，定期爬取或导入最新的医学指南、药品说明书，经过同样的处理流程（去重、分割、向量化）后，增量更新到向量数据库中。同时，可以考虑引入“用户反馈”机制，对答案进行点赞/点踩，将高质量问答对作为新的训练数据，优化检索和生成模型。

回过头看，这个“高分毕设”的价值，不在于它用了多酷的技术，而在于它完整、清晰、可复现地解决了一个真实问题。它告诉你，从一堆 PDF 文档到一个能回答专业问题的 AI 助手，中间每一步具体要做什么、会遇到什么坑、可以怎么解决。技术总是在迭代，但这种构建垂直领域 AI 应用的框架性思维和务实方法，才是更持久的东西。如果你正打算启动一个类似的 RAG 项目，希望这份从实战中总结出来的“地图”，能帮你走得更稳一些。

本文还有配套的精品资源，点击获取