从"你问我答"到"实时对话":交互模型如何重塑人机协作

2026-05-13 16 预计阅读时间:1 分钟
来源:oschina.net AI 摘要 原文链接

免责声明:本文为 AI 摘要整理,建议结合原文阅读。摘要可能省略上下文、版本差异或边界条件,不作为官方说明。

预计阅读时间:13 分钟

当前主流大语言模型的交互方式,本质上是一封电子邮件:你写完发送,对方读完回复,中间有一段沉默的等待。Thinking Machines Lab——由 OpenAI 前首席技术官 Mira Murati 创立的新团队——最近发布的研究预览"交互模型"(Interaction Models),试图把这段等待砍掉,让人与 AI 的协作更像两个人面对面聊天:可以打断、可以补充、可以同时开口。

这个方向看似只是体验优化,实际上触及了 LLM 交互架构的底层假设。值得认真看看它到底在改什么,以及作为开发者可以怎么提前布局。

轮次制交互的隐性代价

几乎所有主流 LLM API 都遵循同一套协议:

用户输入 → 模型推理 → 返回完整文本 → 等待下一轮输入

这套协议的好处是简单——状态清晰、易于缓存、方便计费。但它在三个场景下会卡住:

  1. 长任务协作:让模型写一段 2000 字的分析,你只能等它写完才能说"第三段方向不对"。人之间不会这样——你看到同事写到第三段时就会插一句"这里换个角度"。
  2. 实时决策辅助:驾驶、手术、交易等场景需要模型在用户还在说话时就给出反馈,而不是等用户说完再开始推理。
  3. 多模态同步:语音+手势+屏幕共享的自然对话中,信息是持续流入的,不是打包发送的。

轮次制不是技术限制,而是架构选择。早期的 GPT 系列继承了这个选择,后续几乎所有模型都沿用了,不是因为最优,而是因为惯性。

交互模型的核心改动:从离散轮次到连续流

Thinking Machines Lab 提出的交互模型,核心改动是把交互从离散的"轮次"变成连续的"流"。具体来说有三层变化:

输入端:持续接收而非批量等待。 模型不再等用户把话说完才开始推理,而是在用户输入的过程中就持续处理——类似流式输入的反向应用。用户可以随时追加信息、修正意图,模型实时更新内部状态。

输出端:渐进呈现而非一次性返回。 这一点现有的流式输出(streaming)已经部分实现,但交互模型更进一步:模型可以在输出中途根据用户的新输入调整方向。比如模型正在生成一段代码,用户中途说"改用 Rust",模型可以即时转向,而不是等当前输出完成再重新生成。

状态端:共享上下文而非独立轮次。 每一轮对话不再是独立事件,而是共享一个持续更新的上下文窗口。模型的"注意力"不是每轮重新分配,而是在整个交互过程中持续维护。

用一个类比:轮次制像发邮件,交互模型像共享文档里的实时协作编辑——双方都能随时看到对方的修改并做出响应。

用现有工具模拟交互模型的流式协作

交互模型的完整 API 専尚未公开,但它的核心思路——持续输入、渐进输出、中途可干预——可以用现有的流式 API 加 WebSocket 来模拟。下面是一个可运行的 Python 示例,展示"用户中途打断并修正方向"的交互模式:

"""
实时流式协作示例:模拟交互模型的"中途干预"能力
依赖:pip install openai fastapi uvicorn websockets
运行:python interaction_sim.py
然后打开浏览器访问 ws://localhost:8000/ws 进行交互
"""

import asyncio
import json
from fastapi import FastAPI, WebSocket
from openai import AsyncOpenAI

app = FastAPI()
client = AsyncOpenAI()  # 需设置 OPENAI_API_KEY 环境变量

# 共享的持续上下文——交互模型的核心特征
conversation_context: list[dict] = []


@app.websocket("/ws")
async def interaction_ws(ws: WebSocket):
    await ws.accept()
    await ws.send_json({"type": "system", "content": "连接建立,你可以随时输入。输入 /redirect <新方向> 可中途改变生成方向。"})

    # 用户输入队列:支持持续流入
    user_queue: asyncio.Queue = asyncio.Queue()
    redirect_flag: asyncio.Event = asyncio.Event()
    redirect_msg: str = ""

    async def receive_user_input():
        """持续接收用户输入,区分正常消息和干预指令"""
        try:
            while True:
                data = await ws.receive_text()
                msg = json.loads(data)
                text = msg.get("content", "")
                if text.startswith("/redirect"):
                    # 中途干预:设置重定向标志
                    redirect_msg = text.replace("/redirect", "").strip()
                    redirect_flag.set()
                else:
                    await user_queue.put(text)
        except Exception:
            pass

    async def stream_with_intervention():
        """流式生成,支持中途被用户干预打断并转向"""
        while True:
            # 等待用户的新输入
            user_text = await user_queue.get()
            if user_text is None:
                break

            conversation_context.append({"role": "user", "content": user_text})

            # 开始流式生成
            stream = await client.chat.completions.create(
                model="gpt-4o-mini",
                messages=conversation_context,
                stream=True,
            )

            accumulated = ""
            redirect_flag.clear()

            async for chunk in stream:
                # 检查用户是否发出中途干预
                if redirect_flag.is_set():
                    # 把干预信息注入上下文,重新生成
                    await ws.send_json({
                        "type": "interrupted",
                        "content": f"收到方向修正:{redirect_msg},正在转向..."
                    })
                    conversation_context.append({
                        "role": "assistant", "content": accumulated + f"\n[用户中途修正:{redirect_msg}]"
                    })
                    conversation_context.append({
                        "role": "user", "content": redirect_msg
                    })
                    # 用修正后的上下文重新开始生成
                    new_stream = await client.chat.completions.create(
                        model="gpt-4o-mini",
                        messages=conversation_context,
                        stream=True,
                    )
                    accumulated = ""
                    async for new_chunk in new_stream:
                        delta = new_chunk.choices[0].delta.content or ""
                        accumulated += delta
                        await ws.send_json({"type": "token", "content": delta})
                    break

                delta = chunk.choices[0].delta.content or ""
                accumulated += delta
                await ws.send_json({"type": "token", "content": delta})

            # 保存完整输出到持续上下文
            conversation_context.append({"role": "assistant", "content": accumulated})
            await ws.send_json({"type": "done", "content": accumulated})

    # 并行运行:输入接收与生成输出同时进行
    recv_task = asyncio.create_task(receive_user_input())
    gen_task = asyncio.create_task(stream_with_intervention())

    try:
        await asyncio.gather(recv_task, gen_task)
    except Exception:
        recv_task.cancel()
        gen_task.cancel()


if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

运行前需要做的准备:

  1. pip install openai fastapi uvicorn websockets
  2. 设置 OPENAI_API_KEY 环境变量
  3. 运行 python interaction_sim.py
  4. 用任意 WebSocket 客户端(浏览器 JS、Postman、wscat)连接 ws://localhost:8000/ws

关键设计点:

  • conversation_context 是跨轮次持续维护的,不是每轮重建——模拟交互模型的共享状态
  • receive_user_inputstream_with_intervention 并行运行——输入和输出不再互斥等待
  • /redirect 指令模拟"中途干预"——用户不需要等当前生成完成就能改变方向

这个示例用现有 API 模拟了交互模型最核心的三个特征。真正的交互模型 API 发布后,底层推理机制会进一步优化(比如增量注意力计算而非全量重算),但上层交互模式大概率就是这个形状。

从轮次到流式:架构层面的取舍

交互模型不是免费午餐。从轮次制切换到流式协作,有几个必须正视的工程代价:

推理成本上升。 轮次制下,模型只在完整输入后做一次推理。流式协作中,模型需要持续推理、增量更新状态,计算量可能增加 2-5 倍。Thinking Machines Lab 的论文中提到需要新的推理调度策略来控制成本,具体方案尚未公开。

状态一致性难题。 共享持续上下文意味着模型内部状态在交互过程中不断变化。如果用户中途干预,模型需要决定:是丢弃之前的部分输出,还是在现有基础上修正?这涉及注意力权重的动态重分配,目前没有标准方案。

错误传播风险。 轮次制下,一轮出错只影响那一轮。流式协作中,一个早期错误会持续影响后续所有交互,因为上下文是连续累积的。需要更精细的上下文管理机制——什么时候截断、什么时候回滚。

协议兼容性。 现有的 OpenAI/Anthropic API 都是轮次制。交互模型需要新的传输协议(WebSocket 或类似的双向流),新的请求格式,新的计费模型。这是生态层面的变化,不是换个参数就能适配的。

开发者现在可以做什么

交互模型的完整产品还在研究预览阶段,但方向已经明确。作为开发者,有三件事现在就可以动手:

1. 把所有 LLM 调用改为流式输出。 即使还在用轮次制 API,流式输出(stream=True)是交互模型的前置条件。如果你的应用还在用同步请求一次性返回完整结果,现在就改过来。上面的示例代码已经展示了基本模式。

2. 设计双向通信的接口层。 在你的应用架构中加一层 WebSocket 或 Server-Sent Events 的双向通道,让前端可以在模型生成过程中发送补充信息。不需要等交互模型 API,用现有 LLM + 中途干预逻辑就能跑通基本流程。

3. 实验持续上下文管理策略。 不再每轮清空上下文,而是维护一个持续更新的对话状态。关键问题是:什么时候截断旧内容、什么时候保留?可以先在现有 API 上用滑动窗口 + 摘要压缩的方式实验,为交互模型的正式 API 做准备。

一个最小化的检查清单:

  • ✅ 所有 LLM 调用是否已改为流式?
  • ✅ 前端是否支持在生成过程中发送补充指令?
  • ✅ 上下文是否跨轮次持续维护,而非每轮重建?
  • ✅ 是否有中途干预的 UI 机制(停止按钮、方向修正输入框)?
  • ✅ 是否考虑了增量推理的成本预算?

交互模型要解决的问题很真实:人不会等对方说完再回应,AI 也不应该。从轮次制到流式协作的切换,不只是体验升级,而是交互架构的范式变化。现在开始把你的应用往流式、双向、持续上下文的方向调整,等正式 API 发布时,迁移成本会低很多。


相关推荐