大模型通识 / 大模型理论基础
19. 进阶学习
原文备份 · 第 20 / 20 篇 · 查看极客时间原知识库 ↗
来源:大模型理论基础
读完大模型理论基础的 18 篇内容,再回头看 Token、注意力、Transformer、RAG、工具调用这些概念,它们大致可以被整理成三层。
第一层是模型内部的工作机制。Token、注意力、Transformer、自回归生成、预训练、后训练和推理时计算,解释了文字怎样进入模型,模型怎样利用上下文,又怎样一个 Token 一个 Token 地生成回答。这一层解决的是,模型为什么能够生成内容,又为什么不会像数据库一样稳定地返回唯一答案。
第二层是模型参与任务所需的外部能力。提示词与上下文学习告诉模型当前要做什么,Embedding、 语义检索和 RAG 为模型补充资料,结构化输出和工具调用则让模型的结果可以被程序读取,并进一步连接搜索、数据库或业务接口。这一层解决的是,模型怎样从聊天工具进入具体应用。
第三层是质量、成本与架构选择。模型架构、量化和推理优化,让我们看到效果、速度和成本之间的取舍。幻觉与可靠性提醒我们,语言流畅不等于事实可靠,JSON 合法不等于业务正确。最后的模型选型,则把这些知识重新放回任务、延迟、成本和部署条件中判断。
所以这 18 篇内容真正覆盖的,是一条从模型原理到应用选择的完整路径。
真正值得带走的,是这些知识之间的关系。
模型以自回归方式生成内容,所以应用不能默认每次输出都相同。上下文窗口有限,所以不是资料越多越好,而是要让当前任务看到足够、相关且可信的信息。RAG 可以补充外部知识,却不能自动保证检索结果正确,也不能替代权限、版本和证据检查。
结构化输出能够约束字段形状,却不能判断字段里的内容是否符合现实。工具调用让模型提出行动请求,但参数校验、权限判断、实际执行和结果确认仍然要由程序负责。Agent 可以根据观察结果决定下一步,系统却必须记录它做过什么、当前处于什么状态、什么时候应该停止,以及失败以后能否恢复。
这些关系连起来以后,我们就不容易把所有问题都归因于提示词。面对一次失败,可以继续判断问题出在模型、上下文、检索、工具还是验证环节。面对一个新需求,也能判断直接提供原文是否已经足够,什么时候需要 RAG,什么时候固定工作流更加合适,什么时候确实需要 Agent 动态决定下一步。
知识库能够帮我们建立这张认知地图,但从理解原理到负责一套企业级 Agent 系统,中间仍然隔着完整的工程实践。
个人项目里,一个 Agent 在单进程中完成几次工具调用,失败后重新运行,通常还可以接受。进入企业场景以后,任务可能持续很长时间,还会遇到模型超时、工具失败、服务重启、人工审批和权限变化。
这时,聊天历史已经不足以承担系统状态,简单循环也无法回答任务由谁接管、从哪里恢复、一次操作是否重复执行。规划、查询、分析和生成建议需要的信息也不相同。
评测同样不能只看几条回答是否顺眼。一个 Agent 的最终报告可能读起来不错,执行过程中却使用了过期数据、访问了不该读取的信息,或者付出了无法接受的成本。没有统一的 Trace、固定评测环境、 失败分类和版本记录,团队很难证明一次改动改善了什么。
这些问题不能再靠某个单独技巧解决。开发者需要把模型、上下文、知识、工具、记忆、状态和评测组织成一套能够长期演进的系统,还要明确什么交给模型,什么交给代码,什么必须保留人工控制。
这是为什么想在这里推荐「企业级 Agent 工程架构实战营」。它不是继续重复 LLM API、基础 Prompt、基础 RAG 或某个框架的使用,而是承接知识库最后几篇留下的问题,把能够完成一次任务的 Agent,继续推进为可恢复、可扩展、可维护、可审计的企业级系统。
课程会先把散落的模型调用收进统一的 LLM Runtime,处理多模型路由、超时、重试、降级、结构化输出、调用追踪和成本治理。再把基础 Agent Loop 扩展成 Agent Runtime,通过统一状态、 Checkpoint、异步任务、Sandbox 和人工审批,让长任务能够被调度、恢复和解释。
知识库中的上下文、RAG、记忆和工具调用,也会被放进治理体系。不同步骤只获得当前决策需要的信息,企业知识同时处理访问控制和证据追踪,长期记忆经过筛选、校验和过期管理,模型提出的真实行动则必须经过授权、审批和结果确认。
这些内容会落在一个企业级多租户零售经营分析与决策 DataAgent 中。它需要查询订单、商品、库存、会员、广告和售后数据,理解企业指标口径,通过 SQL 与云端 Python Sandbox 完成分析,并为经营异常建立可以追溯的证据链。涉及工单、预算调整等真实行动时,还要进入人工审批与受控执行。
项目会从模块化单体开始,逐步补齐 LLM Runtime、Agent Runtime、Context、Tool、Memory、 Trace、Eval、多租户策略与安全隔离。每次架构变化都要对应真实问题,并通过 Baseline、 Badcase、Benchmark 和 ADR 记录依据。评测还会同时检查结果、执行过程和系统代价,通过 Trace、Replay、回归门禁、灰度和回滚形成受控的演进路径。
扫码添加学习顾问,领取完整大纲和试听资料
