LangChain-生成式-AI-第二版--六-

LangChain 生成式 AI（第二版）（六）

原文：Generative AI with LangChain

译者：飞龙

协议：CC BY-NC-SA 4.0

chain = LLMChain(llm=router_llm, prompt=prompt)


```python

result = chain.invoke({"text": "LiteLLM provides reliability for LLM applications"})

确保你设置了 OPENAI_API_KEY 和 ANTHROPIC_API_KEY 环境变量以便运行此代码。

LiteLLM 的生产功能包括智能负载均衡（基于权重、基于用量和基于延迟）、提供商之间的自动故障转移、响应缓存和请求重试机制。这对于需要保持高可用性的关键任务 LangChain 应用来说价值连城，即使在单个 LLM 提供商出现问题或速率限制时也能正常运行。

有关提供自托管模型或量化模型的更多实现示例，请参考第 2 章，该章节涵盖了核心开发环境设置和模型集成模式。

成本效益 LLM 部署的关键是内存优化。量化将你的模型精度从 16 位降低到 8 位或 4 位，在质量损失极小的情况下将内存占用减少了 50-75%。这通常允许你在具有一半显存的 GPU 上运行模型，从而大幅降低硬件成本。请求批处理同样重要——配置你的服务层以尽可能自动对多个用户请求分组。与单独处理请求相比，这可以将吞吐量提高 3-5 倍，允许你用相同的硬件服务更多用户。最后，注意注意力键值缓存（attention key-value cache），它消耗的内存通常比模型本身多。设置合适的上下文长度限制并实现缓存过期策略可以防止长对话期间内存溢出。

有效的扩展需要同时理解垂直扩展（增加单个服务器的能力）和水平扩展（添加更多服务器）。正确的方法取决于你的流量模式和预算限制。内存通常是 LLM 部署的主要限制，而不是计算能力。将优化重点放在通过高效的注意力机制和 KV 缓存管理来减少内存占用上。对于成本效益部署，针对你的特定工作负载找到最佳批大小并使用混合精度推理，可以显著提高你的性能成本比。

记住，自托管引入了巨大的复杂性，但赋予了你对部署的完全控制。从这些基础优化开始，然后监控你的实际使用模式以识别针对你应用的特定改进。

如何观察 LLM 应用

与传统的 ML 系统相比，LLM 应用的有效观测性需要监控方法发生根本性的转变。虽然第 8 章建立了开发和测试的评估框架，但由于 LLM 的独特特性，生产监控面临着不同的挑战。传统系统根据明确的真值监控结构化的输入输出，但 LLM 处理的是具有上下文依赖的自然语言，并且对同一个提示有多个有效响应。

LLM 的非确定性本质（特别是在使用温度等采样参数时）会产生传统监控系统无法处理的变异性。随着这些模型深度集成到关键业务流程中，它们的可靠性直接影响组织运营，使得全面的观测性不仅是一项技术要求，更是一项商业必然。

LLM 应用的运行指标

LLM 应用需要跟踪在传统 ML 系统中没有明确类比的特殊指标。这些指标为生产环境中语言模型的独特运行特征提供了见解：

  • 延迟维度：首字延迟 (TTFT) 衡量模型开始生成响应的速度，为用户创建了初始的响应速度感知。这与传统的 ML 推理时间不同，因为 LLM 是增量生成内容的。每个输出 Token 时间 (TPOT) 衡量第一个 Token 出现后的生成速度，捕捉流式体验的质量。通过流水线组件（预处理、检索、推理和后处理）拆分延迟有助于识别特定 LLM 架构的瓶颈。

  • Token 经济指标： 与传统模型（输入和输出大小通常是固定的）不同，LLM 运行在 Token 经济之上，这直接影响性能和成本。输入/输出 Token 比例通过衡量相对于输入 Token 生成的 Token 数量帮助评估提示工程的效率。上下文窗口利用率跟踪应用使用可用上下文的效率，揭示了优化提示设计或检索策略的机会。各个组件（链、智能体和工具）的 Token 利用率有助于识别复杂 LLM 应用中哪些部分消耗了最多的 Token。

  • 成本可见性： LLM 应用根据 Token 使用而非传统的计算指标引入了独特的成本结构。单请求成本衡量了服务每个用户交互的平均费用，而单用户会话成本捕获了多轮对话的总费用。模型成本效率评估应用是否为不同任务使用了适当大小的模型，因为过度强大的模型会增加成本。

  • 工具使用分析： 对于智能体 LLM 应用，监控工具选择的准确性和执行成功至关重要。与预定义函数调用的传统应用程序不同，LLM 智能体会动态决定使用哪些工具。跟踪工具使用模式、错误率和工具选择的合理性提供了传统 ML 应用不具备的独特视角。

通过这些维度实现观测性，组织可以在控制成本和确保质量体验的同时，维护适应变化的可靠 LLM 应用。LangSmith 等专用观测平台为跟踪生产环境中 LLM 应用的独特方面提供了专门的能力。LLM 观测的一个基础方面是对所有交互的全面捕获，我们将在下一节讨论。让我们探索跟踪和分析 LLM 响应的一些实用技术，从如何监控智能体的轨迹开始。

跟踪响应

由于范围广泛的操作和生成能力，跟踪轨迹具有挑战性。LangChain 提供了轨迹跟踪和评估的功能，因此通过 LangChain 查看智能体的轨迹非常简单！你只需要在初始化智能体或 LLM 时将 return_intermediate_steps 参数设置为 True。

让我们将工具定义为函数。复用函数 docstring 作为工具描述非常方便。该工具首先向网站地址发送 ping 并返回关于数据包和延迟的信息，或者（在发生错误时）返回错误消息：


import subprocess

from urllib.parse import urlparse

from pydantic import HttpUrl

from langchain_core.tools import StructuredTool

def ping(url: HttpUrl, return_error: bool) -> str:

    """Ping 完全指定的 url。url 必须包含 https://"""

    hostname = urlparse(str(url)).netloc

completed_process = subprocess.run(



["ping", "-c", "1", hostname], capture_output=True,

    text=True

)

output = completed_process.stdout



if return_error_ and completed_process.returncode != 0:

    return completed_process.stderr

return output

ping_tool = StructuredTool.from_function(ping)

现在，我们设置一个使用该工具并结合 LLM 根据提示词进行调用的代理：


from langchain_openai.chat_models import ChatAI

from langchain.agents import initialize_agent, AgentType



llm = ChatOpenAI(model="gpt-3.5-turbo-0613", temperature=0)

agent = initialize_agent(

    llm=llm,

    tools=[ping_tool],

    agent=AgentType.OPENAI_MULTI_FUNCTIONS,

    return_intermediate_steps=True, # 重要！

)



result = agent("What's the latency like for https://langchain.com?")

代理报告了以下内容：


The latency for https://langchain.com is 13.773 ms

对于具有多个步骤的复杂代理，可视化执行路径可以提供关键洞察。在 results["intermediate_steps"] 中，我们可以看到关于代理操作的详情：


[_FunctionsAgentAction(tool='ping', tool_input={'url': 'https://langchain.com', 'return_error': False},

log="\nVoking: `ping` with `{'url': 'https://langchain.com', return_error': False}`\n\n\n", message_log=[AIMessage(content="", additional_kwargs={'

 function_call': {\n 'name': 'tool_selection', 'arguments':{\

 actions': [\n 'action_name': 'ping',\n 'action': {\n 'url': 'https://langchain.com',\n 'return_error': false\n}\n\n]}\n}}}})}}), example=False)]), PING langchain.com (35.71.142.77): 54 data bytes\n64 bytes from 35.71.142.77-cmp_seq=0 ttl=249 time=13.773 ms\n--- langchain.com ping statistics ---n1 packets transmitted, 1 packets received, 0.0% packet loss\nround-trip min/avg/max/stddev = 13.773/13.773/13.773/0.000 ms\n")

对于 RAG 应用，不仅要跟踪模型输出，还要检索了哪些信息以及如何使用这些信息至关重要：

  • 获取的文档元数据
  • 相似性评分
  • 检索的信息是否以及如何被用于响应中

LangSmith 等可视化工具为追踪复杂的代理交互提供了图形化界面，使得识别瓶颈或失败点变得更加容易。

根据 Ben Auffarth 在 Chelsea AI Ventures 为不同客户的工作，我们提供以下关于跟踪的指导。不要记录一切。对于一个中等繁忙的 LLM 应用，记录一整天的提示词和响应会产生 10-50 GB 的数据——在大规模应用下是完全不可行的。相反：

  • 对于所有请求，仅跟踪请求 ID、时间戳、token 计数、延迟、错误代码和调用的终端。
  • 对 5% 的非关键交互进行采样以进行深度分析。对于客户服务，在部署后的第一个月或重大更新后，增加到 15%。
  • 对于关键用例（金融建议或医疗保健），跟踪 20% 交互的完整数据。对于受监管的领域，比例永远不要低于 10%。

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/generative-ai-with-langchain-second-edition/img/b4e68161fea00e7befce1e978c814dda_646_0.png

  • 删除或聚合超过 30 天的数据，除非合规性要求更长的保留。对于大多数应用，90 天后仅保留聚合指标。
  • 使用提取模式从日志提示中移除 PII（个人身份信息）——永远存储包含电子邮件、电话号码或账户详情的原始用户输入。

这种方法在保持足够用于故障排除和分析的数据的同时，将存储需求减少了 85-95%。可以使用 LangChain 追踪器或自定义中间件来实现，根据请求属性过滤被记录的内容。

幻觉检测

自动检测幻觉是另一个需要考虑的关键因素。一种方法是基于检索的验证，涉及将 LLM 的输出与检索到的外部内容进行比较，以验证事实性声明。另一种方法是 LLM 裁判（LLM-as-judge），使用更强大的 LLM 来评估响应的事实正确性。第三种策略是外部知识验证，涉及将模型响应与外部源进行交叉引用以确保准确性。

这是一个使用 LLM 作为裁判发现幻觉的模式：


def check_hallucination(response, query):

    validator_prompt = f"""

    你是一个事实检查助手。

    用户查询: {query}

    模型响应: {response}

    评估响应是否包含任何事实性错误或

    未支持的声明。

    返回一个包含以下键的 JSON：

    - hallucination_detected: true/false

    - confidence: 1-10

    - reasoning: 

    """

    validation_result = llm.invoke(validator_prompt)

    return validation_result

偏见检测

跟踪模型输出中的偏对于维护系统至关重要。一种方法是基于检索的验证，涉及将 LLM 的输出与检索到的外部内容进行比较，以验证事实性声明。另一种方法是 LLM 裁判（LLM-as-judge），使用更强大的 LLM 来评估响应的事实正确性。第三种策略是外部知识验证，涉及将模型响应与外部源进行交叉引用以确保准确性。

在下面的示例中，我们使用 fairlearn 来监控：


from fairlearn.metrics import demographic_difference

demographic_parity = demographic_difference(

    y_true=ground_truth,

    y_pred=model_predictions,

    sensitive_features=sensitive_features

)

LangSmith

LangSmith 为追踪复杂的代理交互提供了图形化界面，使得识别瓶颈或失败点变得更加容易。它支持对代理和链进行追踪以及评估。监控仪表板包含以下内容：

统计数据 类别
追踪计数、LLM 调用计数、追踪成功率、LLM 成功率 容量
追踪延迟 (s)、LLM 延迟 (s)、每次追踪的 LLM 调用次数 延迟
总 tokens、每次追踪的 tokens、每次 LLM 用的 tokens Tokens
流式传输追踪百分比、流式传输 LLM 调用百分比、追踪到第一个 token 的时间 (ms)、LLM 到第一个 token 的时间 (ms) 延迟

这里是 LangSmith 中的追踪示例：

https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/generative-ai-with-langchain-second-edition/img/b4e68161fea00e7befce1e978c814dda_645_0.png

该平台本身不是开源；然而，LangSmith 和 LangChain 的背后公司 LangChain AI 为有隐私顾虑的组织提供了一些自托管的支持。LangSmith 还有一些替代方案，例如 Langfuse、Weights & Biases、Datadog APM、Portkey 和 PromptWatch，它们在功能上有所重叠。我们在这里关注 LangSmith，因为它在评估和监控方面拥有大量功能。

与静态阈值相比，基于基线的告警能够适应历史趋势，使其对正常波动更具韧性。复合告警还可以通过仅在多个条件同时满足时触发来提高信号质量，从而减少噪声并提高响应聚焦。

在有了这些措施的基础上，建立一套用于 LLM 应用持续改进和优化的流程至关重要。持续改进涉及整合人类反馈以精炼模型、使用版本控制跟踪跨版本的性能，以及自动化测试和部署以实现高效更新。

LLM 应用的持续改进

可观测性不仅仅是监控——它应该积极驱动持续改进。通过利用可观测性数据，团队可以进行根因分析以识别问题来源，并根据关键指标使用 A/B 测试对比不同的 prompt、模型或参数。反馈整合起着至关重要的作用，通过纳入用户输入来精炼模型和提示词，同时维护详尽的文档可以清晰记录更改及其对性能的影响，作为机构知识。

我们建议采用关键方法来启用持续改进。这些包括建立包含人类反馈的反馈循环（例如用户评分或专家标注），以随时间推推调模型行为。模型比较是另一个关键实践，允许团队通过版本控制跟踪并评估不同版本的性能。最后，将可观测性与 CI/CD 流线集成可以自动化测试和部署，确保确保得到高效验证并快速部署到生产环境。

通过实施持续改进流程，你可以确保你的 LLM Agent 与不断演变的性能目标和安全标准保持一致。这种方法与本章讨论的部署和可观测性实践形成补充，为整个生命周期内维护和增强 LLM 应用创建一个全面的框架。

LangChain 应用成本管理

随着 LLM 应用从实验性原型转向服务真实用户的生产系统，成本管理成为一个关键考量。LLM API 成本可能会迅速积累，特别是当使用规模扩大时，因此有效的成本优化对于可持续部署至关重要。本节探讨了在 LangChain 应用中平衡质量与性能管理 LLM 成本的实用策略。然而，在实施优化策略之前，理解驱动 LLM 应用成本的因素很重要：

  • 基于 Token 的定价：大多数 LLM 供应商按处理的 Token 计费，其中输入 Token（你发送的内容）和输出 Token（模型生成的内容）有不同的费率。
  • 输出 Token 溢：输出 Token 的成本通常是输入 Token 的 2-5 倍。例如，使用 GPT-4o，输入 Token 的价格为每 1K 个 $0.005，而输出 Token 的价格为每 1K 个 $0.015。
  • 模型层级差异：更强大的模型价格高得多。例如，Claude 3 Opus 的费用远高于 Claude 3 Sonnet，而后者又比 Claude 3 Haiku 高。
  • 上下文窗口利用率：随着对话历史的增长，输入 Token 的数量可能会剧增，影响成本。

LangChain 中的模型选择策略

在生产环境中部署 LLM 应用时，在不牺牲质量的情况下管理成本至关重要。优化模型使用的两种有效策略是分级模型选择和级联回退方法。第一种使用轻量级模型对查询复杂度进行分类并相应路由。第二种尝试使用便宜的模型生成响应，仅在需要时升级到更强大的模型。这两种技术都有助于在真实系统中平衡性能和效率。

管理成本最有效的方法之一是智能地选择不同任务使用哪种模型。让我们详细查看。

TierChain 模型选择

LangChain 轻松实现根据复杂度将查询路由到不同模型的系统。下面的示例展示了如何使用轻量级模型对查询进行分类并相应选择合适的模型：


from langchain_openai import OpenAI

from langchain_core.output_parsers import StrOutputParser

from langchain_core.prompts import ChatPromptTemplate

# 定义不同能力和成本的模型

affordable_model = OpenAI(model="gpt-3.5-turbo")  # 比 gpt-4o 便宜 ~10 倍

powerful_model = OpenAI(model="gpt-4o")  # 能力更但更贵

# 创建分类器 prompt

classifier_prompt = ChatPromptTemplate.from_template("""

根据以下标准判断以下查询是简单还是复杂的：

- 简单：事实性问题、直接的任务、通用知识

- 复杂：多步推理、细致分析、专业知识

Query: {query}

仅用一个单词回答："simple" 或 "complex"

""")

# 创建分类器链

classifier = classifier_prompt | affordable_model | StrOutputParser()

def route_query(query):

    """根据复杂度将查询路由到合适的模型."""

    complexity = classifier.invoke({"query": query})

    if "simple" in complexity.lower():

        print(f"Using affordable model for: {query}")

        return affordable_model

    else:

        print(f"Using powerful model for: {query}")

        return powerful_model

# 使用示例

def process_query(query):

    model = route_query(query)

    return model.invoke(query)

如所述，此逻辑使用轻量级模型对查询进行分类，仅为复杂任务预留更强大（且更昂贵）的模型。

级联模型方法

在这种策略中，系统首先尝试使用较便宜的模型进行响应，仅在初始输出不足时才升级到更强的模型。下面的代码片段说明了如何使用评估器来实现：


from langchain_openai import OpenAI

from langchain.evaluation import load_evaluator

# 定义不同价格点的模型

affordable_model = ChatOpenAI(model="gpt-3.5-turbo")

powerful_model = OpenAI(model="gpt-4o")

# 加载评估器来评估响应

evaluator = load_evaluator("criteria", criteria="relevance", llm=affordable_model)

def get_response_with_fallback(query):

    """首先尝试廉价模型，如果质量不高则回退到强大模型."""

    # 尝试廉价模型

    initial_response = affordable_model.invoke(query)

    # 评估响应

    eval_result = evaluator.evaluate_strings(

        prediction=initial_response.content,

        reference=query

    )

    # 如果质量分过低，使用强大模型

    if eval_result["score"] < 4.0:  # 1-5 分制的阈值

        print("Response quality insufficient, using powerful model")

        return powerful_model.invoke(query)

    return initial_response

这种级联回退方法有助于在需要时降低成本。

输出 Token 优化

由于输出 Token 的成本通常比输入 Token 高，优化响应长度可以节省大量成本。你可以通过 prompt 和模型参数控制响应长度：


from langchain_openai import ChatOpenAI

from langchain.prompts import ChatPromptTemplate

from langchain_core.output_parsers import StrOutputParser

# 使用 max_tokens 参数初始化 LLM

llm = ChatOpenAI(

    model="gpt-4o",

    max_tokens=150  # 限制约为 100-120 个单词

)

# 创建带有长度引导的 prompt 模板

prompt = ChatPromptTemplate.from_messages([

    ("system", "You are a helpful assistant that provides concise, accurate information. Your responses should be no more than 100 words unless explicitly asked for more."),

    ("human", "{query}")

])

# 创建链

chain = prompt | llm | StrOutputParser()

这种方法确保了响应不会超过特定长度，从而提供了可预测的成本。

其他策略

缓存是降低成本的另一种强大策略，特别是对于接收重复查询的应用程序。正如我们在第 6 章中详细探讨过的，LangChain 提供了几种缓存机制，这些机制在这样的生产环境中特别有价值：

  • 内存缓存（In-memory caching）：简单的缓存，适用于在开发环境中降低成本。
  • Redis 缓存（Redis cache）：适用于生产环境的健壮缓存，支持跨应用程序重启和跨多个应用程序实例的持久化。
  • 语义缓存（Semantic caching）：这种高级缓存方法允许你对语义相似的查询重用响应，极大地提高了缓存命中率。

从生产部署的角度来看，取决于你的应用程序查询模式，实施适当的缓存可以显著降低延迟和运营成本，使其成为从开发转向生产时的基本考虑因素。

对于许多应用程序，你可以使用结构化输出来消除不必要的叙述文本。结构化输出让模型专注于以紧凑格式提供所需的信息，消除不必要的 token。技术细节请参阅第 3 章。

作为最后的成本管理策略，有效的上下文管理可以大幅提高性能并降低生产环境中 LangChain 应用程序的成本。

上下文管理直接影响 token 使用量，这在生产环境中意味着成本。实施智能上下文窗口管理可以在保持应用程序质量的同时显著减少你的运营费用。

请查看第 3 章了解上下文优化技术的全面探索，包括详细的实现示例。对于生产部署，实施基于 token 的上下文窗口尤为重要，因为它提供了可预测的成本控制。这种方法确保对话上下文不会超过指定的 token 预算，防止随着对话变长导致成本失控。

监控与成本分析

实施上述策略只是开始。持续监控对于有效管理成本至关重要。例如，LangChain 提供了跟踪 token 使用的回调（callbacks）：


from langchain.callbacks import get_openai_callback

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o")

with get_openai_callback() as cb:

    response = llm.invoke("Explain quantum computing in simple terms")

    print(f"Total Tokens: {cb.total_tokens}")

    print(f"Prompt Tokens: {cb.prompt_tokens}")

    print(f"Completion Tokens: {cb.completion_tokens}")

    print(f"Total Cost (USD): ${cb.total_cost}")

这允许我们实时监控成本，并识别对支出贡献不成比例的查询或模式。除了我们看到的之外，LangSmith 还提供了关于 token 使用量、成本和性能的详细分析，帮助你识别优化机会。请参阅本章的 LangSmith 部分获取更多详情。通过结合模型选择、上下文优化、缓存和输出长度控制，我们可以为 LangChain 应用程序创建一个全面的成本管理策略。

总结

将 LLM 应用从开发推向真实世界的生产环境需要处理许多围绕扩展性、监控和确保性能一致性等方面的复杂挑战。部署阶段需要仔细考虑通用应用程序的最佳实践和 LLM 特有的需求。如果我们想从 LLM 应用中获得获益，就必须确保它是健壮且安全的，它是可扩展的，我们可以控制成本，并且通过监控快速检测任何问题。

在本章中，我们深入了部署以及用于部署的工具。特别是，我们使用 FastAPI 和 Ray 部署了应用程序，而在之前的章节中，我们使用了 Streamlit。我们还提供了使用 Kubernetes 进行部署的详细示例。我们讨论了 LLM 应用的安全考虑，强调了提示词注入（prompt injection）等关键漏洞以及如何防御它们。为了监控 LLM，我们强调了全面监控策略中需要跟踪的关键指标，并给出了实践中跟踪指标的示例。最后，我们查看了不同的可观测性工具，具体说是 LangSmith。我们还展示了不同的成本管理模式。

在下一章也是最后一章中，让我们讨论生成式 AI 的未来将是什么什么样。

问题

  1. LLM 代理部署前检查清单的关键组成部分有哪些？为什么它们很重要？
  2. LLM 应用的主要安全风险有哪些？如何减轻减轻？
  3. 提示词注入攻击如何破坏 LLM 应用？可以实施哪些策略来减轻这种风险？
  4. 在你看来，描述语言模型化、LLM 应用或通常依赖生成式模型的应用的最佳术语是什么？
  5. 在生产环境中运行 LLM 应用的主要要求是什么？必须考虑哪些权衡？
  6. 对比并区分 FastAPI 和 Ray Serve 作为 LLM 应用的部署选项。它们各自的优势是什么？
  7. LLM 应用全面监控策略中应该包含哪些关键指标？
  8. 在 LLM 可观测性背景下，跟踪（tracking）、追踪（tracing）和监控（monitoring）有什么区别？为什么它们都是必不可少的？
  9. LLM 应用成本管理的不同模式有哪些？
  10. 持续改进在已部署 LLM 应用的生命周期中起什么作用？可以使用什么方法来实现？

生成式模型的未来：超越扩展

在过去的十年里，AI 进展的主导范式是扩展（scaling）——增加模型规模（参数数量）、扩大训练数据集以及应用更多的计算资源。这种方法带来了令人印象的收益，模型规模的每次飞跃都带来了更好的能力。然而，仅靠扩展在可持续性、可访问性和解决根本局限性方面正面临收益递减和日益增长的挑战。生成式 AI 的未来在于超越简单的扩展，转向更高效的架构、专门的方法以及在克服当前局限性的同时实现技术准民主化的混合系统。

在本书中，我们探索了使用生成模型构建应用程序。我们对代理（agents）的关注是核心，因为我们开发了能够在多个领域进行推理、规划和执行任务的自主工具。当我们结束探索时，应该考虑这些技术的影响以及快速发展的代理 AI（agentic AI）领域将引导我们走向何方。因此，在本章中，我们将反思生成模型的当前局限性——不仅是技术上的，还有它们提出的更大的社会和伦理挑战。我们将解决这些问题的策略，并探索创造创造的真实机会在哪里——特别是针对特定行业和用例定制模型时。

我们还将考虑这些技术在现实世界中应该如何实施和监管。

本章中讨论的主要领域包括：

  • 生成式 AI 的现状
  • 扩展的局限性与新兴替代方案
  • 经济和行业转型
  • 社会影响

生成式 AI 的现状

如本书所述，近年来，生成式 AI 模型在生成文本、图像、音频和视频等跨模态的人类内容方面已取得了新的里程碑。如 OpenAI 的 GPT-4o、Anthropic 的 Claude 3.7 Sonnet、Meta 的 Llama 3 以及 Google 的 Gemini 1.5 Pro 和 2.0 等领先模型，无论是在文本生成还是艺术创作方面都展现出了令人印象深刻的流畅性。

AI 开发的一个分水岭出现在 2024 年底，当时 OpenAI 发布了 o1 模型，随后是 o3。这些模型代表了 AI 能力的根本转变，特别是在需要复杂推理的领域。与前代模型的增量改进不同，这些模型展示了性能的巨大飞跃。它们在国际数学奥林匹克竞赛中获得了金牌水平的结果，并在物理、化学和生物问题上达到了博士级别的表现。

o1 和 o3 等新模型的独特之处在于它们采用了迭代处理方法，这种方法建立在前代 Transformer 架构的基础上。这些模型实现了研究人员描述的“递归计算模式”，能够对信息进行多次处理，而不是仅仅依赖于单次前向传递。这种方法允许模型为更具挑战性的问题分配额外的计算资源，尽管这仍受限于其基础架构和训练范式。虽然这些模型针对不同类型的输入整合了一些特殊的注意力机制，但它们仍然在大规模同质神经网络的约束内运行，而不是真正的模块化系统。它们的训练方法已经进化到超越简单的下一个 Token 预测，包含了中间推理步骤，尽管核心方法仍然植根于统计模式识别。

具有“推理能力”营销模型的出现标志着这些系统处理信息的方式可能发生演变，尽管明显的局限性仍然存在。这些模型在某些结构化推理任务上表现出更好的性能，并且能够遵循更显式的思维链，特别是在其训练数据中充分的领域内。然而，正如与人类认知的对比所示，这些系统在处理新领域、因果理解以及真正新概念的开发方面继续挣扎。这代表了企业利用 AI 技术方式的一种增量进展，而非能力上的根本转变。探索这些技术的组织应该实施严格的测试框架，以评估其在特定用例中的性能，特别关注边缘情况以及需要真实因果推理或领域适应的场景。

具有增强推理方法的模型展现了前景，但也伴随着重要的局限性，这些应当指导业务实施：

  • 结构化分析方法： 最近的研究表明，这些模型可以针对某些类型的问题遵循多步推理模式，尽管它们在战略业务挑战中的应用仍处于活跃探索阶段，而非既有能力。
  • 可靠性考虑： 虽然分步推理方法在某些基准任务上显示出前景，但研究表明这些技术在某些情况下实际上会放大误差。
  • 半自动代理系统： 整合了推理技术的模型可以在减少人工干预的情况下执行某些任务，但目前的实现需要仔细的监控和护栏，以防止错误传播并确保与业务目标一致。

特别值得注意的是代码生成能力的不断提高，这些推理模型不仅可以编写代码，还能理解、调试并迭代改进代码。这种能力指向了一个未来，AI 系统可能会自主创建并执行代码，本质上是通过自我编程来解决新问题或适应变化的情况——这是迈向更通用人工智能的一大步。

具有推理方法的模型的潜在业务应用是巨大的，尽管目前更多是出于愿景而非广泛实施。早期采用者正在探索此类系统：AI 助手可能通过结构化推理方法帮助分析市场数据、识别潜在的运营问题并增强客户支持。然而，这些实现在很大程度上仍是实验性的，而非完全自主的系统。

大多数目前的业务部署集中在更窄、定义明确的任务上并有人工监督，而不是营销材料中偶尔描绘的完全自主场景。虽然研究实验室和领先科技公司正在展示基于推理的潜力系统，但将其应用于复杂的业务决策仍然是一个新兴领域，而非既有实践。探索这些技术的组织应该关注受控的试点计划，并带有仔细的评估指标以衡量真实的业务影响。

对于评估 AI 能力的企业来说，推理模型代表了使 AI 成为可靠且高效的高价值业务应用工具的重要的一步。这一进展将生成式 AI 从主要的内容创作技术转变为能够增强核心业务运营的战略决策支持系统。

这些推理能力的实际应用解释了为什么开发 o1 这样的模型代表了 AI 演进中如此关键的时刻。正如我们在后续章节将探讨的，这些推理能力对不同行业的影响差异巨大，某些行业比其他行业能更早受益。

这些推理模型的独特之处不仅在于它们的性能，还在于它们如何实现性能。虽然之前的模型在多步推理方面表现挣扎，但这些系统展示了构建连贯逻辑链、探索多条解决方案路径、评估中间结果以及构建复杂证明的能力。广泛的评估揭示了与早期模型根本上不同的推理模式——类似于专家人类推理者深思熟虑的解决问题方法，而非统计模式匹配。

在我们讨论规模化时，这些模型最有意义的方面是，它们的能力并非主要通过增加规模实现的。相反，它们代表了架构和训练方法上的突破：

  • 先进推理架构： 支持递归思考过程。
  • 过程监督学习： 评估并奖励中间推理步骤，而不仅仅是答案。
  • 测试时计算分配： 允许模型对困难问题思考得更久。
  • 自我博弈强化学习： 模型通过与自己竞争来改进。

这些发展通过证明定性的架构创新和新的训练方法可以产生能力上的跨越式改进，挑战了简单的规模化假设。它们表明，AI 进步的未来可能更多取决于模型如何被结构化以思考，而不是原始参数数量——这一主题我们将在“化的局限性”部分中进一步探讨。

以下跟踪了 25 年内 AI 系统在各项能力上相对于人类表现的进展。人类性能作为基准（在纵轴上设置为零），而每个 AI 的初始性能归一化为 -100。图表揭示了不同 AI 能力达到并超过人类水平性能的不同轨迹和时间线。注意预测性推理极为陡峭的改进曲线，表明这一能力仍处于快速发展阶段，而非进入平台期。阅读理解、语言理解和图像识别都跨越了在大约 2015 年至 2020 年之间的人类性能阈值，而手写和语音识别早早实现了这一里程碑。

人类认知与生成式 AI 之间的比较揭示了尽管在 2022 年至 2025 年间取得了显著进展，但仍然存在的几个根本差异。下表总结了当前生成式 AI 与人类认知相比的主要优势和劣势：

类别 人类认知 生成式 AI
概念理解 构建基于物理和社会经验的因果模型；在统计模式之外建立有有意义的概念关系 主要依赖于统计模式识别，缺乏真正的因果理解；能够流畅地操纵符号，但缺乏深层的语义理解
事实处理 将知识与显著的认知偏差相结合；在维持生存所需功能性可靠性的同时，易受到各种推理错误的影响 产生自信但往往是幻觉的信息；尽管有检索增强，但仍难以与不可靠的信息区分开来
自适应学习与推理 复杂技能获取较慢，但样本效率极高；通过类比思维跨领域迁移；能够在熟悉的背景内通过少数示例进行泛化 初始训练需要海量数据集；推理能力受受限于训练分布；上下文学习能力不断增强，但在处理真正的新领域时表现吃力
记忆与状态跟踪 工作内存有限（4-7 个单元）；尽管存在容量限制，但擅长跟踪相关状态 理论上无限的上下文窗口，但在连贯跟踪对象和智能体状态方面存在根本困难
社会理解 通过具身经验自然地发展他人心理状态模型；根据个人能力异异，直觉性地把握社会动态 跟踪不同信念状态和社会动态的能力有限；基础的心理理论能力需要专门的调优
创造性生成 生成超出以往经验的新颖组合；创新基于重组，但可以推向概念边界 受限于训练分布；产生已知模式的变体，而非根本性的新概念
架构特性 具有专门子系统的模块化、分层组织结构；并行分布式处理，且能量效率极高（约 20 瓦） 大多为同质化架构，功能特化有限；训练和推理都需要海量的计算资源

表 10.1：人类认知与生成式 AI 的比较

尽管目前的 AI 系统在生成跨模态（图像、视频、连贯文本）高质量内容方面取得了巨大进步，但它们在深层认知能力方面继续表现出明显的局限性。

最近的研究强调了社会智能方面尤为深刻的局限。Slar 等人在 2024 年 12 月的一项研究发现，即使是像 Llama-3.1 70B 和 GPT-4o 这样的前沿模型，在挑战性的心理理论 (ToM) 场景中表现糟糕（准确率低至 0-9%）。这种模拟他人心理状态的能力（尤其是当它们与可用信息不同时）代表了人类与 AI 认知之间的根本差距。

有趣的是，同一研究发现，通过精心设计的 ToM 场景进行针对微调可以显著提高（+27 个百分点），表明某些局限可能反映了训练示例不足，而非不可逾越的架构限制。这种模式延伸到了其他能力——虽然仅扩展不足以克服认知局限，但专门的训练方法显示了前景。

状态跟踪能力的差距尤为相关。尽管理论上有无限的上下文窗口，AI 系统在复杂场景中连贯跟踪对象状态和智能体知识方面仍然很困难。人类尽管工作内存容量有限（根据最近的认知研究，通常为 3-4 个单元），但擅长通过选择性注意和有效的信息组织策略跟踪相关状态。

虽然 AI 系统在多模态整合（文本、图像、音频、视频）方面取得了令人瞩目的进展，但它们仍然缺乏人类自然发展的无缝跨模态理解。同样，在创造性生成方面，AI 仍受限于其训练分布，产生已知模式的变体而非根本性的新概念。

从架构角度来看，人类大脑具有专门子系统的模块化、分层组织，这使其具有惊人的能量效率（约 20 瓦），而 AI 是需要大量计算资源的很大同质化架构。此外，AI 系统可能会延续并放大其训练数据中存在的偏差，引发了超出性能限制之外的伦理关注。

这些差异表明，虽然某些能力可以通过更好的训练数据和技术得到改进，但其他能力可能需要更基础的架构创新来弥补统计模式匹配与真实理解之间的差距。

尽管生成式 AI 取得了巨大的进步，但人类与 AI 认知在多个维度上仍然存在根本性差距。最关键的是，AI 缺乏：

  • 知识的现实落地
  • 跨上下文的自适应灵活性
  • 表面流畅之下的真正整合理解
  • 高能效处理
  • 社会和上下文意识

这些局限性并非孤立的问题，而是开发真正的类人人工智能时同一根本挑战的相互关联方面。在技术进步的同时，AI 的监管格局正在快速演变，创造了一个复杂的全球市场。欧盟于 2024 年实施的《AI 法案》制定了严格的要求，这延迟或限制了某些 AI 工具在欧洲市场的可用性。例如，由于监管合规挑战，Meta AI 在其在美国发布两年后才于 2025 年在法国可用。这种日益增长的监管分歧为 AI 的演变增加了技术扩展之外的另一个维度，因为公司必须调整其产品以满足不同的法律要求，同时保持竞争能力。

扩展的局限性与新兴替代方案

对于今天任何构建或实施 AI 系统的人来说，理解扩展范式的局限性和新兴的替代方案至关重要。作为开发者和利益相关者，意识到收益递减何时发生，有助于做出更好的投资决策、技术选择和实施策略。超越扩展的转变既是挑战也是机遇——重新思考我们如何推进 AI 能力的挑战，以及创建更高效、更易访问且更专门的系统的机遇。通过探索这些局限性和替代方案，读者将能够更好地应对不断变化的 AI 态势，做出明智的架构决策，并为他们的特定用例识别最有前景的路径。

受到挑战的扩展假设

目前极大型模型训练计算的翻倍时间约为 8 个月，超过了既建立的扩展法则，如摩尔定律（晶体管密度随成本增加的速度目前约为每 18 个月）和 Rock 定律（GPU 和 TPU 等硬件成本每 4 年减半）。

根据 Leopold Aschenbrenner 在 2024 年 6 月的《态势感知》（Situational Awareness）报告，自 2010 年以来 AI 训练计算每年增长约 4.6 倍，而 GPU FLOP/s 每年仅增长约 1.35 倍。算法改进以每年 3 倍的速度提供性能提升。这种异常的计算扩展速度反映了 AI 开发中前所未有的军备竞赛，远超传统的半导体扩展常模。

估计 Gemini Ultra 在其最终训练运行中使用了约 5×10²⁵ FLOP，使其成为（截至目前）可能是已训练的计算密集度最大的模型。同时，语言模型训练数据集自 2010 年以来每年增长约 3.0 倍，产生了海量数据需求。

到 2024-2025 年，人们对扩展假设的观点发生了显著转变，该假设认为仅仅扩大模型规模、数据和计算量将会导致通用人工智能 (AGI)。尽管对这一方法投入了巨资（估计近五万亿美元），但证据表明，仅靠扩展由于几个原因正在遇到收益递减：

  • 首先，性能已开始平缓。尽管模型规模和训练量巨大增加计算方面，即使在最大的模型中，幻觉、推理不可靠和事实不准确等根本性挑战依然存在。诸如 Grok 3（计算量是前代产品的 15 倍）等备受目的发布，在推理、数学和事实信息方面仍然表现出基础错误。
  • 第二，竞争格局发生了剧烈变化。OpenAI 等公司曾拥有清晰的技术领先地位已被侵蚀，市场上现在有 7-10 个 GPT-4 级别的模型。像 DeepSeek 这样的中国公司以极得少的计算资源（仅为训练成本的 1/50）实现了相当的性能，挑战了巨量资源优势会转化为不可逾越的技术领先这一观点。
  • 第三，经济上的不可持续性已变得显而易见。扩展方法导致了巨额成本，却没有带来成比例的收入。随着具有相似能力的竞争对手相互压价，价格战已经爆发，压缩了利润空间，并削弱了不断扩大模型的经济可行性。
  • 最后，行业对这些局限性的认识日益增加。关键行业人物，包括微软首席执行官 Satya Nadella 和 Marc Andreessen 等知名投资者，已公开承认规模法则可能正在遇到天花板，就像摩尔定律在芯片制造中最终缓慢一样。

科技巨头 vs. 小型企业

开源 AI 的兴起在这一变化的格局中具有特别的变革性意义。Llama、Mistral 等项目让获取强大的基础模型变得民主化，允许小型公司无需像以前那样进行巨额投资即可构建、微调和部署自己的 LLM。这种开源生态系统为创新创造了肥沃的土壤，较小团队开发的特定领域模型在特定应用中可以优于科技巨头的通用模型，进一步侵蚀了仅靠规模的优势。

几家小型公司已成功证明了这种动态。Coere 的团队规模仅为 Google 或 OpenAI 的 get，但他们开发了专注于企业的模型，通过专注于指令遵循和可靠性的创新训练方法，在业务应用中达到或超过了更大的竞争对手。同样，Anthropic 通过强调宪法 AI（Constitutional AI）方法而非仅仅依靠规模，实现了卓越性能，模型在推理和安全基准测试中通常优于更大的竞争对手。在开源领域，Mistral AI 多次证明，其精心设计的较小模型可以实现与其规模大许多倍的模型相竞争的性能。

越来越明显的是，科技巨头曾享有的清晰技术护城河正在迅速侵蚀。2024-2025 年的竞争格局发生了剧烈变化。

多个强大的模型已经涌现。OpenAI 曾凭借 ChatGPT 和 GPT-4 独霸一方，而现在市场上有来自 Anthropic、Google、Meta、Mistral 和 DeepSeek 等公司的 7-10 个相当模型，显著降低了 OpenAI 感知上的独性和技术优势。

价格战和商品化日益加剧。随着能力的趋同，提供商已展开了激进的降价。OpenAI 反复应对竞争压力降低价格，特别是来自那些以较低成本提供类似能力的中国公司。

非传统参与者展示了快速追赶的能力。DeepSeek 和字节跳动等公司以远低得训练成本实现了相当的模型质量，证明了创新的训练方法可以克服资源差异。此外，创新周期显著缩短。新的技术进展在几周或几个月内被匹配或超越，而不是多年，这使得任何技术领先都变得越来越短暂。

从技术采纳格局来看，我们可以考虑 AI 实现的两种主要场景。在中心化场景下，生成式 AI 和 LLM 主要由大型科技公司开发和控制，他们对必要的计算硬件、数据存储和专门的 AI/ML 人才投入了巨资。这些实体生产通用的专用模型，客户通常可以通过云服务或 API 访问，但这些一刀性的解决方案可能无法完美符合每个用户或组织的需求。

相反，在自助服务场景下，公司或个人承担了微调自己 AI 模型的任务。这种方法允许他们创建根据用户特定需求和私有数据定制的模型，提供更具针对性和相关的功能。随着计算、数据存储和 AI 人才成本的下降，中小公司对专门模型的定制微调已变得可行。

可能会出现一种混合格局，两种方法将根据用例、资源、专业知识和隐私考虑履行不同的角色。大型公司可能继续在提供行业特定模型方面表现出色，而小型实体可以越来越多地微调自己的模型以满足小众需求。

如果出现强大的工具来简化和自动化 AI 开发，定制生成式模型可能对于地方政府、社区团体和个人解决超局部挑战也是可行的。虽然大型科技公司目前主导着生成式 AI 的研发，但小型实体最终可能从这些技术中获益最多。

纯扩展之外的新兴替代方案

随着扩展局限性变得越来越明显，一些替代方法正在获得关注。许多关于超越纯扩展的观点灵感源于 Leopold Aschenbrenner 在 2024 年 6 月发表的影响影响力论文《情境感知：未来十年》（https://situational-awareness.ai/），该论文对 AI 规模扩展趋势及其局限性进行了全面分析，同时探索了进步的替代范式。这些方法可以组织为三个主要范式。让我们来看每一个。

向上扩展（传统方法）

AI 进步的传统方法集中在向上扩展（Scaling up）——通过更大的模型、更多的计算和更大的数据集来追求更能力。这种范式可以分解为几个关键部分：

  • 增加模型规模和复杂度： 自 2017 年以来，主流方法是创建参数越来越多的庞大的神经网络。GPT-3 扩展到 1750 亿参数，而更近期的模型（如 GPT-4 和 Gemini Ultra）被认为拥有数万亿有效参数。规模的每次增加通常都会带来广泛任务中能力的提升。
  • 扩展计算资源： 训练这些巨大的模型需要巨大的计算基础设施。目前最大的 AI 训练运行消耗的资源可比小型数据中心，其电力消耗、冷却需求和对特殊硬件的需求超出了所有大型机构的承受范围。一个前沿模型的单次训练成本可能超过 1 亿美元。
  • 收集海量数据集： 随着模型的增长，它们对数据的渴望也随之增加。领先模型在数万亿个 token 上进行训练，基本上消耗了互联网、书籍和专业数据集上可用的大部分文本。这种方法需要复杂的数据处理流水线和大量的存储基础设施。
  • 局限性变得显而易见： 虽然这种方法到目前为止主导了 AI 的发展并取得了显著成果，但在投资回报递减、经济不可持续性以及仅靠扩展无法克服的技术障碍方面，它面临着日益增长的挑战。

效率范式（以少胜多的方法）

效率范式侧重于通过几种关键技术实现“以少胜多”：

  • 量化（Quantization）通过减少权重和激活值的位大小将模型转换为低精度。这种技术可以将大型模型的性能压缩到更小的形态中，从而大幅减少计算和存储需求。
  • 模型蒸馏（Model distillation）将知识从大型“教师”模型转移到更小、更高效的“学生”模型，能够在更有限的硬件上进行部署。
  • 内存增强架构（Memory-augmented architectures）代表了一种突破性方法。Meta FAIR 在 2024 年 12 月对内存层的研究展示了如何在不比例增加计算需求的情况下提高模型能力。通过将部分前馈网络替换为扩展到 128 亿参数的可训练键值内存层，研究人员在事实准确性上实现了 100% 的提升，同时增强了在编码和通用知识任务上的表现。值得的是，这些内存增强模型的性能与计算量是 4 倍的稠密模型相当，直接挑战了“更多计算是通更好性能的唯一途径”这一假设。这种方法专门针对事实可靠性——解决了传统架构在规模扩大后依然存在的幻觉问题。
  • 专业化模型（Specialized models）提供了通用系统的另一种替代方案。与其通过规模追求通用智能，不如针对特定领域定制专注模型通常以更低的成本提供更好的性能。微软的 Phi 系列（现已达到 phi-3，2024 年 4 月）证明了精细的数据筛选如何彻底改变扩展缩律。虽然 GPT-4 等模型是在海量异构数据集上训练的，但 Phi 系列通过专注于高质量的教科书级数据，以小得多的模型实现了卓越的性能。

扩展性（分布式方法）

这种分层范式探索了如何利用模型网络和计算资源。

测试时计算（Test-time compute）将重点从训练更大的模型转向在推理期间分配更多计算资源。这使得模型能够更彻底地推理问题。Google DeepMind 的 Mind Evolution 方法在复杂规划任务上实现了超过 98% 的成功率，无需更大的模型，证明了推理过程中进化搜索策略的威力。由于提示词非常长，该方法消耗了 300 万个 token，而正常的 Gemini 操作为 9,000 个 token，但取得了显著更好的结果。

推理能力的近期进展已超越了简单的自回归 token 生成，引入了“思维”（thought）的概念——即代表推理过程中中间步骤的 token 序列。这种范式转变使模型能够通过树搜索和反思思考方法模拟复杂的人类推理。研究表明，鼓励模型在测试时推理中使用更多 token 进行思考可以显著提高推理准确性。

已经出现了多种方法来利用这一见解：基于过程的监督（Process-based supervision），模型生成分步推理链并在中间步骤获得奖励；蒙特卡洛树搜索（MCTS）技术探索多条推理路径以寻找最优解决方案；以及用于迭代解决问题的修订模型，以不断改进之前的尝试。

例如，2025 年的 rStar-Math 论文（rStar-Math: Small LLMs Can Master Math Reasoning with Self-Evolved Deep Thinking）证明了模型可以在无需从优秀模型蒸馏的情况下，达到与 OpenAI o1 相当的推理能力，而是通过基于 SLM 的过程奖励模型的 MCTS 利用“深度思考”。这代表了提高 AI 能力的一种与传统扩展方法截然不同的方法。

RAG（检索增强生成）将模型输出植根于外部知识源，这比简单扩大模型规模更有效地解决幻觉问题。这种方法允许更小的模型也能访问准确、最新的信息，而无需将所有内容编码到参数中。

高级内存机制（Advanced memory mechanisms）已显示出良好的前景。最近的创新如 Meta FAIR 的内存层和 Google 的 Titan 神经内存模型展示了卓越性能，同时大幅减少了计算需求。Meta 的内存层使用可训练的键值查找机制在不增加 FLOPs 的情况下为模型添加额外参数。它们在事实问答基准上将事实准确性提高了 100% 以上，同时增强了编码和通用知识任务的性能。这些内存层可以扩展到 128 亿参数，并已针对 1 万亿 token 进行了预训练。

该范式中的其他创新方法包括：

  • 神经注意力内存模型（NAMMs）在不改变架构的情况下提高了 transformer 的性能和效率。NAMMs 可以将输入上下文缩小到原始大小的一比例，同时在 LongBench 上性能提升了 11%，并在 InfiniteBench 上提升了 10 倍。它们已证明了对新 transformer 架构和输入模态的零样本迁移能力。
  • 概念级建模（Concept-level modeling）如 Meta 的大概念模型（Large Concept Models），在比 token 更高的抽象级别运行，实现了更高效的处理。LCMs 不是在离散 token 上操作，而是在代表抽象意义单元（概念）的高维嵌入空间中计算，这些单元对应于句子或语句。这种方法本质上是模态无关的，支持 200 多种语言和包括文本和语音在内的多种模态。
  • 视觉中心化增强（Vision-centric enhancements）如 OLA-VLM 专门针对视觉任务优化多模态模型，而不需要多个视觉编码器。深度估计任务中比基准模型提升高达 8.7%，分割任务达到 45.4% 的 mIoU 分（基准为 39.3%）。

这种转变表明，AI 开发的未来可能不仅由拥有最多资源的组织主。相反，训练方法、架构设计和战略专业化的创新可能决定 AI 开发阶段的竞争优势。

训练数据质量的演进

训练数据质量的演进变得日益复杂，遵循三个关键发展。首先，领先模型发现书籍相比网络爬取的内容具有关键优势。发现 GPT-4 广泛记忆了文学作品，包括《哈利·波特》系列、奥威尔的《1984》和《指环王》三部曲——这些网络内容缺乏的连贯叙事、逻辑结构和精炼语言。这解释了为什么访问书籍语料库的早期模型通常优于主要在网络数据上训练的大型模型。

其次，数据筛选已演变为多层次方法：

  • 黄金数据集（Golden datasets）：传统的领域专家创建的集合，代表最高质量标准。
  • 银色数据集（Silver datasets）：模仿专家级指令的 AI 生成内容，实现了训练示例的大规模扩展。
  • 超级黄金数据集（Super golden datasets）：由不同专家通过多层验证经过严格核实的精集。
  • 合成推理数据（Synthetic reasoning data）：专门生成的专注于分步解决问题的数据集。

第三，质量评估已变得日益复杂。现代数据准备流水线采用了多个过滤阶段、污染检测、偏见检测和质量评分。这些改进彻底改变了传统的扩展缩律——一个具有卓越数据质量的训练良好的 70 亿参数模型，现在在复杂推理任务上可以优于早期的 175 亿参数模型。

这种以数据为中心的方法代表了纯扩展方案的一种根本性替代方案，表明 AI 的未来可能属于更高效、更专业的模型，这些模型基于针对性的目标数据进行训练，而不是在所有可用数据上训练的海量通用系统。

数据质量的一个新兴挑战是 AI 生成内容在互联网上日益普及。随着生成式 AI 系统产生越来越多的在线文本、图像和代码，未来在这些数据上训练的模型将越来越多地从其他 AI 输出学习，而不是原始的人类创作。这创造了一个潜在的反馈循环，最终可能导致性能遇到瓶颈，因为模型开始放大前代 AI 中存在的模式、局限性和偏见，而不是从新鲜的人类示例中学习。这种数据饱和现象凸显了持续为未来模型训练筛选高质量、经过验证的人类创作内容的重要性。

通过技术进步实现民主化

AI 模型训练成本的快速下降代表了格局的重大转变，使得更广泛的人员能够参与尖端 AI 的研发。多种因素促成了这一趋势，包括训练方案的优化、数据质量的提高以及新型模型架构的引入。

以下是使生成式 AI 更易获取且更有效的关键技术和方法：

  • 简化的模型架构：精简模型设计，以便于管理、更好的可解释性和更低的计算成本
  • 合成数据生成：在保护隐私的同时增强数据的人工训练数据集
  • 模型蒸馏：将知识从大模型转移到更小、更高效的模型中，以便于部署
  • 优化的推理引擎：提高在给定硬件上执行 AI 模型速度和效率的软件框架
  • 专用 AI 硬件加速器：如 GPU 和 TPU 等专用硬件，可极大地加速 AI 计算
  • 开源和合成数据：高质量的公共数据集，能够在促进协作、增强隐私的同时同时减少偏见
  • 联邦学习：在去中心化的数据上进行训练，在提高隐私的同时从多样化来源中受益
  • 多模态：在顶级模型中将语言与图像、视频和其他模态整合

在这些帮助降低成本的技术进步中，量化技术已成为一项重要的贡献因素。开源数据集和合成数据生成等技术通过提供高质量且数据高效的模型开发，并消除对海量私有数据集的依赖，进一步实现了 AI 训练访问的民主化。开源倡议通过提供具有成本效益的协作创新平台为这一趋势做了贡献。

这些创新共同从几个重要方面降低了迄今阻碍生成式 AI 在现实世界采用的障碍：

  • 通过量化和蒸馏将大模型性能压缩到更小的规格中，降低了财务障碍
  • 隐私考虑可能通过合成数据技术得到解决，尽管专门大语言模型（LLMs）的可靠、可重复的联邦学习实现仍是一个持续研究领域，而非成熟方法
  • 通过外部信息为生成提供支撑（grounding），缓解了限制小模型的准确性局限性
  • 专用硬件显著加速了吞吐量，而优化的软件则最大化了现有基础设施的效率

通过解决成本、安全和可靠性等限制来实现访问民主化，这些方法为极大扩展的受众释放了利益，引导生成式创意从狭窄集中转向赋能多样化的人类人才。

格局正在从关注纯模型规模和暴力计算，转向最大化计算效率和模型效能的巧妙、细致的方法。随着量化及相关技术降低障碍，我们正准备进入一个更加多样化和动态的 AI 发展时代，资源财富不再是决定 AI 创新领先地位的唯一决定因素。

后训练阶段的新扩展法则

与传统的预训练扩展不同（性能改进会随着参数数量的增加最终遇到瓶颈），推理性能会随着推理过程中思考时间的不断增加而持续提高。多项研究表明，允许模型花更多时间逐步解决复杂问题，可以增强它们在某些领域解决问题的能力。这种方法有时被称为推理时扩展（inference-time scaling），仍然是一个不断发展的领域，并取得了良好的初步结果。

这种新兴的扩展动态表明，虽然预训练扩展可能正接近收益递减，但后训练和推理时扩展代表了极具前景的新前沿。扩展法则与指令遵循能力之间的关系尤为值得关注——模型必须具有足够强的指令遵循能力才能展现这些测试时扩展的优势。这为将研究精力放在增强推理时推理而非仅仅扩大模型规模提供了说服力的理由。

在研究了扩展的技术局限性和新兴的替代方案后，我们现在转向这些发展的经济后果。正如我们将会看到的，从纯扩展向更高效方法的转变，对市场动态、投资模式和价值创造机会具有重大影响。

经济与行业转型

生成式 AI 有望通过自动化各部门的任务带来巨大的生产力提升，同时可能由于变化速度导致劳动力动荡。根据普华永 2023 年《全球人工智能指数》和摩根 2024 年《生成式AI的经济影响》报告，到 2030 年，AI 可为全球经济贡献高达 15.7 万亿美元，推动全球 GDP 增长 14%。这种经济影响将分布不均，中国可能看到 26%，北美约为 14%。预计受影响最大的行业按顺序包括：

  • 医疗保健
  • 汽车
  • 金融服务
  • 交通与物流

普华永强调，AI 不仅仅是简单的自动化——它从根本上增强了业务能力。随着技术部门演变，未来的收益可能会遍及经济。

可以在之前的技术革命背景下更好地理解 AI 采用演变，这些革命通常遵循埃弗里特·罗杰斯（Everett Rogers）经典著作《创新的扩散》中描述的 S 曲线模式。虽然典型的技术革命在历史上遵循了这些阶段几十年，但利奥波德·阿申布雷纳（Leopold Aschenbrenner）在《情境感知：未来十年》（2024）中认为，由于其具有改进自身和加速自身发展的独特能力，AI 的实施可能会遵循压缩的时间表。阿申布雷纳的分析表明，传统的 S 曲线对于 AI 可能会变得陡峭，可能将需要几十年的采用周期压缩为：

  • 学习阶段（5-30 年）：初始实验和基础设施建设
  • 执行阶段（10-20 年）：一旦性基础设施成熟后进行快速扩展
  • 优化阶段（持续）：饱和后的增量改进

最近的分析表明，AI 自动化的实施可能会遵循更复杂的分阶段轨迹：

  • 2030-2040 年：制造业、物流和重复性办公任务可能达到 70-90% 的自动化
  • 2040-2050 年：随着人形机器人和 AGI 能力的成熟，医疗和教育等服务行业可能会达到 40-60% 的自动化
  • 2050 年以后：社会和伦理考虑将延迟需要共情能力的角色的完全自动化

根据世界经济论坛《2023 年未来就业趋势报告》和麦肯锡全球研究院关于各行业自动化潜能的研究分析，我们可以描绘关键行业的相对自动化潜力：

行业 自动化潜力 关键驱动因素
制造业 高——特别是在重复性任务中 协作机器人、机器视觉、AI 质量控制
部门 影响 技术
物流/仓储 高——特别是在分拣、拣货和库存管理方面 自主移动机器人 (AMRs)、自动分拣系统
医疗保健 中——集中在行政和诊断任务 AI 诊断辅助、机器人手术、自动化文档记录
零售业 中——主要在库存和结账流程 自助结账、库存管理、自动化履约

表 10.2：各行业自动化水平现状及预测

这些数据支持对不同部门自动化时间表进行细致观察。尽管制造业和物流业正快速向高水平自动化发展，但具有复杂人机交互的服务性部门面临着更巨大的障碍。

麦肯锡 2023 年的早先估计表明，LLM 可以直接自动化 20% 的任务，并间接转型 50% 的任务。然而，事实证明比预期更具挑战。最成功的部署是那些增强人类能力而非尝试完全替代的方案。

行业特定转型与竞争态势

AI 供应商者的竞争格局在 2024-2025 年间发生了显著变化。随着供应商间技术能力的趋同，价格竞争愈演愈烈，给整个行业的利润率带来了压力。公司在建立核心技术之外的可持续竞争优势方面面临着挑战，因为差异化日益依赖于领域专业知识、解决方案集成和服务质量，而非原始模型性能。与最初预测相比，企业的采纳率仍然较低，这表明在“规模化假设”下进行的大规模基础设施投资在短期内可能难以产生足够的回报。

领先的制造业采用者——例如全球灯塔工厂——已经使用 AI 驱动的机器人实现了 50-80% 的任务自动化，并在 2-3 年内实现了投资回报。根据 ABI Research 的2023 年协作机器人市场分析，协作机器人的部署速度比传统的工业机器人更快，实施周期平均缩短了 30-40%。然而，这些进展主要在结构化环境中有效。先驱设施与行业平均水平（目前为 45-50% 自动化）之间的差距说明了未来的潜力，也说明了仍面临的实施挑战。

在创意产业中，我们看到特定领域的进展。像 GitHub Copilot 等软件开发工具正在改变开发者的工作方式，尽管任务自动化的具体百分比仍难以精确量化。同样，数据分析工具正越来越多地处理金融和营销领域的常规任务，尽管其具体程度因实施方式而异。根据麦肯锡全球研究所 2017 年的研究，只有约 5% 的职业可以被已证明的技术完全自动化，而有更多职业有很大比例的活动是可自动化的（实质性地表明，在 60% 的职业中，约 30% 的活动是可以自动化的）。这表明，大多数成功的实施都是增强了人类能力，而非完全替代工人。

职业演变与技能影响

随着自动化在各行业不断普及，对工作的影响将根据部门和时间线而有显著差异。基于目前的采纳率和预测，我们可以预测特定角色将如何演变。

短期影响（2025-2035）

随着自动化在各行业不断普及，对工作的影响将根据部门和时间线而有显著差异。虽然精确的自动化百分比难以预测，但我们可以识别出特定角色可能演变的清晰模式。

根据麦肯锡全球研究所的研究，只有约 5% 的职业可以通过现有技术实现完全自动化，但约 60% 的职业至少有 30% 的组成活动是可以自动化的。这表明，随着 AI 能力的提升，职业转型——而非大规模替代——将成为主要模式。到目前为止，最成功的实施都是增强了人类能力，而非完全替代工人。

自动化潜力在部门之间存在巨大差异。制造业和物流业具有结构化环境和重复性任务，其自动化潜力高于医疗保健和教育等需要复杂人机交互的部门。这种差异导致了整个经济体转型时间线的不均衡。

中期影响（2035-2045）

随着服务业部门在未来十年内达到 40-60% 的自动化水平，我们可以预计传统专业角色将发生重大转型：

  • 法律行业：文档审查和草案起拟等常规法律工作将会在很大程度上实现自动化，从根本上改变初级律师和法律辅助人员的角色。已经开始这一转型的律事务所报告称，在显著增加案件处理能力的同时，维持了人员人数。
  • 教育：教师将利用 AI 进行课程准备、行政任务和个性化学生支持。学生已经在利用生成式 AI 通过个性化教学互动来学习新概念，通过提后续问题来按自己的节奏澄清理解。教师的角色将向导师、批判性思维培养和创造性学习设计发展，而不是纯粹的信息传递，重点关注人类指导能增加最大价值的方面。
  • 医疗保健：虽然临床决策将主要由人类负责，但诊断支持、文档记录和常规监控将日益自动化，使医疗保健提供者能够专注于复杂病例和医患关系。

长期转变（2045 年及以后）

随着技术趋向更多需要共情要求的角色，我们可以预计以下领域将产生需求：

  • 专业知识：对 AI 伦理、监管、安全监督和人机协作设计专家的需求将大幅增长。随着系统变得更加自主，这些角色对于确保负责任的结果至关重要。
  • 创意领域：音乐家和艺术家将开发出新的人机协作形式，可能增强创意表达和可及性，同时对归属和原创性提出新问题。
  • 领导力和战略：需要复杂判断、伦理推理和利益相关者管理的将将最后一批实现显著自动化的，可能会增加它们在经济中的相对价值。

经济分配与公平性考虑

在没有刻意政策干预的情况下，AI 的经济效益可能会不成比例地流向拥有资本、技能和基础设施来利用这些技术的人，可能扩大现有的不平等。这种担忧对于以下情况尤为相关：

  • 地理差异：拥有强大技术基础设施和教育系统的地区可能会进一步拉开与落后地区的距离。
  • 技能不平等：具有辅助 AI 系统所需的教育和适应能力的工人可能会看到工资增长，而其他人可能面临流失或工资停滞。
  • 资本集中：成功实施 AI 的组织可能会获得不成比例的市场份额，可能导致更严重的行业集中。

应对这些挑战需要协调的政策方法：

  • 投资教育和再培训计划，以帮助工人适应变化的工作需求。
  • 促进竞争并防止过度市场集中的监管框架。
  • 为面临巨大冲击的地区和社区提供针对性支持。

在所有时间范围内的一致模式是，尽管常规任务面临着日益增加的自动化（其比例取决于特定部门因素），但引导 AI 系统并确保负责任结果的人类专业知识至关重要。这种演变表明，我们应该预期转型而非大规模替代，专家仍然是开发 AI 工具和实现其业务潜力的关键。

通过自动化常规任务，先进的 AI 模型最终可能会释放人类的时间来从事更高价值的工作，在可能增加整体经济产出的同时，也可能带来需要深思政策应对的转型挑战。具备推理能力的 AI 开发可能会加速分析类角色的这种转型，而对需要情感智能和人际技能角色的直接影响较小。

社会影响

作为 AI 生态系统的开发者和利益相关者，理解这些技术更广泛的社会影响不仅是一项理论练习，更是一项务实需求。我们今天做出的技术决策将塑造未来 AI 对信息环境、知识产权体系、就业模式和监管格局的影响。通过审视这些社会维度，读者可以更好地预测挑战、设计更具责任的系统，并为塑造一个生成式 AI 在创造广泛利益的同时最大限度地减少潜在危害的未来贡献力量。此外，意识到这些影响有助于应对日益影响 AI 开发和部署的复杂伦理和监管考量。

虚假信息与网络安全

AI 对信息完整性和安全而言是一把双刃剑。虽然它能更更好地检测虚假信息，但同时也促进了以前所未有的规模和个性化程度创建日益复杂的虚假信息。生成式 AI 可以创建针对特定人口统计和个人定制的针对性虚假信息活动，使人们难以区分真实内容与被操纵的内容。当与微定位能力相结合时，它可以跨社交平台对舆论进行精准操纵。

除了纯粹的虚假信息，生成式 AI 通过能够模仿信任联系人写作风格的个性化钓鱼信息，加速了社会工程攻击。它还能生成恶意软件代码，使得技术水平较低的威胁者也能发起复杂的攻击。

深度伪造（Deepfake）现象可能是最令人担忧的发展。AI 系统现在可以生成逼真的虚假视频、图像和音频，看起来像是真实人物在说或做他们从未做过的事情。这些技术威胁着人们对媒体和机构的信任，同时为实际的违规行为提供了合理的推卸理由（“这只是 AI 伪造的”）。创建与检测之间的不对称构成了重大挑战——生成令人信服的虚假内容通常比构建检测它的系统更简单、更便宜。这为传播虚假信息的人创造了持续的优势。

扩展规模方法的局限性对虚假信息担忧具有重要影响。虽然人们预期更强大的模型将发展出更好的事实基础和推理能力，但即使在最先进的系统中持续存在的幻觉现象表明，仅靠技术解决方案可能是不足的。这使得重心转向了结合 AI 与人工监督以及外部知识验证的混合方法。

为了应对这些威胁，需要几种互补的方法：

  • 技术防御措施： 内容溯源系统、数字水印和先进检测算法
  • 媒体素养： 开展关于识别被操纵内容和评估信息来源的广泛教育
  • 监管框架： 应对深度伪造和自动化虚假信息的法律
  • 平台责任： 增强的内容审核和身份验证系统
  • 协作检测网络： 跨平台共享虚假信息模式

AI 的生成能力与互联网级分发机制相结合，对支撑民主社会的信息生态系统构成了前所未有的挑战。解决这一问题需要技术、教育和政策领域的协调努力。

版权与归属挑战

生成式 AI 为开发者带来了重大的版权问题。最近的法庭裁决（https://www.reuters.com/world/us/us-appeals-court-rejects-copyrights-ai-generated-art-lacking-human-creator-2025-03-18/）已经确定，没有显著人类创造性输入的 AI 生成内容无法获得版权保护。美国上诉法院在 2025 年 3 月明确判定，根据版权法，“注册需要人类作者”，确认了仅由 AI 创建的作品不受版权。

所有权问题取决于人类的参与。仅有 AI 输出不受版权，而具有创造性选择的人类指导的 AI 输出可能具有版权，AI 辅助的人类创作则保留标准的版权保护。

在受版权保护上训练 LLM 的问题仍存在争议。虽然一些人认为这构成了转换性的合理使用，但最近的案例挑战了这一立场。2025 年 2 月的汤森裁决（https://www.lexology.com/library/detail.aspx?g=8528c643-bc11-4e1d-b4ab-b467cd641e4c）拒绝了基于受版权保护材料训练的 AI 的合理使用辩护。

这些问题严重影响了创意产业，因为既有的补偿模式依赖于清晰的所有权和归属。这些挑战在视觉艺术、美术、音乐和文学中尤为突出，在这些领域，生成式 AI 可以产生与特定艺术家或作者风格相似的作品。

拟的解决方案包括跟踪训练来源的内容溯源系统、向为 AI 提供素材的创作者分配版税的补偿模型、区分 AI 生成内容的技术水印以及归属标准。

在实施 AI 应用时，开发者应该跟踪并归属源内容，实施过滤器以防止逐字复制，记录用于微调的数据，并考虑适当引用来源的检索增强方法。

国际框架各不相同，欧盟 2024 年的《AI 法案》建立了特定的数据挖掘例外，版权持有者从 2025 年起拥有退出权。这种困境强调了迫切需要法律框架，以跟上技术进步，并应对权利者与 AI 生成内容之间复杂的相互作用。随着法律标准的演变，能够适应要求的灵活系统为开发者和用户提供了最好的保护。

监管与实施挑战

以负责任的方式实现生成式 AI 的潜力涉及解决法律、伦理和监管问题。欧盟《AI 法案》采用了全面的、基于风险的方法来监管 AI 系统。它根据风险水平对 AI 系统进行分类：

  • 极低风险：危害潜力有限的基础 AI 应用
  • 有限风险：需要承担透明度义务的系统
  • 高风险：在关键基础设施、教育、就业和基本服务中的应用
  • 不可接受风险：被认为对权利和安全构成根本威胁的系统

医疗软件和招聘工具等高风险 AI 应用在质量、透明度、人工监督和风险缓解方面面临严格要求。法律明确禁止某些被认为对基本权利构成“不可接受风险”的 AI 用，例如社会评分系统和针对弱势群体的操纵行为。《AI 法案》还对开发者施加了透明义务，并对具有高影响潜力的通用 AI 模型包含了特定规则。

对扩展局限性的认识对监管具有重要影响。早期的 AI 治理方法侧重于监管计算资源的访问。然而，最近的创新证明，可以用大幅少的计算量实现顶尖的能力。这使得这促使监管框架发生了转变，转向治理 AI 的能力和应用，而不是用于训练这些模型所使用的资源。

为了在降低风险的同时最大化收益，组织应该确保 AI 开发过程中的人类监督、多样性和透明度。将伦理学纳入计算机科学课程中，可以通过教授开发人员如何构建设计上符合伦理的应用，帮助减少 AI 代码中的偏见。另一方面，决策者可能需要实施护栏措施以防止滥用，同时在活动发生转移时为工作人员提供转型支持。

总结

当我们结束对 LangChain 与生成式 AI 的探索时，我们希望你不仅掌握了技术知识，还对这些技术的发展方向有了更深层次的理解。从基础 LLM 应用到复杂的代理系统（agentic systems），代表了当今计算领域最令人兴奋的前沿之一。

我们在本书书中涵盖的实际实现——从 RAG 到多智能体系统，从软件开发代理到生产部署策略——为今天构建强大且负责任的 AI 应用奠定了基础。然而，正如我们在最后一章看到的，该领域仍在快速演进，正从简单的扩展方法转向更高效、专门化和分布式的范式。

我们鼓励你运用所学，对我们探索的技术进行实验，并为这个不断演变的生态系统做出贡献。与本书相关的仓库（https://github.com/benman1/generative_ai_with_langchain）将随着 LangChain 和更广泛的生成式 AI 领域的持续发展而不断维护和更新。

这些技术的未来将由构建它们的实践者塑造。通过开发深思熟虑、有效且负责任实现，你可以帮助确保生成式 AI 实现其作为变革性技术的承诺，即增强人类能力并带来有意义的挑战。

我们非常期待看到你的作品！

订阅我们的每周通讯邮件

订阅 AI_Distilled，这是 AI 专业人士、研究人员和创新者的首选通讯邮件，地址为：https://packt.link/Q5UyU。

附录

本附录作为与 LangChain 集成的主要 LLM（大语言模型）提供商的实操参考指南。当你使用书中介绍的技巧来开发开发应用时，你将需要连接到各种模型提供商，每个提供商都有自己的身份验证机制、功能和集成模式。

我们将首先介绍主要 LLM 提供者的详细设置说明，包括 OpenAI、Hugging Face、Google 等。对于每个提供商，我们将详细介绍创建账户、生成 API 密钥以及配置开发环境以通过 LangChain 使用这些服务的流程。最后我们将以一个实际实现示例结束，该示例演示了如何处理超过 LLM 上下文窗口的内容——具体来说是使用 LangChain 的 map-reduce 技术总结长视频。这种模式可以适用于各种场景，即你需要处理海量文本、音频转录或其他或其他无法放入单个 LLM 上下文中的内容。

OpenAI

OpenAI 仍然是最受欢迎的 LLM 提供商之一，提供了适用于不同任务的各种能力水平的模型，包括 GPT-4 和 GPT-o1。LangChain 提供了与 OpenAI API 的无缝集成，支持其传统的补全模型（completion models）和聊天模型（chat models）。这些模型中的每一个都可以通过 LangChain 调用。

为了使用 OpenAI 模型，你首先需要获取一个 API 密钥。要获取 OpenAI API 密钥，请遵循以下步骤：

  1. 在 https://platform.openai.com/ 登录。
  2. 设置账单信息。
  3. 在个人密钥页面查看 API 密钥。
  4. 点击创建新的密钥。

获取密钥后，你应该在环境变量中设置 OPENAI_API_KEY。或者，在初始化类时也可以将密钥作为参数传递。

OpenAI 提供了一套全面的功能，与 LangChain 集成：

Hugging Face

Hugging Face 是自然语言处理（NLP）领域非常著名的参与者，提供了预训练模型、数据集和空间（spaces）。LangChain 与 Hugging Face 集成，允许你使用数以千计的模型。

要使用 Hugging Face，你需要一个 API 令牌。你可以通过 https://huggingface.co/ 创建账户并导航到设置来获取。一旦你有了令牌，请将其设置为环境变量 HUGGINGFACE_TOKEN。

LangChain 提供了多种与 Hugging Face 交互的方法，包括：

  • HuggingFacePipeline：用于本地运行模型。
  • HuggingFaceChat：用于与 Hugging Face 上的模型交互。
  • HuggingFaceEmbeddings：用于生成嵌入。

Google

Google 提供了两个主要平台来访问其 LLM，包括最新的 Gemini 模型：

1. Google AI

Google AI 平台为开发者和用户提供了简单的设置，并可以访问最新的 Gemini 模型。通过 Google AI 使用 Gemini 模型：

  • Google 账户：标准的 Google 账户即可进行身份验证。
  • API 密钥：生成 API 密钥进行身份验证。
    • 访问此页面创建 API 密钥：https://ai.google.dev/gemini-api/docs/api-key

获取 API 密钥后，在环境中设置 GOOGLE_API_KEY。

2. Google Cloud Vertex AI

对于企业级功能和集成，Google 的 Gemini 模型可以通过 Google Cloud Vertex AI 平台使用。通过 Vertex AI 使用模型：

  1. 创建 Google Cloud 账户，这需要接受服务条款并设置账单。
  2. 安装 gcloud CLI 以与 Google Cloud 服务交互。参考安装说明 https://cloud.google.com/sdk/docs/install。
  3. 运行以下命令进行身份验证并获取令牌：gcloud auth application-default login
  4. 确保你的 Google Cloud 项目已启用 Vertex AI API。
  5. 你可以设置 Google Cloud 项目 ID - 例如，使用 gcloud 命令：

`gcloud config set project my-project`

其他方法是在初始化 LLM 时传递构造函数参数、使用`aiplatform.init()`或设置 GCP 环境变量。

如果你尚未启用相关服务，你将收到一条实用的错误信息，引导你前往正确的网站，并在那里点击“启用”。你需要根据偏好和可用性启用 Vertex 或 Generative Language API。

LangChain 提供了与 Google 服务的集成，例如语言模型推理、嵌入、从不同源摄入数据、文档转换和翻译。

主要有两个集成包：

- `langchain-google-vertexai`

- `langchain-google-genai`

我们将使用`langchain-google-genai`，这是 LangChain 推荐给个人开发者使用的包。设置非常简单，只需要一个 Google 账号和 API 密钥。对于较大的项目，建议迁移到`langchain-google-vertexai`。该集成提供了企业级功能，如客户加密密钥、虚拟私有云集成等，需要开通计费的 Google Cloud 账户。

如果你遵循了上一节中提到的 GitHub 上的说明，你应该已经安装了`langchain-google-genai`包。

<https://github.com/OpenDocCN/freelearn-dl-zh/tree/master/docs/generative-ai-with-langchain-second-edition/img/b4e68161fea00e7befce1e978c814dda_725_0.png>

## 其他提供者

- **Replicate**: 你可以使用 GitHub 凭据在 https://replicate.com/ 上进行身份验证。然后点击左上角的用户图标，即可找到 API 令牌——只需复制 API 密钥并设置为环境变量`REPLICATE_API_TOKEN`。若要运行更大的任务，你需要设置信用卡（在计费下）。

- **Azure**: 通过 GitHub 或 Microsoft 凭据进行验证，我们可以在 https://azure.microsoft.com/ 创建 Azure 账户。我们可以在 **Cognitive Services | Azure OpenAI** 下创建新的 API 密钥。

- **Anthropic**: 你需要设置`ANTHROPIC_API_KEY`环境变量。请确保你已经在 https://console.anthropic.com/ 设置了计费并向控制台充值。

## 总结长视频

在*第 3 章*中，我们演示了如何使用 map-reduce（映射-还原）方法总结长视频（无法放入上下文窗口的视频）。我们使用 LangGraph 设计了这样的工作流。当然，你也可以将相同的方法用于类似的情况——例如总结长文本或从长音频中提取信息。现在让我们仅使用 LangChain 来同样的操作，因为这将是一次对我们有帮助的练习。

首先，`PromptTemplate`不支持媒体类型（截至 2025 年 2 月），因此我们需要手动将输入转换为消息列表。为了使用参数化链，作为替代方案，我们将创建一个 Python 函数，该函数接收参数（始终通过名称提供）并创建一个待处理的消息列表。每条消息都会指示 LLM 总结视频的某部分（通过偏移量间隔进行拆分），这些消息可以并行处理。输出将是一个字符串列表，每个字符串总结原始视频的一个子部分。

当你在 Python 函数声明中使用额外的星号（`*`）时，意味着星号之后的参数只能通过名称提供。例如，让我们创建一个带有许多参数的简单函数，我们可以在 Python 中通过仅传递少数（或不传递）参数以不同的方式调用它：

```python
def test(a: int, b: int = 2, c: int = 3):
    print(f"a={a}, b={b}, c={c}")
    pass

test(1, 2, 3)
test(1, 2, c=3)
test(1, b=2, c=3)
test(1, c=3)

但如果你更改了签名，第一次调用将抛错误：

def test(a: int, b: int = 2, *, c: int = 3):
    print(f"a={a}, b={b}, c={c}")
    pass

# 这样再不起作用了: test(1, 2, 3)

如果你查看 LangChain 的源码，可能会经常看到这种写法。这就是为什么我们决定详细解释一下它。

现在，回到我们的代码。如果我们想将video_uri作为输入参数，仍然需要运行两个独立的步骤。当然，我们可以将这些步骤封装成 Python 函数，但作为替代方案，我们将所有内容合并到一个链中：

from langchain_core.runnables import RunnableLambda

create_inputs_chain = RunnableLambda(lambda x:
    _create_input_messages(**x))

map_step_chain = create_inputs_chain |
    RunnableLambda(lambda x: map_chain.batch(x, config={"max_concurrency": 3}))

summaries = map_step_chain.invoke({"video_uri": video_uri})

现在，让我们所有提供的总结合并到一个单个提示中，并让 LLM 准备一份最终总结：

def merge_summaries(summaries: list[str], interval_secs: int = 600, **kwargs) -> str:
    sub_summaries = []
    for i, summary in enumerate(summaries):
        sub_summary = (
            f"Summary from sec {interval_secs} to sec {(i+1)*interval_secs}:",
            f"\n{summary}\n"
        )
        sub_summaries.append(sub_summary)
    return "".join(sub_summaries)

reduce_prompt = PromptTemplate.from_template(
    "你被给了一份分段视频总结列表。\nSUMMARIES:\n{summaries}\n基于此，请准备一份视频的最终总结。"
)

reduce_chain = (
    RunnableLambda(lambda x: merge_summaries(x["summaries"]))
    | reduce_prompt
    | llm
    | StrOutputParser()
)

final_summary = reduce_chain.invoke({"summaries": summaries})

  • 精通生成式 AI 和代理系统（agentic systems）的核心原理

  • 理解 AI 代理体如何在动态环境中运行、推理和适应

  • 使 AI 代理体能够分析自身的行为并进行现场发挥

  • 实现 AI 代理体可以利用外部工具并规划复杂任务的系统

  • 应用方法增强 AI 的透明度、问责性和可靠性

  • 探索 AI 代理体在各行业的真实世界实现

Packt 正在寻找像你这样的作者

如果你感兴趣成为 Packt 的作者，请访问 authors.packtpub.com 并立即申请。我们已经与成千上万像你这样的开发者和技术专业人员合作，帮助他们将见解分享给全球技术社区。您可以进行通用申请、申请我们正在招募作者的特定热门话题，或者提交自己的想法。

分享你的观点

现在你已经完成了《基于 LangChain 的生成式 AI》（第二版），我们非常想听听你的想法！如果你是从亚马逊购买的手本书，请点击此处直接进入该书的亚马逊评论页面 并分享你的反馈，或在购买书籍的网站上留下评论。

你的评论对我们以及技术社区至关重要，将帮助我们确保交付高质量的内容。

索引

A

  • 自适应系统 (adaptive systems)

    • 构建 248

    • 动态行为调整 (dynamic behavior adjustment) 248

    • 人机回 (human-in-the-loop) 248-250

  • 高级记忆机制 (advanced memory mechanisms) 411

  • 高级工具调用能力 (advanced tool-calling capabilities) 209, 210

  • 代理化 AI (agentic AI) 9

  • 代理化架构 (agentic architectures) 224-226

    • 模式 (patterns) 225, 226

  • 代理式 RAG 157

  • 代理内存 (agent memory) 266

    • 缓存 (cache) 263

    • 存储 (store) 264, 265

  • 代理体 (agents) 3, 216

    • 规划与解决代理 (plan-and-solve agent) 217-220

  • AI21 Labs Jurassic 30

  • AI 代理体 (AI agents) 11, 12

    • 考量 (considerations) 13

    • 重大挑战 (significant challenges) 12

Amazon Bedrock 31

Annoy 126

Anthropic

  • 引用链接 431

Anthropic Claude 30, 287-289

API key 设置 28-31

应用程序默认认证 (ADC) 28

应用程序接口 (APIs) 7

近似最近邻 (ANN) 126

通用人工智能 (AGI) 406

人工智能 (AI) 2

自动化评估方法 (automated evaluation methods) 320, 321

自主代理体 (autonomous agents) 410

Azure

  • 引用链接 431

Azure OpenAI Service 31

B

BERT 7

大科技公司 (Big tech)

  • 对比中小型企业 (versus small enterprises) 407, 408

BLOOM 429

LangChain 构建块 (building blocks, LangChain)

  • LangChain 表达式语言 (LCEL) 42-44

  • 模型接口 (model interfaces) 32

  • 提示词模板 (prompt templates) 40

  • 内置 LangChain 工具 (built-in LangChain tools) 192-198

C

  • 链链式提示词 (chaining prompt) 88, 89

  • 思维链 (CoT) 90-92

  • 对话历史 (chat history)

    • 修剪 (trimming) 97, 98

  • Chinchilla 缩放法则 (Chinchilla scaling law) 5

  • 分块策略 (chunking strategies) 132

    • 基于代理的分块 (agent-based chunking) 135

    • 特定于文档的分块 (document-specific chunking) 134

    • 固定大小分块 (fixed-size chunking) 132

    • 多模态分块 (multi-modal chunking) 136

    • 递归字符分块 (recursive character chunking) 133, 134

    • 选择 (selecting) 136, 137

    • 语义分块 (semantic chunking) 134, 135

  • Claude 7

  • 云提供商网关 (cloud provider gateways) 31

  • 代码模型 (code LLMs)

    • 基准测试 (benchmarks) 273, 274

    • 演变 (evolution) 271-273

  • 结合 LLM 的代码 (code, with LLMs)

    • 代理方法 (agentic approach) 289, 290

    • Anthropic Claude 287-289

    • 文档 RAG (documentation RAG) 290-292

    • Google 生成式 AI (Google generative AI) 282, 283

    • Hugging Face 284-287

    • 仓库 RAG (repository RAG) 293-295

    • 编写 (writing) 282

Cohere 模型 30

通信协议 (communication protocols) 231, 232

复杂集成应用 (complex integrated applications) 10

概念级建模 (concept-level modeling) 412

Conda 27

共识机制 (consensus mechanism) 229-231

上下文处理 (context processing) 145

  • 上下文压缩 (contextual compression) 145

  • 最大边界相关性 (MMR) 146

上下文窗口 (context window)

  • 使用 (working with) 93, 94

持续集成与持续交付 (CI/CD) 流水线 373

受控输出生成 (controlled output generation) 76

  • 错误处理 (error handling) 79-81

  • 输出解析 (output parsing) 76-79

企业文档聊天机器人 (corporate documentation chatbot)

  • 开发 (developing) 161, 162

  • 文档加载 (document loading) 162-165

  • 文档检索 (document retrieval) 166-168

  • 评估与性能考量 (evaluation and performance considerations) 177, 178

  • 与 Streamlit 集成 (integrating, with Streamlit) 174-176

  • 语言模型设置 (language model setup) 165, 166

  • 状态图设计 (state graph, designing) 168-173

企业文档管理器工具 (Corporate Documentation Manager tool) 161

纠错检索增强生成 (CRAG) 155, 156

自定义工具 (custom tools) 199

  • BaseTool 205, 206

  • 从 Runnable 创建 (creating from Runnable) 202-205

  • 函数工具 (function, as tool) 199

D

DALL-E 模型

  • 使用 OpenAI 55, 56

数据质量 (data quality)

  • 演变 (evolution) 412, 413

  • 技术进展 (via technical advances) 413, 414

DeepSeek 模型 30

依赖项 (dependencies)

  • 设置 (setting up) 26, 27

有向无环图 (DAG) 68

分布式方法 (distributed approach) 410, 411

Docker 27

文档 RAG (documentation RAG) 290-292

文档处理 RAG 流水线 (document processing, RAG pipeline)

  • 分块策略 (chunking strategies) 132

  • 检索 (retrieval) 137

  • 动态少样本提示词 (dynamic few-shot prompting) 89, 90

E

效率创新 (efficiency innovations) 410

  • 关键技术 (key techniques) 410

邮件提取 (email extraction)

  • 评估 (evaluating) 344-347

嵌入 (embeddings) 109, 114, 115

  • 挑战 (challenges) 115

  • 迁移搜索 (migrating to search) 113

错误处理 (error handling) 79-81, 206-209

  • 重试 (retries) 82, 83

  • 外部合作伙伴包 (external partner packages) 21

F

回退 (fallback) 84

Faiss 126

FastAPI

  • Web 框架部署 (for web framework) 354-358

少样本提示词 (few-shot prompting)

  • 对比零样本提示词 (versus zero-shot prompting) 87, 88

FizzBuzz 282

基础模型编排 (Foundational Model Orchestration, FOMO) 353

G

gcloud CLI

  • 安装 (installation) 430

Gemini 1.5 Pro

  • 使用 (using) 58-60

生成式 AI 应用 (generative AI applications)

  • 部署 (deploying) 353

生成式 AI 经济与行业转型 (generative AI economic and industry transformation) 415-417

  • 竞争动态 (competitive dynamics) 417, 418

  • 分布 (distribution) 419, 420

  • 公平考量 (equity considerations) 419, 420

  • 特定行业转型 (industry-specific transformations) 417, 418

  • 职业演变与技能影响 (job evolution and skills implications) 418

  • 局限 (limitations) 401

  • 对比人类认知 (versus human cognition) 403, 404

Google AI 平台 (Google AI platform) 430

Google Cloud Vertex AI (Google Cloud Vertex AI) 330

Google Colab (Google Colab) 26

Google Gemini (Google Gemini) 30

  • Google 生成式 AI (google generative AI) 282, 283

  • Google Vertex AI 31

  • GPT-4 7

    • 使用 (using) 61, 62

  • Gradient Notebooks (Gradient Notebooks) 26

  • 图配置 (graph configuration) 75, 76

  • 图 (graphs) 69

H

  • HF 数据集 (HF datasets and Evaluate)

    • 使用基准测试评估 (benchmark, evaluating with) 343

  • GPT-II 51

  • GPT-4 Vision

    • 使用 (using) 61-63

  • 分层可导航小世界网络 (Hierarchical Navigable Small World, HNSW) 121

  • hnswlib 226

  • Hugging Face 50, 284-287, 429

  • HuggingFace 推理终端 (HuggingFace Inference Endpoints) 31

  • 人类认知对比生成式 AI 模型 (human cognition versus generative AI models) 403, 404

  • 人机回 (Human-in-the-Loop, HIL) 232

    • 评估 (evaluation) 321

  • 混合检索 (hybrid retrieval)

    • 密集检索方法 (dense retrieval method) 140

    • 稀疏检索方法 (sparse retrieval method) 140

  • 假设文档嵌入 (Hypothetical Document Embeddings, HyDE) 144, 145

I

  • 图像理解 (image understanding) 58

    • Gemini 1.5 Pro, 使用 (using) 58-60

    • GPT-4 Vision, 使用 (using) 61-63

索引 (indexes)

  • 迁移检索系统 (migrating to retrieval systems) 108, 109

  • Inflection Pi 30

  • 基础设施即代码 (Infrastructure as Code, IaC) 378

  • LLM 基础设施考量 (infrastructure considerations, LLMs) 377, 378

    • 部署模型，选择 (deployment model, selecting) 378, 379

    • 模型服务基础设施 (model serving infrastructure) 380-382

J

  • 职业演变与技能影响 (job evolution and skills implications)

    • 长期转变 (long-term shifts, 2045 and beyond) 419

    • 中期影响 (medium-term impacts, 2035-2045) 418

    • 短期影响 (near-term impacts, 2025-3035) 418

K

  • Kaggle Notebooks 26

  • KM 缩放法则 (KM scaling law) 5

L

  • LangChain 14

    • 代理开发 (agent development) 16

    • 构建块 (building blocks) 32

    • 集成 (integrations) 281

    • 实现能力 (implementations capabilities) 274

    • 第三方应用 (third-party applications) 22, 23

    • 视觉化工具 (visual tools) 22, 23

LangChain 与数据集 (LangChain, with datasets)

  • 创建 pandas DataFrame (pandas DataFrame, creating) 301-303

  • 问答 (Q&A) 303-306

langchain-anthropic 20

LangChain 应用 (LangChain applications)

  • 成本管理 (cost management) 391

  • 模型选择策略 (model selection strategies) 391

  • 监控与成本分析 (monitoring and cost analysis) 395

  • 其他策略 (other strategies) 394

  • 输出 Token 优化 (output token optimization) 394

LangChain 架构 (LangChain architecture)

  • 优势 (advantages) 19

  • 核心结构 (core structure) 20

  • 生态系统 (ecosystem) 18

  • 探索 (exploring) 17

  • 库组织 (library organization) 20

  • 模块化设计与依赖管理 (modular design and dependency management) 19

langchain-core 20

langchain-experimental 20

LangChain 表达式语言 (LangChain Expression Language, LCEL) 16, 42-44

  • 复杂链示例 (complex chain example) 45-47

  • 工作流 (workflows) 44, 45

langchain-openai 20

LangChain 检索器 (LangChain retrievers)

  • 高级/专门检索器 (Advanced/Specialized Retrievers) 138

  • 算法检索器 (Algorithmic Retrievers) 138

  • 核心基础设施检索器 (Core Infrastructure Retrievers) 138

  • 外部知识检索器 (External Knowledge Retrievers) 138

  • 集成检索器 (Integration Retrievers) 138

LangGraph 21

  • 平台 (platform) 247, 370, 371

  • 流式模式 (streaming modes) 241-243

  • 工作流构建 (workflow building) 95-97

LangGraph 检查点 (LangGraph checkpoints) 101-103

LangGraph CLI

  • 用于本地开发的使用 (using, for local development) 371-373

LangGraph 基础 (LangGraph fundamentals) 68

  • 受控输出生成 (controlled output generation) 76

  • 图配置 (graph configuration) 75, 76

  • 减少器 (reducers) 73-75

  • 状态管理 (state management) 69-73

LangSmith 21, 387-389

  • 使用基准测试评估 (benchmark, evaluating with) 339-342

语言代理树搜索 (Language Agent Tree Search, LATS) 225

大语言模型 (large language model, LLM) 1

  • 复杂的集成化应用 10

  • 局限性 9, 14, 15

LATS 方法 261

Llama 2 8

Llama.cpp 51

LLM 代理评估

  • 最佳实践 323-335

  • 能力 316-320

  • 方法论与方法 320-323

  • 离线评估 336-347

用于数据科学的 LLM 代理

  • 应用 295-297

  • 数据集分析 301

  • ML 模型，训练 297

LLM 应用

  • 偏见检测与监控 387

  • 持续改进 390

  • 部署 353, 354

  • 幻觉检测 386

  • 可观测性策略 389

  • 观察 382

  • 运行指标 383

  • 响应跟踪 384-386

  • 安全考量 350-352

LLM 应用部署

  • LangChain 应用的考量 365-370

  • 基础设施考量 377, 378

  • LangGraph 平台 370, 371

  • 模型上下文协议 (MCP) 375-377

  • 使用 Ray Serve 进行可扩展部署 358

  • 无服务器部署选项 374

  • UI 框架 375

  • 使用 FastAPI 进行 Web 框架部署 354-358

LLM 评估

  • 构建共识 315, 316

  • 性能与效率 312, 313

  • 安全与对齐 311, 312

  • 显著性 310, 311

  • 用户与利益者价值 313-315

LLM 家族 30

LLM 生成的代码

  • 验证框架 279-281

LLMOps 353, 378

软件开发中的 LLM 268

  • 代码 LLM 基准测试 273, 274

  • 代码 LLM 演进 271-273

  • 实现考量 269-271

  • 工程方法 274-277

  • 开发的未来 269

  • LangChain 集成 281

  • 安全与风险缓解 277-279

本地模型

  • Hugging Face 模型 50, 51

  • Ollama 49

  • 运行 48

  • 使用 51-54

长期记忆 262

长视频

  • 总结 432-434

M

Map 方法 94

最大边缘相关性 (MMR) 140

MCP 客户端 375

MCP 服务 375

记忆 2

记忆机制 97

  • 聊天历史，保存到数据库 99-101

  • 聊天历史，修剪 97, 98

  • LangGraph 检查点 101-103

Miniconda

  • 下载链接 26

Mistral 模型 30

Mixtral 7

ML 模型

  • 代理，请求构建神经网络 298

  • 代理执行与结果 299-301

  • 支持 Python 的代理，设置 297

MLOps 353

模型上下文协议 (MCP) 375

LangChain 模型接口 32

  • 聊天模型，使用 34, 35

  • 开发测试 33

  • LLM 交互模式 32, 33

  • 模型行为，控制 38, 39

  • 应用的参数选择 40

  • 推理模型 36-38

模型许可证

  • 引用链接 8

模型开放框架 (MOF) 63

模型缩放法则

  • Chinchilla 缩放法则 5

  • KM 缩放法则 5

模型选择策略，LangChain 391

  • 级联模型 393, 394

  • 分层模型选择 391-393

现代 LLM 现状 2-4

  • 许可 7, 8

  • LLM 供应商 6, 7

  • 模型比较 4-6

蒙特卡洛树搜索 (MCTS) 411

  • 用于修剪 ToT 261, 262

多代理架构 227

  • 通信协议 231-241

  • 通过共享消息列表 245-247

  • 共识机制 229-231

  • 交接 (handoffs) 243, 244

  • LangGraph 平台 247

  • LangGraph 流式处理 241-243

  • 角色与专业化 228, 229

多模态 AI 应用 54

  • 图像理解 58

  • 文本图像 55

多模态扩散 (MMDiT) 57

N

注意力模型 (NAMs) 411

非度空间库 (nmsib) 127

O

  • Ollama 49

  • OpenAI 427, 428

    • 引用链接 428

OPENAI_API_KEY 28

OpenAI GPT-4o 30

LLM 应用的运行指标

  • 可见性 383

  • 延迟维度 383

  • Token 经济 383

  • 工具使用 383

输出修复器

  • 引用链接 84

输出解析 76-79

P

  • 困惑度模型 30

  • 规划解决代理 217-220

产品量化 (PQ) 126

提示词工程 40, 85

  • 思维链 (CoT) 90-92

  • 少样本提示 (few-shot) 87

  • 提示词模板 85-87

  • 自一致性 92, 93

  • 零样本提示 (zero-shot) 87

  • 提示词模板 40, 41, 85

    • 聊天提示词模板 41

R

RAG 架构

  • 代理方法 226, 227

RAG 落地模型 411

RAG 流水线

  • 高级技术 140

  • 组件 127-129

  • 文档处理 130-132

  • 增强器 110

    • 组件 110-112

  • 评估 336-338

    • 评估 317, 318

  • 生成器 110

  • 知识库 110

  • 检索器 110

  • 故障排除 178, 179

RAG 技术

  • 代理 RAG 157

  • 上下文处理 145

  • 修正 RAG 155

  • 混合检索 140

  • 查询转换 143, 144

  • 重排序 141, 142

  • 响应增强 146

  • 选择 158-160

Ray Serve

  • 用于可扩展部署 358

ReACT 188-191

推理模型 92

推理路径

  • 探索 250

  • 思维链 (ToT) 技术 250-261

  • 使用 MCTS 修剪 261-262

减少方法 94

还原器 73-75

人类反馈强化学习 (RLHF) 3

Replicate 31

  • 引用链接 431

仓库 RAG 293-295

重排序

  • 列表重排序器 142

  • 成对重排序器 141

  • 点重排序器 141

重排序实现

  • Cohere 重排序 142

  • 基于 LLM 的自定义重排序 143

  • RankLLM 142

响应增强技术 164

  • 自一致性检查 150-154

  • 来源归属 147-150

  • 重试 82, 83

检索器

  • LangChain 检索器 138

  • 遵循的模式 137

  • 向量存储检索器 139, 140

S

使用 Ray Serve 进行可扩展部署 358

  • 应用运行 363-365

  • 索引构建 359-361

  • 索引服务 361-363

缩放方法 409

  • 训练阶段缩放法则 415

  • 缩放局限性 406

    • 大科技公司对比小企业 407, 408

    • 数据质量训练 412, 413

    • 通过技术进步民主化 413, 414

    • 假设挑战 406

    • 训练阶段缩放法则 415

缩放局限性，替代方法

  • 分布式方法 410, 411

  • 效率创新方法 410

  • 传统方法 409

自一致性 92, 93

小企业

  • 对比大科技公司 407, 408

小语言模型 (SLMs) 4

代码片段 108

社会影响 420

  • 版权与归属挑战 422

  • 错误信息与网络安全 421

  • 监管与实施挑战 423

SPTAG 127

Stable Diffusion

  • 使用 57

状态管理 69-73

结构化生成生成 84

填充方法 (stuff approach) 93

超步 72

系统级评估

  • 最佳实践 322, 323

T

测试时计算 410

文本嵌入推理 (TEI) 429

文本到图像应用 55

  • 通过 OpenAI 使用 DALL-E 55, 56

  • 使用 Stable Diffusion 57

心理理论 (ToM) 404

每个输出 Token 时间 (TPOT) 383

首 Token 延迟 (TTFT) 383

Together AI 31

工具 2

  • 内置 LangChain 工具 192-199

  • 自定义工具 199

  • 定义 192

  • 错误处理 206-209

  • 使用 LangChain 185-187

工具，整合到工作流

  • 控制生成 210, 211

  • 供应商提供的控制生成 212, 213

  • 工具调用范式 214, 215

  • ToolNode 213

传统方法

  • 组件 409

传统数据库搜索

思维链 (ToT) 模式 223, 250-261

  • 使用 MCTS 修剪 261, 262

TypedDict 69

U

UI 框架

  • Chainlit 375

  • Gradio 375

  • Mesop 375

  • Streamlit 375

通用句子编码器 (USE) 320

V

向量索引

  • 策略 121-127

向量存储检索器

  • 数据库检索器 139

  • 词法检索器 139

  • API 检索器 139

向量存储 115, 116

  • 比较 117, 118

  • 嵌入 118

  • 硬件考量 119

  • LangChain 中的接口 119, 120

  • 模式 118

视觉中心增强 412

Z

零样本提示 85-87

  • 对比少样本提示 87, 88

下载本书的免费 PDF 副本

感谢购买本书！

你是否喜欢在旅途中阅读，但无法随身携带纸质书？

你购买的电子书是否兼容你选择的设备？

别担心，现在购买每本 Packt 书籍，都可以免费获得该书的无 DRM PDF 版本。

  1. 提交您的购买证明。

  2. 大功完成！我们将直接将免费 PDF 及其他福利发送到您的邮箱。

与 Packt 的生成式 AI 社区保持联系

如需获取有关 AI 最新趋势、工具和突破的每周更新，请订阅 AI_Distilled——这是 AI 专业人士、研究人员和创新者的首选通讯邮件，订阅地址：AI_Distilled。如果您对此书有任何疑问，或想深入研究生成式 AI 和大语言模型（LLMs），欢迎加入我们的 Discord 服务器参与讨论： https://packt.link/4Bbd9 ，读者、爱好者和专家均可以在那里交流想法和见解。

| 通讯邮件二维码 | Discord 二维码 |

| --- | --- |

| ![QR Code 1] | ![QR Code 2] |

posted @ 2026-09-25 20:42  绝不原创的飞龙  阅读(4)  评论(0)    收藏  举报