PACE: 揭示用户请求中的潜在冲突
个性化助手不仅要执行用户请求,还应评估这些请求在当前情境下是否恰当。但以往工作多聚焦于准确执行请求,忽视了助手需要结合上下文并做出基于冲突的拒绝。同时,现有的冲突或安全检测工作依赖显式给出的因素,而现实场景常涉及隐含因素,需从知识库中检索。 为此,我们提出 PACE 数据集,用于评估模型能否识别潜在约束(以自我中心知识或事件表述),这些约束可能使看似合理的请求变得不恰当。PACE 将基于人设的请求与自我中心知识事实配对,要求模型整合上下文证据判断请求是否冲突。这种隐含检索设置阻碍了请求与冲突诱发知识的直接关联,使现有模型难以定位相关用户特定事实。 针对此挑战,我们进一步提出 PaceMaker 多智能体框架,通过专门智能体协调查询改写、多跳图遍历与冲突感知过滤,以检索关键证据。实验表明 PaceMaker 在证据检索质量与冲突决策准确性上均优于现有方法。
论文精读
TL;DR 面向个性化助手中的隐藏冲突评估，提出 PACE 数据集与 PaceMaker 多智能体框架，通过查询重构、多跳图遍历与冲突过滤检索隐性用户约束，显著提升冲突决策准确率。
问题
问题背景：个性化助手正从“执行指令”向“情境感知”演进，如何判断请求是否与用户隐含约束冲突成为新焦点。
现有方法局限：
- 先前研究侧重请求执行精度，忽略上下文合适性，缺乏冲突拒绝机制。
- 已有冲突检测依赖显式提供因素（如用户画像、安全规则），但真实交互中冲突多半隐含在用户专属知识库（egocentric KB）中，需模型自行检索。
- 隐式检索场景下，请求与冲突知识无直接表面关联，现有基于 BM25 或稠密检索的方法难以定位多跳相关的用户特定事实。
为什么难/重要：任务要求模型在大量候选事实中做多跳推理（如请求“推荐高糖甜点”→ 需连接“用户患有糖尿病”的 KB 事实），且还需判断冲突严重程度以决定拒绝或调整。这对检索器和推理器的协同提出挑战。业界关注个性化助理的安全性与合理性，错误执行冲突请求可能造成用户体验受损甚至安全风险。
行业类比：类似金融顾问助手，用户申请高杠杆交易，助手需从客户风险档案 KB 中隐式检索出“收入不稳定”后拒绝或警示。
核心洞察
- PACE 将个性化助手安全评估从显式约束转向隐式约束检索，要求模型从用户自有的 egocentric KB 中主动发现与请求冲突的个性化事实，而非依赖输入中直接给出的限制条件。这种设定更接近真实助理场景，因为用户通常不会在请求前声明所有个人约束。与现有冲突检测数据集相比，PACE 的冲突诱导知识需要多跳检索且与请求表面文本无直接关联，显著提高了任务难度，也暴露了当前模型在用户特定背景推理上的不足。
- PaceMaker 用多智能体分工解决隐性冲突证据的定位难题，其查询重构、多跳图遍历与冲突感知过滤三个环节分别对应检索中的语义对齐、中间实体穿透与证据相关性筛选问题。相比通用 RAG 或图 RAG 方法只优化单一检索目标，PaceMaker 将冲突判定作为约束贯穿 retrieved evidence 选择过程，使得检索结果更聚焦于“能改变请求可行性”的事实，而不是泛化的用户信息。这种以冲突为中心的检索设计，为个性化安全场景中的证据获取提供了可复用的架构思路。
方法
输入
- 用户请求（自然语言，通常看似合理）
- 与用户 persona 关联的 egocentric KB（包含个性化事实与事件）
关键模块
- 冲突感知查询规划：将用户请求重新表述为适合检索的查询，并可能分解为多个子任务，引导后续检索方向。
- 混合检索与融合：结合多种检索技术（如向量检索与符号检索），从 KB 中召回候选事实，并融合不同来源的相似度信号。
- 多跳图遍历：在 KB 构造的知识图上进行多跳推理，沿实体关系边传播信息，发现与请求间接相关的上下文约束。
- 冲突感知证据选择：对候选证据进行过滤与重排序，保留对冲突判断具有决定性的信息，剔除冗余或无关事实。
- 答案生成：基于选出的证据，生成冲突与否的二元决策，并输出相应的解释性依据。
输出
- 冲突与否的二元分类结果
- 支持该决策的关键证据集合
该方法的核心在于将隐式检索和冲突判断解耦为多个代理协作，每个代理专注单一子任务，通过协同降低端到端推理的复杂度。
与同类方法（如直接检索全部相关事实后统一判断）的差异在于：PaceMaker 通过多智能体分工，显式分离查询重写、图遍历和证据过滤，能更有效地定位上下文决定性证据，避免无关信息干扰冲突判断。
实验
实验设计
论文构建 PACE 数据集，将用户请求与 egocentric KB 事实配对，要求模型检索隐式约束并做出冲突判断。评估指标包括 证据检索质量 与 冲突决策准确率。基线包括现有方法及结构化检索方法，并对 PaceMaker 的多智能体组件进行消融。
关键发现
PaceMaker 通过查询改写、多跳图遍历和冲突感知过滤，有效定位上下文关键证据，在证据检索和冲突决策上均优于基线。消融实验表明各智能体组件对整体性能均有贡献。
对比解读
现有方法难以直接关联请求与冲突知识，而 PaceMaker 分解检索步骤，提升隐式检索的覆盖与精度，更适配多跳推理场景。
行业影响
落地场景
PaceMaker 的方法可应用于任何需要理解用户情境、避免提供不当响应的个性化助手场景：
- 电商推荐：用户请求“推荐一台高性能游戏本”，但知识库中有其近期退货记录或预算限制，需判断是否冲突并调整推荐。
- 健康管理：用户要求“制定高强度训练计划”，系统需结合其医疗史（如关节损伤）拒绝或调整。
- 金融顾问：用户请求“投资高杠杆产品”，系统需根据其风险承受能力、近期负债等隐含信息触发冲突拒绝。
- 企业服务：员工请求访问敏感数据，系统需结合其角色、项目背景判断是否越权。
这些场景均涉及隐式约束来自用户画像与事件知识库，与 PACE 的设定一致。
商业价值
直接价值在于减少错误建议导致的信任损失与合规风险。传统助手只追求执行准确率，忽略情境适应性，可能给出有害或不合适的响应，造成客户流失甚至法律纠纷。PaceMaker 通过多代理协作进行冲突感知检索，能降低：
- 人工审核成本（减少需人工介入的冲突案例）
- 合规与责任风险（尤其在金融、医疗等强监管领域）
- 用户体验损耗（避免频繁打扰或不当内容）
模型替换为 PaceMaker 后可提升个性化服务的“安全边际”，进而增加用户粘性与长期价值。
与现有工作流集成
PaceMaker 的架构可视为对现有 RAG 与 Agent 工作流的增强：
- 知识库接入：替换原有简单向量检索为多跳图遍历 + 冲突感知过滤，可复用在已有用户画像图谱和事件存储上。
- 模块化代理：
查询改写、混合检索、冲突过滤、答案生成各代理可独立部署，与现有 LLM 编排框架（如 LangGraph、AutoGen）兼容。 - 评估与监控：PACE 数据集可作为新的离线评估基准，用于上线前验证助手的情境适应性；也可转化为在线置信度阈值。
总体看，PaceMaker 提供了一种将“安全”与“个性化”结合的工程范式，适合作为智能助手系统的中间层。
局限
- - **数据合成依赖 LLM**：PACE 数据集的生成过程大量使用 LLM 构造请求、persona 和 egocentric KB 事实，这虽然保证了可控性和规模，但也引入了模型自身的系统性偏差。合成数据在语言自然度、噪声水平、用户意图模糊性等方面与真实交互存在差距。此外，KB 事实被设计为独立、结构化的三元组或短句，而现实中用户信息分散在邮件、日历、聊天记录等非结构化数据中，直接迁移到生产环境会遇到检索与消歧难题，影响模型在 PACE 上表现的真实泛化能力。
- - **多智能体框架效率开销**：PaceMaker 在推理时需要多个专用代理依次完成 query reformulation、multi-hop graph traversal 和 conflict-aware filtering，每个代理均调用大语言模型，导致显著的计算成本和响应延迟。论文在离线数据集上只报告了准确率指标，未与更轻量的检索增强基线（如单模型 + 稠密检索）进行成本-收益对比，也未讨论在线部署的可行性。对于毫秒级响应的个性化助手，串行多代理流水线可能难以满足工程约束，存在从学术实验到产品落地的效率鸿沟。
- - **冲突判定过于简化**：任务将冲突定义为基于单条 KB 事实的二元分类，模型只需检索到一条决定性证据即可判定请求是否冲突。但真实场景中请求往往受多个相互牵制的约束影响，用户意图会动态变化，且可能需要主动对话澄清而非直接拒绝。PACE 的预定义 persona 和事实对覆盖的冲突类型有限，未包含价值观冲突、跨领域策略冲突或安全红线等更复杂的个性化决策维度，因此 benchmark 的生态效度不足，后续工作需扩展至多因素权衡与交互式决策。