用 Langfuse 打造终极 LLMOps 体系——大语言模型与监控导论引言大语言模型（Large Language

引言

大语言模型（Large Language Models，LLMs）正在凭借理解和生成人类式内容的能力改变世界。本章将介绍 LLM 的基础知识：它们如何工作、核心架构是什么，以及如今正在被应用于哪些场景。我们还将探讨将这些模型部署到真实系统中时会出现的挑战，包括性能瓶颈、幻觉、不断上升的成本，以及偏见或模型漂移的风险。我们将理解为什么监控对于确保 LLM 长期保持准确、高效和安全至关重要。本章还会进一步勾勒 LLM 生命周期——从开发、微调到部署和持续维护——并说明监控在每个阶段中的位置。我们还会介绍 OpenAI API、LangChain 和 Langfuse 等工具与平台，为后续更偏实践的章节做好铺垫。

结构

本章将覆盖以下主题：

理解大语言模型（LLMs）
NLP 简史
LLM 的架构与组件
LLM 在各行业中的应用场景
内容生成
客户支持与知识管理
软件工程
金融
医疗健康
零售、电子商务与营销
部署 LLM 应用的挑战
非确定性输出
基础设施与性能要求
可观测性要求
伦理、安全与监管问题
LLM 监控与可观测性的关键指标
延迟
成本
Token 使用量
幻觉
完整性
相关性
正确性
LLM 应用生命周期导论
问题定义与需求收集
数据准备
Prompt 与系统设计
原型开发与实验
评估与基准测试
部署与监控
探索本书使用的 LLM 工具集
OpenAI SDK
LangChain
Langfuse

理解大语言模型（LLMs）

大语言模型（LLM）是一种人工智能模型，它在海量文本集合上进行训练，从而理解并生成人类式内容。这些内容可以是文本，也可以是音频、图像，甚至视频。LLM 建立在 Transformer 架构之上。Transformer 是一种人工神经网络（Artificial Neural Network，ANN）架构，使模型能够捕捉长篇文本中的上下文和关系，这一点类似于人类理解自然语言的方式。正因如此，LLM 可以执行广泛的任务，例如回答问题、总结文档、生成代码，或者创作内容，而不需要针对每个任务进行专门编程。作为一种 ANN，LLM 会预测一个词序列中的下一个词。

在 2018 年一篇题为《Improving Language Understanding by Generative Pre-Training》的研究论文中，OpenAI 的一组研究人员提出了一种两阶段模型训练框架。这一框架为我们今天所熟知的大规模 LLM 的发展铺平了道路：

无监督预训练：
这一阶段是在海量文本上训练一个基于 Transformer 的语言模型，目标是预测下一个词。这个步骤帮助模型理解语言的句法、语义以及世界知识。

监督微调：
在第一阶段模型的基础上，将模型适配到某个具体任务上，例如摘要、问答、情感分析等等。

这种简单的“预训练 + 微调”范式，催生了通用语言理解系统的大爆发，而这些系统如今正在重新定义技术史与人类史。

在进入 LLM 的核心架构与组件之前，我们先沿着记忆之路回顾一下自然语言处理（Natural Language Processing，NLP）领域是如何演进的。

NLP 简史

自然语言处理（NLP）是人工智能的一个领域，专注于让计算机能够理解、解释、生成并使用人类语言进行交互。在过去几十年里，NLP 经历了显著演进：从早期基于规则的方法，到如今先进 LLM 的发展。在这一进程中，每个阶段都解决了一些挑战，同时也带来了新的问题，最终促成了 Transformer 架构和 GPT 模型等突破。

1964—1967：ELIZA——第一个“聊天机器人”

NLP 的故事最早可以追溯到 20 世纪 50 年代。一个重要里程碑出现在 1966 年，当时计算机科学家、MIT 教授 Joseph Weizenbaum 构建了 ELIZA。ELIZA 是一个 NLP 程序，它使用模式匹配和硬编码规则来模拟人与机器之间的交流。它最著名的脚本叫作 DOCTOR，模仿一位心理治疗师，可以像理解人类一样与人交谈。

图 1.1：与 ELIZA 的一次对话

ELIZA 本质上开启了聊天机器人时代，并提出了“模拟智能”与“真正智能”之间的区别这一问题。这个问题直到今天，仍然在 GPT、Claude 等现代 LLM 身上被讨论。尽管 ELIZA 并没有真正理解人类语言，但很多用户仍然相信它具备能力和智能。

1990 年代—2000 年代：NLP 开始使用机器学习

早期基于规则的 NLP 模型并不实用。考虑到每一种人类语言中都存在海量文本需要处理，这种思路很快就会变得难以维护。因此，NLP 开始采用早期机器学习模型，转向数据驱动的方法。其思路是让模型从大型文本语料库中学习模式，并基于概率进行预测。

这些统计模型成为结束 20 世纪 80 年代所谓“AI 寒冬”的转折点。AI 寒冬是指人工智能领域兴趣与资金投入下降的一段时期。这一阶段最值得注意的进展包括：

N-gram 模型：
这类模型会基于前面 n-1 个词，估计某个词出现的概率。它们根据某个词在之前见过的文档中出现的可能性，来预测下一个词。虽然这类模型在已见过的数据上表现不错，但最大的问题是词表外词（Out-of-Vocabulary，OOV）。当模型在推理阶段看到一个训练时从未见过的词时，就会出现 OOV 问题。在这种模型中，一个未见过的词会得到零概率，即使它本身是一个完全有效的词。

隐马尔可夫模型（Hidden Markov Models，HMMs）：
虽然 N-gram 模型可以预测下一个词，但它们并不理解词性或命名实体，例如人名、地点、组织等等。HMM 通过捕捉句子结构与词之间的关系来解决这一问题。它们被应用到了语音识别系统和词性标注（Part-of-Speech，POS）中。不过，OOV 词和长文本对于这类模型仍然是问题，因为 HMM 的工作假设是：为了预测接下来会发生什么，我们只需要看最近一步。换句话说，模型只记得上一步，仿佛语言只有一个词的记忆。

循环神经网络（Recurrent Neural Networks，RNNs）：
在 20 世纪 90 年代早期，研究人员开始尝试设计真正能够像人脑一样思考和工作的 NLP 模型。这催生了神经网络（Neural Network，NN）的概念。神经网络是一种受大脑启发的计算模型，由互相连接的单元（“神经元”）组成，用于处理和转换输入。虽然神经网络本身就是一个很大的主题，但这里值得提到一种特殊类型的神经网络：循环神经网络（RNN）。RNN 引入了一种神经架构，理论上可以用无限记忆来建模序列，从而解决 N-gram 和 HMM 的短距离限制。RNN 的突破在于证明了神经网络原则上可以在没有显式硬编码结构的情况下，学习语言的序列结构。后来的创新，例如长短期记忆网络（Long Short-Term Memory，LSTM，1997），进一步克服了其中许多限制，并为 2010 年代的深度学习革命奠定了基础。

2010 年代：神经网络的崛起

到 2010 年代早期，传统统计 NLP 以及 RNN 等早期神经网络在大规模数据集上暴露出了局限。随着数字文本的增长，研究人员借助更好的硬件和新架构，转向表示学习。这标志着 NLP 领域的一次神经网络复兴。在这一时期，来自社交媒体、互联网和企业数据的内容迅速爆发，既带来了迫切需求，也提供了构建更强大模型的机会。这一时期的一些关键突破包括：

Word2Vec：
Word2Vec 是 Google AI 在 2013 年开发的一种技术。它的核心是将词表示为连续空间中的稠密向量。这种方法让模型能够捕捉词与词之间的语义关系，而这是传统 N-gram 模型做不到的。在实践中，Word2Vec 显著提升了 NLP 系统对意义进行推理的能力，改进了信息检索、类比推理和情感分析等任务。

编码器—解码器架构：
编码器—解码器模型引入了一种处理序列的两部分神经框架：编码器读取输入序列，并将其压缩成一个固定长度的表示；解码器则生成对应的输出序列。这一方法是 NLP 的重大进展，因为它使机器翻译和文本摘要等任务可以端到端地完成，而不需要针对任务进行专门的特征工程。

注意力机制：
2017 年论文《Attention is All You Need》中引入的注意力机制，使模型在生成每个输出词时，可以有选择地关注输入中的不同部分，而不是依赖单一的固定表示。这从根本上改变了 NLP：模型如今可以高效捕捉长距离依赖，扩展到数十亿参数规模，并最终成为 GPT、Claude、Llama 等现代 LLM 的骨干。

2017：Attention is All You Need

Vaswani 等人发表的里程碑论文《Attention is All You Need》提出了 Transformer 架构，彻底重新构想了文本处理方式。Transformer 的主要创新是自注意力（self-attention），它让模型能够同时评估一个序列中的所有词。与 RNN 不同，Transformer 可以并行处理文本，因此训练效率更高，也能更好地处理长距离依赖。它使用位置编码来保持词序，而不依赖循环结构。

Transformer 将之前神经网络方法中的经验——嵌入、编码器—解码器架构和注意力机制——统一到一个可扩展框架中，并成为现代 AI 的基础。简而言之，Transformer 让我们第一次有可能以此前从未达到过的规模，训练通用且表达能力极强的语言模型。

图 1.2：Transformer——模型架构
来源：arxiv.org/pdf/1706.03…

转折点：ChatGPT

ChatGPT 在 2022 年底发布，标志着一个文化层面的转折点。几周之内，它就触达了数百万用户，并进入了关于 AI 的主流讨论。与早期模型不同，ChatGPT 将原始语言建模能力与指令微调以及基于人类反馈的强化学习（Reinforcement Learning from Human Feedback，RLHF）结合在一起，因此更符合用户预期。

对很多人来说，ChatGPT 是第一个具体而真实的证明：AI 可以自然对话、起草文章、编写代码，甚至进行创意头脑风暴。它的病毒式普及，把 LLM 推到了公共讨论和商业战略的中心。

有了这段历史回顾，我们就可以进入当代 LLM 的核心架构了。

LLM 的架构与组件

GPT、Claude、Llama 等大语言模型都建立在我们前面看到的 Transformer 架构之上。虽然不同提供商的实现细节各不相同，但底层设计保持一致。从高层来看，LLM 将文本作为输入，通过一系列专门的层进行转换，然后逐词生成最可能的输出。为了理解后面监控是如何工作的，我们有必要拆解现代 LLM 的架构和组件：架构指整体结构，组件指构成模型的基本模块。

Tokenization：分词

LLM 的输入并不是实际文本。文本首先会被拆分成 token，也就是词的一部分，有时甚至是单个字符。然后，每个 token 会被转换成一个数字 ID。这些 ID 会被映射成称为 embeddings 的稠密向量，作为输入的数学表示。在下面的图中，我们可以看到 GPT-4o 如何对句子 “You are reading this book called Ultimate LLM Monitoring using Langfuse” 进行分词。注意，由于 Langfuse 不是一个标准词典词，它被转换成了三个 token：Lang、f 和 use。编号列表展示了 GPT-4o 中每个 token 对应的数字 ID。

图 1.3：Tokenization 示例

Embeddings：嵌入

由于计算机只能理解数字，我们可以把 embeddings 理解为文本的数字等价物，同时它还能保留语义含义。这也帮助模型理解并比较文本之间的意义。

模型并不是把 “You” 仅仅存成文本，而是将其表示成类似下面这样的形式：

You as [0.12, -0.55, 0.89, …]

“book” 可能是：

[0.33, 0.41, -0.20, …]

“Langfuse” 可能是：

[0.02, 1.10, -0.75, …]

Embeddings 捕捉的是意义和关系，而不仅仅是精确的词。

意义相近的词在向量空间中距离较近。

例如，“book”和“novel”作为向量时会彼此接近。

意义不同的词则距离较远。

比如 “book” 与 “monitoring”。

这些数字来自训练阶段。在训练中，出现在相似上下文中的词会得到相似的向量。不同模型可能会使用不同的 embeddings 来存储同一段文本。Embeddings 可以说是模型的一种商业机密，并不是通用公开知识。OpenAI 的 embedding 模型中 “Langfuse” 的 embedding，与 Hugging Face 某个模型中的 embedding 完全不同。这些数字只有在对应训练模型的上下文中才有意义。

Positional Encoding：位置编码

为了保留词序，每个 embedding 都会与位置编码相结合。这使模型能够根据词在序列中出现的顺序，理解词之间的差异。正如我们刚才看到的，在 Transformer 中，每个词都会被转换成一个 embedding，也就是一串数字。但词向量本身并不包含顺序信息。因此，我们需要位置编码。位置编码也是数字。这些数字来自正弦和余弦波。我们会把两个向量逐元素相加：

对 “You”（位置 1）：

最终向量 = Embedding("You") + PE(1)

对 “are”（位置 2）：

最终向量 = Embedding("are") + PE(2)

……依此类推，直到 “Langfuse”。

现在，每个词的向量不仅表达这个词是什么意思，也表达它在句子中的位置。

Multi-Head Self-Attention：多头自注意力

多头自注意力是 Transformer 架构的核心。它让每个词都能查看所有其他词，并决定哪些词对理解自己更重要。这可以用下面的公式表示：

每个词都会创建三个向量：Query（Q）、Key（K）、Value（V）。

可以类比为：

“我在问什么？”——Q
“我能提供什么？”——K
“我应该传递什么信息？”——V

例子：

“reading”（Q）与 “book”（K）强匹配，因此它会非常关注 “book”。
“Langfuse” 会关注 “LLM Monitoring”。
“are” 会稍微关注 “You”（主语）和 “reading”（动词）。

我们有多组 Q、K、V，因此模型可以学习不同视角：

一个头可能跟踪语法关系，例如“主语 → 动词 → 宾语”。
另一个头可能跟踪语义关系，例如 “LLM ↔ Monitoring ↔ Langfuse”。

完成注意力计算后，每个词的表示都会根据它所关注的词提供的信息进行更新。

Feed Forward Network（FFN）：前馈网络

FFN 是一个应用在每个词上的小型神经网络，它帮助将特征转换成更抽象的特征。

例如：

注意力之后，“book” 知道它与 “reading” 有关联。

FFN 会把这一点转换成一个更高层级的特征：“作为 reading 宾语的 book”。

可以把它理解为对表示进行打磨和精炼。

Add（Residual）+ Normalization Layers：残差连接与归一化层

在这一架构中，残差连接与归一化就像质量控制系统，确保整条装配线不会崩溃。

Residual：
它在每一步都保留原始含义。

Normalization：
它让数字保持稳定，使下一层能够正确处理。

没有这些机制，模型的响应很快就会变得不稳定。我们可以继续使用前面的句子作为例子：

“You are reading this book called Ultimate LLM Monitoring using Langfuse.”

第一次 Residual + Norm：确保当 “reading” 从 “book” 学到信息时，它不会丢失自己的原始身份。

如果注意力过度强调了某个词，归一化会把它拉回合理范围。

第二次 Residual + Norm：再次防止 FFN 对信号造成过度扭曲。

这个过程会在很多层中重复。每一次，residual + norm 都保证意义是逐渐积累的，而不是爆炸或消失。

Layer Stacking：层堆叠

如果我们回想上面的 Transformer 图，编码器（左侧）和解码器（右侧）都会多次堆叠上述这些层，因为一次处理不足以让模型深入理解语言。每一层都会进一步精炼并加深模型的理解。

较低层捕捉局部关系，尤其是 “reading ↔ book”。
中间层捕捉短语级关系，特别是 “called Ultimate LLM Monitoring”。
较高层捕捉全局意义，例如“这个句子是在讲一本与 Langfuse 相关的书”。

当所有层都应用到文本之后，文本表示会被送入最终输出层。

Final Output Layer：最终输出层

这一层有两个主要操作：

Linear：
将向量投影到模型词表大小的空间中。例如，可能有 50,000 个候选词。

Softmax：
将这些值转换为概率，例如“下一个词是 X 的概率为 92%”。

图 1.4：LLM 架构与组件总结

在回顾了 LLM 的组件之后，我们现在来看现代 LLM 在实践中是如何被使用的。

LLM 在各行业中的应用场景

大语言模型正在对社会和技术的多个领域产生重大影响。在考察 LLM 在这些领域中的具体用途之前，我们先看一下今天的 LLM 通常能做什么，然后再深入一些行业特定的例子。

LLM 最独特的能力之一，是能够以人类难以做到、或者需要数周乃至数月才能完成的规模和水平来执行 NLP 任务。这包括：跨领域长文本摘要、查找文本之间的相似性、在不同语言之间翻译文本，以及对文本进行分类，例如情感分析。当然，即使一开始没有文本，LLM 也可以生成文本。最典型的例子就是代码生成，直到今天，这仍然是 ChatGPT 使用最广泛的功能之一。大多数 LLM 也是基于指令的，这意味着用户只需通过 prompt，就可以按照自己的意愿生成各种类型的文本。

除了文本，现在还有数百甚至数千个模型可以解决计算机视觉问题，例如图像分类、目标检测、图像分割，以及图像到文本和文本到图像的转换。列表并没有止于图像；音频分类、自动语音识别和文本转语音模型也已经在行业中得到广泛使用。

LLM 最近的一项进展，是所谓多模态模型的发展。多模态模型可以同时处理一种以上的媒体类型。例如，文档问答可以帮助回答关于文档内容的问题；图像文本到文本模型则可以回答关于图像的问题。

正如我们看到的，这里的可能性几乎没有尽头，而且这张列表仍在不断增长。现在我们来看一些今天更常见的 LLM 用途。

内容生成

由于 LLM 是 NLP 领域的进展之一，因此它们最流行的用途之一就是生成文本内容。这包括但不限于博客文章、电子商务网站的产品描述、社交媒体内容和创意写作。使用过 ChatGPT 或任何类似应用后，我们已经亲身体验过这一点。只需要几行 prompt，这些工具就能围绕几乎任何主题生成有吸引力且细节丰富的内容，这一点令人惊叹。

内容生成并不止于文本。AI 图像生成如今也正在进入各个领域。Midjourney 和 DALL-E 等工具，只需通过 prompt，就可以生成高分辨率、具有艺术感的图像。进展也没有止步于此；Google 的 Veo 和 OpenAI 的 Sora 等视频生成 AI 平台，已经展现出通过 prompt 生成逼真视频的卓越能力。

客户支持与知识管理

AI 驱动的聊天机器人和虚拟助手正在改写客户支持系统的规则。LLM 让对话式智能体能够理解自然语言查询，并给出符合上下文的回答。这些聊天机器人可以提供 7×24 小时客户支持，减少等待时间，并处理大量重复性问题。

公司和电子商务平台会部署基于 LLM 的聊天机器人，用于故障排查、账户咨询和订单跟踪。这些助手还可以将复杂问题无缝升级给人工客服。在更高级的场景中，LLM 可以分析进入系统的支持工单，以判断紧急程度、类别和最合适的客服分配。

LLM 还可以自动创建、更新和总结知识库文章、FAQ 和文档。公司随后可以集成 AI 工具，在支持工单被记录时，从文档中自动建议解决方案。结合 LLM 识别趋势、情绪和重复问题的能力，这种技术可以把洞察反馈给产品团队，帮助他们开发新功能，或者快速处理客户投诉。

软件工程

使用 LLM 的生成式 AI 已经永久改变了软件编码。AI 通过减少样板代码、自动化测试和文档编写、提升团队速度和生产力，简化了软件开发。LLM 可以通过建议代码片段、补全函数，甚至根据自然语言描述生成完整程序，来帮助开发者。GitHub Copilot 和 Cursor IDE 这样的 AI 工具就像智能编程伙伴，帮助开发者构思解决方案、更快调试，并在工作中即时学习。

LLM 可以审查代码库以发现 bug、推荐解决方案，并用直接易懂的语言解释错误信息。LLM 还可以根据代码或需求描述生成单元测试、集成测试和边界用例。

像 vanna.ai 这样的基于 LLM 的工具，可以让用户只需用自然语言提问，就为数据库生成 SQL 语句。这使数据对不熟悉 SQL 的人更加可访问，减少了对专家的依赖，也加快了分析工作流。

mintlify.com 这样的 AI 驱动工具，可以在几分钟内将代码仓库转换成可交互的文档。它能够保持文档更新，并降低工程团队维护代码文档的负担，而工程团队往往一直在为文档与代码同步而挣扎。

金融

LLM 正在稳步改变金融行业。通过简化研究、增强合规能力、改善客户交互，AI 正在成为现代金融运作中不可或缺的一部分。LLM 在金融领域的出现并不是最近才发生的事情。2023 年 3 月，Bloomberg 宣布推出 BloombergGPT，这是一个面向金融行业的 500 亿参数 LLM。Bloomberg 使用自己的数据源训练了该模型，而这些数据源是该领域最大的金融数据集合之一。这个模型在金融任务上大幅超过了其他通用 LLM。虽然 BloombergGPT 本身并不是一个公开产品，但 Bloomberg 会把它的能力集成到 Bloomberg Terminal 及相关服务中。

组织正在使用人工智能解决方案来监督每天数十亿笔交易，有效识别潜在欺诈迹象。LLM 正在重塑反洗钱（Anti-Money Laundering，AML）和金融犯罪预防，尤其是在依赖语言和非结构化数据的任务中。它们可以通过更好的多语言匹配来增强制裁名单和姓名筛查，通过解释文档和发现不一致来简化 KYC，并通过分类和摘要让负面媒体监测更快速。

LLM 驱动的机器人顾问可以提供定制化的投资组合建议、退休规划和税务优化。不过需要注意的是，这些模型可能会给出过于简单或不准确的建议，因为它们并不具备金融判断力，也可能无法考虑某个人财务情况或法规中的每一个方面。它们应被视为决策支持资源，而不是认证金融顾问的替代品。

医疗健康

使用 LLM 的生成式 AI 正在开始简化医疗行政工作、增强患者沟通，并辅助临床决策。虽然这需要谨慎监管，但早期结果表明，它可以减轻临床医生的工作负担，并提升患者结果。

Microsoft Dragon Copilot 是一款专为医疗专业人员打造的 AI 临床助手。该工具可以根据医患对话自动生成临床记录、起草转诊信，并创建就诊后摘要。

LLM 使专业人士能够快速访问医疗数据库中的关键信息，从而加速临床决策。

即使某人不是专业人士，LLM 也可以把复杂医学术语简化成清晰、友好的解释，用于信息和教育目的。

LLM 在医疗健康领域展现出潜力，但错误可能非常危险。它们可能产生幻觉、忽略关键细节，或给出误导性建议。因此，监管监督和严格的人类验证至关重要。

零售、电子商务与营销

在我们目前看到的所有行业中，LLM 和 AI 的影响在零售、电子商务与营销领域可能最为深刻。这也受到一个事实的推动：在线平台正在竞相向客户提供越来越多 AI 功能。由于这是一个非常宽泛的领域，AI 在这里的应用几乎没有上限。

LLM 可以生成产品标题、描述和广告文案，用于改善搜索引擎优化（SEO）。这极大减少了内容优化中的人工工作，也让产品目录保持一致的语气。

基于 AI 的聊天机器人在电商网站上的使用比其他任何地方都更明显。从个性化购物推荐到问题解决，这些聊天机器人可以覆盖从转化客户到降低客服中心负载之间的各个环节。

在幕后，LLM 会处理客户评论、反馈和社交媒体内容，以发现趋势、评估新兴需求，并观察品牌感知的变化。这帮助公司快速响应变化，并调整营销策略。

借助多模态 LLM，如今甚至可以通过上传另一件产品的照片，利用视觉搜索能力查找相似产品。

虽然 LLM 已经在改变各个行业，但要在真实环境中部署一个使用 LLM 的系统，远不是一件直接简单的事情。理解可靠性、可扩展性、安全性和伦理风险等挑战非常重要，这也将是下一节的重点。

部署 LLM 应用的挑战

部署基于 LLM 的应用涉及一些不同于传统软件即服务（Software-as-a-Service，SaaS）应用的复杂性。虽然两类应用都共享一些常见关注点，例如正常运行时间、扩展性和安全性，但基于 LLM 的应用由于依赖概率模型、计算要求高，以及行为动态变化，呈现出独特挑战。理解这些差异，对于在生产环境中交付稳健可靠的 LLM 驱动解决方案至关重要。

非确定性输出

正如我们之前看到的，LLM 的输出本质上是一个预测：基于一个句子中前面出现的词，预测下一个词或 token 可能是什么。考虑到人类语言极其庞大，“下一个词应该是什么？”这个问题在理论上有无限多种可能。这使得 LLM 输出的本质具有非确定性。这不同于 API 这类系统，API 通常会对同一个查询给出确定性的响应。如果你曾经使用过 ChatGPT 或任何其他基于 LLM 的 AI 应用，应该已经体验过这一点。在大多数此类应用中，业务逻辑无法被显式定义，而且可能的输出路径太多，无法显式处理每一个边界情况。AI 聊天机器人、摘要器或推荐引擎等应用必须包含额外层，例如输出验证、排序，或人在回路中的审查，以确保可靠性。此外，大模型有时会生成看似合理但包含不准确或无关信息的输出。所谓“幻觉”仍然是 LLM 中最棘手的监控与缓解问题之一。

基础设施与性能要求

无论我们选择托管自己的模型，还是依赖 GPT、Claude、Gemini 等专有 API，基础设施方面的考虑都会在决定成本、延迟和可扩展性时发挥核心作用。

如果我们实现开源 LLM，例如 Llama、Falcon 或 Mistral，就会遇到显著的运维挑战。这些模型需要大量 GPU 资源和具备高内存容量的专用硬件，才能提供可接受的延迟。支持多个并发用户需要高级编排策略，包括请求批处理、GPU 分配管理，以及跨集群分发工作负载。扩展推理通常需要投资昂贵的 GPU 基础设施、分布式服务方案，以及量化和模型蒸馏等技术优化。如果缺少这些方法，我们可能会遇到延迟增加、吞吐下降和成本上升的问题。

虽然专有 API 抽象掉了模型托管和 GPU 基础设施，但这并没有消除性能挑战，只是把它们转移到了技术栈的另一层。

延迟：
即便推理经过优化，API 调用仍可能需要数秒。需要实时响应的应用必须调整用户体验流程，例如展示“正在输入”的提示、流式输出部分结果，或管理用户预期。

吞吐与限制：
提供商会实施严格的速率限制和并发上限。如果使用量激增，应用可能会触及每分钟请求数或每秒 token 数的上限，从而导致用户体验下降。扩展并不只是增加更多服务器这么简单；它需要仔细管理工作负载，有时还需要与提供商直接协商。

成本—性能权衡：
基于 token 的定价意味着性能与成本无法分离。长 prompt、多轮对话，以及图像或视频等丰富输出，会迅速推高费用。

可观测性要求

LLM 应用的可观测性涉及跟踪多个方面，包括性能指标、输出质量、正确性、安全性和偏见。检测漂移或退化通常需要使用基准测试或人工审查数据进行持续评估。在大规模场景中监控可能变化的输出，会带来运维挑战。

我们将在下一节详细看到对 LLM 应用重要的可观测性指标。

为了监控这些应用，团队通常会构建评估流水线：捕获生产中的模型输出，对其进行抽样，并基于基准、自定义指标或人类反馈进行审查。

在后续章节中，我们会看到 Langfuse 如何帮助端到端地构建这些流水线。

伦理、安全与监管问题

下一个挑战对于 LLM 应用而言相当独特。LLM 的输出可能存在偏见、有害或冒犯性，即便这并非有意为之。如果不加监控，即使一次糟糕的交互，也可能破坏用户信任，或者让组织面临法律和声誉损害。

应用的安全功能必须从开发一开始就实现，而不是事后才补上。

在设计使用 LLM 的应用时，护栏（guardrailing）是一个常见实践。Guardrailing 指通过技术和系统约束或监控 LLM 行为，以确保输出安全、可靠、合规。护栏会在模型响应发送给用户之前对其进行过滤。过滤器可以对响应中的有毒或偏见内容进行评分，也可以实现一些领域级或基于规则的约束。

Guardrailing 也从来不是完美的，不能用来替代对 LLM 的持续监控。

贯穿所有这些挑战——无论是基础设施复杂性、延迟与成本权衡、安全风险，还是监管压力——有一点是清楚的：监控不可或缺。现在让我们来看 LLM 可观测性中的一些关键指标。

LLM 监控与可观测性的关键指标

在开始监控之前，理解哪些指标对基于 LLM 的应用很重要，是非常必要的。很明显，LLM 相比此前技术是一次重大进步，这也要求我们发展专门的指标，才能准确评估它们的性能。话虽如此，这里介绍的指标并不是一个穷尽列表，而是我们在使用 LLM 时最常用、最有用的一些指标。我们还会在后续章节中看到，Langfuse 如何帮助监控和追踪这些指标。

延迟

一般来说，延迟指从发送请求到收到第一个有意义响应之间的总时间。当谈到监控时，这是一个显而易见的指标。快速响应对任何系统都至关重要，因此在使用基于 LLM 的应用时，延迟应该是我们最先监控的内容之一。

我们在架构部分没有详细讨论这一点，但 LLM 通常会以流式方式返回响应，这意味着它们会逐词，或者更准确地说逐 token 生成输出。我们可能已经注意到 ChatGPT 在回答时会一个词一个词地显示。这其实就是响应的流式输出。

在这个语境下，LLM 的延迟指的是生成第一个 token 所需的时间。这不同于响应时间。响应时间是一个更通用的术语，用来衡量看到完整响应所花费的总时间。对于 LLM 来说，响应时间就是直到最后一个 token 出现所花费的时间。

延迟越低，用户越快获得第一次反馈。延迟通常以毫秒为单位衡量。

成本

和延迟一样，成本也是另一个我们从一开始就应该追踪的基础指标。对于 LLM 来说，每个 token 都很重要。无论我们使用开源模型还是专有模型，成本都是监控画像中无法忽视的一项。

大多数商业 LLM，例如 GPT、Claude 或 Gemini，都提供按使用量付费的定价模式。虽然成本乍看起来可能微不足道，例如 GPT-5 每百万输入 token 价格为 1.25 美元，每百万输出 token 价格为 10 美元，但这些数字会非常快地累积起来。如果我们正在开发一个 LLM 应用，尝试几十甚至上百种不同 prompt，并在多个模型上进行测试并不罕见。所有这些加起来，我们甚至在得到一个可工作的原型之前，就已经花掉了真实的钱。

即使我们选择使用 Hugging Face 或 Llama 上的开源模型，它们不会按 token 使用量计费，但 GPU 推理成本仍然可能很高，甚至更高，具体取决于我们使用的硬件。

由于 LLM 使用是基于 token 的，成本会随着流量扩大而上升。在这种情况下，即使 prompt 稍微长一点，当乘以大量用户访问时，也可能造成巨额支出。长话短说，对于 LLM 驱动的应用来说，成本监控是必不可少的。

Token 使用量

Token 使用量和成本很可能是相伴而行的。由于在大多数 LLM 中，成本都是 token 使用量的直接函数，因此监控其中一个指标，通常也意味着我们隐式监控了另一个。与成本类似，token 使用量也分为输入 token 使用量和输出 token 使用量。

不过，在一些细微场景中，独立于成本或延迟去监控 token 使用量，仍然非常有洞察价值，也很有必要。在 prompt 保持不变的情况下，输入 token 使用量的跳升可能说明用户的问题或查询变长了。这也可以帮助发现不必要的上下文添加，这些上下文可能被发送给了 LLM。

更多输出 token 意味着更长的推理时间。Token 使用量可以帮助解释延迟或响应时间的峰值。在很多情况下，更多输出 token 也可能说明 LLM 的回答过于冗长。如果目标是保持输出简洁，这可能适得其反。

Prompt injection 是一种攻击方式，攻击者会故意构造输入文本，操纵 LLM 忽略其原始指令或策略，转而遵循攻击者的指令。其最初迹象之一，就是异常数量的输入 token。

总之，token 使用量不仅仅与成本相关，也可能是应用效率和安全性的早期指标。

幻觉

到目前为止，我们看到的指标在性质上都是量化指标。但对于 LLM 来说，监控质量才是确保系统可靠性、可信度和现实可用性的核心。

幻觉指的是 LLM 生成没有事实依据，或偏离所提供上下文的内容。这些编造或误导性输出会削弱应用的可靠性，尤其是在准确性至关重要的场景中。时至今日，幻觉仍然是 LLM 面临的最大挑战之一。虽然在缓解幻觉方面已经取得了显著进展，但一个“完全无幻觉”的应用是非常不可能的。通过了解系统中幻觉发生的时间或位置，我们可以采取适当步骤，防止 LLM 产生幻觉。

我们将在后续章节中看到，一个 LLM 本身如何推断另一个 LLM 的输出是否表现出幻觉迹象，并在问题真正落地之前提醒开发者。

完整性

完整性衡量 LLM 的回答是否完整覆盖了用户查询中的每一个部分，而不仅仅是其中一部分。在很多情况下，缺失信息可能和错误信息一样有害。尤其是在医疗、法律或金融等领域，LLM 生成的回答不应该遗漏任何内容，也不应该为用户自行想象留下空间。

这个指标与准确性紧密相关。准确性回答的问题是：“答案是否正确？”完整性回答的问题则是：“答案是否覆盖了被问到的一切？”

正确性

正确性本身相当直观。它衡量 LLM 的回答在事实层面是否正确。在传统机器学习系统中，我们可能会使用准确率作为这一指标。然而，对于 LLM 来说，准确性的概念可能非常宽泛，甚至在某些情况下并不适用。例如，如果我们问 ChatGPT：“帮我规划一次纽约之旅”，这个问题并不存在一个准确答案，回答可能会有很大差异。

这并不意味着正确性不被广泛用于判断 LLM 的性能。正确性通常是评估 LLM 有用性的核心质量指标。如果我们的应用存在“正确答案”或 ground truth 的概念，那么正确性可以通过比较 LLM 的回答与 ground truth 来简单衡量。

AI 应用中常常存在“参考答案”而非“唯一正确答案”的概念。为了理解这一点，我们可以考虑一个例子：在翻译工具中，一段文本可以有很多不同译法，而所有译法在技术上都可能是“正确”的。如果已知一个理想译文，那么正确性就可以通过检查生成回答与这个期望答案的接近程度来衡量。

虽然幻觉、完整性、相关性和正确性都是质量指标，但它们可以被量化为数字表示，用于比较、监控和评估 LLM。我们将在第 7 章《Evaluating LLMs in Langfuse》中看到，Langfuse 的 LLM-as-a-judge 功能如何帮助实现这一点。在进入下一节之前，我们先看一下这些指标的简短总结：

指标	简短定义	使用场景
延迟	到第一个 / 最后一个 token 的时间	当用户体验依赖快速响应时，例如聊天、搜索。
成本	每个请求 / token 花费的金额	当扩展使用规模并保持 AI 支出可预测时。
Token 使用量	消耗的 token 数量	当优化 prompt 或检测低效问题时。
幻觉	不正确 / 编造的信息	当事实可靠性和信任非常重要时，例如医疗、法律、金融。
完整性	覆盖所有必需方面	当任务要求完整覆盖指令时，例如摘要、列表、报告。
相关性	紧扣查询主题	当答案必须与用户意图或检索上下文保持一致时，例如 RAG。
正确性	答案的事实准确性	当事实真相很重要时。

表 1.1：关键 LLM 指标总结

LLM 应用生命周期导论

在进入监控之前，让我们先理解一个 LLM 应用可能经历的一些常见阶段。开发一个由 LLM 驱动的应用，不只是 prompt—response 之间的交互；它需要一种结构化方法，将测试、扎实的工程实践、用户关注和持续改进结合起来。虽然这类应用并没有一个通用生命周期，但下面的图展示了 LLM 应用通常可能遵循的步骤。我们也可以看到 Langfuse 如何几乎应用于所有这些阶段。在后续章节中，我们会更详细地讨论每个主题。

图 1.5：LLM 应用的典型生命周期

问题定义与需求收集

这一阶段关注的是定义应用要解决的问题，并确保它与业务或用户需求保持一致。团队会设定范围、成功标准和约束条件，例如延迟、成本、合规等等。在这一阶段，我们还需要评估 LLM 是否是解决这个问题的正确工具。有时，传统机器学习模型，甚至一个 API 这样的 SaaS 应用就已经足够。在这些情况下，使用 LLM 甚至可能是过度设计。

判断我们的解决方案是否需要 LLM 的一个经验法则是：如果问题涉及以灵活方式理解或生成自然语言，并且在输出被监控、验证或通过持续迭代改进的前提下，可以容忍一定不确定性，那么 LLM 可能适合。如果问题高度确定、结构化，或者属于安全关键场景，那么非 LLM 方案应该是首选。

这一阶段的预期产出，是清晰的问题陈述和成功指标。

数据准备

LLM 高度依赖所提供数据的质量和相关性。数据准备方法会因我们使用的是基础模型 / 自研 LLM，还是类似 OpenAI GPT 的专有 API 模型而不同。

对于基础模型：

大规模数据集收集：
我们需要大量、多样且与领域相关的语料，用于训练或微调模型。

清洗与预处理：
移除重复内容，进行归一化，并删除低质量或有害文本。确保格式一致。

领域适配：
根据领域特定性能整理专门数据集。

偏见与安全过滤：
主动过滤敏感或有偏见的内容，因为模型会继承训练数据中的模式。

使用专有 LLM 时，例如 GPT：

以 Prompt 为中心的准备：
与其进行大规模训练，不如专注于整理高质量输入示例，这些示例应能代表真实用户查询。

知识落地：
如果适用，应整理领域特定数据，例如数据库、文档、FAQ，用于检索增强生成（RAG）。

Few-Shot 示例：
准备有代表性的演示 prompt，也就是 few-shot examples，用来引导模型行为。

验证数据集：
构建评估集，用于测试专有 LLM 在 prompt 或检索过程中使用我们数据的效果。

Prompt 与系统设计

Prompt 本质上是 LLM 应用中的核心组件之一。它是 LLM 生成任何输出所需要的主要输入。这使 prompt 设计对应用整体运行至关重要。

通常来说，为我们的应用设计 prompt 会占据整个生命周期中相当大的工作量。Prompt Engineering 指的是为 LLM 设计输入，以塑造它们的响应。优秀的 prompt 可以显著提升输出的准确性、质量和一致性，而无需改变模型本身。Prompt 通常被拆分为系统消息、用户消息和 few-shot 示例：系统消息定义整体行为，用户消息代表当前任务，few-shot 示例展示期望格式或推理方式。

理论上，prompt 可以有无限多种写法，这让我们很难找到能最大化应用输出质量的完美 prompt。Prompt 设计需要与实验、评估和基准测试紧密结合，通过多次迭代逐步达到尽可能好的结果。在现代应用中，像代码一样对 prompt 进行版本控制，并为每个版本维护成功指标日志，已经非常常见。

由于 Prompt Engineering 本身就是一个庞大的主题，我们这里不会展开细节。在第 7 章《Evaluating LLMs in Langfuse》中，我们会看到 Langfuse 如何支持 prompt 管理和版本控制，使我们可以直接在应用中使用 prompt，而不需要把 prompt 维护在代码里。

系统设计原则适用于 LLM 应用，正如它们适用于任何软件系统一样。顾名思义，系统设计定义一个系统的架构。LLM 应用可能是应用开发中的一个新类型，但从根本上看，它们仍然受同样的支柱约束：设计一个稳健、可扩展、可维护，并能按用户需求交付高质量输出的系统。这些支柱包括但不限于：

模块化：
将系统拆分为更小、独立、可复用的组件。

可扩展性：
系统应当在负载增加时仍然可靠运行。

可用性：
系统应在需要时可用且可访问。

可靠性：
系统随时间持续给出一致结果的能力。

性能：
系统的速度和响应性。

以下是一些专门针对当前 LLM 应用的关键设计决策：

数据与上下文处理：

外部知识将如何集成？通过检索增强生成（RAG）、微调，还是 API 调用？
什么缓存或预计算策略可以减少重复调用和成本？

可靠性与安全：

输入 / 输出将如何验证？
需要哪些审核或过滤层来处理不安全、有偏见或不相关的内容？

用户体验：

应用是否应该返回流式响应，以获得更快的感知性能？
系统将如何处理模糊查询？

可扩展性与成本效率：

是否可以让较小模型处理简单查询，把较大模型保留给复杂查询？
是否可以使用批处理或速率限制，在规模化场景下优化性能？

监控与反馈循环：

应该记录哪些指标，例如延迟、token 使用量、成本等等？
用户反馈将如何进入 prompt 优化或微调流程？

原型开发与实验

到上一个阶段结束时，我们已经进入迭代阶段。一旦问题被定义、数据准备完成、初始 prompt 和系统设计被勾勒出来，下一步就是通过原型验证假设。在 LLM 应用开发中，原型开发的重点是测试模型在真实场景中的行为，并在投入最终方案之前发现缺口。

原型开发通常应该以离线方式进行，也就是说，在应用的某次迭代上线之前完成。与其一开始构建完整系统，不如通过轻量实验测试 prompt、检索流水线和输出，这样更高效。原型能够模拟交互，并对响应的有用性、可靠性和质量提供初步反馈。

实验通常包括：

Prompt 对比：
比较不同类型、不同结构、不同风格的 prompt。

模型：
测试不同 LLM，例如 GPT、Llama、Claude，在成本、速度和准确性之间取得平衡。

上下文策略（如果适用）：
评估不同知识源对性能的影响。

输出对比：
尝试不同输出形式，例如 JSON schema、项目符号、摘要等等，看看哪种在可用性方面效果最好。

一旦我们有证据表明原型有效，就可以进入评估阶段；否则就继续优化原型。

评估与基准测试

现在我们已经有了一个原型，是时候看看它在类似真实世界的环境中表现如何了。我们在第一阶段定义的成功指标，是评估与基准测试阶段的骨架。在数据准备阶段，我们也已经拥有验证数据集，用于对不同评估阶段进行公平比较。

需要再次强调的是，选择正确的成功指标非常关键。构建了正确的应用，却追踪了错误的指标，可能导致最终产品无法满足用户需求，并因返工而造成不必要的资源浪费。

如果测试规模巨大，自动评估可能是最快、最可扩展的选择；但这一阶段也可能正是引入人在回路（Human-in-the-loop）的最佳时机。根据应用类型，如果系统被设计用于医疗、金融或法律等关键领域，人类评估可能是必要的。业务需求和安全要求也可能强制要求这一点。

还可以实现自动评估与人工评估的理想结合：第一轮评估是自动完成的，类似一种基于成本、延迟等基础指标的筛选；然后从样本中抽取一个子集交给人工审查，用于检查事实正确性、合规性、伦理安全等方面。这种双层评估也是 Langfuse 的一个标志性功能，我们将在第 8 章中详细介绍。

一个基本的评估与基准测试报告框架可以如下：

选项比较：
交叉检查哪种 prompt、模型、上下文和检索策略组合（如果适用）在每个成功指标上效果最好。

权衡平衡：
很可能没有一个选项在所有成功指标上都排名第一。例如，正确性表现最好的模型可能也是最昂贵的；让 LLM 最少幻觉的 prompt，可能也是所有 prompt 中最慢的。在这些情况下，可以根据系统需求，客观地对成功指标进行优先级排序，从而选择胜出的组合。

错误与失败：
尝试识别某些选项为何失败，以及是否存在失败原因。某个模型是否经常幻觉？某个 prompt 是否永远无法导向正确答案？RAG 是否选取了无关文档？这种分析有助于发现系统设计或 prompt 设计问题，也会影响模型选择。

建议：
根据指标和权衡，决定最适合部署的配置。如果最佳选项在生产环境中不起作用，也要有缓解策略。

部署与监控

一旦我们的应用完成评估，并被选定进入生产，重点就转向部署和监控。这一阶段不是生命周期的结束，而是系统真实世界旅程的开始。系统将在真实环境中被持续监控和测试。

我们的原型是在离线模式下运行的，而实际应用则会处于在线模式。对于在线应用来说，首先需要具备的是可观测性。这意味着我们要捕获系统与用户之间的交互，为应用停机设置告警，并实时监控所有关键系统参数。

在线评估至少应该覆盖所有请求的所有成功指标评估；如果请求量太大，则可以对请求样本进行评估，例如 20%。在真实应用中，除了预设指标，还可以监控并收集真实用户反馈。用户反馈是这一阶段最有价值的产出。

这些反馈和评估完成了 LLM 应用生命周期中单次迭代的闭环。基于结果，可能会继续进行多轮开发、验证和部署，每一轮都会带来更好的最终产品。

在本章最后一节中，我们将介绍贯穿本书会使用的框架和工具。这包括一些基础介绍和代码块，帮助我们熟悉如何在 LLM 应用中集成 Langfuse。

探索本书使用的 LLM 工具集

现在让我们探索本书中将使用的框架和库。LLM 开发领域变化很快，几乎每天都有新的工具和框架出现。本书的重点是 Langfuse，而 Langfuse 本身支持几十种集成选项。不过，为了让内容聚焦，我们选择了一部分库来使用。这样既能保持内容简洁，也能为尝试不同技术栈保留空间。我们会尽量使用开源软件（Open-Source Software，OSS），让读者在前期不需要进行金钱投入，就可以自由学习 Langfuse。

本书选择的编程语言是 Python 3.12。虽然 Langfuse 也支持 JavaScript / TypeScript，但本书不会覆盖它们。本书中的代码示例可以很容易地以较少改动适配到 JS / TS。话虽如此，读者应该熟悉 Python 编程，并将安装 Python 3.12 作为前置条件。本书中我们会使用 Python 虚拟环境。官方文档在这里：docs.python.org/3/library/v…

OpenAI SDK

我们的第一个库是 OpenAI Python SDK。ChatGPT 的创建者提供了这个 SDK，用于以编程方式访问底层 OpenAI REST API。它使用简单的基于 HTTP 的调用，是开始使用 GPT 系列模型最容易的方式。

我们先创建一个虚拟环境来开展工作。在终端或 shell 中运行：

python3 -m venv /path/to/environment # for Linux/Mac based systems
python -m venv C:\path\to\environment # for Windows

然后运行下面命令激活环境：

source /path/to/environment/bin/activate # for Linux/Mac based systems
C:> path\to\environment\Scripts\activate.bat # for Windows

要在 Python 应用中安装 OpenAI SDK，可以在终端 / shell 中使用命令：

pip install openai python-dotenv

我们还会安装另一个名为 python-dotenv 的 Python 包，它用于加载环境变量。这是一种相当标准的方式，用于在应用中设置 API key 等变量。该包可以在这里安装：pypi.org/project/pyt…

OpenAI API 是按使用量付费的服务，因此开始使用之前，我们需要购买 credits。我们还需要一个 API key，并购买 credits 才能使用该模型。这两件事都可以在这里完成：platform.openai.com/settings/or…

API key 需要添加到项目根目录下名为 “.env” 的文件中，如下所示：

OPENAI_API_KEY=<your_api_key>

之后，我们就可以开始使用 API client 调用 GPT。

from dotenv import load_dotenv
load_dotenv()
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5-nano",
input="Write a short introduction about Langfuse, the LLM Engineering Platform"
)
print(response.output_text)

这会打印出类似下面代码的输出，不过响应可能会有所不同：

Langfuse is an LLM engineering platform designed to help teams build, deploy, and govern production-ready language-model applications. It provides end-to-end tooling for prompt and chain management, evaluation, monitoring, and governance—so you can ship faster with confidence. With versioned prompts, test suites, real-time observability dashboards (latency, accuracy, errors, costs), and guardrails, Langfuse makes it easier to iterate on models while maintaining safety and reliability. It integrates with major LLM providers and data systems, enabling seamless collaboration across engineering, product, and data science teams.

在这个基础示例中，我们使用了 GPT-5-nano 模型，但我们可以使用 OpenAI 支持的任何 GPT 模型。

这个 SDK 的另一个常见用法是使用 Chat Completions API，它模拟类似 ChatGPT 的对话。我们会在本书中频繁使用这个 API。

completion = client.chat.completions.create(
model="gpt-5-nano",
messages=[
{"role": "system", "content": "You are an expert in Langfuse, the LLM Engineering Platform"},
{
"role": "user",
"content": "What are the top 3 features of Langfuse?",
},
],
)
print(completion.choices[0].message.content)

输出：

Langfuse is an LLM engineering platform that focuses on production-grade management of LLM services. The top features users commonly highlight are:
- End-to-end LLM orchestration and lifecycle management
- Unified workflow for deploying, routing, and versioning prompts and models
- Fine-grained control over routing policies, multi-model ensembles, and A/B tests
- Observability baked in metrics, traces, and dashboards for prompt variants, latency, and accuracy
- Deployment, monitoring, and reliability tooling
- Seamless deployment to multiple environments and providers with versioned models
- Real-time monitoring and alerts for latency, errors, and model drift
- Proven reliability features like retries, fallbacks, and circuit breakers to keep production endpoints healthy
- Observability and measurement at scale
- Detailed telemetry for prompts, completions, and user interactions
- Evaluation hooks to compare model performance, safety, and alignment across versions
- Data-driven optimization through dashboards, dashboards, and event-level insight to improve prompts and routing logic

虽然这个 SDK 还有很多其他功能，但我们不会在这里详细介绍。该 SDK 的官方 GitHub 页面在这里：github.com/openai/open…

LangChain

本书将使用 LangChain（www.langchain.com/langchain）作… 是一个开源编排框架，为每个模型、工具和数据库提供标准接口。LangChain 提供所谓 chains，也就是一系列步骤，在这些步骤中，LLM 会处理输入、调用工具或 API，并生成输出。它非常适合检索增强生成（RAG）应用、聊天机器人、AI Agent，以及许多其他类型的基于 LLM 的工作流。

它最强大的功能之一是组件的即插即用，这使得替换模型、数据库甚至 prompt 都变得非常容易，而不需要重写整个应用。

安装：

pip install langchain langchain_openai

要执行与 Chat Completions API 完全相同的操作，LangChain 中的等价写法如下：

from langchain.chat_models import init_chat_model
from dotenv import load_dotenv
load_dotenv()
model = init_chat_model("gpt-5-nano", model_provider="openai")
model_response = model.invoke(
input=[
{
"role": "system",
"content": "You are an expert in Langfuse, the LLM Engineering Platform",
},
{
"role": "user",
"content": "What are the top 3 features of Langfuse?",
},
]
)
print(model_response.content)

LangChain 的 init_chat_model 方法会自动负责从提供商的实现中创建合适的模型 client，在这个例子中就是 OpenAI SDK。invoke 方法也会根据 OpenAI API 的要求，将 prompt 消息格式化为所需结构。

假设我们想把 GPT 换成另一个模型，比如 Google Gemini，在 LangChain 中只需要改一行：

model = init_chat_model ("gemini-2.5-flash", model_provider="google_genai")

其余代码保持不变。我们还需要提供 GOOGLE_API_KEY，而不是 OpenAI API key。这种替换能力也适用于 chain 中的大多数组件，并使 LangChain 成为开发者构建 LLM 应用时最喜欢的库之一。本书中的许多示例也会使用 LangChain。LangChain 不是本书的前置要求，我们会在后续过程中覆盖必要的学习内容。

Langfuse

最后，我们会大量使用 Langfuse（langfuse.com/），因为这是本书的核心… 是一个面向 LLM 应用的开源 LLM 工程平台。它为开发者和机器学习工程师提供强大的工具，用于追踪、prompt 管理、评估和性能监控，并将这些能力整合在一个地方。

我们在本书中已经多次提到 Langfuse，尤其是在 LLM 应用生命周期一节中，我们看到它如何被用于完整的开发、评估、基准测试和监控流程。Langfuse 也兼容任何 LLM，并支持多种集成方式。

本节不会覆盖任何代码示例，但请放心，从第 4 章《Introduction to Langfuse》开始，我们会非常详细地介绍这些内容。

接下来的几章会进一步深入 LLM 监控的概念部分，以及模型漂移和偏见等主题，为本书专门讨论 Langfuse 的章节奠定基础。

结论

本章介绍了大语言模型（LLMs），追溯了它们从 ELIZA 等早期 NLP 系统到现代基于 Transformer 架构的演进过程。本章详细说明了 LLM 的组件和行业应用，探讨了部署挑战，包括性能、成本和伦理风险，并强调了监控延迟、成本、token 使用量和输出质量等关键指标的必要性。本章还勾勒了 LLM 应用生命周期，并介绍了 OpenAI SDK、LangChain 和 Langfuse 等关键工具，用于有效开发和可观测性建设。在下一章中，我们将深入探讨 LLM 的监控概念，包括监控的核心原则和多个维度。我们还会看到如何为典型 LLM 应用创建稳健的监控策略。