LangSmith 提供了监控和评估的基本功能。当生产环境中不可避免地出现问题时,其细致的追踪功能在调试方面尤其强大。与传统软件相比,调试使用大型语言模型(LLMs)构建的应用带来了独特挑战。LLM 响应的非确定性、多步骤链的复杂性以及提示词或数据处理中潜在的细微错误,都需要专门工具进行有效的根本原因分析。LangSmith 正好提供了对 LangChain 应用内部运作的这种清晰可见性。当应用行为异常时,无论是抛出错误、给出不正确答案还是耗时过长,您的第一步通常应该是检查 LangSmith 中相应的追踪记录。每个追踪记录都提供了执行过程的详细分层日志,记录了处理请求所涉及每个组件的输入、输出、时间以及潜在错误。了解用于调试的追踪视图LangSmith 追踪记录不仅仅是日志;它是您应用执行流程的结构化表示。用于调试的重要元素包括:运行层级: 追踪记录通常具有嵌套结构。一个顶层运行(例如,代理执行)包含子运行(例如,LLM 调用、工具执行、检索器查询)。这种层级结构立即向您展示了不同操作之间的顺序和关系,使您更容易理解应用逻辑。输入和输出: 对于追踪记录中的每一步(运行),LangSmith 都会显示接收到的确切输入和生成的输出。这非常宝贵。您可以看到发送给 LLM 的精确提示词、接收到的原始文本响应、传递给工具的数据、检索器返回的文档以及最终解析的输出。预期输入/输出与实际输入/输出之间的差异通常能找出错误来源。延迟: 每次运行都显示其持续时间。这有助于识别性能瓶颈。如果一个追踪记录表明整体延迟过高,您可以检查子运行,查看是否有特定的 LLM 调用、工具执行或数据检索步骤是造成问题的原因。状态和错误: 运行标有状态(成功、错误)。如果发生错误,LangSmith 会捕获异常类型和消息,并将其直接与失败的组件关联。这会立即告诉您故障发生的位置。digraph G { rankdir=LR; node [shape=box, style=rounded, fontname="sans-serif", fontsize=10]; edge [fontname="sans-serif", fontsize=9]; Start [label="用户输入"]; Agent [label="代理执行器"]; LLM1 [label="LLM 调用\n(思考过程)"]; Tool [label="工具执行\n(例如:搜索 API)"]; LLM2 [label="LLM 调用\n(最终答案合成)"]; Output [label="最终输出"]; Error [label="错误捕获", shape= Mdiamond, style=filled, fillcolor="#fa5252", fontcolor="white"]; Start -> Agent; Agent -> LLM1 [label=" 提示词"]; LLM1 -> Agent [label=" 行动计划"]; Agent -> Tool [label=" 工具输入"]; Tool -> Agent [label=" 工具输出 / 错误"]; Agent -> LLM2 [label=" 更新的提示词"]; LLM2 -> Agent [label=" 原始答案"]; Agent -> Output [label=" 解析输出"]; Tool -> Error [style=dashed, color="#f03e3e", label=" 失败"]; }代理执行的简化流程,说明 LangSmith 追踪记录中捕获的步骤。工具执行期间的错误被突出显示。使用 LangSmith 的常见调试场景让我们来看看如何使用 LangSmith 追踪记录处理典型问题:场景:意外或不正确的输出: 应用无错误运行,但生成无意义或事实不正确的信息。分析: 逐步检查追踪记录。检查发送给生成输出的 LLM 的最终提示词。它格式是否良好?是否包含必要的上下文?检查前一步骤的输出。如果是 RAG 应用,检索器是否获取了相关文档?它们是否正确地整合到提示词中?查看中间 LLM 调用(例如,代理中的思考过程)。模型是否正确推理?它是否误解了指令或上下文?检查任何输出解析器。它们是否正确处理了原始 LLM 响应,或者是否误解了结构?场景:工具执行失败: 追踪记录显示工具运行的错误状态。分析:在追踪层级中找到失败的工具运行。检查提供的错误消息。LangSmith 通常会捕获 Python 异常。检查传递给工具的 inputs。通常,错误是由于 LLM 或前置逻辑生成的格式错误输入(例如,不正确的参数、错误的数据类型)导致。如果错误表明连接问题,请验证工具的外部依赖项(例如,API 端点)是否正常运行。场景:输出解析错误: 最后一步失败,因为输出解析器无法处理 LLM 的响应。分析:找到失败的输出解析器运行。检查其 input,这通常是来自前一个 LLM 调用的原始字符串输出。将此原始输出与解析器期望的结构(例如,JSON、编号列表)进行比较。通常,LLM 没有遵循提示词中的格式指令。这可能需要调整提示词或使解析器更可靠。场景:高延迟: 用户报告应用运行缓慢。分析:打开慢速请求的追踪记录。总运行时间显示在顶部。检查追踪视图中每个子运行的延迟(通常以时间线或甘特图的形式呈现)。确定耗时最长的步骤。是特定的 LLM 调用?是复杂的工具执行?还是缓慢的向量数据库查询?这有助于缩小优化工作应关注的范围(例如,提示词调整、缓存、优化检索、并行化调用)。运用 LangSmith 功能进行高效调试在检查单个追踪记录时,LangSmith 提供了功能来简化跨多个运行的调试:筛选和搜索: 生产应用会生成大量追踪记录。使用筛选功能隔离相关记录。可以按状态(error)、延迟(> 5s)、您添加的特定标签(例如,user_segment: premium、chain_type: RAG)、元数据或用户反馈分数进行筛选。搜索特定错误消息也可以快速将相似故障进行分组。比较视图: 有时,理解故障的最佳方式是将其追踪记录与处理相似输入的成功记录并排比较。LangSmith 通常会促进这种比较,突出显示执行路径、输入或输出的差异。Playground 集成: 您通常可以将追踪记录中的特定运行(例如带有其精确输入的 LLM 调用)直接发送到 LangSmith Playground。这允许您独立地实验提示词变体或模型设置,以查看是否可以纠正行为,而无需重新运行整个应用。反馈关联: 如果您收集用户反馈(例如,点赞/点踩)并将其记录到 LangSmith,您可以根据负面反馈筛选追踪记录。点击反馈分数通常会直接带您到关联的追踪记录,提供用户可能不满意的原因的即时上下文。在 LangChain 中调试通常是一个迭代过程:观察问题,使用 LangSmith 追踪并确定根本原因,修改代码(调整提示词、修复工具逻辑、改进解析),重新部署,然后再次监控 LangSmith 以确认修复并确保没有引入回归。通过提供对执行流程的全面可见性,LangSmith 将调试从猜测转变为系统性调查。