2026年FPGA大赛用国产紫光同创盘古板做「多路视频拼接+AI人流统计」，评委问「统计精度怎么保证的」，我该怎么补一份有说服力的指标验证报告？

先说个现实点的判断：评委问「精度怎么保证」，很多时候不是要你证明算法多强，而是想知道你有没有把「作品能跑」变成「作品可测量」。这两件事差得很远。你们只交截图，评委没法判断是模型好还是你挑了个好片段，所以补报告的核心不是堆数据，而是让每个数字都能被别人复现。

具体到必测项，我建议按「输入条件—指标—基线」三层来搭。输入条件就是测试集怎么来的：别只用一段顺光、人少的视频。至少录三四段，覆盖逆光/夜间/人流密集/多人遮挡，每段剪成固定时长比如一分钟，人工逐帧或用标注工具标出真值（跨线人数、当前帧人数）。这一步最费时间但最值钱，因为后面所有指标都靠它。

指标上分两类。检测层面看漏检率、误检率，可以按帧统计也可以按目标统计，说明口径就行；计数层面看跨线计数误差，用「|算法计数-真值|/真值」表示，密集场景误差通常比稀疏大，分开报反而显得你懂。延迟要报端到端，从摄像头输入到串口/屏幕输出计数结果的时间，别只报YOLO推理耗时，拼接和DDR搬运都算进去，用时间戳或逻辑分析仪抓。

对比基线容易被忽略但评委很吃这套：同一段视频，跑纯CPU或官方例程的结果，和你FPGA方案放一起。哪怕你的方案精度略低但延迟低一个量级，也是清晰的工程取舍。

有个风险提醒：别为了数字好看只挑顺光片段，评委一旦追问「夜间呢」就露馅。报告里附上测试环境、量化配置、复现脚本和原始数据，比多写两页原理更管用。

你们现在手头有带标注的视频源吗，还是打算自己标？这个决定了报告能不能在一周内补出来。

我换个角度说，假设你是评委，坐在那儿听一天答辩，什么样的验证报告会让你点头？不是数字最漂亮的，而是你能感觉到「这队知道自己方案的边界在哪」。所以补报告这件事，本质上是在讲一个因果故事：我的架构决定了我会在什么场景下退化，我用什么实验把退化量化出来，我又做了什么取舍。

先理清楚你们的链路。4路1080P拼接，意味着视频要先缓存、缩放、拼接，再送进YOLOv5-tiny，最后做跨线计数。这条链上每一环都可能影响最终计数：拼接时的缩放会改变目标尺度，DDR带宽不足会丢帧，丢帧直接导致跨线漏计。所以报告的第一层不是「精度多少」，而是「帧率稳不稳」。如果端到端帧率在密集场景掉到15fps以下，那漏检率再低也没意义，因为人已经走过去两帧了。建议先测一个帧率-人流密度曲线，把系统的可用区间框出来。

第二层才是精度。固定测试集这件事没有捷径，但可以聪明地做：不用标满所有帧，只标跨线事件附近的时间窗，因为计数误差主要来自漏掉跨线那一刻。真值可以用人工数+回放慢放确认，记录每个跨线事件的时间戳，然后和算法输出的时间戳对齐，这样你得到的不只是「误差3人」，而是「哪几次漏了、漏在什么条件下」——这比一个总数有说服力得多。

第三层是对比。纯CPU基线不一定跑得动4路，那就退一步，用单路1080P对比，说明「同等输入下FPGA方案的延迟优势」，同时坦诚你的精度损失来自哪里（比如量化到INT8、模型裁剪）。评委不会因为你精度低几分就否定你，但会因为你回避取舍而扣分。

报告结构上，我倾向把复现脚本和参数配置放在附录，正文只放结论表和关键曲线。测试环境写清楚：板卡型号、摄像头型号、光照条件、室温（是的，温度影响DDR时序），这些细节堆起来就是工程感。

最后提醒一句，别把报告写成论文。评委翻两页就想看到「测了什么、怎么测、结果如何」，因果链清楚比篇幅长重要。你们现在卡在哪一步，是标注没做还是延迟测不准？

先说个容易被忽略的点：评委问精度，往往不是要你证明算法多牛，而是想确认你们知道自己的系统在什么条件下会失效。所以报告里一定要有「边界」这一节，而不是只报最好看的数字。具体可以这样搭：录四段固定视频，分别对应顺光稀疏、逆光、夜间或弱光、人流密集遮挡，每段剪成统一时长比如六十秒，人工标出跨线人数和逐帧人数当真值，标完存成csv，这就是你的固定测试集。指标分两层报，检测层用漏检率和误检率，计数层用跨线计数误差，写成绝对误差除以真值，再补一个端到端延迟，从摄像头输入到计数结果输出的毫秒数，用打点计时或者帧号对齐来测。对比基线别省，至少跑一个纯CPU或官方例程的版本，把你的FPGA加速方案和它放在同一段视频上比，这样帧率和延迟的优势才有参照。风险在于人工标注很花时间，如果来不及全标，就挑两段各标三十秒，但要说明口径。报告结构上，测试环境、参数配置、复现脚本三样缺一不可，脚本哪怕只是个跑批的python也行。你们现在标注打算自己逐帧做，还是想找个半自动工具先预标再人工修？

我想从工程路径的角度多说一层，因为这事的核心不是补一份报告，而是把你们的作品从「能演示」变成「可测量」。这两者之间隔着一个很实在的鸿沟：截图能证明某一刻它对了，但证明不了它在什么密度、什么光照下还能对。评委的质疑其实是在问，你们有没有把系统当成一个需要被验证的工程对象。

先理因果链。四路1080P拼接，视频要先缓存、缩放、拼接，再进YOLOv5-tiny，最后跨线计数。这条链上，拼接缩放会改变目标尺度，DDR带宽不够会丢帧，丢帧直接导致跨线漏计。所以报告第一层不该是精度，而是帧率稳不稳。测一条帧率对人流密度的曲线，把可用区间框出来，比如密集场景掉到十五帧以下，那漏检率再低也没意义，因为人两帧之间已经走过去了。这个判断会让评委觉得你们懂系统。

第二层才是精度。固定测试集是地基，别只用一段顺光人少的视频。至少覆盖逆光、夜间、密集遮挡，每段固定时长，人工标真值。标注这一步最费时间但最值钱，因为后面所有指标都靠它。指标口径要写清楚，漏检率是按帧统计还是按目标统计，计数误差用绝对误差除以真值，密集场景误差通常比稀疏大，这很正常，报出来反而显得诚实。

第三层是对比基线。纯CPU或者官方例程跑同一段视频，把精度和延迟放一起比。你们FPGA方案的价值不在精度更高，而在延迟更低、能实时，这个对比能把取舍讲清楚。报告里附上测试环境、参数配置和复现脚本，哪怕脚本很粗糙，评委也会认可这份严谨。

最后提醒一个取舍：别为了数字好看去调测试集，评委看一天答辩，最反感的就是挑片段。宁可报一个不好看的密集场景误差，也别只报顺光数据。你们现在手头能复现的基线方案，是CPU版还是厂商例程？