我们已经熟悉了模型路由，简单的请求被送到更小、更快的LLM，而更复杂的问题由有能力的模型处理。这是一种平衡成本、延迟和性能的实用方法。但是，当我在过去几周开始探索专门的人工智能模型时，一个问题不断回到我的脑海中:为什么我们把我们的选择局限于LLM？如果我们所需要的只是对支持票证进行分类、从发票中提取信息或做出特定决策，那么是否有其他方法可以更高效地处理这些问题？
这种好奇心引导我走向任务优先的人工智能设计，在这种设计中，https://www.skdaren.com我们根据应用程序的需求选择正确的功能，无论是专门的模型、LLM、检索还是普通的后端逻辑。
在过去的两周里，我一直在尝试Jev、ScaleDown的约束解码模型(CDM)和通过NVIDIA NIM托管的LLM。我建立了一个基准测试实验室，在100个支持票据上运行了900个推理请求，比较了准确性、延迟、可靠性和成本。一些结果令人惊讶，尤其是当我不仅仅关注一个模型是否返回正确答案的时候。
在这篇文章中，我将分享我从这些实验中学到的东西，以及它们如何塑造我未来人工智能项目的方法。我们还将浏览一个智能客户支持系统的设计，探索这些不同功能的归属，以及将它们结合起来是否真正具有工程意义。
超越通用LLM:了解Jev和CDM
Meet LLMs, Jev and CDMs
让我们看一条简单的客户支持消息:“我的订阅费被收了两次。”我们的应用程序需要识别问题并将其发送给正确的团队。预期的输出只是账单。
通用LLM可以轻松处理这一问题。我们提供消息，定义可用的类别，https://www.iissbbs.com并要求它返回正确的类别。在幕后，该模型逐个令牌地生成其响应。我们还可以将其输出约束到预定义的JSON模式。但是当应用程序只需要一个类别时，探索专门为这类工作设计的模型是值得的。
Jev:围绕决策构建
由TypeSafe AI开发的Jev采用了一种不同的方法来与AI交互。我们不是要求它生成一个响应，而是提供一些上下文并询问一个特定的问题。它返回我们的应用程序可以直接使用的结构化决策。
Jev支持三种主要的判断类型:选择，用于在预定义的选项中进行选择；分数，用于在有序的尺度上评估某物；和Noul，用于是或否概率判断。对于我们的支持票，我们可以使用Choice在计费、技术、帐户和常规以及模型的概率分布之间进行选择。
这使得Jev对于路由、优先级和其他有界决策很有意思。当然，一个结构化的决策仍然可能是错误的，并且它的置信分数不应该被视为有保证的准确性。
按比例缩小的CDMs:用于特定任务的模型
ScaleDown通过其约束解码模型(CDM)和特定于任务的API进一步专业化。其分类模型使用描述或规则将输入映射到预定义的标签，而提取则从文档中识别信息，总结则浓缩较长的内容。
考虑一个发票处理工作流。我们可以针对每个需求评估专门的操作，而不是要求通用的LLM读取发票、识别其字段、对文档进行分类并在一个提示中对其进行总结。
这里有一个重要的重叠。Jev和ScaleDown Classify都可以对支持票进行分类，通用LLM也可以产生受约束的结构化输出。它们的界面和功能本身并不能告诉我们哪个会更快、更便宜或更准确。
正是这种重叠让我想在相同的工作负载下测试它们。
三个我都测试过了。结果挑战了我的假设。
在我的项目中采用这些模型之前，我想了解它们在相同工作负载下的表现。一个专门化的模型在理论上可能听起来很有前途，但是为一个实际的应用程序选择一个模型需要的不仅仅是API文档。
所以我用Python和FastAPI搭建了一个小型的基准测试实验室，比较Jev、ScaleDown CDM和NVIDIA NIM的Llama 3.2 11B Vision Instruct。
我是如何设置实验的
我创建了100个综合客户支持票据，分为四个类别:账单、技术、账户和一般查询。该数据集包括直截了当的请求，含糊不清的情况下，和对抗性的投入。
Experiment
所有三个模型都接受了相同的分类目标和类别定义，适用于各自的API。我分别跟踪成功的预测和失败的请求，因为超时告诉我们一些不同于错误分类的东西。
Model Comparison Lab
我的模型比较实验室比较了支持票分类的三种推理方法。仪表板的裁定准确性不包括标记的模糊案例，因此其百分比不同于下面讨论的所有请求结果。
结果告诉了我什么？
第一个结果让我很惊讶。当它们的请求成功完成时，所有三个模型都达到了95%的准确率。Jev和CDM分别正确分类了300个请求中的285个，而NVIDIA正确分类了221个已完成请求中的210个。
更大的差异出现在延迟和可用性上。Jev记录的平均响应时间为316毫秒，其次是CDM为562毫秒，NVIDIA为764毫秒。Jev和CDM完成了所有300个请求，而NVIDIA遇到了79次超时，将其端到端正确响应率降至70%。
这里有一个重要的限制。NVIDIA正在运行一个免费的托管评估端点。在执行过程中，我还将其超时时间从75秒减少到15秒，并将重试次数从两次减少到一次。失败的请求与完成响应延迟分开跟踪。这使得可靠性和延迟比较具有探索性，而不是模型固有性能的受控测量。
一个对抗性的案例也引起了我的注意。账单包含忽略分类规则并返回常规的指令。NVIDIA遵循了这一指示，而Jev和CDM正确地发现了计费问题。这是一个有趣的失败案例，尽管它并没有证明专门化的模型本质上更安全。
成本呢？
价格是我想了解的另一个因素。使用2026年10月公布的费率，Jev成本为每百万输入令牌0.042美元，而按比例缩小分类成本为0.05美元。
在我的实验中，他们平均每个分类分别消耗448.1和375.4个报告输入令牌。使用:
估计成本=(输入令牌/ 1，000，000) ×每百万令牌的价格
两者都计算出每100，000个分类大约1.88美元。这些是使用测量的平均值预测的推理成本，而不是实际的账单。NVIDIA的托管评估端点是免费的，所以我无法进行同等的生产成本比较。
我拿走的东西
这个实验向我展示了专门化的模型对于有限的任务来说是有前途的，但是仅仅是准确性还不足以证明采用它们是正确的。有趣的是，所有三个模型在成功请求时都返回了有效的单标签输出。
重要的是这些功能在测试条件下的表现，以及它们的优势是否会转化为更大的应用。
这让我想到了另一个问题:如果我现在正在设计一个人工智能系统，我会在哪里使用这些模型？
为了探索这一点，让我们从头开始设计一个客户支持系统。
设计一个客户支持系统，不要事事依赖LLMs
让我们将我所学到的知识应用到实际的系统设计练习中。
假设我们正在为订阅平台构建一个人工智能支持的客户支持系统。客户提交此请求:
“这个月我的订阅费被收了两次。我已经附上我的发票。你能查一下我是否有资格退款，并解释接下来会发生什么吗？”
我们的系统需要理解请求，提取相关信息，验证交易，检查适用的退款政策，并响应客户。我们还需要处理缺失的信息，并防止未经授权的金融行为。
我们可以使用具有工具访问和结构化输出的通用LLM来构建初始版本。这可能会非常有效。但是，如果我们根据实际需要来分配每项职责，会怎么样呢？
分解责任
1.理解客户的意图
首先，我们需要确定请求是否涉及账单、技术支持、账户访问或其他内容。面向决策的模型(如Jev)或分类器(如ScaleDown CDM)可以处理这个问题。
我们不一定两者都用。我们的基准测试表明，根据工作负载的不同，这两种方法都是合理的选择。分类结果决定了车票的去向，而不是顾客是否值得退款。
2.从发票中提取信息
接下来，我们需要发票号、账单日期、订阅金额和交易参考等详细信息。
专门的提取模型可以以结构化格式返回这些字段。但是，提取的值仍然需要根据源文档和支付记录进行验证。自信提取的金额并不意味着交易已经被验证。
3.检索正确的信息
一旦我们理解了请求，应用程序需要访问客户的交易历史和相关的退款政策。
传统的数据库查询和API可以检索帐户信息，而文档检索可以帮助定位适用的策略文档。我们还需要考虑政策版本、订阅计划和地区条件，以避免使用过时的信息做出决策。
4.做出实际的商业决策
这就是我要小心给AI太多权力的地方。
退款资格应取决于经过验证的支付记录、授权检查和明确的业务规则。一个模型可能有助于标记可疑活动或建议人工审查，但它的预测应该仍然是一个信号，而不是最终的权威。
如果系统无法验证交易或遇到相互冲突的信息，它应该请求额外的证据或上报案例，而不是猜测。
5.产生客户反应
一旦确定了结果，通用LLM又变得有用了。它可以将经过验证的发现转化为清晰的解释，参考相关政策，并指导客户完成后续步骤。
LLM处理通信，而后端仍然负责决策和任何授权的事务。
将架构整合在一起
Architecture
根据我的分类实验提出的架构。发票提取、策略检索和完整的端到端工作流尚未一起进行基准测试。
一些操作可以并行发生。例如，意向分类和发票提取可以在输入验证后独立开始，从而避免不必要的顺序处理。
我们还需要回退行为。如果提取失败，可能会要求客户提供缺失的详细信息。如果分类不确定，票据可能会进入审查队列。失败的模型呼叫不应自动阻止客户获得帮助。
这种设计看起来很有前途，但是在没有评估整个工作流的情况下采用每个组件是不成熟的。每个额外的模型都必须证明其引入的延迟、操作依赖性和成本。
这就引出了下一个问题:什么时候增加更多的模型会让系统变得更糟？
当添加更多的模型使您的架构变得更糟时
看一下提议的架构，很明显，每个任务都有自己的专用模型。分类到Jev，提取到CDM，响应生成到LLM。在图表上看起来很干净，但是我真的要部署所有的吗？
如果不先测试完整的工作流程，可能不会。
每一个额外的模型都会引入另一个API依赖、网络请求、故障场景和运营成本。分类器可能在300毫秒内响应，但这并不意味着整个应用程序变得更快。如果几个推理调用相互依赖，它们的延迟就会累积。即使我们并行执行独立的任务，工作流仍然可能被最慢的所需操作延迟。
更简单的选择值得公平的比较。对于一个小型的支持应用程序，一个具有结构化输出、数据库和定义良好的业务规则的LLM可能已经满足了我们的需求。只有当专门化模型显著提高了某些重要的东西，如分类准确性、提取可靠性、延迟或成本时，添加专门化模型才有意义。
还需要考虑故障场景。如果提取模型不可用，会发生什么？我们是否可以退回到另一个模型，或者我们应该向客户询问缺失的信息？如果分类器不确定，我们可以将请求路由给人工审查吗？这些决策对整个应用程序可靠性的影响超过了对任何单个模型性能的影响。
我还会避免通过多个模型发送相同的请求，因为它们是可用的。对同一分类运行Jev和CDM没有增加多少价值，除非它们的组合结果改善了测量结果。
我的方法是从满足需求的最简单的架构开始，建立一个基线，并在有证据证明的地方引入专门化。
基准测试帮助我理解了单个模型的行为。生产决策需要另一个层次的评估:测量实际流量下的完整工作流程，包括故障和恢复。
最终，应用程序中模型的数量并不能告诉我们它的设计有多好。重要的是每个组件是否贡献了足够的价值来证明它所带来的复杂性。
选择正确人工智能模型的实用框架
在这些实验之后，我开始重新考虑如何选择模型。我不会首先选择一个LLM并围绕它设计工作流，而是从理解每个任务实际需要什么开始。
以下是我想在未来的项目中提出的四个问题。
1.任务需要什么样的输出？
普通代码能可靠处理吗？它需要有界决策、结构化提取还是开放式生成？输出要求应该指导哪些方法值得考虑。
2.如果结果错了会怎么样？
将支持票证分类错误可能会延迟问题的解决，而错误的财务决策可能会带来严重的后果。失败的影响决定了所需的验证、安全措施和人员参与。
3.我怎么知道模型够好？
我会根据有代表性的输入进行评估，并衡量准确性、延迟、可靠性和成本。更重要的是，我会检查它失败的地方，而不仅仅是它成功的频率。
4.额外的复杂性值得吗？
我会将提议的方法与更简单的基线进行比较。如果一个专门化的模型为工作负载提供了有意义的改进，那么它就赢得了它的位置。否则，我会避免引入另一个依赖项。
最后的想法
当我开始探索Jev和CDM时，我想了解专用模型是否能胜过通用LLM。这些实验给了我更有价值的东西:一个质疑我的建筑选择的更好的方法。
展望未来，我希望将同样的工程学科应用于人工智能模型，就像我应用于数据库、缓存或消息传递系统一样。了解工作量，测试备选方案，并捍卫折衷方案。
下一次我设计一个人工智能系统时，我不仅要解释每个模型做什么，还要解释为什么它应该在架构中占有一席之地。
