AI Agent从无到有6：大模型选型决策框架与短板解决方案

纲要

• 模型选型决策框架
  • 开源与闭源的本质区别
  • 决策坐标系：灵活定制化与隐私安全的多象限分析
    • 高定制 + 高安全：私有化部署
    • 高定制 + 低安全：标准开源模型微调
    • 低定制 + 高安全：混合方案（API + 专属隔离）
    • 低定制 + 低安全：直接调用闭源 API
• 模型选型六个核心评估维度
  • 效率：部署耗时与推理延迟
  • 成本：初始投资与运营开销
  • 场景适配：对话、多模态、代码生成、专业问答
  • 安全与合规：数据主权与行业监管
  • 开发生态：社区活跃度与工具链完备性
  • 上下文窗口：长文本处理能力上限
• 大模型四大架构性短板
  • 记忆能力受限：上下文窗口外的信息遗忘
  • 知识更新滞后：训练数据截止日期后的信息盲区
  • 无法操作外部系统：缺乏工具调用与实时数据交互能力
  • 专业领域适应性差：通用能力与垂直场景的精度鸿沟
• 短板应对方案技术矩阵
  • 微调（Fine‑tuning）：通过领域数据深度注入行业知识
  • 嵌入（Embedding）+ 检索增强生成（RAG）：构建轻量级动态知识外挂
  • 提示工程（Prompt Engineering）：零成本的行为引导与格式约束
  • 组合策略：微调构建领域基座 + RAG 注入实时上下文
• 微调与 RAG 技术对比
  • 成本、实时性、知识深度、系统复杂度的多维度权衡
• 代码实战：基于 OpenAI 兼容 API 与 Chroma 的简易 RAG 系统
  • 完整可运行 Python 脚本，涵盖文档分块、向量索引、检索生成全链路
• 渐进式选型策略与架构弹性设计

---

开源还是闭源：基于决策坐标系的选型框架

面对当前数百个大模型，开发者面临的第一个战略性决策是选择开源模型还是闭源 API。该问题不存在普适性答案，但可以通过一个二维决策坐标系，依据项目的灵活定制化程度与隐私安全需求两个关键维度进行定位。

• 右上象限（高定制 + 高安全）：适用于政府机构、金融行业及大型企业场景。该象限要求私有化部署开源模型，甚至基于开源底座从零训练自有大模型，确保数据在物理层面完全隔离。典型案例包括滴滴利用海量交通数据自研出行大模型，以及金融机构将所有客户数据留存于内部 GPU 集群。
• 右下象限（高定制 + 低安全）：适合中小企业或低敏感度业务场景。可直接采用 LLaMA、Qwen 等开源模型进行微调，将业务数据注入模型参数，快速获得垂直领域定制能力，同时控制算力成本。
• 左上象限（低定制 + 高安全）：典型场景为数据高度敏感但对模型通用能力要求较高的商业应用。可采用“闭源 API + 厂商专属部署”的混合方案，或本地部署未经微调的开源模型，实现开箱即用且数据不外传。
• 左下象限（低定制 + 低安全）：适用于原型验证、通用服务及个人项目。直接调用 OpenAI、Gemini 等闭源 API，省去 GPU 集群部署与运维工作，实现分钟级上线。

模型选型六个核心评估维度

确定开源或闭源方向后，需从以下六个维度对具体模型进行精细化筛选：

评估维度	核心问题	实践参考
效率	部署周期多长？推理延迟是否满足业务 SLA？	开源模型需自行搭建 GPU 推理服务并优化吞吐；闭源 API 可在一分钟内完成接入
成本	初始硬件投入与持续运营 Token 消耗	GPU 云实例每小时成本数元至数十元不等；高频调用闭源 API 的 Token 费用同样不可忽视
场景适配	任务类型为对话、图文理解、代码生成还是垂直领域问答？	多模态任务需选择 GPT-4o 或 Gemini；纯文本场景可选用成本更优的轻量模型
安全与合规	数据是否允许传出本地？是否需通过国家生成式 AI 备案？	医疗、政务数据通常强制留存在内网，必须优先考虑私有化部署方案
开发生态	模型维护是否活跃？周边工具链是否完善？	LLaMA 与 Qwen 社区生态繁荣，Hugging Face 平台工具链成熟
上下文窗口	单次推理可处理的最大 Token 数是否满足业务需求？	Gemini 1.5 Pro 支持 100 万 Token 上下文，适合长文档分析与多轮复杂对话

综合上述六个维度，方可做出具有业务依据的技术决策。然而，无论选择何种模型，在实际落地过程中均会面临若干共性架构瓶颈。

大模型的四大架构性短板

当前大模型在工程化落地时普遍存在以下系统性缺陷：

记忆能力受限：上下文窗口内的天才，窗口外的“健忘症”

无论上下文窗口扩展至 100 万还是 200 万 Token，一旦对话或文档内容超出窗口边界，模型即丧失对该部分信息的感知能力。在多轮对话场景中，用户需频繁重申背景信息，严重影响交互体验的连贯性。

知识更新滞后：静态的知识快照

模型的知识体系固化于训练数据截止日期，无法感知该时间点之后的新事件、新政策或前沿研究成果。例如，询问当日实时股价或最新发布的技术标准时，模型只能提供过时的参考信息。

外部系统交互能力缺失：信息孤岛

原生大模型不具备查询数据库、调用第三方 API、读取本地文件或操作外部系统的能力，其输出完全基于内部参数化知识，无法与现实世界进行动态数据交换。

专业领域知识精度不足：通用智能的垂直落地鸿沟

通用大模型在医疗诊断、法律文书分析、金融风控等垂直场景中，经常生成语义流畅但事实错误的“幻觉”内容，缺乏经过严格验证的领域知识体系。

上述短板将直接导致基于大模型的 AI Agent 在可靠性、时效性与可控性方面存在严重缺陷。业界已发展出三类主流应对技术，下文将逐一阐述其原理、适用边界与组合策略。

三种解决方案：微调、检索增强生成与提示工程

微调：将通才转化为领域专家

微调（Fine‑tuning）通过在预训练模型基础上使用垂直领域数据进行参数更新，使模型在保留通用能力的同时，显著提升特定领域的响应准确性与专业度。

标准工作流程：

1. 数据准备：采集、清洗并格式化领域数据，构造为模型所需的对话模板或文本对结构。
2. 基座模型选择：根据可用算力选择适配的参数规模（7B、13B、70B 等）。
3. 超参数配置：设置学习率、批次大小、LoRA 秩（Rank）等关键参数。
4. 训练执行：监控训练损失曲线，采用早停策略避免过拟合。

适用场景：企业拥有大量高质量独家行业数据（如长期积累的医疗病例库、法律文书档案），且数据内容相对稳定，无需高频实时更新。

技术局限性：全参数微调的算力成本与时间成本极高（接近重新预训练）；无法感知训练完成后的新信息，知识更新需重新执行完整微调流程。

嵌入与检索增强生成（RAG）：构建动态外挂知识库

RAG（Retrieval‑Augmented Generation）通过实时检索外部知识库，为大模型提供可动态更新的“外挂记忆”，从根本上解决知识滞后与上下文窗口限制问题。

系统工作流程：

核心技术步骤：

• 数据加载与分块（Chunking）：将长文档切分为适配模型上下文窗口的小型文本块，同时保留语义连贯性。
• 向量化（Embedding）：使用 Embedding 模型将文本块转换为稠密语义向量，存储至向量数据库。
• 检索（Retrieval）：用户提问时，将问题向量化后在向量空间中执行相似性搜索，召回 Top‑K 个最相关文档块。
• 生成（Generation）：将检索到的文档块作为上下文，与原始问题拼接为增强提示，提交给大模型生成有据可依的回答。

核心优势：无需模型训练，成本低廉；知识库可随时增量更新，实时反映最新信息；有效突破上下文窗口的物理限制。

关键挑战：检索质量是系统性能的决定性瓶颈，分块策略、Embedding 模型选择及向量数据库的检索算法均直接影响最终回答质量。

提示工程：零成本的行为引导

提示工程（Prompt Engineering）通过精心设计的指令模板、格式约束和思维链提示，引导模型输出更符合预期的结果。该方法虽为最轻量级的优化手段，但对复杂专业知识的补充效果有限，更适合作为微调和 RAG 的辅助策略。

在实际生产级系统中，通常采用组合策略：微调构建行业基座模型，RAG 注入实时变化的知识，提示工程控制交互风格与输出格式，三者协同构建高可靠性的 AI Agent 架构。

微调与 RAG 技术对比

对比维度	微调	RAG
实时信息感知	需重新执行训练流程，无法感知实时变化	支持实时检索，知识库动态更新
专业知识深度	深度内化至模型参数，精度高	依赖检索质量，召回结果直接影响精度
初始投入成本	高（需 GPU 集群与训练工程）	低（仅需向量数据库与 Embedding 服务）
系统运维复杂度	中（模型版本管理与部署）	较高（需维护索引更新与检索质量监控）
适用数据规模	需大量高质量标注数据	少量数据即可启动，支持渐进式扩充

代码实战：基于 OpenAI 兼容 API 与 Chroma 构建 RAG 问答系统

本节提供一个完整可运行的 Python 脚本，使用 OpenAI 兼容 API（以 deepseek-chat 为例）搭配 Chroma 向量数据库，实现端到端的 RAG 问答系统。用户可直接复制运行，快速验证检索增强生成的技术效果。

环境准备：

1. 安装依赖包：

   pip install openai chromadb langchain-text-splitters
   

2. 准备知识库文件 knowledge.txt，可填入产品手册、公司制度、技术文档等任意领域知识。

3. 配置 API Key：脚本默认使用 deepseek-chat（兼容 OpenAI 协议），也可替换为 OpenAI 官方或其他兼容端点。

完整实现代码：

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

# ======================== 配置区 ========================
# 使用 DeepSeek API 作为示例（兼容 OpenAI SDK）
# 可替换为 OpenAI 官方或其他兼容端点
MODEL_NAME = "deepseek-chat"
API_KEY = "your-api-key-here"  # 请替换为有效 API Key
BASE_URL = "https://api.deepseek.com"

# 若使用 OpenAI 官方 API，请修改为：
# 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")

# 配置 Embedding 函数：使用 sentence-transformers 模型（无需 API Key）
# 若需更高精度，可替换为 OpenAI text-embedding-ada-002 或其他商业 Embedding 服务
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: str):
    """读取文档并按指定策略分块"""
    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: list):
    """将文本块向量化并存入 Chroma 集合"""
    # 演示环境采用重建索引策略，生产环境应实现增量更新
    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 ValueError:
        pass  # 集合不存在时忽略删除异常

    ids = [f"chunk_{i}" for i in range(len(chunks))]
    collection.add(documents=chunks, ids=ids)
    print(f"索引完成，共 {len(chunks)} 个文本块。")

def retrieve(query: str, top_k: int = 3):
    """执行向量检索，返回 Top-K 相关文档块"""
    results = collection.query(query_texts=[query], n_results=top_k)
    return results["documents"][0]

def generate_answer(query: str, context_docs: list):
    """基于检索到的上下文生成最终回答"""
    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

def rag_qa(question: str):
    """完整的 RAG 问答流程：检索 -> 增强生成"""
    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}")

代码说明：

• 分块策略：采用 RecursiveCharacterTextSplitter 递归分割文档，优先按段落和句子边界切分，确保语义完整性。
• 向量化与存储：使用 all-MiniLM-L6-v2 轻量级 Embedding 模型，将文本块转换为 384 维稠密向量，通过 Chroma 本地持久化存储。
• 检索与生成：用户查询时执行向量相似性搜索，召回 Top‑3 相关文档块；将检索结果与原始问题构造为结构化提示，提交给大模型生成有据可依的回答。

运行上述脚本后，模型将结合 knowledge.txt 文件中的外部知识进行回答，而非仅依赖模型参数化记忆。这正是 RAG 在知识时效性和可信度方面的核心价值。

渐进式选型策略与架构弹性设计

大模型技术栈不存在普适的最优解，唯有最适配当前业务阶段的方案。建议遵循以下渐进式演进路径：

1. 小规模试点阶段：采用闭源 API 快速验证产品价值与用户接受度，或选择轻量开源模型配合 RAG 进行技术可行性实验。
2. 评估与反馈阶段：系统收集成本、延迟、回答准确率、用户满意度等关键指标，评估当前方案与业务目标的匹配度。
3. 逐步演进阶段：若闭源 API 成本超预期或数据合规要求升级，迁移至私有化部署方案；若专业知识响应不足，引入微调流程优化领域精度。
4. 架构弹性设计：在系统架构层面抽象模型调用层（如使用统一 ChatCompletion 接口），支持底层模型的无缝替换；将知识库与模型解耦，使 RAG 和微调可作为独立能力模块灵活组合。

从技术趋势看，大模型的推理成本持续走低，商业化应用正逐步转向直接向终端用户收费以覆盖推理开销。作为技术决策者，提前构建“模型可替换、知识可插拔”的架构设计，将为 AI Agent 产品的长期运营留下宝贵的弹性空间。

参考文档

官方文档

• OpenAI API 文档：https://platform.openai.com/docs/api-reference
• Chroma 向量数据库文档：https://docs.trychroma.com/
• LangChain 文本分割器文档：https://python.langchain.com/docs/modules/data_connection/document_transformers/
• Hugging Face Transformers 文档：https://huggingface.co/docs/transformers/index

参考链接

• DeepSeek API 文档：https://platform.deepseek.com/api-docs/
• Sentence-Transformers 模型库：https://www.sbert.net/docs/pretrained_models.html
• Microsoft GraphRAG 项目：https://github.com/microsoft/graphrag

总结

本文围绕 AI Agent 系统构建中的大模型选型与能力短板问题，系统阐述了以下核心技术要点：

• 选型决策框架：基于定制化程度与安全需求二维坐标系的开源/闭源选择方法。
• 六大评估维度：效率、成本、场景适配、安全合规、开发生态、上下文窗口的综合考量。
• 四大架构短板：记忆受限、知识滞后、外部系统交互缺失、垂直领域精度不足的成因与影响。
• 三类应对技术：微调、检索增强生成（RAG）、提示工程的原理、适用边界与组合策略。
• 微调与 RAG 对比矩阵：成本、实时性、知识深度、系统复杂度的多维度权衡。
• 生产级代码实现：基于 OpenAI 兼容 API 与 Chroma 向量数据库的完整 RAG 问答系统，涵盖文档分块、向量索引、检索生成全链路。
• 渐进式选型策略：从小规模试点到私有化部署的演进路径，以及模型调用层与知识库解耦的架构弹性设计。