当前位置：首页 > news >正文

LLM的创造力与不确定性：概率系统的双面性

news 2026/8/4 15:13:31

在传统软件里，研发的目标通常是把需求形式化为确定的逻辑：输入是什么、输出是什么、边界条件是什么。你写代码时，是在构造一个可推理的因果链条：只要条件满足，结果必然出现。测试也因此建立在“确定性断言”上：这个输入就该得到那个输出。而在LLM应用里，你构建的不是一条完全由你掌控的因果链，而是一个“生成式系统”：模型内部推理过程不可见、不可证明、不可逐行调试；你能控制的最为是外部变量——提示词、上下文、工具、采样策略、输出格式约束、以及后处理与验证。于是你从“写规则”变成“搭环境”，从“实现算法”变成“塑造行为”。既然关键引擎变成了概率系统，商业级应用该如何保证严格的稳定性和可靠性呢？简要的解决思路是：通过意图识别与路由把请求送入合适的任务轨道；用状态机/工作流把交互拆成可控阶段，并在每个阶段限定允许的工具调用与输出形式；再配合结构化校验、事实依据约束等手段来提升稳定性和可靠性。

LLM应用开发的相关的信息并不稀缺——课程、路线图、项目清单到处都是，真正稀缺的是一种清晰感：哪些内容属于“LLM应用开发”的关键，哪些只是围观热闹的知识点，这需要有相当清晰精准的认知。

这里说的LLM应用开发是指用LLM来实现业务功能做应用产品，绝大多数人没必要去死磕算法、推公式，那不是广大普通码农的赛道。

在这里我想通过以下几个问题来展开我的探索和思考：

LLM应用的典型特征是什么？
传统软件和LLM应用的本质区别？
LLM应用有什么样的开发范式？
开发者的角色和思维模式要进行哪些转变？
以服务端开发方式举例，哪些技能是能够迁移的？哪些是需要舍弃的？哪些是需要持续学习的？
哪怕我的思考和结论还达不到满意的程度，但我会尽量把我的理解写清楚，也欢迎在评论区一起补充和纠偏。

LLM应用的典型特征

自然语言交互是LLM最直观的特征
采用自然语言的交互方式彻底颠覆了传统的人机交互模式。以往，用户必须学习专业指令、代码，或通过点击按钮等结构化命令（GUI/CLI）才能与系统沟通；而现在，LLM允许用户以日常对话的方式输入需求。

对开发者而言，这意味着系统不再只是“接收命令并执行”，而要理解“用户想达成什么”，并将这种模糊意图映射到具体的任务流程、数据查询与工具调用中。因此，应用界面的关键不再只是前端控件，而是对话状态管理、意图识别与澄清、输出控制等隐形的“语义层组件”。这点可能不太好直观理解，但却是相当重要的，在后续的实践案例中我们会再深入探讨。

LLM应用具有“创造性”与“不确定性”
LLM的关键特征在于基于概率分布的“生成式能力”，这为创意和灵感的激发提供了巨大的价值。然而，这种概率驱动的机制具有双面性：它在赋予模型“创造力”的同时，也带来了输出的不确定性。当这种不确定性导致模型生成逻辑通顺但违背事实的内容时，便产生了所谓的“Hallucination”风险。因此，LLM开发不仅是逻辑的构建，更是对这种随机性与事实精准性之间的博弈与平衡。

LLM具备强大的任务泛化能力
一个基础的大语言模型即可覆盖问答、翻译、摘要、创作、代码生成等多种任务。以旅游场景为例：它既能帮你撰写旅行攻略，又能基于攻略自动生成结构化的每日行程表，还能顺便解答行程中的当地交通与住宿问题。这种“一模型多能”的特性，大幅降低了应用的开发与维护成本，也让跨功能的业务整合变得前所未有的高效。

LLM高度依赖上下文：
传统系统把知识写进代码或数据库规则里；LLM应用更多是把知识以“提示词、召回到的资料、结构化记忆、工具输出”这种形式临时注入到提示词上下文窗口里。于是出现一个很关键的工程对象：上下文本身成为一等公民。你如何组装、清洗、召回和处理这些上下文，直接决定了 LLM应用的智力上限。

2026年，大模型已经无处不在，但"幻觉"（hallucination）仍是企业落地的最大杀手：金融风控、医疗问诊、客服机器人动辄编造事实，直接导致合规风险和信任崩盘。

知识图谱（Knowledge Graph）的核心价值正是结构化知识：把碎片化数据变成"实体-关系-属性"的三元组网络，让大模型"先查图谱再回答"。