Tabbit 1.0 上线:多模型并行 PK,浏览器开始替你选模型

2026-06-10 16 预计阅读时间: 1 分钟
来源: oschina.net AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:10 分钟

美团旗下光年之外团队在 Tabbit 诞生的第 100 天推出了 V1.0。这不是又一个套壳 ChatGPT 的浏览器插件——Tabbit 的核心思路是:不同任务用不同模型,同一个问题让五个模型同时回答再自动对比。这个方向值得认真拆一下。

多模型供给:把"选模型"这件事从用户手里拿走

日常开发中,我们早就习惯了按任务挑模型:写代码找 Claude,做摘要找 GPT-4o-mini,跑推理找 DeepSeek。但普通用户不会做这件事,甚至不知道模型之间有差异。

Tabbit 的做法是接入一批头部模型,由系统根据任务类型自动路由。用户只管提问,浏览器决定谁来答。这背后的技术假设是:任务分类器比用户自己更懂哪个模型合适

实际效果取决于两个环节——任务分类的准确度,以及模型池的覆盖面。V1.0 目前宣称接入了"行业最好的一批",具体名单和路由逻辑没有公开,但从产品形态看,大概率覆盖了代码生成、长文本摘要、创意写作、知识问答等主流场景。

多模型 PK:五路并行,自动对比

V1.0 最有意思的功能是「多模型 PK」。同一个问题,五个模型同时生成回答,Tabbit 自动对比差异,呈现给用户。

这解决了一个真实痛点:单模型回答的可靠性无法自校验。当你问一个技术问题,一个模型说 A,你没法知道它是不是在胡说。但如果五个模型里有四个说 A、一个说 B,你就有理由相信 A——或者至少知道 B 需要额外验证。

从工程角度看,五路并行意味着五倍推理成本。Tabbit 大概率做了两件事来控制开销:

  1. PK 触发条件有限制——不是每个搜索都走五路,只在用户主动发起或系统判定问题复杂度较高时启用。
  2. 对比逻辑用轻量模型完成——五个回答的异同分析不需要大模型,用小模型做摘要和差异提取即可。

实践:用 Python 搭一个迷你多模型 PK 流程

Tabbit 的多模型 PK 功能目前只在浏览器内可用,没有公开 API。但核心思路——多路调用 + 自动对比——可以用开源工具直接复现。下面是一个可运行的示例,用 OpenAI-compatible 接口同时调用多个模型,再自动汇总差异。

import asyncio
import os
from openai import AsyncOpenAI

# 假设你有一个兼容 OpenAI API 的网关(如 one-api、litellm-proxy)
# 不同模型通过 model 参数区分
client = AsyncOpenAI(
    api_key=os.environ.get("OPENAI_API_KEY"),
    base_url=os.environ.get("OPENAI_BASE_URL", "https://api.openai.com/v1"),
)

MODELS = ["gpt-4o-mini", "deepseek-chat", "claude-3-haiku-20240307"]
# 根据你的网关配置调整模型名,以上仅为示意

async def ask_one_model(model: str, question: str) -> str:
    resp = await client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": question}],
        max_tokens=512,
    )
    return resp.choices[0].message.content or ""

async def multi_model_pk(question: str) -> dict[str, str]:
    """并行调用多个模型,返回各模型的回答"""
    tasks = [ask_one_model(m, question) for m in MODELS]
    results = await asyncio.gather(*tasks, return_exceptions=True)
    answers = {}
    for model, result in zip(MODELS, results):
        if isinstance(result, Exception):
            answers[model] = f"[调用失败: {result}]"
        else:
            answers[model] = result
    return answers

async def summarize_diff(answers: dict[str, str], question: str) -> str:
    """用轻量模型对比多个回答的差异"""
    diff_prompt = f"""用户问题:{question}

以下是三个模型的回答:
{chr(10).join(f'- {m}: {a}' for m, a in answers.items())}

请对比这三个回答,指出:
1. 共识点(多数模型一致的内容)
2. 分歧点(模型之间说法不同的内容)
3. 哪个回答最可信,为什么"""
    resp = await client.chat.completions.create(
        model="gpt-4o-mini",  # 对比任务用轻量模型即可
        messages=[{"role": "user", "content": diff_prompt}],
        max_tokens=256,
    )
    return resp.choices[0].message.content or ""

async def main():
    question = "Python 里 asyncio.gather 和 asyncio.TaskGroup 有什么区别?"
    answers = await multi_model_pk(question)
    print("=== 各模型回答 ===")
    for m, a in answers.items():
        print(f"\n[{m}]\n{a[:200]}...")  # 截断显示

    diff = await summarize_diff(answers, question)
    print("\n=== 对比摘要 ===")
    print(diff)

if __name__ == "__main__":
    asyncio.run(main())

运行前需要设置环境变量:

export OPENAI_API_KEY="your-key"
export OPENAI_BASE_URL="https://your-api-gateway/v1"  # 如果用统一网关
python multi_model_pk.py

假设说明:示例依赖一个兼容 OpenAI API 的多模型网关(如 one-apiLiteLLM Proxy),实际模型名需按你的网关配置修改。核心流程——并行调用 + 自动对比——与 Tabbit 的 PK 功能思路一致。

成本与延迟的现实考量

多模型 PK 听起来美好,但落地要面对两个硬约束:

  • 成本:五路并行意味着五倍 token 消耗。如果每次搜索都 PK,月账单会很快失控。合理做法是只在复杂问题或用户主动触发时走 PK,日常简单查询用单模型路由。
  • 延迟:并行调用最慢的模型决定总响应时间。如果某个模型 API 响应慢,整个 PK 结果要等它。工程上可以设超时截断——3 秒内没返回的模型直接标记为"未参与"。

Tabbit 作为浏览器产品,用户容忍的等待时间在 2-5 秒。这意味着 PK 功能大概率做了模型筛选——不是真的五个最慢模型一起跑,而是选响应速度合格的五个。

什么时候该用多模型,什么时候不该

场景 建议 原因
技术方案选型、架构决策 开 PK 多视角减少盲区
代码 bug 排查 开 PK 不同模型可能看到不同层面的问题
快速查 API 用法 单模型即可 答案高度确定,PK 浪费资源
创意写作、文案 可开 PK 风格差异大,对比有价值
简单事实查询 单模型即可 如"Python 3.12 发布日期",没必要五路验证

100 天出 V1.0 的节奏意味着什么

从 0 到 V1.0 只用了 100 天,说明团队选择了快速验证产品形态而非打磨单点深度。多模型路由和 PK 是方向验证,不是终态。接下来值得关注的演进点:

  1. 路由算法是否会公开或可配置——用户可能想强制指定某个模型处理特定任务。
  2. PK 结果的呈现是否会从"对比摘要"进化到"自动合成最优答案"——目前是展示差异让用户判断,下一步可能是直接输出一个融合答案。
  3. 本地模型支持——浏览器场景下,部分轻量任务用本地小模型完成,可以省掉 API 调用和延迟。

Tabbit 的方向是对的:AI 浏览器的价值不在"能对话",而在"能替你做决策"——选哪个模型、要不要交叉验证、怎么呈现结果。这些才是浏览器层面该做的事,也是纯聊天界面做不到的事。


相关推荐