TIDE: 通过模板引导迭代的主动多问题发现

TL;DR TIDE 通过模板引导的迭代发现机制，让 LLM 智能体从上下文主动挖掘多个隐藏问题并给出行动方案，显著提升覆盖率和识别精度。

问题

问题背景

LLM agents 作为数字助理被广泛部署于文档、工具与代码环境，但通常仅响应用户的显式请求，导致大量存在于上下文中的隐藏问题（总数未知）被忽略，这些未被察觉的问题可能严重影响工作效率与系统可靠性。

现有方法的局限

• 单次推理 (single-shot)：模型倾向于锚定最显著的问题，生成笼统的声明，无法覆盖分布零散、数量不确定的隐藏问题，遗漏率极高。
• 并行多 Agent：虽可扩大搜索范围，但缺乏协调机制，不同 Agent 容易发现重复问题或产生冲突，无法系统化地收敛到完整问题集，且计算成本随 Agent 数量线性增长。 两类方法均未能有效平衡覆盖度 (coverage) 与精确性，且无法利用已发现的信息引导后续探索，导致问题发现停留在表面。

为何重要且困难

主动发现问题能力是 agent 从被动工具进化为预见性助手的关键。技术上存在三大挑战：

1. 未知数量：上下文内隐藏的问题总数无法预知，停止条件难以设计。
2. 深层推理：每个问题需基于上下文证据定位，并给出可行的解决动作，这要求跨文档、跨实体进行语义关联。
3. 评估复杂：传统精度指标无法衡量"全面发现"能力，需设计融合覆盖率与识别率的复合指标。 在工程管理、代码审查、个人工作流等现实场景中，忽略隐藏问题可能导致重大损失，业界迫切需要可扩展的主动发现方案。

行业类比

类似代码静态分析工具（如 SonarQube）不止检查语法错误，更能挖掘技术债与安全隐患；TIDE 期望在更泛用的文档与工具环境下，主动诊断那些"不像问题但必须处理"的上下文异常。

核心洞察

• **Thought templates 将隐性发现模式显式化为可复用 schema**。传统单次推理（single-shot）倾向于锚定最显著的问题并给出泛化结论，容易忽略上下文中共存却不易察觉的隐患。TIDE 从已解决案例中蒸馏出 **thought templates**，明确规定了关注哪些上下文信号以及如何连接它们，将每个预测锚定到可识别的问题类别。这不同于简单 few-shot 示例，它提供了一种结构化的、可跨任务转移的推理模式，大幅提升了问题发现的精确性和一致性。
• **迭代式发现（iterative discovery）以小批次、条件化方式扩展覆盖，优于并行多代理基线**。已有工作常采用单次预测或并行多代理一次性生成所有候选，但问题总数未知时容易遗漏或不准确。TIDE 每轮仅产生少量候选，并基于已发现内容调整后续轮次的搜索焦点，实现了逐步“剥洋葱”式的发现过程。在相同 LLM 调用预算下，这种迭代机制不仅在覆盖率和识别准确率上显著优于单次和并行方法，还避免了并行代理之间的冗余和冲突，展现出更强的可扩展性和工程实用性。

方法

任务与动机

日常使用的 LLM 智能体往往仅响应用户显式请求，然而实际上下文（如个人文档集、代码仓库）中并存大量被忽视的潜在问题，且总数未知。TIDE 将此类需求形式化为隐藏问题发现：从上下文自动挖掘所有未被察觉的问题，要求每个发现附有证据并给出可执行行动。

方法核心：模板引导的迭代流程

TIDE 采用“输入上下文 → 迭代发现 + 思想模板 → 问题清单”的双机制框架，替换传统的一步到位预测。

• 迭代发现：将发现问题分解为多轮小型探索。每轮模型基于已发现集合作为条件，生成一小批（如2~3个）新问题候选，强制后续轮次覆盖被首轮“显著性偏差”遗漏的盲区。该过程重复直至达到预算或无明显新发现，逐步提升召回与覆盖面。
• 思想模板：从先前成功解答的案例中蒸馏出可复用的推理模式。模板明确指出应关注哪些上下文信号（如文件异常、依赖缺失）以及如何将这些信号关联为可识别的问题类别。每次预测时，模型检索相关模板，将猜想锚定在已知的经验结构上，避免产出泛化声明，同时提高证据引用的精准度。

与同类方法的差异

单次预测（single-shot）倾向锁定最显著问题且容易重复输出，并行多智能体方案则缺少全局协调导致冗余。TIDE 通过条件迭代抑制重复，用可共享的模板池在不同 LLM 骨干间传递已学习的发现策略，并在跨 LLM 迁移中展现通用性，是一种更高效、可积累经验的主动问题发现范式。

实验

实验设计

TIDE 在两类真实场景上验证效能：

• Personal Workspace：模拟个人工作空间中的文档、笔记等异构内容，问题隐蔽且数量未知。
• Software Repository：面向代码仓库中的潜在缺陷与优化点，要求精准识别并提供可操作方案。

选择四个不同的 LLM 骨干（未具名）评估通用性。评价指标为 Coverage（覆盖率） 与 F1，衡量发现问题的全面性与识别质量。基线包括 single-shot（单次预测）与 parallel multi-agent（并行多智能体）两种常见范式，均不加模板引导。

关键发现

• 迭代发现大幅提升覆盖：每轮只产出少量候选，并基于已发现结果扩展搜索，有效避免了单次预测“锚定最显著案例、产出笼统断言”的缺陷。
• 思想模板增强精细度：从过往成功案例中抽取的可复用模式（ thought templates）指导模型关注关键证据并连接上下文，使每个预测对应明确的问题类别，显著改善识别与解决方案质量。
• 模板跨 LLM 可迁移：分析表明，从一种模型蒸馏的模板池在其它模型上同样有效，且模板池大小对性能有可调节的影响。

与基线对比解读

single-shot 基线一次性生成全部候选，倾向于忽略次要问题，且输出多为泛泛陈述，缺乏具体可执行动作。parallel multi-agent 虽可并行探索更多方向，但缺乏结构化引导与累积上下文，容易产生冗余或冲突的发现。TIDE 通过迭代机制逐步扩展覆盖，配合模板注入问题解决的“先验经验”，在覆盖率、辨识度与方案实用性上均显著优于这两类基线，证明结构化迭代与可复用知识在隐蔽问题发现中的关键价值。

行业影响

落地场景

TIDE 框架的核心能力是主动发现上下文中的多个隐藏问题，适合嵌入需要持续监控与智能审计的产品中。典型场景包括：

• 代码与文档助手：IDE 插件或代码仓库托管平台（如 GitHub Copilot、GitLab）可集成 TIDE，自动扫描代码库，发现潜在 bug、安全漏洞、文档不一致等多类问题。
• 企业知识库治理：在 Confluence、Notion 等协作平台上，TIDE 可周期性分析文档集合，识别过时内容、信息冲突或缺失引用，并生成修复建议。
• 客服与运维系统：分析历史工单和系统日志，主动暴露出高频但未被关注的流程缺陷或产品缺陷，推动问题提前解决。

商业价值

TIDE 通过迭代式多问题发现直接降低遗漏风险，将隐性成本显性化：

• 降本：减少人工审计与事后修复成本。例如代码审查中，人工往往只关注最显眼的问题，而 TIDE 能批量发现低显著性但高风险的缺陷，缩短故障定位时间。
• 增收/体验提升：在电商或内容平台，主动发现商品描述、用户界面中的隐藏问题可提升转化率与用户留存；在 SaaS 产品中，TIDE 可增强平台智能性，形成差异化竞争力，提升客单价。

与现有产品/工作流的接口

TIDE 设计为轻量 LLM agent 框架，容易融入现有技术栈：

• 集成方式：以 API/微服务形式部署，接受上下文（文档集合、代码库、日志流）输入，输出结构化问题列表与行动建议。可与现有的向量数据库、RAG 管线结合，利用已有索引加速证据检索。
• 触发机制：支持定时巡检、事件驱动（如新 PR、新文档上传）或按需调用，适配 CI/CD 流水线、知识管理系统的事件钩子。
• 结果消费：输出格式可与现有告警系统（PagerDuty）、工单系统（Jira）或代码评审界面直接对接，最小化迁移成本。

具体落地用例

1. 电商平台：全渠道商品信息一致性巡检
   大型电商平台常有多语言、多地区商品页面，信息多源同步易出现不一致（如价格、规格、合规声明）。TIDE 可周期性扫描全站商品，发现标题与描述矛盾、合规信息缺失、图片替代文本不准确等多类隐藏问题，并给出具体修改方案，大幅降低人工抽检成本，避免消费者投诉或监管处罚。

2. 软件工程：跨仓库架构问题检测
   在微服务组织中，一个业务变更往往涉及多个代码仓库，依赖关系复杂。TIDE 可配置为在合并请求触发时，自动检查本次变更涉及的多个仓库，发现接口契约不一致、配置漂移、安全依赖过期等跨边界问题，生成报告并标记相关责任人，让平台工程团队能够在不增加人力的情况下提升系统韧性。

局限

• **思维模板** 的质量与数量直接影响 TIDE 的发现性能。论文指出，模板从已解决案例中蒸馏，若初期案例不足或分布偏斜，模板库覆盖不全，将制约迭代后期新问题的发掘，并可能引入偏差。此外，模板的跨 LLM 迁移能力仅在部分模型间验证，实际环境中模型行为差异更大，迁移有效性存疑。这暗示方法对高质量示例集有较强依赖，冷启动时可能性能不佳。
• 从实验设计看，TIDE 的迭代轮数与每轮候选数固定，缺乏自适应停止机制：简单场景下造成计算浪费，复杂场景下可能过早结束。在**软件仓库**场景中，发现问题仅依赖表面上下文，模板可能忽略深层逻辑缺陷（如运行时错误、依赖冲突），实用范围受限。同时，论文未探讨模板如何随领域漂移动态更新，长期部署中模板库可能逐渐失效。
• 与**并行多智能体**基线相比，TIDE 在覆盖率和 F1 上提升显著，但未对比基于强化学习或交互式探索的主动学习方法，而这些方法更擅长处理未知状态空间。另外，论文未提供在受限资源下的效率分析：固定迭代轮次可能消耗大量 LLM 调用，实际部署时投入产出比不明确，且方法对 LLM 推理延迟敏感，实时性要求高的场景难以落地。