首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >AI大模型应用开发:从API调用到可交付工程系统的架构与实践

AI大模型应用开发:从API调用到可交付工程系统的架构与实践

原创
作者头像
资源大佬 jzit-top
发布于 2026-11-03 16:40:11
发布于 2026-11-03 16:40:11
880
举报

大模型应用开发的分水岭,不在于是否调通了API,而在于是否完成了从“确定性软件”到“概率性系统”的思维切换。传统Web应用给定相同输入必得相同输出,性能靠水平扩展线性提升;AI工作负载则不同:输出具有概率性,成本取决于模型大小、上下文长度与调用频次的乘积,安全边界从网络层延伸到了语义层。这意味着一个能在本地跑通的Demo与一个可交付的生产系统之间,横亘着检索质量、工具编排、评估闭环与成本治理四道工程门槛。

分层架构:把LLM当作可替换的“大脑”

2026年企业AI系统的共识架构是分层解耦:业务逻辑层不直接绑定任何一家模型供应商,而是通过统一的LLM API聚合层接入。这样做的好处是,可以用OpenAI的text-embedding-3做向量化,用Claude做长文本总结,用DeepSeek做低成本推理,充分发挥各家模型的长板。Prompt不应硬编码在业务代码中,而应作为配置项进行版本化管理;复杂推理场景通过CoT模板在API层自动注入,统一全公司的输出规范。

RAG:让模型“开卷考试”的工程化实现

RAG是企业落地ROI最清晰的模式,但生产级RAG与Demo的差距集中在切分和检索两个环节。固定长度切分会切断语义边界,生产环境应采用递归字符切分并保留重叠窗口;单纯向量相似度检索召回率有限,需要引入MMR(最大边际相关性)提升结果多样性。以下是一个可运行的基线实现:

代码语言:javascript
复制
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma
from langchain.chains import RetrievalQA

loader = PyPDFLoader("./knowledge_base/manual.pdf")
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500, chunk_overlap=50,
    separators=["\n\n", "\n", "。", "!", "?", ";", ",", " ", ""]
)
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": 5, "fetch_k": 20}
)
qa = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o-mini", temperature=0.2),
    retriever=retriever, return_source_documents=True
)
result = qa("CPU使用率持续超过90%如何处理?")
print(result["result"], result["source_documents"])

这段代码涵盖了加载、递归切分、MMR检索与生成四个环节,其中separators按中文语义边界逐级降级切分,是提升中文RAG质量最廉价有效的手段。检索质量仍不足时,应引入Reranker对Top-K候选做二次打分,再送入生成模型。

Agent:用Function Calling替代文本解析

Agent的本质是让模型自主编排工具。早期ReAct模式依赖Prompt约束模型输出“Thought/Action”文本再解析,脆弱且难以调试。2026年的首选路径是Function Calling:用Pydantic声明工具入参Schema,模型直接输出结构化的调用指令,无需正则提取。

代码语言:javascript
复制
from openai import OpenAI
from pydantic import BaseModel

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

client = OpenAI()
tools = [{
    "type": "function",
    "function": {
        "name": "query_order_count",
        "description": "查询指定时间范围内的订单数量",
        "parameters": QueryOrderInput.model_json_schema()
    }
}]

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "查一下上个月的订单量"}],
    tools=tools
)
tool_call = response.choices[0].message.tool_calls[0]
args = QueryOrderInput.model_validate_json(tool_call.function.arguments)
print(f"执行 query_order_count({args.start_time}, {args.end_time})")

工具描述的质量直接决定选对工具的概率,“description”应当写清楚用途与边界,而非简单重复函数名。对于需要多轮信息补充的复杂任务,静态RAG应升级为Agentic RAG:用LangGraph构建“检索—评估—改写查询—再检索”的循环,由模型判断当前证据是否足以作答,不足则自动发起下一轮检索。

评估与成本:工程化的最后一公里

大模型输出的非确定性决定了评估不能是“上线前测一次”。生产系统应至少建立四个核心指标:上下文召回率、上下文精准率、答案忠实度与答案相关性,用RAGAS在黄金数据集上自动化打分,并在每次修改Prompt、更换Embedding模型或调整检索策略后运行回归测试。成本方面,80%的长尾需求用通用模型加RAG覆盖,只有高频、高价值的垂直任务才值得走微调路线。每一次Token消耗都应当能对应到可度量的业务收益,模型路由策略必须在质量与延迟之间做出显式权衡。

从API调用到生产系统,差的不是模型能力,而是架构对概率性输出的驾驭能力。检索的可控性、工具的结构化、评估的自动化,三者共同构成大模型应用工程化的底线。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档