AI大模型应用工程化：从检索可控到工具结构化的生产路径

大模型应用的分界线不在模型能力，而在工程系统对概率性输出的驾驭程度。Demo阶段调通API即可获得“惊艳感”，但一旦进入生产环境，三个结构性问题会立刻暴露：检索召回的噪声让答案不可靠，工具调用依赖脆弱的文本解析，输出质量无法用确定性断言来验证。2026年企业AI架构的共识是：大模型不再是中心，而是作为可替换的“大脑”下沉到基础设施层，业务逻辑通过统一的LLM API层与之解耦。真正的工程工作发生在模型之外——检索的可控性、工具的结构化、评估的自动化，三者共同划定了Demo与生产之间的门槛。

RAG的检索质量控制：切分粒度决定上限

RAG是企业落地ROI最清晰的模式，但“一周出Demo，半年用不好”的症结集中在预处理与检索两个环节。固定长度切分会切断语义边界，对于技术文档或代码库，生产环境应采用递归字符切分并针对语法定制分隔符：保留def、class作为切分锚点，同时维持重叠窗口以防止关键上下文被截断。检索侧，纯向量相似度容易召回内容高度重复的片段，引入MMR（最大边际相关性）可以在相关性与结果多样性之间取得平衡：先粗筛fetch_k个候选，再从中选出k个冗余度最低的片段。对于精确关键词敏感的场景（如报错码、特定接口名），混合检索（密集向量+BM25）配合交叉编码器重排序是更稳妥的基线；实测中混合检索将Recall@5从0.71提升至0.84，交叉编码器带来的额外延迟约128ms，但MRR提升超过0.07。

from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512, chunk_overlap=50,
    separators=["\n\n", "\n", "def ", "class ", "```", " ", ""],
    keep_separator=True
)
chunks = splitter.split_documents(docs)

vectorstore = Chroma.from_documents(
    chunks, OpenAIEmbeddings(), persist_directory="./chroma_db"
)
retriever = vectorstore.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 6, "fetch_k": 20}
)

Agent：用结构化Schema替代文本解析

Agent的本质是让模型自主编排工具，但实现路径的选择直接决定了系统的可维护性。早期ReAct模式依赖Prompt约束模型输出“Thought/Action”文本再做正则解析，一旦模型措辞波动，整个执行链路就会断裂。2026年的首选方案是Function Calling：用Pydantic声明工具入参的JSON Schema，模型直接输出结构化的调用指令，参数类型和必填字段由Schema校验，而非依赖脆弱的字符串匹配。当工作流需要多轮检索与条件分支时，LangGraph提供了状态图级别的控制：节点是函数，边是条件判断，何时调用工具、何时停止、何时重试完全由开发者显式定义，而非交给一个黑盒AgentExecutor“自行决定”。

from openai import OpenAI
from pydantic import BaseModel

class OrderQuery(BaseModel):
    start_time: str
    end_time: str

client = OpenAI()
tools = [{
    "type": "function",
    "function": {
        "name": "query_order_count",
        "description": "查询指定时间范围内的订单数量，时间格式为YYYY-MM-DD",
        "parameters": OrderQuery.model_json_schema()
    }
}]

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "查一下上个月的订单量"}],
    tools=tools
)
call = resp.choices[0].message.tool_calls[0]
args = OrderQuery.model_validate_json(call.function.arguments)

工具description的质量直接决定选对工具的概率，应当写清用途与边界，而非复述函数名。

评估与成本：工程化的闭环

非确定性输出意味着评估不能是“上线前跑一次”。RAGAS以LLM-as-judge的方式提供了可操作的量化基线：faithfulness衡量生成答案中的每个论断是否被检索上下文支撑，answer_relevancy检测是否答非所问，context_recall评估回答问题所需的信息是否被成功检索。高风险场景下，faithfulness的工程底线应在0.85以上，理想状态不低于0.90。每次修改切分策略、更换Embedding模型或调整Prompt后，都应在黄金数据集上运行回归，否则优化无法被度量。

成本侧的核心决策是模型路由而非盲目微调。RouteNLP在客服场景的8周试点给出了可参照的量级：约70%的查询属于轻量任务，通过分层路由将这部分请求导向小模型，整体推理成本降低58%，同时保持91%的响应接受率，p99延迟从1847ms降至387ms。通用模型加RAG覆盖长尾需求，只有高频、高价值的垂直任务才值得走微调路线。每一次Token消耗都应当对应可度量的业务收益，模型选择必须在质量、延迟与成本之间做出显式权衡，而非默认使用最贵的模型。

从API调用到生产系统，差的不是模型能力，而是工程纪律。检索的切分与重排让上下文变得可控，Function Calling让工具编排变得可校验，RAGAS与模型路由让质量与成本变得可观测。这三者共同构成了大模型应用从“能跑”走向“可交付”的底线。