Laya AI：模型选择与 API 集成指南

Laya AI 将上下文转化为范围明确的决策：一个类别、一个有序评分，或某个是非命题为真的概率。 当应用已经知道可能的结果，却需要帮助从中做出选择时，Laya 模型就有用武之地。Laya API 通过 HTTP 接口提供这类决策，但模型与提供接口的服务是两个不同层面。

假设客服收到一条消息：“更新后结账功能就不能用了，客户无法付款。”应用需要确定负责团队、优先级，也可能需要标记是否应由人工审核。每个决策并不一定都需要先生成一段文字。可以从 Laya AI 在线体验区开始，用自己的样本探索这种方式。

本指南沿着这一工作流，依次介绍模型选择、API 请求和生产环境评估。模型资料来自上游项目；接口说明针对 thejevai.com 提供的服务。资料核对日期为 2026 年 9 月 28 日。示例和插图用于解释集成方式，并非实测性能结果。

目录

• 什么是 Laya AI
• 理解三种决策类型
• 为自己的任务选择 Laya 模型
• 调用 API 前先设计决策
• 发送第一个 Laya API 请求
• 处理限制、错误与积分
• 自动化前先评估决策
• 逐步上线有价值的工作流
• Laya AI、模型与 API 常见问题
• 资料来源与维护

什么是 Laya AI

Laya 是 Convai Innovations 发布的开放权重决策模型系列，采用 Apache-2.0 许可证。它使用非自回归架构，对预先定义的答案进行评分，而不是逐个 token 生成回复。英语检查点采用 ModernBERT，多语言检查点采用 mmBERT。上游 Python 包内置路由器，并支持本地推理。

这种架构适合分类、路由和目标明确的评估。生成式模型可以负责起草客户回复，Laya 则提供路由信号。两者可以配合使用，因为它们承担的输出职责不同。

应当区分以下三个层面：

层面	需要选择什么	需要验证什么
模型	检查点、具体版本、运行时	在自身任务上的准确率
API	身份验证、请求与响应格式	限制、可用性、实际部署方式
应用	允许的操作与回退规则	某个决策是否可以触发操作

结构化输出能简化集成，但合法的标签仍然可能判断错误。同样，开放许可证不会消除托管成本，某块 GPU 上的基准成绩也无法确定你的应用响应时间。

理解三种决策类型

Choice：选择一个具名结果

对于 billing、technical 和 other 这类含义清晰的类别，可以使用 choice。答案中的 choice 字段给出选中的标签，响应还可能包含概率字段。类别描述应足够明确，让不同的人都能一致地应用相同规则。

例如，“被扣了两次钱”属于账单问题，“结账页面崩溃”属于技术问题。如果一条消息同时包含这两个问题，就要明确哪个问题决定路由。other 只是你定义的兜底类别，并不自动表示模型检测到了不确定性。

Score：在有序量表上评分

当顺序有意义时，使用 score。实用的紧急度标准可以区分日常咨询、存在替代方案的工作阻塞，以及没有替代方案的服务中断。托管接口采用从零开始的量表，返回值可以包含小数。

在三级量表中，1.8 位于第二级和第三级之间，不代表发生服务中断的概率是 80%。应用需要明确如何处理中间值；评估时，也应把严重低估优先级与相邻等级之间无害的分歧分开统计。

Noul：估计一个具体命题

对于“客户是否明确要求退款”这类目标明确的是非问题，使用 noul。它的值是概率估计，不是布尔值。不要用 JavaScript 的 Boolean(value) 转换它：即使很小的正数也会变成 true。

识别出的意图与操作授权需要分开处理。“客户要求退款”并不能证明确实发生了重复付款，也不能证明允许退款。这些检查应依赖已验证的记录和应用策略。

为自己的任务选择 Laya 模型

Laya 模型概览介绍了模型系列及其决策接口。在上游项目中，主要选项是英语检查点、多语言检查点，以及针对特定类型化决策工作流微调的检查点。

候选模型	适合首先尝试的任务	评估重点
英语	以英语输入为主的任务	领域词汇与模糊标签
多语言	非英语或混合语言输入	实际收到的各类语言分别表现如何
Typed-decisions	与其专门训练场景相近的工作流	能否适配自己的标签、策略和文档

托管 API 接受 english、multilingual 和 typed-decisions 作为请求标识。这些标识属于公开接口约定，不能证明服务使用了某个固定版本的检查点。 当前项目实现采用了服务提供方适配层。将托管响应作为某个开放权重检查点的能力证据之前，应先确认实际提供推理的模型及其版本。

若要进行可复现的模型比较，应在相同条件下运行固定版本的检查点。记录软件包版本、模型版本、设备、问题措辞和上下文设置。不要假设托管服务暴露了本地 SDK 中的全部设置。

语言覆盖也需要实际测试。多语言模型声称覆盖广泛，不等于它对不同语言、俚语、音译文字或混合语言工单具有相同准确率。应按这些条件分别统计结果，而不只是报告总体平均值。

如果分类体系包含几十个高度相似的标签，可以测试两阶段设计：先选大类，再选该类别下的专门队列。这样能让每个标签的描述更清晰，但第一阶段也可能把请求送入错误分支。应将完整流程与单阶段基线比较，把额外延迟以及纠正首次选择错误的能力一并纳入评估。

调用 API 前先设计决策

先写清楚决策规范，包括输入证据、允许的结果和后续影响。在客服分流中，模型可以建议队列与紧急度；谁有权退款或修改账户，仍由现有权限系统决定。

用足够完成任务的最少上下文构造 state。包含当前客户消息和相关的已验证事实。如果只有最新的故障报告有用，就不必传入完整对话历史。若判断需要某个账户状态，应明确提供，而不是期待模型推断它看不到的数据。

问题应当在独立评估时仍然成立。同一次请求中的优先级问题，不应依赖读取路由问题的答案。如果一个决策确实依赖另一个，就应在应用代码中将它们编排为不同步骤。

集成前，准备一组小型挑战样本：简单的账单问题、技术故障、混合诉求、无关消息、非英语工单，以及证据不足的消息。还要加入否定表达，例如“我不是要求退款”。这些样本可以迅速暴露标准含糊的问题，而顺利案例的演示往往会掩盖它们。

发送第一个 Laya API 请求

Laya API 集成文档说明了本站接口、身份验证和响应封装格式。创建账户 API 密钥，确保积分充足，并将密钥保存在服务端环境变量 LAYA_API_KEY 中。

向 https://thejevai.com/laya/v1/systemone 发送 POST 请求，使用 Bearer 身份验证和 JSON 请求体。API 路径没有语言前缀。应由后端进程发起请求，避免密钥进入浏览器代码包。

将以下示例保存为 laya-triage.mjs，设置环境变量后，用 Node.js 18 或更新版本运行。它只发送一次请求，不会自动重试可能产生费用的操作。示例中的英语输入和 english 模型保持对应。

const apiKey = process.env.LAYA_API_KEY;
if (!apiKey) throw new Error('Set LAYA_API_KEY on the server.');

const payload = {
  model: 'english',
  state: {
    message: 'Checkout crashes for every customer. Nobody can pay.',
    verified_status: 'No workaround has been confirmed.',
  },
  questions: {
    department: {
      type: 'choice',
      instructions: 'Which team owns the reported problem?',
      criteria: {
        billing: 'Charges, invoices, or refund requests',
        technical: 'Software failures or unavailable services',
        other: 'Issues outside billing and technical support',
      },
    },
    urgency: {
      type: 'score',
      instructions: 'Assess urgency using only the supplied evidence.',
      criteria: [
        'Routine question; work is not blocked',
        'Work is blocked but a workaround is confirmed',
        'Service is unavailable and no workaround is confirmed',
      ],
    },
    refund_requested: {
      type: 'noul',
      instructions: 'Does the customer explicitly request a refund?',
    },
  },
};

const response = await fetch('https://thejevai.com/laya/v1/systemone', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${apiKey}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify(payload),
  signal: AbortSignal.timeout(45_000),
});

const body = await response.json();
if (!response.ok || body.code !== 0) {
  throw new Error(`Laya request failed: HTTP ${response.status}`);
}

const answers = body.data?.result?.answers;
const department = answers?.department;
const urgency = answers?.urgency;
const refund = answers?.refund_requested;
if (
  department?.type !== 'choice' ||
  !['billing', 'technical', 'other'].includes(department.choice) ||
  urgency?.type !== 'score' ||
  !Number.isFinite(urgency.score) ||
  urgency.score < 0 ||
  urgency.score > 2 ||
  refund?.type !== 'noul' ||
  !Number.isFinite(refund.noul) ||
  refund.noul < 0 ||
  refund.noul > 1
) {
  throw new Error('Unexpected decision output; send this case for review.');
}

console.log({ answers, creditsUsed: body.data.creditsUsed });

从 data.result.answers 读取答案，使用请求时提供的问题 ID 查找。既要检查 HTTP 请求是否成功，也要检查 code === 0。使用结果前，应验证返回类型、标签和数值范围。示例只打印结果；将错误接入人工审核队列，需要由应用自行实现。

响应还会在 data.result 下提供 token 用量和请求耗时，并在 data.creditsUsed 中给出实际扣除的积分。示例响应里的耗时或费用并不承诺未来请求也会相同。应另外记录客户端端到端延迟，与服务端报告的耗时区分开。

处理限制、错误与积分

截至核对时，托管接口接受的 UTF-8 JSON 请求体最大为 32 KiB，每次包含 1–8 个问题。Choice 问题允许 2–100 个选项，Score 问题允许 2–10 条有序描述。已登录的在线体验区请求至少间隔三秒，这项体验区规则不应被描述为所有 API 密钥通用的限流规则。

推理请求的超时时间为 30 秒。客户端需要为网络传输和完整响应预留额外时间，但延长客户端超时，并不能延长服务自身的推理时限。

HTTP 状态码	含义	合适的处理方式
400	请求无效	修正字段或判断标准
401	身份验证失败	检查服务端密钥
402	积分不足	补足账户余额
413	请求体过大	缩减上下文或拆分任务
429	请求间隔过短	响应提供 Retry-After 时遵循它
502	推理失败或返回了无效数据	检查失败原因后再决定是否重试
503	服务不可用	使用回退方案或稍后再试

接口文档没有提供幂等键。客户端超时后，第一次请求仍可能完成并产生费用。因此，盲目重试可能导致重复工作和重复扣费。保留本地任务状态，在可行时核实执行结果，并明确制定重试决策。

请求大小与模型上下文也要分开考虑。通过 32 KiB 的 HTTP 限制，不代表每句话或每个选项都能完整保留在检查点的 token 预算内。长输入和大标签集合需要专项测试。

自动化前先评估决策

从经过适当处理的真实工作流样本构建评估集。调整阈值的数据应与最终测试集分开。划分数据时，让相关消息留在同一分组，防止高度相似的工单跨越训练集、验证集和测试集造成泄漏。

根据实际后果衡量各类输出。路由要看混淆矩阵，以及各类别的精确率和召回率。紧急度除平均误差外，还要统计严重低估的情况。退款意图检测应覆盖明确请求、否认、假设性讨论和引用他人消息等样本。

校准需要单独检查。将预测概率接近的样本分组，与实际发生频率比较。如果置信度约为 0.8 的预测只有一半正确，那么基于这些数值设置的阈值，其实际表现就会与直觉不同。拟合任何校准调整时，都不能使用最终测试集。

上游模型卡列出了重要局限，包括过度自信，以及对标签 token 预算的敏感性。它还描述了一种 noul 失败模式：选项标签可能压过输入内容，主导答案。如果二元输出似乎总是不变，应使用相反含义的样本调查，并与两个选项的 choice 写法比较。没有测量之前，不要假设这种替代方式一定有效。

将弃答视为一种权衡。覆盖率指自动处理的样本比例，选择性错误率指这些自动处理样本内部的错误率。提高阈值可能减少自动化比例，同时增加人工审核队列。应同时报告这两个指标和审核工作量，而不是只展示越来越小、越来越容易的样本子集上的准确率。

也要设置一个简单基线。对确定的故障代码应用规则，或使用现有队列分类器，可能已经能低成本解决部分问题。用相同输入和结果定义，将 Laya 与该基线比较。保留简短的错误记录，列出典型失败及其原因，每次只调整一个因素：问题措辞、提供的证据、检查点或阈值。这样能解释改进来源，也能减少反复调试演示、直到它表面上令人满意的倾向。

逐步上线有价值的工作流

先以影子模式运行：记录建议，但仍由现有流程决定实际结果。将模型决策与人工处理结果比较，查看分歧集中出现在哪些场景。反复出现的错误可能意味着标签不清晰、上下文不足、语言不匹配，或模型并不适合该任务。

接着让工作人员在执行前审核建议。这样可以了解审核成本、评分是否易懂，以及建议的路由是否真正节省时间。只有当实测错误率和业务收益支持时，再自动执行范围较小且可撤销的操作。

客服试点应在启动前定义成功标准：可接受的错误分流程度、严重紧急事件的最大漏判量、审核能力，以及服务失败时的回退方案。保留一个能恢复原有路由的简单开关。审核人员应能纠正标签，而不在无意中改变底层策略；这些纠正结果应进入下一轮评估数据集。

记录足以复现失败的元数据，包括自己的请求标识、Schema 版本、提交的模型标识、能够获得的服务版本信息、延迟、费用和最终结果。尽量少存储客户内容。跟踪输入语言、标签频率和审核量的变化，因为它们可能比总体准确率更早暴露漂移。

应从完整工作流比较经济性。托管积分、自建推理算力、工程维护、人工审核和错误操作都会产生成本。关于更广泛的部署取舍，可以阅读 Jev 与 Laya 对比。选择在你的实际证据与运维约束下表现良好的方案。

Laya AI、模型与 API 常见问题

Laya AI 是聊天机器人吗

它的核心用途是范围明确的决策。可以用它选择、评估或分类；如果需要开放式文字输出，则使用生成式模型。应用可以把两者结合起来。

Laya 模型免费吗

已发布的权重采用 Apache-2.0 许可证。运行模型仍然需要算力和运维投入。本文介绍的托管服务会消耗账户积分，开放权重不等于免费托管请求。

Laya API 会自动选择检查点吗

本站 API 要求明确提供模型标识。上游本地 SDK 带有路由器，但不能假设它的路由行为与选项适用于每一种托管服务。

Laya 的概率可以授权操作吗

概率可以为策略提供参考，但无法建立权限，也无法验证输入中不存在的事实。有实际影响的操作应由应用检查和适当的审核流程把关。

应该先用本地推理还是托管 API

可以用托管接口探索请求约定和工作流。如果需要针对特定检查点做实验，或掌控基础设施，则使用固定版本的本地推理。两种方式都应使用同一组有代表性的样本评估。

资料来源与维护

Laya 上游仓库提供安装、路由、服务部署和运行时选项的文档。Convai Innovations 模型卡介绍检查点、架构、评估和已知局限。托管请求细节已于 2026 年 9 月 28 日根据上文链接的两份站内指南及本项目接口实现核对。

部署前应重新确认推理后端、限制和模型版本。从一个真正重要的决策开始，用真实样本测量它，等证据充分后再扩大自动化范围。