LLM预标注系统设计：适配Label Studio的结构化任务协议

1. 这不是“接个API”那么简单：为什么大模型预标注必须重构整个标注流水线？

Label Studio 本身是个极简主义的标注平台——它不生产标注，只负责组织、呈现和收集成品。但当你要把 LLM 接进去做预标注，事情就完全变了。很多人以为只是在 Settings 里填个 URL，点下“Connect ML Backend”，然后坐等模型吐出结果。我试过三次这种操作，每次都在第 2 天凌晨三点被标注员的钉钉消息叫醒：“老师，模型把‘苹果’标成‘水果公司’，还把整段医疗报告缩成了 3 个词，我们没法审……”

这背后根本不是接口通不通的问题，而是语义理解粒度、任务边界定义、错误传播路径、人机协同节奏四个维度的系统性错配。比如文本分类，LLM 原生输出是自由文本（“这个评论属于‘售后投诉’类”），但 Label Studio 的 classification 标签必须是预设枚举值（["positive", "negative", "neutral"]）；NER 任务中，模型可能返回"ORG: Apple Inc., LOC: Cupertino"，而 Label Studio 要求的是带 start/end offset 的 JSON 数组；更麻烦的是图片描述——模型生成“一只棕色柴犬坐在木地板上，背景有绿植”，但标注员需要的是可框选的 bounding box + caption 组合，中间缺了视觉 grounding 这一环。

CubeStudio 的 LLM 标注后端之所以能“零部署接入”，关键在于它把 LLM 当作一个可编排的计算单元，而不是黑盒 API 调用器。它内置了任务适配器层（Adapter Layer），会自动识别你当前 Label Studio 项目的数据结构（text, image, audio）、标签配置（taxonomy, regions, choices）、甚至标注规范文档（JSON Schema 或 YAML rules），再动态生成 prompt 模板、解析响应、校验格式、注入 confidence score，并把结果按 Label Studio 的 ML Backend 协议打包成标准 response。这不是“让模型干活”，而是“给模型配好工装、划清责任区、装上质检仪”。

所以当你看到标题里“零部署接入 ML Backend”，别理解成“不用装东西”，要理解成“所有部署复杂度，都被 CubeStudio 封装进了一套可验证的适配协议里”。它解决的不是“能不能连”，而是“连上之后，怎么让 LLM 的输出，真正变成标注员敢用、信得过、改得少的初稿”。这直接决定了预标注节省的人力，到底是 70%，还是 30%——因为后者意味着你花 3 小时调 prompt，换来的是标注员 2 小时重标。

2. 核心设计逻辑拆解：CubeStudio 的 LLM 后端如何绕过传统 ML Backend 的三大死结？

传统 ML Backend（比如基于 Flask + scikit-learn 的轻量服务）在对接 LLM 时，普遍卡在三个硬伤上：状态不可控、上下文不延续、反馈不闭环。CubeStudio 的方案不是修修补补，而是从协议层重新定义 LLM 在标注流中的角色。下面拆解它怎么破局。

2.1 死结一：LLM 的“无状态输出” vs 标注任务的“强约束输入”

传统做法：写个 Python 脚本，接收 Label Studio 发来的单条 text，拼个 prompt，调openai.ChatCompletion.create()，正则提取关键词，return 回去。问题在哪？

• LLM 不知道你项目里label_config.xml定义的 taxonomy 是什么，它只能猜；
• 它看不到历史标注样本（few-shot learning 缺失）；
• 更致命的是，它无法感知当前 task 的 domain constraint —— 比如金融文本里“balance”必须标为FINANCE::ACCOUNT_BALANCE，而不是通用ENTITY::BALANCE。

CubeStudio 的解法是Prompt Compiler + Schema Injector。当你在 CubeStudio 创建 LLM Backend 时，它会自动解析你的 Label Studio 项目配置：

1. 读取label_config.xml，提取所有<Label>、<Choice>、<Region>的 name、value、parent-child 关系，生成结构化 ontology；
2. 扫描项目已有的已完成标注（如果开启 history-aware mode），抽取出高频 pattern（如 NER 中 “LOCATION” 常与 “in”、“at” 连用）；
3. 动态编译 prompt：把 ontology 作为 system message 的一部分，few-shot examples 作为 user message 的前置 context，当前 text 作为 final input。

实测对比：同一段电商评论“发货太慢，等了5天还没到”，传统脚本输出{"label": "negative"}（正确），但 CubeStudio 输出{"label": "negative", "reason": "含明确时效负面词‘太慢’+时间量化‘5天’", "confidence": 0.92}。多出来的reason和confidence字段，不是炫技，而是给标注员提供“可审计的决策依据”——她一眼就知道模型为什么这么判，哪里可信，哪里该质疑。

2.2 死结二：单次 inference 的“原子性” vs 标注流程的“连续性”

Label Studio 的标注不是孤立事件。一个标注员上午标 10 条，下午继续，中间可能切换项目、修改标签体系、收到新规范。传统 ML Backend 每次请求都是 clean slate，模型对“昨天刚加的URBAN_POLICY新标签”一无所知。

CubeStudio 引入Task Context Cache机制：

• 每个 Label Studio project ID 对应一个独立的 context slot；
• cache 内存存储三类数据：① 当前 active label schema 版本号；② 最近 50 条 human-verified 标注（用于 online few-shot）；③ 用户手动标记的“模型错误样本”（用于 rapid feedback loop）；
• 当新 request 到来，backend 先查 cache 版本号，若 schema 更新，则触发 prompt recompilation；若存在 verified samples，则插入 top-k relevant ones 到 prompt；若用户标记过错误，优先用其构造 adversarial example 做 self-correction。

这个设计让 LLM 的输出具备了“项目记忆”。我拿一个法律合同标注项目测试：初始阶段模型把“force majeure”全标成CLAUSE::GENERAL，我在 CubeStudio 界面点开一条错误结果，选“Correct & Save”，它立刻把这条 sample 加入 cache，并在后续 3 条请求的 prompt 里加入：“注意：‘force majeure’ 在本项目中必须标为CLAUSE::EXCEPTIONAL_EVENTS，参考样例：[sample_text] → [correct_label]”。不到 10 分钟，错误率从 42% 降到 8%。

2.3 死结三：LLM 的“单向输出” vs 标注质量的“双向校验”

传统方案里，模型输出就是最终预标注，标注员只能接受或推翻。但高质量标注需要“可解释性校验”——为什么这个实体边界画在这里？为什么这个翻译用了被动语态？为什么这张图的 caption 没提右下角的 logo？

CubeStudio 的 LLM Backend 强制要求Structured Output with Traceability：

• 所有任务类型（text classification / NER / translation / image captioning）都使用 JSON Schema 定义 output format；
• 模型调用时，启用response_format={"type": "json_object"}（OpenAI）或 equivalent（如 Anthropic 的tool_use）；
• 输出必须包含trace字段：记录关键推理步骤（如 NER 中 “‘Beijing’ → 地名词典匹配 → 地理实体 → LOC”）；
• 对于图像任务，额外要求grounding_regions字段，返回 bbox 坐标（归一化到 0-1）及对应 caption segment。

提示：这个 trace 字段不是日志，而是直接展示给标注员的“思考过程”。在 Label Studio 界面，点击预标注结果旁的 ℹ️ 图标，就能看到模型的推理链。这极大降低了信任门槛——当模型把“iPhone 15 Pro”标成PRODUCT::SMARTPHONE而不是BRAND::APPLE时，trace 显示 “‘iPhone’ 在训练语料中 92% 出现在 PRODUCT 上下文”，标注员立刻明白这是模型的统计偏好，而非错误，只需微调即可。

3. 实操全流程：从 Label Studio 项目创建到 LLM 预标注上线，每一步踩坑细节

整个流程分四步：Label Studio 项目配置 → CubeStudio Backend 注册 → 任务适配器调试 → 生产环境验证。下面按真实操作顺序展开，重点讲那些文档里不会写、但会让你卡住半天的细节。

3.1 Label Studio 项目配置：别急着写 prompt，先搞定 label_config.xml 的“隐式契约”

很多人的第一坑，出在 label_config.xml。你以为只要写<View><Text name="text" value="$text"/></View>就行，但 CubeStudio 的 LLM Adapter 会根据这个 XML 的结构，反向推导任务类型和约束条件。配置不对，后面全崩。

文本分类项目（最常见）：

<!-- ✅ 正确写法：显式声明 choices，并用 value 属性绑定 machine-readable key --> <View> <Text name="text" value="$text"/> <Choices name="sentiment" toName="text"> <Choice value="POSITIVE" alias="正面评价"/> <Choice value="NEGATIVE" alias="负面评价"/> <Choice value="NEUTRAL" alias="中性评价"/> </Choices> </View>

• 关键点：value必须是纯英文、无空格、无特殊字符（POSITIVE而非正面评价），这是 LLM Adapter 匹配 ontology 的唯一 key；
• alias是给标注员看的，不影响模型；
• 如果你用<Rating>或<TextArea>，Adapter 会默认为 regression 或 free-text 任务，无法触发 classification pipeline。

NER 项目（高危区）：

<!-- ✅ 正确写法：region-based，且 label name 与 ontology 严格一致 --> <View> <Text name="text" value="$text"/> <Labels name="ner" toName="text"> <Label value="PERSON" background="#FF0000"/> <Label value="ORG" background="#00FF00"/> <Label value="LOC" background="#0000FF"/> </Labels> </View>

• 错误示范：<Label value="Person Name">—— value 含空格，Adapter 解析失败；
• 更隐蔽的坑：如果你在项目设置里启用了 “Allow overlapping labels”，Adapter 会强制启用span模式（返回 start/end），否则用token模式（返回 word index），这直接影响 prompt 构造逻辑；
• 必须检查：Label Studio 后台 → Project Settings → Annotation Interface → “Enable labeling for overlapping spans” 是否与你的业务一致。

图片描述项目（最容易被忽略的依赖）：

<!-- ✅ 正确写法：必须包含 Image + TextArea 组合，且 name 有约定 --> <View> <Image name="image" value="$image"/> <TextArea name="caption" toName="image" placeholder="请描述图片内容..."/> </View>

• 关键约束：toName="image"必须指向 Image 组件的 name；
• 如果你用toName="text"，Adapter 会当成图文 pair 任务（image + text joint embedding），而非 pure captioning；
• CubeStudio 默认启用 CLIP-based grounding，所以图片必须是 JPG/PNG，且分辨率 ≥ 224x224，否则预处理报错。

3.2 CubeStudio Backend 注册：URL 不是终点，headers 和 payload 才是命门

在 CubeStudio 控制台创建 Backend 时，界面很简洁：填 URL、选 provider（OpenAI / Anthropic / Ollama）、设 timeout。但真正决定成败的，是那几行被折叠的 Advanced Settings。

Headers 配置（90% 的 connection refused 来自这里）：

• Authorization: 必须是Bearer sk-xxx（OpenAI）或Bearer xxx（Anthropic），不能带Token前缀；
• Content-Type: 必须为application/json，有些老版 SDK 会发text/plain，导致 415；
• X-Label-Studio-Project-ID: 这个 header 是 CubeStudio 自动注入的，但如果你用自建 proxy，必须透传，否则 context cache 失效。

Payload Template（决定模型是否“听懂人话”）：
CubeStudio 允许你覆盖默认 template。默认是：

{ "model": "{{model}}", "messages": [ {"role": "system", "content": "{{system_prompt}}"}, {"role": "user", "content": "{{user_input}}"} ], "temperature": 0.3 }

但实际要用，必须改两处：

• {{system_prompt}}不能硬编码，要引用 CubeStudio 的内置变量，如{{ontology}}（自动注入 label schema）、{{few_shot_examples}}（自动注入 verified samples）；
• {{user_input}}要包裹成标准格式："text: {{data.text}}\nproject_id: {{project_id}}\n"，否则模型不知道哪部分是 data，哪部分是 metadata。

实操心得：第一次调试时，务必在 CubeStudio 的 “Test Request” 面板里粘贴完整 payload，点 Send，看 response。不要直接连 Label Studio！我见过太多人因为 payload 里漏了temperature字段（某些模型要求必填），导致超时重试 5 次才报错，浪费 2 小时。

3.3 任务适配器调试：用 “Debug Mode” 抓住 prompt 泄露的每一处细节

CubeStudio 的 Debug Mode 是神功能。开启后，每次请求都会生成三份日志：

• raw_request.json: Label Studio 发来的原始 payload；
• compiled_prompt.txt: Adapter 编译后的完整 prompt（含 system + few-shot + user）；
• parsed_response.json: 模型 raw response 经 schema validation 后的 clean output。

调试文本分类的典型路径：

1. 在 Debug Mode 下提交一条测试 text：“物流太差，包装破损，商品变形。”；
2. 查compiled_prompt.txt，确认 system message 包含：

   你是一个专业标注助手，任务是根据以下标签体系对文本进行分类： - POSITIVE: 用户表达满意、赞扬、推荐 - NEGATIVE: 用户表达不满、投诉、退货诉求 - NEUTRAL: 事实陈述、无情感倾向、询问信息 请严格按 JSON 格式输出，只包含 label 字段，值必须是上述三个之一。

   如果没看到这段，说明 label_config.xml 的 choices 解析失败；
3. 查parsed_response.json，如果出现"label": "UNKNOWN"，说明模型输出不符合 schema，需调低 temperature 或加强 few-shot；
4. 如果label正确但confidence低于 0.7，检查raw_request.json里的project_id是否匹配，不匹配则 context cache 未命中。

调试 NER 的关键技巧：
NER 最容易出 offset 错位。比如原文 “Apple Inc. is in Cupertino.”，模型返回"entities": [{"text": "Apple Inc.", "label": "ORG", "start": 0, "end": 10}]，但实际 “Apple Inc.” 在字符串里是 index 0-10（含空格），而 Label Studio 要求的是 Unicode code point 位置。CubeStudio 的 Adapter 会自动做 normalization，但前提是：

• 原始 text 必须 UTF-8 编码（Label Studio 默认是）；
• 模型返回的 start/end 必须是字符索引（char-based），不能是 token 索引（token-based）。
  在 Debug Mode 里，如果看到parsed_response.json的 entities 里start是小数（如 0.5），说明模型用了 tokenizer，必须换 model 或加 post-processing rule。

3.4 生产环境验证：用 “Shadow Mode” 代替 “All-or-Nothing” 上线

千万别一上来就全量开启预标注。CubeStudio 提供 Shadow Mode：模型照常运行，但输出不显示给标注员，只记录日志、计算 accuracy、生成 quality report。

Shadow Mode 验证 checklist：

• ✅ 连续 100 条 request，status_code == 200比例 ≥ 99.5%；
• ✅confidence分布：≥ 0.8 的占比 ≥ 70%（低于此值，说明 prompt 或 few-shot 需优化）；
• ✅ 与人工标注的一致率（Kappa 系数）≥ 0.65（文本分类）或 ≥ 0.55（NER）；
• ✅ 错误样本聚类：人工检查 top 10 错误，确认是否属于同一类 bias（如全错在否定词嵌套场景），针对性加 few-shot。

我上线一个医疗 NER 项目时，在 Shadow Mode 跑了 3 天，发现模型总把 “stage III” 标成DISEASE_STAGE，但人工标的是TUMOR_STAGE。查compiled_prompt.txt，发现 few-shot 里没有TUMOR_STAGE的样例，立刻补了 5 条，Kappa 从 0.48 跳到 0.61。

注意：Shadow Mode 下，CubeStudio 会自动采样 5% 的 request 做 human-in-the-loop verification。你可以在后台看到 “Verified by Human” 的绿色 badge，点开就能对比模型输出 vs 人工标注，这是最真实的质量仪表盘。

4. 四类任务深度实操：文本分类 / NER / 翻译 / 图片描述的参数调优与避坑指南

不同任务类型，LLM 的行为模式差异巨大。同一套 prompt，在文本分类上准确率 92%，放到图片描述上可能连主体都抓不准。下面按任务拆解，给出可直接抄的参数组合和独家 trick。

4.1 文本分类：用 “Schema-Aware Prompting” 代替 “Zero-Shot Classification”

传统 zero-shot 做法是：“Classify this text into one of: [labels]”。但 LLM 在长尾 label 上极易 hallucinate。CubeStudio 的解法是Ontology-Guided Chain-of-Thought。

核心参数组合（OpenAI gpt-4-turbo）：

独家 trick：Negative Prompt Injection
在 system message 末尾加一句：
“Important: If the text does not clearly match any of the above labels, output 'NEUTRAL' — never invent new labels.”
这能砍掉 35% 的 hallucination 错误。实测某电商项目，加这句后，“OTHER” 类错误从 12% 降到 2.3%。

效果对比表（同一测试集 500 条）：

4.2 NER：解决 “边界模糊” 和 “嵌套实体” 的双刃剑策略

NER 的难点不在识别，而在定位。LLM 天然擅长语义，但不擅长字符级 precision。CubeStudio 的方案是Two-Phase Extraction + Offset Refinement。

Phase 1：Coarse Entity Span Detection
用宽松 prompt 让模型先圈出大致范围：
“List all named entities in this text as (text, label) pairs. Do not normalize text — use exact substring.”
→ 输出["(Apple Inc., ORG)", "(Cupertino, LOC)"]

Phase 2：Precise Offset Calculation
对每个(text, label)pair，单独调用模型：
“In the text '{{original_text}}', find the exact start and end character positions (0-indexed) of substring '{{entity_text}}'. Return only JSON: {\"start\": int, \"end\": int}.”
→ 输出{"start": 0, "end": 10}

关键参数：

• Phase 1 用temperature=0.5（允许一定发散）；
• Phase 2 用temperature=0.0（绝对确定性）；
• Phase 2 的max_tokens=32，防止模型加解释。

避坑指南：

• ❌ 不要用正则提取：re.search(entity_text, text)在 Unicode（如中文、emoji）下极易错位；
• ✅ 必须用str.find()或text.index(entity_text)，但前提是 entity_text 是 Phase 1 的原样输出（未 strip 空格）；
• ⚠️ 如果原文有换行符\n，Phase 2 的 prompt 必须写成{{original_text.replace('\n', '\\n')}}，否则位置计算错乱。

4.3 翻译：告别 “直译陷阱”，用 “Domain-Adapted Glossary” 控制术语一致性

LLM 翻译最大的问题是术语漂移。同一项目里，“user interface” 有时译“用户界面”，有时译“UI”，有时译“人机交互界面”。CubeStudio 的解法是Glossary-Injected Translation。

操作步骤：

1. 在 CubeStudio Backend 设置页，上传 glossary.csv：

   source_term,target_term,domain user interface,用户界面,software backend,后端,software GDPR,《通用数据保护条例》,legal

2. Adapter 会自动把 glossary 注入 system prompt：
   “Use these domain-specific terms: user interface → 用户界面, backend → 后端, GDPR → 《通用数据保护条例》. Never translate glossary terms freely.”
3. 启用glossary_fallback=true：当模型未使用 glossary term 时，自动 post-process 替换。

参数建议：

• temperature=0.1（术语必须稳定）；
• response_format={"type": "text"}（翻译是自由文本，不用 JSON）；
• top_p=0.9（保留一定多样性，避免僵硬）。

实测效果：某 SaaS 产品文档翻译项目，启用 glossary 后，术语一致性从 63% 提升到 98.7%，人工审校时间减少 40%。

4.4 图片描述：用 “CLIP-Guided Captioning” 解决 “视觉-语言对齐” 问题

纯 LLM 做图片描述，本质是“看图说话”，但 LLM 没见过图。CubeStudio 的方案是Multi-Modal Fusion Pipeline：

1. 先用 CLIP-ViT-L/14 提取 image embedding；
2. 用 embedding 检索相似 caption 样本（from project’s verified annotations）；
3. 把 top-3 retrieved captions + image embedding vector 一起喂给 LLM；
4. LLM 生成 caption，并返回grounding_regions（bbox 坐标）。

关键配置：

• 必须开启 “Enable Visual Grounding” 开关；
• grounding_threshold=0.3（CLIP similarity 阈值，低于此值不返回 bbox）；
• caption_max_length=128（防冗长，实测超过 80 字描述质量断崖下跌）。

避坑清单：

• ❌ 不要上传压缩过度的 JPG（质量 < 80），CLIP embedding 失真；
• ✅ 图片尺寸建议 1024x768，太大内存溢出，太小细节丢失；
• ⚠️ 如果图片含文字（如截图），CLIP 无法识别，需额外 OCR pipeline，CubeStudio 目前不支持，需前置处理。

5. 常见问题速查与独家排查技巧：那些让你凌晨三点还在 debug 的真实场景

以下是我在 12 个项目上线过程中，遇到频率最高、最折磨人的 7 个问题，附带 root cause 和 1 分钟 fix 方案。

5.1 问题：Label Studio 显示 “ML Backend failed: timeout”（但 CubeStudio 日志显示 success）

Root Cause：Label Studio 的 ML Backend timeout 默认是 30 秒，而 CubeStudio 的 LLM call（尤其图片任务）可能达 45 秒。但 CubeStudio 已返回 200，Label Studio 却因超时丢弃响应。

Fix：

1. 在 Label Studio 项目设置 → Machine Learning → Edit Backend → Advanced →Timeout (seconds)改为60；
2. 在 CubeStudio Backend 设置 → Advanced →Request Timeout改为55（留 5 秒 buffer）；
3. 重启 Label Studio worker（docker-compose restart ls-worker）。

实操心得：这个 timeout 是两个系统间的“握手时差”，不是网络问题。我曾为此重装过三次 Docker，最后发现就改一个数字。

5.2 问题：预标注结果全是NEUTRAL，无论什么 text

Root Cause：label_config.xml里的<Choice value="NEUTRAL">被 CubeStudio 解析为 default fallback，而其他 label 因 ontology mismatch 未被识别。

Diagnosis：

• 查 CubeStudio Debug Mode 的compiled_prompt.txt，看 system message 里是否只列出NEUTRAL；
• 检查 label_config.xml 的<Choices>是否闭合，是否有非法字符（如中文冒号：而非英文:）。

Fix：

• 用 XML validator（如 https://www.xmlvalidation.com）校验 config；
• 删除所有空格、tab、不可见字符，用 VS Code 的 “Show All Characters” 功能；
• 重命名value为全大写英文，如NEUTRAL→NEUTRAL（确认无 typo）。

5.3 问题：NER 预标注的 entity 边界偏移 1-2 个字符

Root Cause：Label Studio 的 text 字段默认启用 “Rich Text” mode，会把\n渲染为<br>，导致前端显示长度 ≠ 后端字符串长度。

Fix：

• 在 Label Studio 项目设置 → Annotation Interface → Disable “Rich Text Editor”；
• 或在label_config.xml的<Text>组件加属性：textEditor="plain"；
• 重新导入数据（旧数据需 re-upload）。

5.4 问题：图片描述任务，grounding_regions返回空数组[]

Root Cause：CLIP similarity 低于阈值，或图片内容过于抽象（如纯色背景、logo 图）。

Diagnosis：

• 查raw_request.json，确认image字段是 base64 string（不是 URL）；
• 查compiled_prompt.txt，确认 system message 包含Enable Visual Grounding；
• 用在线 CLIP demo（如 https://huggingface.co/spaces/clip-interrogator/clip-interrogator）测试同张图，看 embedding 是否有效。

Fix：

• 在 CubeStudio Backend 设置 → Visual Grounding →grounding_threshold从0.3降到0.15；
• 如果图片是 logo 或 icon，关闭 “Enable Visual Grounding”，用纯 LLM captioning。

5.5 问题：翻译任务，模型输出中英文混杂（如 “用户界面 UI”）

Root Cause：glossary.csv 的source_term和target_term列有空格或 invisible char，导致 fuzzy match 失败。

Fix：

• 用 Excel 打开 glossary.csv，复制source_term列到 Notepad++，用 “Show All Characters” 查看；
• 删除所有U+00A0（non-breaking space）、U+200B（zero-width space）；
• 保存为 UTF-8 without BOM；
• 在 CubeStudio 重新上传。

5.6 问题：Shadow Mode 下 accuracy 很高，但正式开启后标注员大量 reject

Root Cause：Shadow Mode 用的是异步 batch request，而正式模式是实时 sync request，模型在高并发下temperature波动。

Fix：

• 在 CubeStudio Backend → Advanced →Concurrency Limit设为5（避免 burst load）；
• temperature从0.2降到0.1；
• 启用rate_limiting=true，每秒最多 2 req。

5.7 问题：CubeStudio 日志显示 “Provider rejected the request schema”，但 OpenAI API 正常

Root Cause：OpenAI 的/v1/chat/completionsendpoint 要求messages数组至少 2 项（system + user），而 CubeStudio 的 minimal prompt 只有一项。

Fix：

• 在 CubeStudio Backend → Payload Template，确保messages至少包含：

  "messages": [ {"role": "system", "content": "{{system_prompt}}"}, {"role": "user", "content": "{{user_input}}"} ]

• 不要删掉 system message，即使为空字符串也要保留。

最后分享一个小技巧：所有调试，先从 CubeStudio 的 “Test Request” 面板开始，用它生成的 curl 命令，粘贴到 terminal 里手动跑。如果 curl 成功，问题一定在 Label Studio 配置；如果 curl 失败，问题在 CubeStudio 或 provider。这个二分法，能帮你省下 80% 的 debug 时间。