千问台前，文心底层：大模型应用分层架构实践

最近在帮几个团队做大模型应用改造，发现一个很有意思的普遍现象：前台给客户演示的对话功能，大多直接挂了千问（通义千问）；后台真正干活的那些流程——文本分类、信息抽取、批量总结、内容校验——反而默默跑着文心（文心一言）。大家还把这件事总结成一句话：千问台前折腾，文心底层无声。

这句话乍一听像段子，实际上是现在很多大模型项目里真实存在的分层架构：可见的交互层用一套模型，不可见的处理层用另一套模型。这篇文章就围绕“台前”和“底层”这两个位置，聊清楚千问和文心各自适合干什么、怎么接入、怎么配合，以及最容易翻车的地方在哪。

先说结论：如果你正在做或者准备做一个接大模型的应用，我的建议不是“只选一家，其他别碰”，而是先按任务类型分层，再决定哪家放台前、哪家放底层。台前要的是体验和响应速度，底层要的是稳定性、成本和结构化输出。这两个目标经常冲突，硬要用一个模型扛下所有事情，最后往往是两头都顾不好。

1. 先搞懂“台前”和“底层”为什么不是同一个模型

很多人看到“一个应用里用了两个模型”，第一反应是“是不是在套壳”。实际上，多模型路由是已经非常常见的工程架构。台前和底层对模型的要求本来就不一样，硬放在一起，才会出问题。

1.1 台前是体验，底层是流程

台前指的是用户能直接看到、直接操作的部分，典型场景是对话机器人、产品助手、演示 Demo。用户对这个模型的判断标准很直接：回复快不快、语气自不自然、能不能听懂我上一句话、前后逻辑连不连贯。台前模型本质上是在做“给人看”的交互，体验好不好，用户三秒内就有感觉。

底层指的是用户看不见、但每天都在运行的自动化流程，典型场景是工单分类、合同关键信息抽取、舆情打标、批量文本摘要、数据清洗。这些任务不追求语言优美，追求的是输出格式稳定、字段齐全、能批量跑、结果可校验。底层模型出错不会弹窗告诉你，它只会静默地写坏一条数据，几天后才在报表里显现。

拿智能客服举例会更直观。台前：用户问“我上个月的账单为什么多了 20 块”，模型要能自然回复，语气不能像机器人念稿。底层：每次会话结束，系统要把对话自动分类成“账单咨询”“投诉”“退换货”，再把用户情绪、意向、紧急程度抽出来，写进工单系统。前者是体验问题，后者是流程问题，两者对模型的需求完全不同。

1.2 决定模型分层的四个核心变量

我接触到的团队在做模型选型时，最后基本都会落在这四个变量上：

第一是成本。台前对话每天请求量很大，用户聊几句就是几个来回，Token 消耗按小时涨。底层批量任务虽然单条场景简单，但架不住量大，跑十万条和跑一百条的成本完全不是一个量级。不同模型、不同版本的价格差异很大，具体要以对应云平台控制台为准，但判断逻辑是固定的：把“单次调用成本 × 调用量”算清楚，再看预算能承受哪一层用贵模型、哪一层用便宜模型。

第二是延迟。台前用户等不了五秒才看到第一个字，底层任务三十秒一分钟都能接受。如果你把底层模型拿到台前用，用户会不断抱怨“怎么这么慢”；你把台前模型放到底层跑批量，又可能因为单次输出太长导致单条成本暴涨。

第三是能力侧重。有的模型通用对话能力强、跟随指令自然，适合做交互；有的模型在中文结构化任务上更稳，适合做抽取和分类。注意，这个判断不能只看宣传，要拿自己业务里的真实数据跑一轮，不同版本、不同任务的结论可能完全不同。

第四是稳定性和合规约束。底层任务长期挂机跑，尤其涉及内容安全、数据合规时，要选更保守、更可控的模型或部署方式。台前任务则可以更激进一点，因为有人盯着，出了问题能及时介入。

2. 千问站台前：先把演示体验跑顺

如果台前已经决定用千问，那第一件事不是调 prompt，而是先把接入链路跑通，再逐步打磨体验。

2.1 前置准备：平台账号、API Key 和调用方式

千问模型目前主要通过阿里云百炼平台对外提供服务。你需要先完成这几步：

1. 注册并开通百炼平台服务，创建 API Key。
2. 确认模型名称。平台里会有多个模型版本可选，名称以你开通时控制台列出的为准，不要照抄网上文章里的旧模型名。
3. 准备一个能正常访问平台接口的运行环境，本机测试、服务器部署都可以。
4. 安装合适的 SDK，或者直接用 HTTP 调用。

这里最容易忽略的是权限和模型开通状态。有几次我排查半天，问了一圈才发现是 API Key 没有绑定对应模型的服务，控制台测通了，代码里一调用就报错。所以第一次接入，我建议先在平台自带的调试工具里发一条消息，确认“账号权限、模型开通、接口连通”三件事都没问题，再写代码。

2.2 单次对话调用示例与参数说明

下面给一个非常基础的 Python 调用示例。实际接入时以你使用的 SDK 版本和官方文档为准。

# 示例代码：通义千问单次对话调用 # 实际实现请以百炼平台官方文档为准 from dashscope import Generation resp = Generation.call( model="qwen-plus", # 模型名以控制台实际开通为准 prompt="你好，请用一句话介绍你自己", temperature=0.7, max_tokens=200 ) if resp.status_code == 200: print(resp.output.text) else: print("调用失败：", resp.code, resp.message)

这个示例里最关键的不是代码本身，而是参数理解：

2.3 台前场景要盯住的首字延迟和流式体验

台前体验好不好，核心看两个数字：首字延迟和完整回复耗时。

首字延迟就是从请求发出到收到第一个 token 的时间。一般情况下，首字延迟控制在 2 到 3 秒以内，用户还能接受；超过 5 秒，用户就会觉得“卡了”。排查时先看网络，再看模型负载，最后看是不是多轮对话的上下文太长。

流式体验也很关键。用 stream=True 逐字输出，用户能感觉到“模型在打字”，心理等待时间会大幅降低。但流式也会带来新问题：前端渲染频率太高时，页面会抖动；中断、重连、超时的处理都要提前想好。

另外，多轮对话要控制历史长度。很多人一开始不限制上下文，聊了二十轮之后，每次请求都带上前面所有内容，首字延迟越来越慢，Token 成本也越来越高。我一般会做一个滑动窗口，只保留最近几轮关键对话，既能维持连贯性，又能控制延迟和成本。

3. 文心沉底层：安静地跑完批量任务

底层模型不需要被用户看到，但它每天都在产生数据，是整个系统里最“沉默”也最需要负责的部分。

3.1 底层任务和前台交互的根本差异

底层任务几乎都有共同点：输入格式固定、输出格式固定、重复性高、量大。比如从一段合同文本里抽取“甲方、乙方、金额、有效期、付款方式”，或者把一批评论按照预设标签分类，再或者把长文档拆成段落做摘要。

这类任务对“文风自然”完全不敏感，对“字段是否齐全”“格式能否解析”特别敏感。你让模型写一段漂亮的散文它可能很强，但你让它每次都在同一个地方输出一个合法 JSON，它反而可能给你夹带一段解释文字。

很多团队在底层选文心，不是因为词藻多漂亮，而是它在中文信息抽取、文本分类这类任务上表现稳定，而且百度千帆在企业部署和合规配套方面相对完整。这个选择逻辑本身没错，但要注意：具体哪个模型更适合你的任务，还是要拿自己的数据跑。我在多个项目里见过“换模型之后字段缺失率从 5% 涨到 20%”的情况，谁强谁弱不能拍脑袋。

3.2 批量处理的基本框架：队列、重试、校验

底层批量任务不能只写一个 for 循环无脑跑。跑通和跑稳是两回事，这里至少要考虑四件事。

第一，分批和队列。十万条数据一次性并发打过去，大概率触发限流。正确做法是做一个任务队列，控制并发数，一批一批地处理。并发数从 5、10 开始试，不要一上来就开到 50。

第二，重试策略。对超时、限流、临时性 5xx 错误要做指数退避重试，比如第一次等 2 秒，第二次等 4 秒，第三次等 8 秒，最多重试三到五次。但对内容安全拦截、参数错误这类确定性失败，不要重试，重试多少次都会失败，只会白白消耗额度。

第三，输出校验。模型返回的文本不能直接当数据用。先解析 JSON，再检查字段是否齐全，再校验字段值是否合法。比如金额字段必须是数字，日期字段必须符合格式，这些校验逻辑一定要写在代码里。

第四，失败落盘。处理失败的输入要单独存一份，带原始内容和失败原因，方便之后补跑。否则一次跑十万条，有两百条失败，你都不知道是哪两百条。

# 批量处理伪代码，重点看重试和校验的写法 import json import time def process_item(item, call_model, validate): for attempt in range(3): try: text = call_model(item["content"]) data = json.loads(text) validate(data) # 字段校验 return data except json.JSONDecodeError: # 输出无法解析，不重试，直接记失败 return None, "json_parse_error" except TimeoutError: time.sleep(2 * (attempt + 1)) # 指数退避 except RateLimitError: time.sleep(5 * (attempt + 1)) return None, "max_retry_exceeded"

3.3 为什么越“无声”越需要监控

底层模型最大的风险不是它不干活，而是它“假装干活干得很好，其实已经偏了”。因为它没有对话框，不会告诉你“我不确定”，它只会安静地把错误结果写进数据库。

所以底层任务一定要有监控。至少盯这几个指标：处理成功率、JSON 解析失败率、字段缺失率、单条平均耗时、累计成本。每天或者每周跑一次统计，出现异常第一时间看日志。

更稳妥的做法是定期抽查输出样例。自动校验只能检查格式对不对，不能检查内容对不对。比如模型把“乙方向甲方支付 100 万”抽成了“甲方向乙方支付 100 万”，格式完全合法，但语义反了。这种错误只能靠人工样本抽查来发现。

4. 多模型配合的工程化写法：路由、降级与观测

台前千问、底层文心，这只是最简单的分层。真正做工程化时，你还需要一套机制，让两个模型能配合、能互相兜底、能被观测。

4.1 统一接入层，屏蔽两边协议差异

千问和文心属于不同平台，API 格式、鉴权方式、错误码都不一致。如果业务代码里到处直接调用，后面换模型、加模型都会非常痛苦。

正确做法是抽象一个统一接入层，对外只暴露业务方法，比如chat()、extract()、classify()。内部根据任务类型路由到对应的模型实现。这样业务代码根本不需要知道底层用的是千问还是文心，切换模型只改路由层。

4.2 路由规则与降级策略

路由规则可以按任务类型分，也可以按成本预算分。比如：

• 客户对话、产品咨询这类交互任务，路由到千问。
• 工单分类、信息抽取这类结构化任务，路由到文心。
• 高价值 VIP 用户请求，走更好的模型版本；普通请求走成本更低的版本。

降级策略更重要。主模型调用失败时，不能直接报错给用户，要有一套自动降级流程：主模型失败后重试，重试仍然失败就切到备用模型，备用模型也失败才落库记录。这里要注意，降级不能无限重试，要加熔断机制。比如主模型连续失败超过十次，就暂时把它切掉，过一段时间再恢复探测。否则主模型已经挂了，你的系统还在拼命打它的接口，只会加重问题、拖慢响应。

4.3 日志与费用拆分

多模型架构下，没有日志就等于没有眼睛。每次调用至少要记录：时间、任务类型、模型名称、输入 Token 数、输出 Token 数、耗时、是否成功、是否触发降级。

有了日志，你才能回答三个问题：

1. 每个模型实际承担了多少调用量？
2. 每个模型的实际成本是多少？
3. 降级触发率有多高，是哪个环节在拖后腿？

费用拆分也很关键。很多团队只关心模型本身好不好，忽略了“调用量 × 单价”才是真成本。同一个模型，有人日均调用一万次，有人十万次，费用完全不是一个量级。建议每周拉一张按任务类型分组的成本报表，哪一层的费用超了预期，一眼就能看出来。

另外，如果产品对外承诺了具体模型品牌，路由和降级策略要提前和产品、合规同学对齐，避免用户实际使用到的模型和宣传不一致，引发误解。多模型路由本身是正常工程实践，但对外宣传要透明。

5. 实测中容易翻车的五个点

这一部分全部来自实际踩坑。不算全面，但都是高频问题。

5.1 结构化输出不稳定

这是底层任务最常见的问题。让模型返回 JSON，它偶尔会给你一段 Markdown 代码块，或者在 JSON 前后夹带解释。“今天是晴天，以下是提取结果：json ...”，这种输出看起来没问题，但json.loads直接报错。

解决办法有几个层次：优先开启平台提供的 JSON 输出模式，没有就靠提示词强约束，输出前明确写“只输出 JSON，不要任何解释”；再加一层代码兜底，从返回文本中用正则截取 JSON 片段。判断标准是：解析失败率要无限接近 0，出现一次都不能放过。

5.2 超时和限流被当成模型“变笨”

请求偶尔超时，或者报限流，很多人第一反应是“这个模型不行”，然后立刻换模型。实际上超时和限流很可能是自己的问题：并发设太高、没有重试、网络不稳定、请求体太大。

排查顺序应该是：先看错误码，确认是限流还是超时；再看自己的并发数和重试策略；最后再看是不是模型本身响应变慢。不要一限流就换模型，新模型可能限流更狠。把并发数降下来、把重试加上，很多“模型不行”的问题会自动消失。

5.3 安全过滤返回被前端误展示

国内大模型平台都有内容安全机制，输入或输出触发后会返回特定错误或者空内容。如果台前直接把原始错误信息抛给用户，用户会看到“请求被拒绝”之类的话，体验非常差。

正确的做法是在前端捕获这类错误，统一转换成友好提示，比如“这个问题我暂时无法回答，请换个方式问问”。底层任务里遇到安全拦截，不要重试，先检查输入文本本身是否合规，再决定是否需要拆句、改写后重新提交。

5.4 Token 口径不一致导致超长

不同平台的 Token 计算方法不一样，中文场景尤其明显。同一个上下文长度，在平台 A 可能算 3000 Token，在平台 B 可能算 3800 Token。如果你的代码按固定 Token 数切割文本，很可能会出现“我以为没超，实际超了”的情况。

长文档处理的稳妥方式是切块：按段落或者固定长度切片，逐块处理，再合并结果。每块之间保留少量重叠，避免语义断档。同时在代码里统一做一次 Token 估算，不要靠感觉判断上下文是否超长。

5.5 版本升级带来的静默行为变化

模型是持续迭代的，今天调好的提示词，平台更新模型版本后，结果可能完全不同。台前模型换版本，用户马上能感觉到；底层模型换版本，可能要三天后从报表里看出异常。

应对办法是：生产环境尽量锁定模型版本，升级前先在固定评估集上跑一轮回归测试。评估集不用大，二十到五十条业务真实样例就够了，关键是能暴露行为变化。我见过最典型的情况是，底层批量任务在某天突然解析失败率升高，查了半天，最后发现是模型版本被平台自动切换了。

6. 落地顺序：先单模型，再分层，最后再优化

看到这里，你可能觉得要把路由、降级、监控全部做上才有安全感。我的建议恰恰相反：先不要搞那么复杂，按下面这个顺序一步步来。

6.1 第一步：固定评估集

无论台前还是底层，先准备一个固定评估集。从真实业务里挑 20 到 50 条样例，每条写清楚正确输出是什么、可接受范围是什么。比如“抽取合同金额，输出必须是数字，单位单独标注”。没有评估集，你根本无法判断一个模型是变好了还是变差了，所有调参都靠感觉。

6.2 第二步：加第二模型做兜底

先做最简单的主备关系，不要做复杂路由。主模型正常时全走主模型，主模型连续失败或超时，自动切到备用模型。跑一段时间，重点看三个数字：整体成功率、备用模型调用占比、总成本。这一步先把“不会因为单模型故障导致全盘崩掉”这个目标实现。

6.3 第三步：根据日志持续调路由

当主备模式稳定了，再开始看日志做精细化路由。观察哪些任务在哪个模型上更稳定、成本更低，然后把这些任务单独分流。比如发现短文本分类在文心上更稳、长文本对话在千问上体验更好，就按任务长度或者任务类型做路由规则。

每调整一次路由，都要回到评估集上验证，同时盯降级触发率和成本报表。真正稳定运行一段时间后，你自然会把“根据场景自动选模型”这件事做得越来越细。

最后说回那句“千问台前折腾，文心底层无声”。真正跑过一段时间就会明白，台前折腾不是坏事，说明产品还在快速迭代；底层无声也不是万事大吉，反而更需要盯着成功率、解析失败率和成本曲线。与其纠结哪家模型最强，不如先把每一层该负责的事情定义清楚，让两个模型各干各的、互相兜底。先把单任务跑稳，再谈分层和路由；先把日志做全，再谈优化。这套顺序，比任何一次模型切换都重要。