首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >AGI大模型应用:从模型到产品的工程化蜕变

AGI大模型应用:从模型到产品的工程化蜕变

原创
作者头像
用户12645013
发布2026-07-23 13:44:53
发布2026-07-23 13:44:53
50
举报

AGI大模型应用:从模型到产品的工程化蜕变

当大模型的能力不再成为瓶颈,真正的挑战从“模型怎么训”变成了“应用怎么做”。本文深入 AGI 应用开发的工程全貌,涵盖 RAG、Agent、评估、成本与架构设计,为开发者提供一份可落地的实战指南。所有代码片段均可直接运行或改造后用于生产环境。


引言:AGI 应用的“下半场”

2025 年,大模型的技术曲线正在趋缓——模型参数量不再是新闻头条,多模态能力逐渐成为标配,上下文窗口从 128K 卷到 10M 也接近边际效应递减。真正发生剧变的,是模型之上的应用层

如果说过去两年是“模型能力秀”,那么从现在开始,赛场已经切换到了“工程化落地”。同一个 GPT-4 级别的模型,有的人用它做出来的是高级聊天机器人,有的人却做出了能够自主处理供应链异常、自动生成合规报告并完成跨系统操作的智能体。差距不在于模型,而在于应用架构、工程实践和对业务场景的深度理解

本文从一线实战视角出发,系统拆解 AGI 大模型应用开发的完整技术图谱,帮你从“能调 API”进阶到“能交付可靠产品”。


第一章:RAG——让模型“开卷考试”的工程化实践

RAG(检索增强生成)是目前企业落地最广泛、ROI 最清晰的 AGI 应用模式。它让大模型不再依赖训练时“背下来”的知识,而是实时检索外部知识库,实现“开卷作答”。

1.1 RAG 的标准流水线

一条标准的 RAG 流水线包含五个环节:

  1. 文档加载:从 PDF、Word、数据库、网页等源头提取文本
  2. 文档切分:将长文档切成适合向量化的语义块(Chunk)
  3. 向量化:用 Embedding 模型将文本转为向量
  4. 向量存储与检索:存入向量数据库,用户提问时检索最相关的 Top-K 片段
  5. 生成回答:将检索到的片段拼接成提示词(Prompt),交由大模型生成最终答案

1.2 生产级 RAG 的进阶技巧

从 Demo 到生产,RAG 需要跨过几道坎:

切分策略的精细化:固定长度切分容易切断语义边界。生产环境需要引入语义切分——基于段落边界、标题层级或 Embedding 相似度动态调整切分点。

检索质量优化:简单的向量相似度检索远远不够。需要引入混合检索(向量检索 + 关键词检索,如 BM25),并根据场景动态调整权重。rrf(倒数排名融合)是一种简单有效的融合算法。

多路召回与重排序:召回之后,用更精细的重排序模型(Reranker) 对候选段落进行二次打分,过滤掉低相关度的内容,再送入大模型。这能显著提升回答质量。

索引策略:对于千万级以上的文档规模,需要合理选择索引类型。FLAT 索引支持精确搜索但内存占用大,适合百万级以下;HNSW 和 IVF 系列支持近似搜索,适合大规模场景。

以下是使用 Python 实现的一个基础 RAG 流程,涵盖文档切分、向量化和检索:

代码语言:javascript
复制
import os
from typing import List
from langchain.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA

# 1. 加载文档
loader = PyPDFLoader("./knowledge_base/运维手册.pdf")
documents = loader.load()

# 2. 语义切分
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    separators=["\n\n", "\n", "。", "!", "?", ";", ",", " ", ""]
)
chunks = text_splitter.split_documents(documents)

# 3. 向量化存储
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory="./chroma_db")

# 4. 检索器配置:混合检索(需要额外安装 BM25 插件)
retriever = vectorstore.as_retriever(
    search_type="mmr",          # 最大边际相关性,提升多样性
    search_kwargs={"k": 5, "fetch_k": 20}
)

# 5. 构建 QA 链
llm = ChatOpenAI(model_name="gpt-4", temperature=0.2)
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True
)

# 执行查询
result = qa_chain("CPU 使用率持续超过 90% 应该如何处理?")
print(f"答案: {result['result']}")
print(f"参考文档: {[doc.metadata for doc in result['source_documents']]}")

1.3 高级 RAG:引入 Agent 能力的迭代检索

静态 RAG 的局限在于:一次检索就生成答案,无法应对需要多轮信息获取的复杂问题。引入 Agentic RAG 模式后,模型可以自主判断是否需要补充检索、换一个检索方向、或者调用外部工具获取实时数据,从而显著提升复杂问答场景的准确率。

以下是使用 LangGraph 实现的可迭代检索的 Agentic RAG:

代码语言:javascript
复制
from langgraph.graph import StateGraph, END
from typing import TypedDict, List

class AgentState(TypedDict):
    question: str
    retrieved_docs: List[str]
    rounds: int
    answer: str

def retrieve(state: AgentState):
    # 初次检索
    docs = vectorstore.similarity_search(state["question"], k=5)
    return {"retrieved_docs": [d.page_content for d in docs], "rounds": 1}

def evaluate(state: AgentState):
    # 用大模型评估检索结果是否充分
    prompt = f"问题: {state['question']}\n已检索内容: {state['retrieved_docs']}\n这些信息足够回答吗?回复'是'或'否'及理由。"
    response = llm.invoke(prompt)
    if "是" in response.content and state["rounds"] >= 1:
        return "generate"
    elif state["rounds"] >= 3:
        return "generate"  # 最多 3 轮
    else:
        return "refine"

def refine_query(state: AgentState):
    # 改写查询词,补充检索
    prompt = f"原始问题: {state['question']}\n已有内容: {state['retrieved_docs']}\n请生成一个更精准的检索查询。"
    new_query = llm.invoke(prompt).content
    docs = vectorstore.similarity_search(new_query, k=3)
    state["retrieved_docs"].extend([d.page_content for d in docs])
    state["rounds"] += 1
    return state

def generate(state: AgentState):
    prompt = f"基于以下信息回答问题:\n{chr(10).join(state['retrieved_docs'])}\n\n问题: {state['question']}"
    answer = llm.invoke(prompt).content
    return {"answer": answer}

# 构建状态图
graph = StateGraph(AgentState)
graph.add_node("retrieve", retrieve)
graph.add_node("evaluate", evaluate)
graph.add_node("refine", refine_query)
graph.add_node("generate", generate)

graph.set_entry_point("retrieve")
graph.add_conditional_edges("evaluate", lambda s: s["next_step"])
graph.add_edge("refine", "evaluate")
graph.add_edge("generate", END)

app = graph.compile()
result = app.invoke({"question": "如何排查数据库连接池耗尽问题?", "rounds": 0})
print(result["answer"])

第二章:Agent——让大模型“动手做事”

如果说 RAG 让大模型“会查资料”,那么 Agent 让大模型“会办事”。Agent 的核心能力是自主规划 + 工具调用 + 记忆反思

2.1 Agent 的五大核心组件

一个成熟的 Agent 系统由以下模块构成:

  • 感知模块:接收用户指令和外部环境信息(监控数据、系统状态、用户画像)
  • 规划模块:将模糊目标拆解为可执行的步骤序列,并支持动态重规划
  • 工具调用模块:连接外部 API、数据库、操作系统、甚至其他 Agent
  • 记忆模块:短期记忆(当前会话上下文)+ 长期记忆(历史经验和知识沉淀)
  • 反思模块:对执行结果进行自我评估,从错误中学习并改进后续行为

2.2 Java 生态的 Agent 开发框架

相比 Python 的 LangChain 和 AutoGen,Java 生态也在快速追赶:

Spring AI:背靠 Spring 生态,提供统一的 Model API 抽象和函数调用(Function Calling)机制。开发者只需将 Java 方法注册为工具,AI 会自主决定调用时机。

LangChain4j:LangChain 的 Java 移植版,功能更接近 Python 原版,提供了完整的 Agent 构建模块。

以下是使用 Spring AI 构建一个带工具的 Agent 的完整示例:

代码语言:javascript
复制
import org.springframework.ai.chat.ChatClient;
import org.springframework.ai.chat.ChatResponse;
import org.springframework.ai.chat.prompt.Prompt;
import org.springframework.ai.chat.prompt.SystemPromptTemplate;
import org.springframework.ai.tool.annotation.Tool;
import org.springframework.ai.tool.annotation.ToolParam;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;
import java.util.List;

@Service
public class AgentService {

    @Autowired
    private ChatClient chatClient;

    @Tool(description = "查询指定时间范围内的订单数量")
    public int queryOrderCount(
            @ToolParam(description = "开始时间,格式 yyyy-MM-dd HH:mm:ss") String startTime,
            @ToolParam(description = "结束时间,格式 yyyy-MM-dd HH:mm:ss") String endTime) {
        // 实际场景中这里会查询数据库
        System.out.println("查询订单: " + startTime + " 到 " + endTime);
        return 1342;  // 模拟返回
    }

    @Tool(description = "获取当前系统时间")
    public String getCurrentTime() {
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"));
    }

    public String processUserRequest(String userInput) {
        // 构建系统提示词,声明可用工具
        String systemPrompt = """
                你是一个智能运维助手,你可以使用以下工具:
                1. queryOrderCount - 查询订单数量
                2. getCurrentTime - 获取当前时间
                请根据用户问题,自主决定调用哪些工具,并基于结果给出最终答案。
                """;

        Prompt prompt = new Prompt(
                new SystemPromptTemplate(systemPrompt).createMessage(),
                new UserMessage(userInput)
        );

        // Spring AI 会自动将 @Tool 注解的方法注册给模型
        ChatResponse response = chatClient.call(prompt);
        return response.getResult().getOutput().getContent();
    }
}

2.3 Agent 模式:ReAct 与 Plan-and-Execute

ReAct 模式(Reasoning + Acting):每次推理和行动交替进行——思考下一步做什么,执行,观察结果,再思考。适合简单任务。

Plan-and-Execute 模式:首先生成完整的任务计划,再按计划逐步执行,每个步骤完成后根据反馈决定是否调整后续计划。适合复杂多步骤任务。

以下是 ReAct 模式的核心循环实现(使用 Python):

代码语言:javascript
复制
def react_loop(user_question, max_steps=5):
    thought_history = []
    for step in range(max_steps):
        # 1. 推理:决定下一步动作
        prompt = f"""
        你是一个 Agent,当前任务:{user_question}
        历史操作:{thought_history}
        可选工具:search(query), calculate(expr), get_weather(city)
        请输出下一步行动,格式:Action: tool_name(parameters)
        如果已经有答案,输出:Final Answer: 答案内容
        """
        response = llm.invoke(prompt).content
        
        if "Final Answer:" in response:
            return response.split("Final Answer:")[1].strip()
        
        # 2. 解析动作并执行
        action = parse_action(response)  # 解析出 tool_name 和参数
        result = execute_tool(action.tool, action.params)
        
        # 3. 观察结果,加入历史
        thought_history.append(f"执行 {action.tool} 得到结果: {result}")
    
    return "抱歉,未能完成任务。"

# 使用示例
print(react_loop("帮我查一下北京今天的天气,然后计算比昨天高多少度?"))

选择哪种模式取决于场景复杂度:简单的单步工具调用用 ReAct 就足够了;涉及跨系统协同、多条件判断的复杂任务,Plan-and-Execute 更可控。


第三章:评估——AGI 应用的生命线

AGI 应用与传统软件最大的不同在于:输出是非确定性的。这使得评估不再是“上线前测一次就完事”,而是需要建立持续的质量监控体系。

3.1 评估的三大维度

准确性评估:回答是否正确、是否基于事实。对于有标准答案的场景(如知识库问答),可以构建测试集,用精确匹配或 LLM-as-Judge 方式进行自动化评估。

相关性评估:回答是否切题、是否冗余。Context Relevance 和 Answer Relevance 是两个核心指标,可以使用 RAGAS 等开源框架自动计算。

安全性评估:是否产生有害内容、是否泄露敏感信息、是否出现幻觉。特别是 Agent 场景下,需要验证模型不会调用危险的工具或超出授权范围操作。

3.2 评估工具链

  • RAGAS:专为 RAG 系统设计的评估框架,提供 Faithfulness、Answer Relevancy、Context Recall 等指标
  • DeepEval:开源评估框架,支持 Pytest 集成,适合 CI/CD 流水线
  • LLM-as-Judge:用更强或同等级的模型来评估当前模型的输出质量,成本高但效果好

3.3 持续评估的工程化

代码语言:javascript
复制
# 使用 RAGAS 对 RAG 系统进行自动评估
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall
from datasets import Dataset

# 准备测试数据
test_data = Dataset.from_dict({
    "question": [
        "什么是 Kubernetes 的 Pod?",
        "如何排查内存泄漏?"
    ],
    "answer": [
        qa_chain("什么是 Kubernetes 的 Pod?")["result"],
        qa_chain("如何排查内存泄漏?")["result"]
    ],
    "contexts": [
        ["Kubernetes Pod 是...", "Pod 是 K8s 最小部署单元..."],
        ["内存泄漏通常表现为...", "使用 jstat 监控 GC 频率..."]
    ]
})

# 运行评估
result = evaluate(
    dataset=test_data,
    metrics=[faithfulness, answer_relevancy, context_recall]
)
print(result)

# 将结果接入 CI:如果 faithfulness < 0.8,构建失败
if result["faithfulness"] < 0.8:
    raise Exception("RAG 质量不达标,请检查检索效果")

在 CI/CD 流水线中集成评估:

代码语言:javascript
复制
# .github/workflows/rag_eval.yml
name: RAG Quality Check
on: [push, pull_request]

jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      - run: pip install -r requirements.txt
      - run: python tests/evaluate_rag.py
      - name: 检查评估结果
        run: |
          if [ $(cat eval_result.json | jq '.faithfulness') -lt 0.8 ]; then
            echo "Faithfulness 低于阈值 0.8,请优化 RAG 流水线"
            exit 1
          fi

第四章:成本——从“不计代价”到“精打细算”

大模型 API 的调用成本在 POC 阶段可以忽略不计,但一旦产品日活达到万级,成本将成为不可回避的问题。

4.1 成本构成模型

一个标准 AGI 应用的成本由四部分构成:

  • 输入 Token 费用:每次请求携带的 Prompt 长度,包括系统提示词、检索到的上下文、历史对话等
  • 输出 Token 费用:模型生成的回答长度
  • 向量检索费用:如使用托管向量数据库,按存储量和请求量计费
  • Embedding 费用:文档入库和用户问题向量化的调用成本

一个简单的成本监控模块:

代码语言:javascript
复制
import hashlib
from datetime import datetime

class CostTracker:
    def __init__(self):
        self.total_input_tokens = 0
        self.total_output_tokens = 0
        self.input_price_per_1k = 0.01   # 以 GPT-4 为例
        self.output_price_per_1k = 0.03
        
    def log_call(self, prompt: str, response: str, model: str = "gpt-4"):
        # 粗略估计 Token 数:中文约 1.5 字符/Token,英文约 4 字符/Token
        input_tokens = len(prompt) // 2
        output_tokens = len(response) // 2
        self.total_input_tokens += input_tokens
        self.total_output_tokens += output_tokens
        
        cost = (input_tokens / 1000 * self.input_price_per_1k + 
                output_tokens / 1000 * self.output_price_per_1k)
        print(f"[{datetime.now()}] 本次调用成本: ${cost:.4f}")
        return cost
    
    def report(self):
        total = (self.total_input_tokens / 1000 * self.input_price_per_1k + 
                 self.total_output_tokens / 1000 * self.output_price_per_1k)
        print(f"总输入 Token: {self.total_input_tokens}")
        print(f"总输出 Token: {self.total_output_tokens}")
        print(f"总成本: ${total:.2f}")

# 使用
tracker = CostTracker()
response = qa_chain("什么是智能运维?")
tracker.log_call("什么是智能运维?", response["result"])

4.2 降本策略

Prompt 压缩:对检索到的上下文进行重排序和截断,只保留最相关的段落,控制输入长度。

缓存策略:对高频相似提问进行语义缓存——如果新问题的向量与已缓存问题足够接近,直接返回缓存结果,零 Token 消耗。

模型分级路由:简单问题用小模型(如 GPT-3.5 或 Qwen-Turbo),只有复杂推理场景才路由到最强模型。

以下是一个基于意图分类的模型路由实现:

代码语言:javascript
复制
def route_model(user_question: str) -> str:
    """根据问题复杂度选择模型"""
    # 用轻量级分类器判断问题复杂度
    simple_keywords = ["是什么", "定义", "多少", "几", "哪个"]
    complex_keywords = ["为什么", "如何", "比较", "分析", "优化", "设计"]
    
    if any(k in user_question for k in simple_keywords) and \
       not any(k in user_question for k in complex_keywords):
        return "gpt-3.5-turbo"   # 低成本模型
    else:
        return "gpt-4"          # 高性能模型

# 调用时动态选择
model = route_model(user_input)
response = chat_completion(model=model, messages=[...])

第五章:架构设计——让 AGI 应用跑得稳、跑得久

5.1 分层架构:解耦是关键

一个可长期维护的 AGI 应用建议采用以下分层架构:

层级

职责

技术选型示例

接入层

统一 API 网关、鉴权、限流、路由

Spring Cloud Gateway / Kong

编排层

Agent 调度、任务规划、状态管理

Spring AI / LangChain4j

执行层

工具执行、数据库操作、第三方调用

微服务 + 消息队列

模型层

大模型 API 调用、降级、切换

OpenAI / Azure / 通义千问 / 私有化

数据层

向量库、关系库、缓存、对象存储

Milvus / PostgreSQL / Redis

5.2 稳定性工程

超时控制:大模型 API 的 P99 延迟远高于普通后端服务,必须设置分级超时。

代码语言:javascript
复制
// 使用 Spring Retry 实现模型调用降级
@Retryable(
    value = {TimeoutException.class},
    maxAttempts = 2,
    backoff = @Backoff(delay = 1000)
)
public String callModelWithFallback(String prompt) {
    try {
        return primaryModel.generate(prompt);
    } catch (Exception e) {
        // 降级到备用模型
        return fallbackModel.generate(prompt);
    }
}

// 备用模型返回兜底响应
@Recover
public String recover(TimeoutException e, String prompt) {
    return "抱歉,当前模型服务繁忙,您的请求已转交人工处理,工单号: " + UUID.randomUUID();
}

5.3 可观测性

结构化日志:记录每一次模型调用的输入输出、Token 消耗、延迟。

代码语言:javascript
复制
import structlog

logger = structlog.get_logger()

def call_with_observability(prompt, model="gpt-4"):
    start = time.time()
    try:
        response = llm.invoke(prompt)
        latency = time.time() - start
        logger.info(
            "model_call",
            model=model,
            prompt_length=len(prompt),
            response_length=len(response.content),
            latency_ms=latency * 1000,
            status="success"
        )
        return response
    except Exception as e:
        logger.error("model_call_failed", model=model, error=str(e))
        raise

Trace 追踪:对于 Agent 的多步推理,需要记录完整的“思维链”和执行轨迹。

代码语言:javascript
复制
import json
from uuid import uuid4

class Trace:
    def __init__(self, session_id):
        self.session_id = session_id
        self.steps = []
    
    def add_step(self, step_name, input_data, output_data, metadata=None):
        self.steps.append({
            "step": step_name,
            "input": input_data[:200],   # 截断防止过大
            "output": output_data[:200],
            "metadata": metadata or {},
            "timestamp": datetime.now().isoformat()
        })
    
    def save(self):
        with open(f"traces/{self.session_id}.json", "w") as f:
            json.dump(self.steps, f, indent=2, ensure_ascii=False)

# 在 Agent 中使用
trace = Trace(session_id=uuid4().hex)
trace.add_step("retrieve", question, retrieved_docs, {"k": 5})
trace.add_step("generate", prompt, answer, {"model": "gpt-4"})
trace.save()

第六章:团队建设——AGI 应用需要什么样的人

AGI 应用开发对人才的要求,介于传统后端开发和 AI 算法研究之间:

  • AI 应用工程师:负责模型集成、Prompt 工程、Agent 编排和工具开发。需要熟悉至少一种大模型 API 和 Agent 框架(LangChain/LangChain4j/Spring AI)。
  • 后端/数据工程师:负责数据流水线、向量库运维、API 治理和性能优化。需要扎实的分布式系统经验和数据工程能力。
  • 产品/评估专家:负责定义场景、构建测试集、持续评估效果、优化用户体验。需要兼具产品思维和数据敏感度。
  • MLOps 工程师:负责模型部署、版本管理、监控告警、持续训练(如有自研模型)。需要掌握 MLflow/Kubeflow 等工具。

对于中小团队,不必一开始就追求全建制,“强后端 + 懂 Prompt + 业务理解力”的铁三角组合足以启动大部分 AGI 应用项目。


结语:从“能跑”到“能打”

AGI 大模型应用的开发,正在经历从“demo 满天飞”到“产品硬碰硬”的关键转折期。早期靠“套壳”就能获得关注的红利已经消失,真正能活下来的应用,拼的是:

  • 检索质量(RAG 的工程深度)
  • 任务完成率(Agent 的可靠性)
  • 成本可控性(架构的经济性)
  • 持续迭代能力(评估与优化的闭环)

大模型给了我们前所未有的能力,但把这种能力转化为可靠的产品,依然需要回到软件工程最朴素的那些原则:解耦、抽象、可测试、可观测、可演进。

代码已经为你准备好了,从 RAG 到 Agent,从评估到成本管控。接下来,就看你在真实业务场景中,如何把这些代码片段组装成真正能产生价值的 AI 产品了。AGI大模型应用:从模型到产品的工程化蜕变

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

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

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

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

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • AGI大模型应用:从模型到产品的工程化蜕变
  • 引言:AGI 应用的“下半场”
  • 第一章:RAG——让模型“开卷考试”的工程化实践
    • 1.1 RAG 的标准流水线
    • 1.2 生产级 RAG 的进阶技巧
    • 1.3 高级 RAG:引入 Agent 能力的迭代检索
  • 第二章:Agent——让大模型“动手做事”
    • 2.1 Agent 的五大核心组件
    • 2.2 Java 生态的 Agent 开发框架
    • 2.3 Agent 模式:ReAct 与 Plan-and-Execute
  • 第三章:评估——AGI 应用的生命线
    • 3.1 评估的三大维度
    • 3.2 评估工具链
    • 3.3 持续评估的工程化
  • 第四章:成本——从“不计代价”到“精打细算”
    • 4.1 成本构成模型
    • 4.2 降本策略
  • 第五章:架构设计——让 AGI 应用跑得稳、跑得久
    • 5.1 分层架构:解耦是关键
    • 5.2 稳定性工程
    • 5.3 可观测性
  • 第六章:团队建设——AGI 应用需要什么样的人
  • 结语:从“能跑”到“能打”
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档