发生了什么
集团RESTART旗下公司 ООО «Инвент» 推出了“Polygon”——人工智能系统验收与负载测试平台。该平台部署于客户环境中，单次运行即可同时回答两个问题：AI助手可承载多少并发用户，以及在此负载下其回答质量是否下降。
该产品解决了当前需要手动填补的空白：负载测试工具无法评估响应质量，质量评估工具无法施加负载，而且这两类工具都无法生成可用于交付验收报告的文档。产品落地页—— polig-on.ru.
一次运行完成两根轴
Polygon按照指定的负载模式对AI系统进行压力测试——从单个请求到数百个并发用户——同时并行采集响应样本以评估质量。这两个维度（负载与质量评估）是在同一轮测试中、基于完全相同的流量进行计算的，而非在不同时间、使用不同数据通过两种独立工具分别完成。
加载
五种负载模式：单次请求、突发脉冲、阶梯式并发递增、带思考时间的持续背景负载、在时间窗口内随机到达。测试平台自动确定队列出现的拐点和系统失效的拐点。
HTTP 中不可见的拒绝
系统崩溃不仅通过返回码来判断，还要通过容器RESTART计数器的增长来检测：在负载下静默RESTART的系统，常规的压力测试无法发现。
引擎内部指标
队列和内存直接从推理引擎（vLLM）读取：实际正在执行的请求数量、排队等待的请求数量以及GPU显存占用量。
回答质量
在答案样本上评估相关性、完整性、与来源的一致性（groundedness）以及幻觉特征。每项评分均附有文字说明的评判依据，而非单纯的数字。
测试配置文件是唯一的真实来源：其中所设定的内容（负载配置文件、基准数据集、验收阈值）将在测试报告中逐字引用。
测试协议作为验收工件
运行的主要成果并非随着测试环境访问权限消失而消失的带图表的网页，而是按照可编辑模板生成的PDF和DOCX格式的测试报告：包括封面、测试方案与方法、测试条件、负载与质量结果、基础设施状态、各项验收标准的判定、通俗易懂的结论、附录（包含“问题→答案→评分→解释”的示例）以及签名栏。
| 标准 | 门槛 | 事实 | 结果 |
|---|---|---|---|
| 成功响应率 | ≥ 99% | 97,4% | FAIL |
| P95 响应时间 | ≤ 15 秒 | 11.2 秒 | PASS |
| 服务宕机次数 | 0 | 0 | PASS |
| 总体质量评分 | ≥ 80 | 84 | PASS |
| 无排队的同时在线用户数 | ≥ 12 | 9 | FAIL |
判决行示例——仅作说明。当结果为 FAIL 时，协议会指出具体违反的标准、预期值和实际值，而不是笼统地表述为“存在问题”。
展台在你们那边。裁判也是。
安全团队对任何质量评估平台的主要异议是：“你们会把我们的数据发送到第三方云。”而在“Polygon”中，这种情况从架构上就不会发生：
- 该环境通过 docker-compose 在客户环境中部署，并从离线镜像包进行安装——所有阶段（包括安装）均无需连接互联网；
- LLM 裁判在内部回路的本地模型上运行：问题、标准答案、实际回答和评判标准均不离开该边界；
- 法官的输入数据在方法上受到限制——仅包含问题、标准答案、回答和评分标准，不含令牌、Cookie 和会话标识符；
- 数据集在导入时会检查个人数据（电话、电子邮件、姓名、银行卡号和账户号码），并提供掩码建议，检查报告与数据集版本一同保存；
- 客户系统的访问凭据存储在环境变量或密钥保管库中，而不是存储在测试配置文件中。
测试台的最低配置为 4 个 vCPU、8 GB RAM、50 GB 磁盘；在干净的服务器上按照说明进行安装，无需开发。
谁现在就需要这个
银行和金融机构
即将发布RAG助手、客服聊天机器人或网银助手的新版本或重大更新。验收委员会需要一份文件，其中包含负载数据，并确认该机器人在负载下不会开始胡说八道。
国有部门
配备AI组件的GIS系统即将投入运行。需要一份“测试程序和方法”格式的文件，并附带测试结果，以及一名因身体原因无法将数据发送至互联网的法官。
大型零售
客服聊天机器人即将迎来季节性高峰。需要提前了解它能同时处理多少咨询，并确认在咨询量激增时是否会编造不存在的促销活动和价格。
这与 k6 和 Ragas 有什么区别？
开源工具各自只解决一半的问题：k6 和 JMeter 用于施加负载，Ragas 和 DeepEval 用于评估质量。它们之间没有集成，而要自行搭建这样的集成，则需要耗费数月时间的独立项目。
- 它们都无法看到推理引擎内部的队列和内存占用情况；
- 容器RESTART失败未被记录——仅记录了 HTTP 错误；
- 负载和质量是在不同时间、基于不同数据计算的，而不是通过一次运行得出的；
- 输出端没有一份统一的包含 PASS/FAIL 判定结果、可用于验收报告的文件。
«Poligon» 并不否认 k6 和 Ragas 是优秀的工具。它填补了「负载 + 质量 + 协议 + 环境内交付」这一组合需求，而这些工具各自都无法单独解决该问题。
试验是如何进行的
申请和电话会议
讨论系统：类型（RAG 助手、聊天机器人、LLM API）、真实问题的可用流量、是否有基础设施指标的访问权限。
试验配置文件
我们共同设定负载配置文件、基准问答数据集以及验收标准——这些阈值将针对您的系统确定 PASS/FAIL。
您环境中的运行
测试平台对目标施加负载，同时使用本地判定器评估响应样本，并在获得访问权限时采集基础设施状态。
协议
包含每个标准评判结果的PDF/DOCX文档——可直接放入验收报告附件中。
基础设施指标部分是可选的：即使没有容器和 GPU 的访问权限，测试平台仍会通过 HTTP 对目标施加负载，测量响应和质量，并根据验收标准作出判断。
让我们讨论一下您的环境
描述任务、当前系统、约束和预期结果。我们将提供实用的第一步：诊断、试点、审计、路线图或项目团队。
