AI不炒作：使用LLMs降低噪声，而非取代思考

Source: Dev.to

第4部分 – AI & AppReviews

This is part 4 of my series on AppReviews.

• 第1部分: From “I should check the reviews” to a SaaS
• 第2部分: From feature creep to focus – deciding what AppReviews would never be
• 第3部分: Building AppReviews – the stack, the choices, and the compromises

可视化

从“仅获取评论”到“让 AI 帮我看全局”

在构建 AppReviews 的过程中，我某个时刻开始思考 AI——不是以一种*“这必须要用 AI”*的方式，而是以一种安静、稍带犹豫的方式。

我已经有一个系统可以抓取评论、推送到 Slack，并确保反馈不会被遗漏。仅此就解决了核心问题。但当评论始终可见时，会出现新的问题。

它们数量庞大。

• 有些很有用。
• 有些模糊不清。
• 有些情绪化。
• 有些是同一问题的重复，只是表述略有不同。

阅读每一条评论是可行的——但只能到一定程度。之后，你又回到浏览、略读，并在脑中筛选噪音的状态。

这时我开始自问一个不同的 问题：

如果系统能帮助我更快地理解评论，而不是假装替我思考，会怎样？

我 不 想要的

在加入任何与 AI 相关的内容之前，我已经非常明确地说明了我 不 想要构建的东西。

• 伪装成洞察的 AI 生成摘要
• 没有解释的神奇评分
• 代表我回答用户的聊天机器人
• 另一套看起来很智能但并不能帮助决策的图表仪表盘

最重要的是，我 不 想让 AI 成为产品本身。

AppReviews 的存在是为了缩短用户与产品团队之间的反馈循环。AI 应该支持这一目标，而不是分散注意力。

如果 AI 没有以非常具体的方式降低认知负荷，它就不该出现。

AI 能帮助的实际问题

真正的问题并不是理解 单个 评论。
而是理解 随时间推移的众多评论。

当十位用户用十种不同的方式描述同一问题时，人类在阅读完全部十条后能够很好地看到模式。但当评论不断涌入时，这种方式就难以扩展。

我想要的帮助是：

• 将相似的反馈进行分组
• 发现重复出现的话题
• 粗略了解情感趋势
• 当某事突然激增时突出其紧迫性

不是答案——信号。

为什么先使用 embeddings，而不是到处使用 prompts

我添加的第一个构建块是 embeddings。

每条评论都可以转化为一个捕捉其含义的向量。一旦拥有了这些向量，就可以在语义层面比较评论，而不必依赖关键词或星级评分。

这立刻解锁了许多有用的功能：

• 相似的评论可以被归为一组
• 主题会自然浮现，而不是预先定义
• 你可以检测到“这似乎是同一个问题再次出现”

对于 embeddings，我使用 nomic-embed-text —— 速度快、可以本地运行，且足以满足此用例。每条评论都会生成一个 768 维向量，并与原始文本一起存储。

仅此一步就已经带来了价值，即使没有大型语言模型生成文本也是如此。

LLM 在何处发挥作用，谨慎说明

在嵌入的基础上，我添加了第二层 可选 的大语言模型。

我使用的模型是 llama3.1:8b，通过 Ollama 本地运行。这是有意的选择：

• 没有每 token 成本的顾虑
• 没有外部 API 依赖
• 可以在我的机器或小型服务器上运行

LLM 用于非常具体的任务：

• 估计情感倾向
• 提取高层主题
• 检测语气（愤怒、中性、积极）
• 在相关时标记紧急程度

每条评论 独立 处理。

• 没有长上下文
• 没有代理
• 没有编排复杂性

最重要的是：

整个流程都是可选的。

如果 AI 处理器被禁用或不可用，AppReviews 的工作方式完全相同：仍会抓取评论、存储、发送到 Slack，并在仪表盘中可见。AI 只是一个增强功能，而非依赖。

异步、隔离且易于关闭

1. 首先保存评论。
2. 然后才将它们排入分析队列。
3. 处理以异步方式进行，分小批次。
4. 失败会重试几次，然后被丢弃。

AI 系统会以奇怪的方式失败。任何这些都不应影响产品的核心功能。

为什么不使用 “AI‑生成的洞察”

这可能是我最常被问到的问题。

为什么不生成诸如“用户对入职流程不满意”或“多数投诉集中在性能上”的摘要？

简短的答案很直接：

我不信任它们。

这些摘要看起来很漂亮，却隐藏了不确定性。它们把细微差别压缩成一种看似权威的表述——即使实际上并非如此。

相反，AppReviews 展示的是原始信号：

• 这些评论相似
• 这个话题经常出现
• 情感 …

上周此功能已下线

从那里，人类可以决定它的意义。

AI 应该帮助你看到该去哪里寻找，而不是告诉你该怎么想。

成本、控制与乏味的决策

在本地使用 Ollama 运行所有内容并不是最具可扩展性的选择，但它完全符合约束条件。

• 没有可变成本
• 没有意外情况
• 没有需要轮换的 API 密钥
• 没有将用户反馈发送到其他地方的隐私问题

如果 AppReviews 规模扩大，切换 AI 后端相对容易——接口已经被隔离。

目前，这种设置是可预测且可控的。这比挤出最后一点点准确率更重要。

AI 故意不做的事

为了非常明确，AppReviews 不：

• 自动回复评论
• 决定哪些反馈重要
• 替代阅读评论
• 预测用户行为
• 生成产品决策

AI 不：

• 与用户交谈
• 代表他们行动
• 覆盖人类判断

它只是减少重复，并帮助模式更快显现。

到目前为止的结果

在实际操作中，这种方法出奇地有效。

• 你仍然阅读评论。
• 你仍然自行回复。
• 你仍然做出决策。

但你在更多上下文和更少噪音的情况下完成这些工作。

这也是我唯一能够放心承诺的。

1. 从人类工作流开始。
2. 找出注意力浪费的地方。
3. 然后看看 AI 能否帮助减少这些浪费。