纲要

• 模型选型决策框架
  • 开源与闭源的本质区别
  • 决策坐标系：灵活定制化 vs 隐私安全
    • 高定制+高安全 → 私有化部署
    • 高定制+低安全 → 标准开源微调
    • 低定制+高安全 → 混合方案
    • 低定制+低安全 → 直接调用闭源 API
• 选择模型的六个核心要素
  • 效率：部署时间与响应速度
  • 成本：初始投入与运营开销
  • 场景：对话、多模态、推理等
  • 安全与合规：数据隐私、行业法规
  • 开发生态：维护团队、社区活跃度、工具链
  • 上下文窗口：长文处理能力
• 大模型的四大短板
  • 记忆能力受限（上下文窗口外遗忘）
  • 知识更新滞后（训练数据截止后无法感知新信息）
  • 无法直接操作外部系统与实时数据
  • 专业领域适应性差
• 短板应对方案
  • 微调（Fine‑tuning）：深度注入行业知识
  • 嵌入（Embedding）+ 检索增强生成（RAG）：轻量级知识外挂
  • 提示工程（Prompt Engineering）：零成本引导输出
  • 组合策略：微调打底 + RAG 实时更新
• 微调 vs RAG 对比
  • 成本、实时性、专业知识深度、系统复杂度
• 代码实战：搭建一个简易 RAG 问答系统
  • 使用 OpenAI 或兼容 API + Chroma 向量数据库
  • 完整可运行 Python 脚本
• 渐进式选型策略与未来趋势

开源还是闭源：用坐标系找到你的答案

面对市面上成百上千的大模型，第一个现实问题就是：开源还是闭源？
这个问题没有标准答案，但可以借助一个二维坐标系，根据项目的灵活定制化程度和隐私安全需求来定位。

• 右上象限（高定制 + 高安全）：适用于政府、金融、大型企业。需要私有化部署开源模型，甚至基于开源底座训练自有大模型，确保数据完全隔离。典型案例：滴滴利用海量交通数据自研模型，金融机构将客户数据留存在内部服务器。
• 右下象限（高定制 + 低安全）：适合中小企业或低敏感场景。可直接使用 LLaMA、Qwen 等开源模型进行微调，将自己的业务数据注入模型，快速获得定制化能力，同时成本可控。
• 左上象限（低定制 + 高安全）：典型场景是数据敏感但对模型能力要求相对通用的商业应用。可以采用“闭源 API + 厂商专属部署”的混合方案，或者本地部署未微调的开源模型，实现开箱即用且数据不外泄。
• 左下象限（低定制 + 低安全）：原型验证、通用服务、个人项目的最优选择。直接调用 OpenAI、Gemini 等闭源 API，省去部署和运维烦恼，快速上线。

选择模型必须考虑的六个要素

一旦确定了开源/闭源的大方向，还需要从以下六个维度进一步筛选具体模型：

要素	核心问题	举例
效率	部署周期多长？推理延迟能否接受？	开源模型需自行搭建 GPU 推理服务，闭源 API 一分钟即可接入
成本	初始投入 + 持续运营成本	GPU 云实例每小时几元，频繁调用 API 的 token 消耗同样不菲
场景	对话、图文理解、代码生成还是专业问答？	多模态任务需选择 GPT‑4o 或 Gemini，纯文本可选更便宜的模型
安全与合规	数据是否允许传出本地？是否需通过国家备案？	医疗、政务数据通常必须留存在内网，优先考虑私有化部署
开发生态	模型维护是否活跃？周边工具是否完善？	LLaMA、Qwen 社区庞大，Hugging Face 上工具链成熟
上下文窗口	单次处理的最大 token 数是否满足业务需要？	Gemini 支持 100 万 token，适合长文档分析

综合这六个要素，才能做出理性的技术决策。而无论选择哪种模型，在实际应用中都会遇到一些共性的“天花板”。

大模型的四大短板

当前的大模型虽然强大，但在实际落地时普遍存在以下痛点：

记忆受限：健忘的天才

无论上下文窗口开多大，一旦超出窗口的内容就会被“遗忘”。多轮对话中，用户经常需要反复重申背景信息，体验割裂。

知识滞后：静止的图书馆

模型知识停留在训练数据截止日期，无法感知此后发生的新事件、新政策、新研究成果。例如询问今年最新的股票行情，模型给出去年的数据。

无法操作外部系统

模型本身不能查询数据库、调用 API、读取文件，只能基于内部知识生成文本，无法与现实世界交互。

专业领域适应不足

通用大模型在医疗、法律、金融等垂直领域往往给出看似合理实则错误的答案，缺乏经过严格验证的专业知识。

这些问题会直接导致 Agent 不可靠。好在业界已经发展出三种主要应对技术。

三种解决方案：微调、嵌入（RAG）与提示工程

微调：将通才变成专家

微调相当于让一个博学的预训练模型“进修”特定领域课程，在保留原有广泛知识的同时，显著提升该领域的准确性。

典型流程：

1. 准备数据：收集、清洗、格式化为模型可接受的对话或文本对。
2. 选择基座模型：根据参数规模（7B、13B、70B 等）匹配可用算力。
3. 设置超参：学习率、批次大小、LoRA 秩等。
4. 执行训练：监控损失曲线，使用早停避免过拟合。

适用场景：拥有大量独家行业数据（如多年积累的医疗病例、法律文书），且数据相对稳定，不要求实时更新。

局限性：训练成本高（全参数微调相当于重训），无法动态感知新信息，每次知识更新都需重新微调。

嵌入与检索增强生成：给模型外挂知识库

RAG（Retrieval‑Augmented Generation）通过实时检索外部知识库，为模型提供“外挂”记忆。它的工作流程如下：

其核心步骤包括：

• 数据加载与分块（Chunking）：将长文档切分成适合模型窗口的小块。
• 向量化（Embedding）：将文本块转换为语义向量，存入向量数据库。
• 检索（Retrieval）：用户提问时，在向量空间中查找最相似的 Top‑K 个块。
• 生成（Generation）：将检索到的块作为上下文，与问题一同提交给大模型，生成有据可依的回答。

优势：成本低（无需训练）、灵活、知识库可实时更新，解决了知识滞后和记忆窗口限制。
挑战：检索质量是关键瓶颈，分块策略和 Embedding 模型的选择直接影响效果。

提示工程：零成本的引导术

通过精心设计提示词，引导模型输出更符合预期的答案。虽然最轻量，但对于复杂专业知识的补充效果有限，更适合作为微调和 RAG 的辅助手段。

在实际项目中，往往采用组合拳：微调打造行业基座，RAG 注入实时数据，提示词控制交互风格。

微调 vs RAG 快速对比

维度	微调	RAG
实时信息感知	❌ 需重新训练	✅ 实时检索
专业知识深度	✅ 深度内化	⚠ 依赖检索质量
初始成本	高（需要 GPU 集群）	低（仅需向量库）
系统复杂度	中	较高（需维护索引）
适用数据量	大量高质量标注数据	少量即可启动，可逐步扩充

代码实战：搭建一个简易 RAG 问答系统

下面提供一个完整可运行的 Python 脚本，使用 OpenAI（或兼容 API）搭配 Chroma 向量数据库，实现一个简单的 RAG。你可以直接复制运行，快速体验知识检索增强的效果。

环境准备：

1. 安装依赖：pip install openai chromadb langchain-text-splitters
2. 准备一个文本文件 knowledge.txt（你可以放入任意知识内容，例如产品手册、公司制度等）。
3. 准备 API Key：脚本默认使用 deepseek-chat（兼容 OpenAI 协议），也可换成其他模型。

import os
import openai
import chromadb
from chromadb.utils import embedding_functions
from langchain_text_splitters import RecursiveCharacterTextSplitter

# ======================== 配置区 ========================
# 使用 DeepSeek 作为示例（兼容 OpenAI SDK），你也可以换成 OpenAI 或其他兼容 API
MODEL_NAME = "deepseek-chat"
API_KEY = "your-api-key-here"  # 替换为你的 key
BASE_URL = "https://api.deepseek.com"

# 如果使用 OpenAI 官方，修改为：
# MODEL_NAME = "gpt-4o-mini"
# API_KEY = "sk-xxx"
# BASE_URL = "https://api.openai.com/v1"

# 知识库文件
KNOWLEDGE_FILE = "knowledge.txt"
CHUNK_SIZE = 500           # 分块大小（字符数）
CHUNK_OVERLAP = 50         # 块之间重叠长度
COLLECTION_NAME = "my_knowledge_base"
# ======================================================

# 初始化 OpenAI 客户端
client = openai.OpenAI(api_key=API_KEY, base_url=BASE_URL)

# 初始化 Chroma 向量数据库（使用本地持久化）
chroma_client = chromadb.PersistentClient(path="./chroma_db")

# 获取或创建向量集合，使用 OpenAI 兼容的 embedding 函数
# 注意：这里使用 OpenAI 的 text-embedding-ada-002 需要相应权限，若没有可以换成其他 embedding 服务
# 简便起见，我们使用 Chroma 自带的 sentence-transformers 作为 embedding 函数（无需额外 API key）
sentence_transformer_ef = embedding_functions.SentenceTransformerEmbeddingFunction(
    model_name="all-MiniLM-L6-v2"
)
collection = chroma_client.get_or_create_collection(
    name=COLLECTION_NAME,
    embedding_function=sentence_transformer_ef
)

# 读取并分割文档
def load_and_split_document(file_path):
    with open(file_path, "r", encoding="utf-8") as f:
        text = f.read()
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=CHUNK_SIZE,
        chunk_overlap=CHUNK_OVERLAP,
        separators=["\n\n", "\n", "。", ".", " ", ""]
    )
    return splitter.split_text(text)

# 将分割后的文本块存入向量数据库（自动生成向量）
def index_documents(chunks):
    # 为避免重复索引，先清空已有集合（仅用于演示，生产环境应增量更新）
    try:
        chroma_client.delete_collection(COLLECTION_NAME)
        global collection
        collection = chroma_client.get_or_create_collection(
            name=COLLECTION_NAME,
            embedding_function=sentence_transformer_ef
        )
    except:
        pass
    ids = [f"chunk_{i}" for i in range(len(chunks))]
    collection.add(documents=chunks, ids=ids)
    print(f"索引完成，共 {len(chunks)} 个文本块。")

# 检索相关文本块
def retrieve(query, top_k=3):
    results = collection.query(query_texts=[query], n_results=top_k)
    return results["documents"][0]

# 生成增强回答
def generate_answer(query, context_docs):
    # 构造提示词
    context_str = "\n\n".join(context_docs)
    prompt = f"""你是一个知识渊博的助手。请根据以下提供的上下文信息回答问题。
如果上下文信息不足以回答，请如实说明“信息不足”，不要编造。

上下文信息：
{context_str}

问题：{query}

回答："""
    response = client.chat.completions.create(
        model=MODEL_NAME,
        messages=[{"role": "user", "content": prompt}],
        temperature=0.3,
        max_tokens=500
    )
    return response.choices[0].message.content

# 完整的 RAG 问答流程
def rag_qa(question):
    relevant_chunks = retrieve(question)
    answer = generate_answer(question, relevant_chunks)
    return answer, relevant_chunks

if __name__ == "__main__":
    # 首次运行或知识库更新时执行索引
    if not os.path.exists(KNOWLEDGE_FILE):
        # 创建一个示例知识文件
        with open(KNOWLEDGE_FILE, "w", encoding="utf-8") as f:
            f.write("大模型（LLM）是基于 Transformer 架构的深度学习模型。\n"
                    "检索增强生成（RAG）通过向量数据库实时检索外部知识，弥补大模型的记忆限制。\n"
                    "微调（Fine-tuning）能够让通用模型在特定领域表现出色，但成本较高。\n"
                    "2025年全球AI峰会在北京召开，发布了新一代多模态模型。")
        print(f"已自动创建示例知识库文件：{KNOWLEDGE_FILE}")

    chunks = load_and_split_document(KNOWLEDGE_FILE)
    index_documents(chunks)

    # 测试问答
    test_questions = [
        "什么是RAG？",
        "2025年AI峰会在哪里举行？",
        "微调有什么优缺点？"
    ]
    for q in test_questions:
        ans, sources = rag_qa(q)
        print(f"\n问题：{q}")
        print(f"回答：{ans}")
        print(f"参考块：{sources}")

运行上述脚本后，你会看到模型结合了 knowledge.txt 中的内容进行回答，而不再仅仅依赖训练时内化的旧知识。这正是 RAG 的核心价值。

渐进式选型与长期规划

没有完美的模型，只有最适合当前阶段的方案。建议采用渐进式策略：

1. 小规模试点：先用闭源 API 快速验证产品价值，或选择一个轻量开源模型进行 RAG 实验。
2. 评估反馈：观察成本、延迟、回答质量是否符合预期。
3. 逐步演进：如果发现闭源 API 成本过高或数据敏感，再迁移到私有化部署；如果专业知识不足，考虑引入微调。
4. 保持架构弹性：在设计系统时，抽象模型调用层，方便未来切换底层模型或引入 RAG/微调组合。

技术层面，大模型的价格正在持续下探，而商业化应用也越来越倾向于直接向用户收费以覆盖推理成本。作为开发者，提前建立“模型可替换”的设计思维，将为 AI Agent 的长线运营留下宝贵弹性。