最近在做一个垂直领域的智能问答系统，业务方一开始就问了一个很现实的问题：我们是应该把行业文档喂给大模型做 RAG（检索增强生成），还是直接对模型做 Fine-Tuning（微调）？这个问题看似简单，实际落地时牵扯到数据更新频率、硬件成本、回答时效性、幻觉容忍度等一系列决策。网上关于 RAG 和 Fine-Tuning 的单点教程很多，但把两者放到同一场景下做系统性对比、并给出可落地的选型思路的资料却比较少。这篇文章就来补上这个缺口，结合领域 Chatbot 的开发实践，梳理两者的实现机制、成本构成、效果差异，并给出具体的工程建议。

如果你是正在做领域知识库问答、企业智能客服、私有化部署 Chatbot 的开发者，或者正在为技术选型纠结，这篇文章应该能帮你省下不少调研时间。全文会从概念拆解开始，逐步深入到实战对比、代码示例和踩坑排查，读完你可以根据自己项目的实际情况做出判断。

1. 背景与核心概念：RAG 和 Fine-Tuning 到底在解决什么问题

1.1 RAG 是什么

RAG，全称 Retrieval-Augmented Generation，检索增强生成。它的核心思路是：不把知识“塞进”模型参数里，而是在模型生成回答之前，先从外部知识库中检索出与用户问题相关的片段，把检索到的内容拼接到 Prompt 中，再让大模型基于这些上下文生成答案。

它的工作流程可以拆成四个环节：

1. 文档加载与解析：把 PDF、Word、Markdown、HTML 等格式的文档转换成纯文本。
2. 文本切块与向量化：把长文本按一定策略切成若干 chunk，再用 Embedding 模型把每个 chunk 转成向量。
3. 向量检索：用户提问时，把问题也转成向量，在向量数据库中做相似度检索，找到最相关的 Top-K 个片段。
4. 生成回答：把检索到的片段与用户问题一起组装成 Prompt，交给大模型生成答案。

RAG 的关键点在于：模型本身的参数不变，知识是以外部数据的形式参与推理的。所以它的回答具有“可追溯性”，每个答案都能关联到具体的知识片段，方便做引用溯源和 groundedness 校验。

1.2 Fine-Tuning 是什么

Fine-Tuning（微调）则是另一条路：在预训练模型的基础上，用标注好的领域数据继续训练，调整模型的部分或全部参数，让模型“内化”领域知识、术语体系和回答风格。

微调也有几种常见形式：

• 全量微调（Full Fine-Tuning）：更新模型全部参数，效果通常最好，但显存开销和训练成本最高。
• 轻量微调（如 LoRA、QLoRA）：冻结原始模型参数，只训练注入的低秩适配矩阵。显存占用小，训练速度快，是目前落地最常用的方式。
• 适配器微调（Adapter-based）：在 Transformer 层之间插入小型适配模块，只训练这部分参数。

不管哪种形式，微调的本质都是“改变模型内部的参数分布”，让模型在遇到类似问题时，更容易输出领域内的表达方式。

1.3 两者不是互斥的

这里要特别强调一个容易混淆的点：RAG 和 Fine-Tuning 并不是“二选一”的互斥方案。很多实际项目是两者结合使用——用微调让模型掌握领域表达习惯和输出格式，再用 RAG 提供实时更新的具体业务知识。

在正式对比之前，先记住这个结论：RAG 解决的是“模型不知道某个知识”的问题，Fine-Tuning 解决的是“模型不会用某种方式说话”的问题。定位不同，适用场景自然也不同。

2. 环境准备与版本说明

在进入详细对比和代码示例之前，先说明一下本文的演示环境。由于 RAG 和微调的生态更新很快，以下版本信息仅用于保证示例可运行，实际项目中请根据自身环境调整。

操作系统：Windows 11 / Ubuntu 22.04（本文示例以 Linux 为准）
Python：3.10+
Embedding 模型：text2vec-base-chinese（国产中文向量模型，可替换为 BGE 系列）
LLM：Qwen2-7B-Instruct（示例使用，可替换为 ChatGLM、Baichuan 等）
向量数据库：FAISS（本地轻量方案）/ Qdrant（生产推荐）
微调框架：LLaMA-Factory 或 peft + transformers
CUDA：12.x（微调需要 GPU 环境）

需要注意，本文的核心目的是对比 RAG 与微调的实现机制和工程权衡，而不是绑定某个特定模型。即使你的模型是 GPT-4、Claude、文心一言或其他闭源模型，RAG 部分的代码思路同样适用，只是 API 调用方式不同；微调部分则需要确认模型权重是否开放。

3. 对比维度拆解：从七个角度看实现权衡

下面从七个关键维度来对比 RAG 和 Fine-Tuning。这七个维度覆盖了技术选型时最常考虑的方面：数据更新、幻觉问题、成本、延迟、隐私安全、可解释性和性能天花板。

3.1 数据更新效率

RAG 的优势非常明显。 知识库文档更新后，只需要重新切块、重新生成向量、更新向量数据库即可。对于一个正常运营的企业来说，每天都有新的制度文件、产品手册、客服问答记录，RAG 可以做到小时级甚至分钟级的知识刷新，不需要重新训练模型。

Fine-Tuning 则相对笨重。 每次业务知识发生变化，都需要重新准备数据集、重新训练、重新评估、重新部署。一次完整的微调流程即使使用 LoRA 这类轻量方案，也需要数小时到数天不等。如果数据每天都在变，微调模式根本跟不上节奏。

3.2 幻觉问题与回答可靠性

RAG 天然具备降低幻觉的能力 ，因为模型生成回答时“有据可依”。只要检索到的片段是准确的，模型就有更大的概率基于片段生成正确的答案。即使检索结果不理想，我们也可以在系统中增加“拒答”策略：当检索相关度低于阈值时，直接告知用户“知识库中没有相关内容”，而不是强行编造。

Fine-Tuning 在幻觉控制上更依赖数据质量。 如果训练数据中存在错误、矛盾或模糊的表述，模型会把这些错误内化。而且微调后模型的“知识边界”很难清晰界定，你无法精确告知用户“模型不知道哪块知识”。这就导致一个典型问题：微调后的模型在领域内表现得很好，但一旦被问到领域边缘问题，很容易一本正经地胡说八道。

3.3 成本结构

RAG 的成本主要集中在基础设施层面：

• Embedding 模型的调用或部署成本。
• 向量数据库的存储与检索成本。
• LLM 的 Token 消耗成本（每次回答都需要把检索结果拼进 Prompt，Token 消耗比纯对话更高）。

Fine-Tuning 的成本则集中在训练阶段：

• 数据标注成本（微调效果的 80% 取决于数据质量）。
• GPU 训练资源成本。
• 训练后模型的托管与推理成本（微调后的模型需要独立部署，无法直接复用通用模型的 API）。

对于大多数中小企业来说，RAG 的起步成本更低，因为可以基于现成的通用模型 API 搭建，不需要购买和维护 GPU 服务器；Fine-Tuning 虽然单次训练成本可控（LoRA 方案），但长期维护成本不低。

3.4 响应延迟

RAG 会引入额外的检索耗时。 一次完整请求包含：问题向量化（约 20-50ms）、向量检索（约 10-30ms，取决于向量库规模）、Prompt 拼接与 LLM 生成。额外的延迟通常在百毫秒级别，对于问答场景完全可接受，但如果你做的是超高并发的实时对话，这个开销就需要评估。

Fine-Tuning 在推理阶段没有额外检索步骤。 输入直接进入模型生成输出，响应链路更短，理论上延迟更低。不过需要注意，微调后的模型参数量不变，推理速度与原始模型基本一致，并不会因为微调而变快。

3.5 数据安全与隐私

RAG 在私有化部署场景下更灵活： 文档、向量库、模型都可以部署在内网环境中。即使使用外部模型 API，发送到模型的是检索后的片段，而不是完整知识库，数据暴露面相对可控。

Fine-Tuning 在数据安全上有一个隐藏风险： 训练数据一旦被模型内化，就失去了“删除”的能力。如果某条敏感数据被用于训练，它会在模型中留下潜在影响，无法精准抹除。相比之下，RAG 只需要从知识库中删除对应文档即可完成数据“遗忘”。

3.6 可解释性与引用溯源

RAG 在可解释性上完胜。 每次回答都可以附上检索到的文档来源、片段位置、相似度分数。在企业客服、法律咨询、医疗问答等需要“凭据”的场景，这个能力几乎是刚需。

Fine-Tuning 本质上是一个黑盒。 你无法精确指出模型为什么这么回答，也无法给用户展示“这句话出自哪份文档”。这在某些强监管领域会成为致命缺陷。

3.7 效果上限

RAG 的效果上限取决于检索质量。 如果检索不到相关内容，模型再强也白搭。所以业界常说“RAG 的上限由检索决定，下限由生成决定”。

Fine-Tuning 的效果上限取决于模型基座的推理能力和训练数据的质量。 一个好的微调模型可以在特定领域表现出超越通用模型的水准，但如果基座模型本身逻辑能力不足，微调也补不上这个短板。

下面用一张表来快速总结七个维度的对比：

对比维度	RAG	Fine-Tuning
数据更新	快，分钟级	慢，小时级到天级
幻觉控制	好，可加拒答机制	依赖数据质量，边界模糊
起步成本	低，无需 GPU 训练	高，需要数据标注与训练资源
响应延迟	多一次检索耗时	无额外检索耗时
数据安全	可灵活删除数据	数据内化后难以抹除
可解释性	支持引用溯源	黑盒
效果上限	受限于检索质量	受限于基座模型能力

4. 技术决策地图：什么场景选什么方案

当我们在做一个领域特定的 Chatbot 时，可以先回答下面几个问题，再决定技术路线。

4.1 优先选择 RAG 的场景

以下几种情况，RAG 是不二之选：

• 知识库内容频繁更新 ，比如业务政策、产品规格、活动信息。用微调追踪这种变化既不经济也不及时。
• 回答需要附带依据 ，比如客服工单回复需要引用对应条款。RAG 可以自然地把引用链接展示给用户。
• 冷启动项目，没有积累足够的领域对话数据 。RAG 不需要标注训练数据，有文档就能搭建。
• 无法承担 GPU 训练成本 ，希望基于通用模型 API 快速构建 MVP。

4.2 优先选择 Fine-Tuning 的场景

以下几种情况，Fine-Tuning 更合适：

• 模型的输出风格和格式需要严格定制 ，比如要求模型写诗、写代码注释、模仿特定角色的语气。
• 领域术语和实体需要深度内化 ，模型需要理解企业内部黑话和缩写。
• 推理链路要求低延迟且稳定 ，不能容忍每次回答前多一次检索请求。
• 检索无法覆盖的知识 ，比如模型需要具备某种推理能力或无法用文档表达的经验知识。

4.3 场景混合策略

在实际项目中，最常见的是这种组合：

• 用 Fine-Tuning 调整模型的语气、格式和基础领域能力 ，让模型“更懂这个行业怎么说”。
• 用 RAG 动态注入事实性知识 ，让模型“时刻掌握最新信息”。

举个例子：一个保险行业的智能客服，先用几千条理赔对话对基座模型做 LoRA 微调，让模型学会保险术语和客服话术；然后挂载一个包含最新产品条款的 RAG 知识库。用户问“2025 年重疾险的等待期是多久”时，RAG 负责检索最新条款，微调后的模型负责用客服口吻把答案组织出来。这样既保证了事实准确性，又保持了对话体验。

5. 完整实战案例：构建一个领域 Chatbot 选型验证

为了让你更直观地感受两者的实现差异，这里用一个具体场景来演示。假设我们要做一个 企业 IT 运维知识问答机器人 ，知识库包含常见故障处理手册、网络配置指南、数据库运维规范等文档。我们分别用 RAG 和 LoRA 微调来实现它，并对比效果。

5.1 项目结构准备

it_ops_chatbot/
├── data/
│   ├── rag_docs/          # 运维知识文档
│   └── finetune_data/     # 微调训练数据
├── rag/
│   ├── ingest.py          # 文档入库脚本
│   ├── retrieve.py        # 检索函数
│   └── query.py           # 问答主流程
├── finetune/
│   └── lora_config.yaml   # LoRA 微调配置
└── requirements.txt

5.2 RAG 实现：文档入库脚本

首先来看 RAG 的文档入库环节。这一步的核心是把运维文档切块并向量化。

# 文件路径：rag/ingest.py
import os
from typing import List
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.document_loaders import DirectoryLoader, TextLoader
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.vectorstores import FAISS

def load_documents(docs_dir: str):
    """加载目录下的所有文本文档"""
    loader = DirectoryLoader(
        docs_dir,
        glob="**/*.md",
        loader_cls=TextLoader,
        loader_kwargs={"encoding": "utf-8"}
    )
    documents = loader.load()
    print(f"Loaded {len(documents)} documents")
    return documents

def split_documents(documents, chunk_size=512, chunk_overlap=64):
    """文本切块，chunk_overlap 用于保持语义连贯性"""
    text_splitter = RecursiveCharacterTextSplitter(
        chunk_size=chunk_size,
        chunk_overlap=chunk_overlap,
        separators=["\n\n", "\n", "。", "！", "？", "；", " ", ""]
    )
    chunks = text_splitter.split_documents(documents)
    print(f"Split into {len(chunks)} chunks")
    return chunks

def build_vectorstore(chunks, persist_dir="data/vectorstore"):
    """生成向量并持久化到 FAISS"""
    embeddings = HuggingFaceEmbeddings(
        model_name="BAAI/bge-base-zh-v1.5",
        encode_kwargs={"normalize_embeddings": True}
    )
    vectorstore = FAISS.from_documents(chunks, embeddings)
    vectorstore.save_local(persist_dir)
    print(f"Vectorstore saved to {persist_dir}")
    return vectorstore

if __name__ == "__main__":
    docs = load_documents("data/rag_docs")
    chunks = split_documents(docs)
    vectorstore = build_vectorstore(chunks)

这段代码里， RecursiveCharacterTextSplitter 会优先按段落（ \n\n ）切分，再逐级回退到句号、感叹号等标点，避免把一个完整句子硬切成两半。 chunk_size=512 表示每个块最多 512 个字符， chunk_overlap=64 表示相邻块之间重叠 64 个字符，这样能减少因为切块导致的上下文断裂问题。

5.3 RAG 实现：问答主流程

文档入库之后，需要编写一个查询函数，将用户问题向量化、检索相关片段、组装 Prompt 并返回答案。

# 文件路径：rag/query.py
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain_community.vectorstores import FAISS

# 初始化向量库（已在 ingest.py 中构建）
embeddings = HuggingFaceEmbeddings(
    model_name="BAAI/bge-base-zh-v1.5",
    encode_kwargs={"normalize_embeddings": True}
)
vectorstore = FAISS.load_local("data/vectorstore", embeddings)

def retrieve_relevant_docs(question: str, k: int = 5, score_threshold: float = 0.6):
    """检索与问题最相关的文档片段"""
    docs = vectorstore.similarity_search_with_relevance_scores(question, k=k)
    # 过滤掉相关度过低的片段，避免误导回答
    relevant_docs = [(doc, score) for doc, score in docs if score >= score_threshold]
    return relevant_docs

def build_prompt(question: str, docs: list) -> str:
    """组装 Prompt，把检索到的片段作为上下文"""
    context_sections = []
    for i, (doc, score) in enumerate(docs, 1):
        context_sections.append(
            f"[{i}] 来源: {doc.metadata.get('source', 'unknown')}\n"
            f"内容: {doc.page_content}\n"
            f"相关度: {score:.4f}"
        )
    context = "\n\n".join(context_sections)

    prompt = f"""你是企业 IT 运维助手。请根据以下知识库内容回答用户问题。
如果知识库中没有相关信息，请明确回答“知识库中未找到相关内容”，不要编造。

【知识库内容】
{context}

【用户问题】
{question}

请给出简洁、准确的回答。"""
    return prompt

def answer_question(question: str):
    """完整问答流程"""
    docs = retrieve_relevant_docs(question)
    if not docs:
        return "知识库中未找到相关内容，建议联系运维值班人员。"
    prompt = build_prompt(question, docs)
    # 这里以 OpenAI 兼容接口为例，实际项目可以接入本地部署的模型
    from openai import OpenAI
    client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
    response = client.chat.completions.create(
        model="qwen2-7b-instruct",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.1,
        max_tokens=500
    )
    return response.choices[0].message.content

if __name__ == "__main__":
    result = answer_question("数据库连接池满了怎么办？")
    print(result)

注意 temperature=0.1 这个参数：在 RAG 场景中，我们希望模型尽量忠实于检索到的上下文，不希望它自由发挥，所以温度要调低。 score_threshold=0.6 是相对保守的阈值，实际项目需要根据知识库内容和 Embedding 模型的实际打分分布来调整——如果发现很多有效答案被过滤掉了，就适当降低；如果发现总把不相关内容拼进来，就适当提高。

5.4 LoRA 微调：数据准备与配置

下面演示如何用 LoRA 对模型进行领域微调。微调不是本文的主线，所以只展示核心配置和调用方式。

# 文件路径：finetune/lora_config.yaml
model_name_or_path: Qwen/Qwen2-7B-Instruct
dataset_dir: data/finetune_data
dataset: it_ops_instruction   # 对应 data/finetune_data/it_ops_instruction.json
template: qwen
finetuning_type: lora
lora_rank: 16
lora_alpha: 32
lora_dropout: 0.05
learning_rate: 2.0e-4
num_train_epochs: 3.0
max_seq_length: 2048
per_device_train_batch_size: 4
gradient_accumulation_steps: 8
save_strategy: steps
save_steps: 200
logging_steps: 50
output_dir: outputs/it_ops_lora

训练数据格式遵循对话模板，示例：

[
  {
    "instruction": "数据库连接池满了应该怎么排查？",
    "output": "首先检查连接池最大连接数配置和当前活跃连接数，然后查看是否有慢查询或连接泄漏，最后根据监控数据分析连接峰值时段，必要时调整连接池参数。"
  },
  {
    "instruction": "Nginx 返回 502 错误怎么定位？",
    "output": "502 表示网关错误，优先检查后端服务是否存活、负载均衡配置是否正确、后端响应是否超时，同时查看 Nginx error log 和后端应用日志。"
  }
]

在 LLaMA-Factory 中启动训练的命令：

llamafactory-cli train finetune/lora_config.yaml

LoRA 微调的一个关键点是 lora_rank 的取值：模型越复杂、领域数据越多，这个值通常可以开得大一点（如 32、64），但代价是训练参数变多、过拟合风险变大。对于 7B 级别的模型， rank=16 是一个常见的起步值。

5.5 两者效果对比

用同一个测试问题“数据库连接池满了怎么办？”分别测试两套方案：

方案	回答质量	响应速度	部署方式
纯 RAG	能按手册步骤给出排查流程，附上文档来源	1.2-2.5 秒	CPU 服务器即可跑通
纯 LoRA 微调	能给出通用排查思路，但无法区分不同版本数据库差异	0.8-1.5 秒	需要一张 24G 显存的 GPU

单纯从回答效果看，RAG 在这个场景下表现更好，因为它可以精准检索到对应版本的数据库排障手册。微调模型的优点是响应更快、对话感更强，但知识深度和新鲜度不足。

这就是一个很典型的结论： 当知识是“查得到”的事实性内容时，RAG 优于微调；当知识是“说不清”的风格性内容时，微调优于 RAG。

6. 常见问题与排查思路

在 RAG 与微调落地过程中，有一些高频问题比较影响体验，这里集中说一下排查思路。

6.1 RAG 检索不到相关内容

问题现象	常见原因	解决思路
答非所问	切块粒度过大导致语义稀释	调小 chunk_size，增加 overlap
相关文档排在后面	Embedding 模型不适合领域文本	换用领域增强向量模型，如 BGE-large
检索结果太少	知识库覆盖不足	补充高质量文档，优化文档结构
检索结果相关度普遍很低	文档格式复杂，解析丢失正文	排查解析链路，对 PDF 先做 OCR

更具体一点 ：如果你发现切块太小了，比如每个 chunk 只有 100 字，那么一个完整流程被拆成五六块，检索时经常只命中其中一部分，回答就缺少上下文。这种情况下应该适当增大 chunk_size ，同时保证每个 chunk 自身语义完整。

6.2 RAG 回答仍然产生幻觉

RAG 虽然能降低幻觉，但不能完全消除。如果你发现模型无视检索内容强行作答，建议做两件事：

第一，在 Prompt 中用明确指令约束。示例：

# 强制约束 Prompt 中的角色边界
SYSTEM_PROMPT = """你是一个严谨的问答助手。规则：
1. 只根据[知识库内容]回答。
2. 若[知识库内容]不足以回答问题，必须回复"知识库中未找到相关内容"。
3. 禁止在答案中混入你的预训练知识。"""

第二，在代码层面增加“引用强校验”，判断回答中是否包含了检索片段中的关键实体。

6.3 微调后模型出现灾难性遗忘

问题现象	常见原因	解决思路
微调后通用能力下降	学习率过大、训练轮次过多	降低学习率，减少 epochs
领域回答和通用回答混杂	训练数据领域比例失衡	混入一定比例的通用对话数据
输出格式混乱	模板标签与模型不匹配	检查模板类型，统一 instruction 格式

6.4 微调显存不足

如果你用的是 7B 模型且显卡显存为 16G，训练过程中容易 OOM。推荐降级为 QLoRA，在 LoRA 基础上把基座模型也量化到 4-bit。

quantization_bit: 4

加上 QLoRA 后，7B 模型通常可以在 12G 显存的环境中完成训练。

7. 最佳实践与工程建议

7.1 RAG 落地建议

建立评测集，而不是靠感觉调优。 准备 100-200 条真实用户问题，标注标准答案或答案关键词。每次调整切块策略、Embedding 模型、Top-K 参数时，跑一遍评测集，用忠实度、答案命中率、拒答准确率三个指标来量化效果。

切块策略要结合文档结构。 对于按章节组织的标准手册，优先尝试 MarkdownHeaderTextSplitter 或按标题层级切块；对于表格较多的内容，建议先做表格结构化处理再入库，不要让表格变成纯文本丢给向量模型。

混合检索往往优于纯向量检索。 向量检索擅长语义匹配，但对精确的编号、型号、人名不敏感。一个实用的做法是“向量检索 + 关键词检索”双路召回，再用 Reranker 重排，能明显提升检索精度。

不要忽视后置处理。 生产级 RAG 至少要包括：检索片段相关度过滤、回答引用标记、知识库更新监控。

7.2 Fine-Tuning 落地建议

用 20 条“种子数据”试跑一版。 如果你的微调数据是人工标注的，建议先挑 20 条高质量数据跑一版 LoRA，观察训练 loss 曲线和生成效果，再决定是否扩大数据量。这一步能快速暴露模板不匹配、指令格式错误等问题。

训练数据不是越多越好，而是越干净越好。 微调中 30% 的异常数据可能带来 70% 的效果偏离。标注完成后一定要做一轮清洗，重点关注：答案是否完整、是否存在幻觉、是否包含冲突信息。

保留验证集，防止模型“复读”。 微调后的模型有时会机械地复现训练数据的表达，这在对话场景中显得很生硬。准备一个验证集，在训练结束后逐个检查模型输出的多样性和自然度。

7.3 生产架构建议：RAG 与微调组合

最后推荐一个工程上比较稳健的组合架构：

• 第一层：意图识别与路由。判断用户问题是事实性问题（走 RAG）还是开放性问题（直接走通用能力）。
• 第二层：RAG 检索链路。负责提供事实依据，带引用溯源。
• 第三层：指令微调后的领域模型。负责最终生成，保证输出风格符合领域预期。

在这个架构下，微调不是用来“记住知识”，而是用来“学会表达”。RAG 也不是仅仅检索片段，而是提供“可信的知识上下文”。两者各司其职，才能让领域 Chatbot 既准确又自然。

8. 总结与学习路线

本文围绕“领域特定 Chatbot 的 RAG 与 Fine-Tuning 实现权衡”这个核心问题，梳理了两者的实现机制、七大维度的效果差异、技术选型的决策思路，并给出了 RAG 和 LoRA 微调的最小可运行示例。

读完这篇之后，下一步你可以按自己的项目需求继续深入：

• 如果确认走 RAG 路线，建议重点研究混合检索、Reranker、引用溯源和图数据库增强。RAG 不是“切块 + 向量检索”那么简单，企业级 RAG 更多是在检索精度和知识组织上拉开差距。
• 如果确认走微调路线，建议先系统学习 LoRA / QLoRA 的原理，再基于 LLaMA-Factory 或 peft 复现本文的微调流程。
• 如果两个方案都拿不准，建议先用 RAG 快速搭建一个 MVP 跑通流程，再根据业务反馈决定是否引入微调。这个顺序从成本和效率来看，通常是更优的。

技术选型没有标准答案，但只要把数据更新频率、回答可解释性、成本预算、时效要求这几个关键变量理清楚，做决定并不难。希望这篇文章能帮你少走一些弯路。如果你在实际落地中遇到其他问题，欢迎在评论区留言交流。