大语言模型交互中的认知疲劳与能耗问题

基本信息

作者: tjohnell
评分: 212
评论数: 149
链接: https://tomjohnell.com/llms-can-be-absolutely-exhausting
HN 讨论: https://news.ycombinator.com/item?id=47391803

导语

随着大语言模型（LLMs）在各类应用中的普及，其高昂的推理成本与延迟问题正逐渐成为制约技术落地的瓶颈。本文深入探讨了导致模型“疲惫”的计算瓶颈与资源消耗现状，分析了这对工程实践的具体影响。通过阅读此文，读者可以了解当前模型性能的边界，并获取关于优化推理效率与降低部署成本的实用视角。

深度评论

中心观点

大语言模型（LLM）在降低信息获取门槛的同时，通过引入高熵的输出、高昂的验证成本以及认知幻觉，正在创造一种新型的“认知税”。这种机制导致用户在长期交互中产生深层的精神耗竭，即“AI疲劳”。

支撑理由与边界条件

1. 支撑理由

高熵输出引发认知过载
- [事实陈述] LLM基于概率生成文本，倾向于输出冗长、啰嗦且包含大量“填充词”的内容。
- [作者观点] 相比于传统搜索引擎的精确链接或确定性代码的返回，用户必须投入额外的执行功能，从非结构化的文本流中提炼核心信息。这种“信息淘洗”过程消耗了大量脑力。
- [你的推断] 这类似于将“阅读说明书”变成了“听一位口若悬河但抓不住重点的推销员”。大脑为了抑制无关干扰，前额叶皮层负荷增加，从而加速了疲劳感的产生。
幻觉导致双倍认知成本
- [事实陈述] LLM存在“幻觉”现象，即生成看似合理但完全错误的信息。
- [作者观点] 为了确保输出的准确性，用户被迫保持“认知警觉”，对每一个生成的细节进行事实核查。这种“永远不能完全信任”的状态，使大脑始终处于高耗能的监控模式，而非放松的接收模式。
- [你的推断] 这解释了为何使用AI辅助编程有时比直接手写更累。Debug AI生成的逻辑错误，往往比直接编写逻辑需要更复杂的上下文切换和验证工作。
决策外包导致思维肌肉萎缩
- [作者观点] 过度依赖LLM进行摘要、判断和决策，本质上是一种“认知卸载”。长期来看，这会导致用户自身的批判性思维能力和深度思考能力退化，产生一种“智力空虚感”及随之而来的焦虑。
- [你的推断] 这种深层的心理负担和对自身能力丧失的担忧，是造成“exhausting”（精疲力竭）的根本原因，超越了单纯的视觉疲劳。

2. 反例与边界条件

反例一：创造性头脑风暴
- [你的推断] 在需要发散性思维而非收敛性思维的场景下（如构思小说情节、营销文案），LLM的高熵输出是一种优势。此时用户追求的是灵感的广度而非精确度，验证成本极低，因此不会感到疲惫。
反例二：高度结构化的任务
- [事实陈述] 当LLM被严格限制输出格式（如JSON、SQL）或用于底层API调用时，其语言上的冗余性被屏蔽。
- [你的推断] 在这些“无头”模式下，LLM表现为高效的功能性工具，用户感知到的主要是生产力的提升，而非交互上的磨损。

深度评价（7个维度）

1. 内容深度

[评价] 文章触及了人机交互（HCI）中常被忽视的“认知负荷”维度。它跳出了单纯追求模型参数规模的技术崇拜，转而从用户体验的微观心理学角度切入。论证较为严谨，特别是关于“验证成本 > 生成收益”的边际效应分析，具有很强的逻辑支撑。不足之处在于观点略显主观，缺乏脑科学或眼动追踪等生理数据的实证支持。

2. 实用价值

[评价] 具有极高的警示价值。对于开发者而言，它提示产品优化不应只关注模型的“流畅度”，更应关注输出的“信噪比”。对于知识工作者，文章建议应将AI视为“初稿生成器”而非“最终决策者”，以此规避无休止的校对循环，这对提升实际工作效率有直接指导意义。

3. 创新性

[评价] 文章提出了“AI疲劳”并非源于技术复杂性，而是源于概率性交互模式的本质。将“信任成本”引入AI效能评估公式是一个较新的视角，有力挑战了传统以“Token吞吐量”或“延迟”为唯一效率指标的行业标准。

4. 可读性

[评价] 文章通常文笔流畅，善用类比（如“喝盐水解渴”）来阐述复杂概念，逻辑结构清晰。能够引起技术从业者的强烈共鸣。但在区分“生理疲劳”与“心理疲劳”的界限时，论述稍显模糊，可能影响读者对核心论点的精准把握。

5. 行业影响

[评价] 该观点可能会推动AI交互设计的范式转移。未来的AI产品可能会更倾向于提供“引用来源”以降低信任成本，或者开发“简洁模式”以减少认知过载。这将促使行业从单纯的“模型能力竞赛”转向“用户体验效能竞赛”。

6. 逻辑严密性

[评价] 内部逻辑链条完整，从现象（啰嗦、幻觉）推导至机制（认知负荷、信任成本），再上升至后果（精神耗竭、能力退化）。但在归因上，将“疲惫”完全归咎于LLM的特性，可能忽略了用户本身使用习惯不当（如过度依赖）这一变量，逻辑闭环上存在一定的外溢。

7. 数据与证据

[评价] 文章多基于定性分析和经验观察，缺乏定量数据的支撑。例如，若能提供“使用LLM编写代码与手写代码在皮质醇水平或眼动疲劳度上的对比数据”，其说服力将呈指数级增长。目前的论证更多依赖于逻辑自

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 示例1：自动生成会议摘要
def generate_meeting_summary(transcript):
    """
    从会议记录中自动生成摘要
    :param transcript: 会议记录文本
    :return: 摘要文本
    """
    # 这里模拟LLM处理过程，实际应用中会调用真实LLM API
    summary = f"会议摘要：\n{transcript[:100]}..."  # 简单截取前100字作为示例
    return summary

# 测试代码
meeting_text = "今天讨论了项目进度，前端开发完成80%，后端API已全部完成。下周开始集成测试。"
print(generate_meeting_summary(meeting_text))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
# 示例2：智能客服回复生成
def generate_customer_response(query):
    """
    根据客户查询自动生成回复
    :param query: 客户问题
    :return: 建议的回复文本
    """
    # 模拟LLM生成回复
    if "退款" in query:
        return "关于退款问题，您可以在订单页面点击申请退款，我们会在3个工作日内处理。"
    elif "发货" in query:
        return "您的订单已发货，预计3-5天送达，快递单号是123456789。"
    else:
        return "感谢您的咨询，我们的客服人员会在24小时内联系您。"

# 测试代码
customer_question = "我想退款，请问怎么操作？"
print(generate_customer_response(customer_question))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 示例3：代码注释自动生成
def generate_code_comments(code):
    """
    为代码自动生成注释
    :param code: 源代码
    :return: 带注释的代码
    """
    # 模拟LLM添加注释
    commented_code = f"# 这个函数实现了{code.split('(')[0]}功能\n{code}"
    return commented_code

# 测试代码
sample_code = "def calculate_sum(a, b):\n    return a + b"
print(generate_code_comments(sample_code))

案例研究

1：Klarna（瑞典金融科技公司）

背景:
Klarna 是一家欧洲领先的“先买后付”金融科技服务商，拥有庞大的全球客户基础。其客服团队每天需要处理海量的咨询，包括支付查询、退款请求和账户管理等重复性高的问题。

问题:
随着业务扩张，客服成本急剧上升，且人工客服在处理大量重复性问题时容易出现疲劳，导致响应时间变长，客户满意度下降。单纯依靠增加人力不仅成本高昂，而且管理和培训新员工的周期长。

解决方案:
Klarna 集成了基于 GPT-4 大型语言模型（LLM）的 AI 客服助手。该系统并非简单替换人工，而是通过处理大量重复性、标准化的查询来辅助人工。AI 能够直接访问 Klarna 的知识库，用 35 种语言与客户进行自然、流畅的对话，并在必要时无缝转接给人工坐席。

效果:
在上线一个月内，该 AI 助手直接处理了 230 万次对话（占总咨询量的三分之二），相当于 700 名全职人工客服的工作量。此举预计每年将为 Klarna 节省 4000 万美元的成本。同时，客户的解决时间从 11 分钟缩短至 2 分钟，且客户满意度与人工服务持平，有效解决了人力疲劳和效率瓶颈问题。

2：MosaicML（Databricks 旗下企业）

背景:
MosaicML 是一家专注于大模型训练和推理优化的公司（后被 Databricks 收购）。其核心业务是为企业提供高效构建和部署 LLM 的能力。

问题:
在推广 LLM 技术时，企业客户面临严重的“模型幻觉”和“不可预测性”问题。通用的 LLM（如未经微调的 GPT-3.5）往往会在特定领域生成看似合理但完全错误的信息，导致企业不敢将其用于关键业务流程（如法律合同审查或医疗咨询）。

解决方案:
MosaicML 推出了 MPT 系列开源模型及相应的微调工具链。他们不再仅依赖通用模型，而是帮助企业利用私有数据对基础模型进行微调。通过特定的训练技术（如 ALiBi 位置编码和 FlashAttention），他们让模型在保持高性能的同时，能够更精准地遵循指令并减少幻觉。

效果:
这一方案使得企业能够部署“懂行”的 LLM。例如，某医疗机构利用其方案微调后的模型，在处理病历时不仅准确率大幅提升，还避免了通用模型常见的胡编乱造现象。这证明了通过技术手段驯化 LLM，可以将其从“令人疲惫的不可靠工具”转变为“高效、精准的垂直领域助手”。

3：Rippling（企业 IT 管理平台）

背景:
Rippling 是一家快速增长的独角兽企业，提供员工管理、薪资和 IT 设备管理的一体化系统。随着公司规模扩大，内部开发团队面临着巨大的代码编写和维护压力。

问题:
开发人员将大量时间花费在编写重复性的样板代码、单元测试以及调试旧代码上。这种机械性的劳动导致工程师职业倦怠，且拖慢了新功能的上线速度。虽然市场上已有 GitHub Copilot 等工具，但在处理 Rippling 特有的复杂内部框架时，通用工具往往给出的建议不够精准。

解决方案:
Rippling 并没有直接使用通用的 LLM，而是利用其内部积累的数百万行高质量代码库，构建了一个内部定制的 AI 编程助手。这个助手基于 LLM，但经过了 Rippling 特定代码风格的微调，专门用于辅助生成符合公司规范的代码、自动生成测试用例以及重构遗留代码。

效果:
该定制化工具显著提升了开发效率，工程师在编写单元测试等枯燥任务上的耗时大幅减少，且代码质量更加统一。通过让 AI 接手“脏活累活”，开发团队能够将精力集中在架构设计和核心业务逻辑上，有效缓解了技术团队因重复劳动产生的疲惫感，加速了产品迭代周期。

最佳实践

最佳实践指南

实践 1：明确任务目标与范围

说明: 在使用 LLM 之前，必须清晰定义你希望模型完成的具体任务。模糊的指令会导致模型产生幻觉或生成无关内容，增加后续筛选和修正的工作量。明确的范围能防止模型过度发散。

实施步骤:

在提问前，先用一句话写下你期望的最终输出结果。
列出任务必须包含的关键要素和绝对不能触碰的红线。
将任务背景信息（如受众、用途）作为上下文提供给模型。

注意事项: 避免使用“帮我写一篇文章”这样宽泛的指令，而应使用“为技术新手写一篇关于 Docker 基础的 500 字教程”。

实践 2：采用结构化提示词工程

说明: 结构化的提示词能显著提高模型的响应质量和一致性。通过设定角色、任务、约束和输出格式，可以减少模型产生“废话”的概率，直接获取可用内容，从而降低反复调试的疲劳感。

实施步骤:

定义角色：例如“你是一位资深的产品经理”。
描述任务：具体需要完成什么工作。
设置约束：规定字数、语言风格、必须包含的要点。
指定格式：要求输出 Markdown、JSON 或表格形式。

注意事项: 即使是简单的追问，也应保持上下文的连贯性，避免让模型猜测你的意图。

实践 3：建立迭代式验证机制

说明: 不要试图一次性让 LLM 生成完美的最终产品。将大任务拆解为小步骤，每一步都进行人工验证。这种“小步快跑”的方式能及时纠正偏差，避免在错误的方向上浪费大量精力。

实施步骤:

将复杂任务拆分为大纲、草稿、润色三个阶段。
先让模型生成大纲，确认逻辑通顺后再生成具体内容。
每次生成后，快速检查核心事实和逻辑漏洞，并在下一轮对话中修正。

注意事项: 对于代码或事实性查询，必须进行人工复核，LLM 可能会自信地输出错误信息。

实践 4：将 LLM 作为副驾驶而非全权代理

说明: 过度依赖 LLM 会导致思维惰性和技能退化。最佳实践是将 LLM 视为辅助工具，用于头脑风暴、润色或生成初稿，而核心的决策、创意整合和最终审核必须由人类完成。

实施步骤:

在遇到瓶颈时使用 LLM 生成多个备选方案。
利用 LLM 改写措辞或总结长文本，节省阅读时间。
始终保留对最终产出的修改权和否决权。

注意事项: 不要让 LLM 替代你进行批判性思考，它的输出应作为参考而非教条。

实践 5：管理认知负荷与使用边界

说明: 频繁地与 LLM 交互和筛选大量生成内容会造成认知疲劳。设定明确的使用边界和休息机制，能保持高效率并减少因信息过载带来的疲惫感。

实施步骤:

设定单次交互的时间限制（如 20 分钟），避免陷入无休止的调优。
对于重复性任务，编写脚本或使用 API 批量处理，而非手动复制粘贴。
当模型输出质量明显下降时，暂停使用，稍后再试或重新组织 Prompt。

注意事项: 如果发现自己在反复纠缠于同一个细节无法推进，应果断停止，寻求其他解决方案或人工介入。

实践 6：构建个人知识库与提示词模板

说明: 重复编写相似的提示词是造成疲惫的主要原因之一。建立可复用的提示词模板库，不仅能提高效率，还能减少每次启动任务时的脑力消耗。

实施步骤:

将过去验证有效的提示词分类保存（如“代码重构”、“邮件撰写”、“文案润色”）。
为常用任务创建标准化的“元提示词”，只需填入变量即可使用。
定期回顾并更新模板库，剔除低效的旧模板。

注意事项: 模板应保持一定的灵活性，以便根据具体场景快速微调，避免僵化。

学习要点

基于您提供的标题和来源（Hacker News 讨论 “LLMs can be exhausting”），以下是关于大语言模型（LLM）局限性及用户疲劳感的 5 个关键要点总结：
大语言模型在处理复杂任务时往往需要极高的人力和认知成本进行反复提示与纠错，这种“认知税”可能超过了其带来的效率提升。
模型倾向于产生“幻觉”或自信地编造事实，导致用户必须花费大量精力去验证其输出的每一处细节。
LLM 的输出具有高度的不确定性，同样的提示词可能产生截然不同的结果，使得调试和工程化变得极其困难。
在需要精确性或逻辑严密性的工作流中，盲目依赖 LLM 可能会导致整体工作质量的下降而非提升。
用户在与 LLM 交互时容易产生“交互疲劳”，因为维持对话语境并引导模型走向正确答案需要持续的专注力。

常见问题

1: 为什么说大语言模型（LLM）会让使用者感到“精疲力竭”？

A: 这种疲惫感主要源于认知负荷的增加。虽然 LLM 能生成文本，但用户必须时刻保持高度警惕，扮演“编辑”和“审核者”的角色。用户需要不断地验证模型输出的事实准确性，检查逻辑漏洞，并修正细微的错误。这种持续的“人机博弈”和纠错过程，往往比直接从头开始撰写或解决问题更消耗精力，导致心理上的倦怠。

2: 既然 AI 能提高效率，为什么使用它反而会觉得累？

A: 效率的提升主要体现在执行层面，而非决策层面。使用 LLM 时，用户需要投入大量精力在“提示工程”上，即如何精确地向机器描述意图、设定上下文和约束条件。此外，AI 生成的内容往往缺乏个性或存在“幻觉”，用户仍需进行深度的二次加工。当工具的使用成本（学习、调试、纠错）超过了其带来的便利时，用户就会感到心累。

3: 什么是与大语言模型交互时的“认知税”？

A: 这里的“认知税”指的是为了获得高质量输出而必须付出的额外脑力劳动。用户不仅要具备原本任务所需的专业知识，还需要掌握如何与 AI 沟通的技巧。例如，用户需要预判 AI 可能会犯什么错，并在提示词中提前规避。这种“不仅要懂业务，还要懂模型逻辑”的双重负担，就是使用 LLM 所必须支付的隐性认知成本。

4: LLM 的“幻觉”问题是如何导致用户疲劳的？

A: “幻觉”指模型一本正经地胡说八道。这对用户的信任度是极大的打击。为了确保信息的准确性，用户不敢直接使用模型生成的代码、数据或引用，必须逐行、逐句地进行核实。这种被迫产生的怀疑态度和繁琐的验证工作，将原本轻松的阅读或创作过程变成了高强度的审查工作，从而产生强烈的疲劳感。

5: 面对这种“LLM 疲劳”，有什么应对策略吗？

A: 首先要调整预期，将 LLM 视为“副驾驶”或“头脑风暴伙伴”，而非全能的替代者。其次，建立标准化的提示词库和工作流，减少每次交互时的重复思考。最后，学会“断连”，在不需要高度精确或创造力的场景下，不要强迫使用 AI，回归传统工具以减轻认知负担。

6: 这种技术带来的疲惫感是暂时的吗？

A: 目前来看，这可能是一个长期存在的适应期问题。虽然模型技术会不断迭代进步，降低使用门槛，但随着 AI 能力的增强，人类处理信息的标准也在提高。我们可能会逐渐习惯这种“人机协作”的模式，疲劳感可能会从“如何使用”转变为“如何筛选海量信息”。因此，学会管理注意力和设定工具边界将是长期课题。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**:

在处理 LLM 返回的流式数据时，如何实现一个简单的"打字机效果"（即逐字显示回复），并确保在数据流结束时能正确处理连接状态，避免内存泄漏或界面卡顿？

提示**:

引用

原文链接: https://tomjohnell.com/llms-can-be-absolutely-exhausting
HN 讨论: https://news.ycombinator.com/item?id=47391803

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

分类：大模型 / 效率与方法论
标签： LLM / 认知疲劳 / 能耗 / 人机交互 / 用户体验 / 心理学 / AI疲劳 / 交互设计
场景：大语言模型 / AI/ML项目

LLM生成内容导致用户认知负荷过重
LLM 应用中的认知负荷与用户疲劳问题研究
LLM的高认知负荷与用户疲劳机制分析
LLM驱动的VR导览系统如何帮助视障用户实现无障碍体验
大语言模型导览如何帮助视障群体使用虚拟现实 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

大语言模型交互中的认知疲劳与能耗问题