AI视觉产品研发，成本如何分析？如何省钱？

花钱的地方在哪里

• 系统的架构与核心功能设计 。 这个模块发生在公司已经决定要做这款产品，产品经理也完成了相关产品的功能设计了之后，一般系统架构师来承接这块的核心工作，理解产品功能，将其翻译成技术可实现的方案，设计技术架构，进行技术选型。把块放第一条讲，不是说这个工作模块会花掉多少钱，架构师工资多高之类的。而是，这部分的工作是研发的源头，架构设计的不好，或者没有较强的前瞻性与可扩展性，将是一件很头疼的事情，一个决定，对应着一堆兄弟们忙前忙后的，这块一定是“慢就是快”，任何决策都要考虑清楚。

  在进行技术评审的时候，经常会有人说，现在时间紧、任务重，先用这个方案顶一顶，后面再优化，但实际上，方案一上，后面再动，就麻烦了。记得以前有做一个项目，需要将端识别的目标结构化数据传到云上，走无线传输，当时研发时间很紧，软件架构就选了一条将一条条零碎的微小结构化文件传到云上的技术链路。那一个个文件只有几B，但是数量成千上万，走4G传输，可想而知这效率会怎么样。整机架构选择端上完成绝大多数的高密度计算，就是想快速的，使用原始图像质量的情况下，进行目标的结构化，达成客户的实时性要求，但最后发现，整个系统实时瓶颈竟然不在那海量的科学计算，尽然在数据传输上。但这时功能已经研发完毕，后面不得不利用几个大版本进行功能优化，现在想来，当时确实是快了，想得快，做的也快，但是实际上，却慢了不知道多少，钱也多花了不知道多少。

• 模型的训练优化 。 模型的训练优化是花钱的大头，一般产品研发团队，大概率会有人专门的进行模型的开发、迭代优化，他们一部分精力聚焦在模型的选型，训练，模型本身结构的优化以提升模型性能；另一部分（可能是大部分）精力，会聚焦在和数据打交道上，标注数据；质检数据；从数据中发现规律，引入先验去更好的发挥出数据价值。这后面除了模型研发同学外，往往还跟着数目庞大的数据标注团队，这里面会有一套数据运转SOP，这个飞轮运转起来，不仅仅是动力强劲的数据生产机器，也是核动力碎钞机。这里面门道有很多，一不注意，钱砸进去也不见得能看到多大的水花，但摸清楚脉络，很多事情是可以做到更有针对性，更高效，更自动化，钱都是省在细节里的。

• 系统的工程开发 。 这块的工程研发是一个非常系统的活，里面涉及硬件，算法，系统软件等多个部分，很庞杂，但这里面都对应着成本。比如，接了一个项目，做一个城市300路监控视频的结构化分析，粗略做个类比，一台服务器可以实时处理5路，跟一台服务器可以实时处理50路，这里面不止是十倍的硬件成本，当然，比如一台服务器2万块，5路的话，硬件成本120万，50路的话，硬件成本只要12万，这差距还挺多的。还有可能要考虑的一点，一台机器处理5路，就得60台机器，客户大概率得给建专门的机房，6台机器的话，估计随便搞个地方就塞进去了，你看哪个对客户更友好。这里讲的是本地化部署，很多客户有这个诉求，如果用公有云，那更可怕，每时每刻都在以10倍的价格被人薅羊毛，真的是想想都肉疼。服务端的系统有上面的计算，端上的系统也一样，如果你通过工程优化，可以让原来在Orin NX上的系统能在Orin NANO上运行起来，这将是多大的成本降低。

  如果你的产品具有一定的规模化，那上面的事情是不得不考虑的，就算利润高也不好随意挥霍，况且，也很难有什么行业利润高，出货量大还没人竞争的，到最后都得精打细算。而系统工程开发的工作，有一部分属性就是做精打细算的活的。技术方案的选择要有整体性，要能被经得起算总账。

• 系统的测试保障 。 这块的工作和架构设计那块类似，它俩是整个产品研发的一头一尾。测试工作本身也是投入，但它的价值更多的在于严格把关研发实现的功能是否满足产品的设计？有没有明显的问题？算法的性能是否达标？有没有非常明显的低级问题？这块工作如果做的不好，那系统就是开环的，研发的功能将直接对客户，没有被把关的东西直接给到最终的使用者，可能会带来灾难性的后果，客户吐槽几句都算谢天谢地的，与客户之间的信任建立很难，给人的感觉是咱拿人家当小白鼠，遇到性子急的客户，反手一个投诉，让把东西拆走，都是很常见的事情。这块工作是最后一道防线，这个钱得花，但也得花的其所。

• 售后的交付迭代 。 有人会说，测试完成了后研发流程不就闭环了么，其实是也不是，公司内部的测试是完成小闭环，在交付过程中客户的反馈与迭代是大闭环，有人用你东西，并说好与不好，才是最重要的，闭门造车不能做出优秀的产品。和手机，电脑这些消费电子类产品，以及手机APP这类产品不同，服务于具体行业的视觉产品，大多To B/G，有很强的行业属性，很难做成标品。这类产品的交付迭代往往会更重一些，这里面涉及现场部署，客户问题收集与迭代，功能更新等诸多事宜，里面的人员投入和差旅也是不小的开支。好好理一理，其实也能省下来不少成本。

  
  

• 架构与功能实现设计要做一步想三步 。 前一段时间听刘润老师的文章，讲如何不做草台班子，这里面有一个做事的模型，即5-3-1模型，具体就是，看5年，想3年，认认真真干1年，这个思想在产品的架构和功能实现设计上也同样适用。架构设计类的工作要更谨慎一些，这个角色不是一人吃饱全家不饿的，他的一个决定，可能会造成后面多名研发同学很多天的人力投入，所以，这个角色的工作，一定不能图快，要想的更深入、全面一些，当然这有时候很难，前路也不一定看的那么明白，但这根弦咱得绷着。

  架构设计的时候，有很多具体的模型可以遵守，如架构设计的SOLID原则，DRY原则，KISS原则等等，这块具体做架构的同学可能更专业，我这半路出家的就不班门弄斧了，今天只聊聊的这些年工作中的一些感触。

1. 多了解客户的业务背景，从客户使用角度出发设计功能实现方式。 有人可能会说，这不是产品的活吗？实际上，工作的边界很难划分的那么开，很多产品经理同学没有技术背景，很多事情他们也不一定想得到。比如说，产品说，结构化后的数据需要传给下游系统，后面再细他可能就提不出来了，但是架构设计时我们就得想到，如果只是识别的视频数据，给客户做可视化的，那实现的时候，可能重点保障流畅性，但如果是客户的核心成果数据，那就一定得做数据完整性的保障了，这块在设计的时候就得考虑到，而不是被客户发现数据丢了才弥补。

2. 功能的设计要附带非功能的性能指标，二者必须一一对应，功能需率先完成，性能的优化也得有序进行。

3. 功能的设计要可扩展，多和产品沟通，心里有数后面的演进趋势，在进行架构和功能设计的时候，要提前布局。 比如，一款端上的设备，目前只接一路视频，如果我们就按一路视频设计数据流，那后面如果需要接多路的时候，就懵逼了，但如果实现考虑到这一点，架构设计就是支持多路，只是目前只接了一路，那后续做扩展就容易得多了。当然，这不是让过度设计，毕竟考虑的越多，实现起来越复杂，能准确预知到后续会发生啥，也是能力。

1. 第一阶段是产品研发开始到算法性能达到可用状态之前。这一阶段的测试不要做复杂了，要简单，研发更新了一版算法，测试可以通过浏览的方式，重点关注系统中明显存在的问题，记录并反馈研发，研发下一期重点解决这类明显的问题，一般几轮下来，明显的问题没有了，那系统就会达到一个基础可用的状态。这个阶段，重点是快，定性比定量重要的多，切忌这时候就搞一套完备的测试体系。

2. 第二阶段是达到可用状态之后。上面的阶段过去后，其实我们对算法的性能只有一个大致的认识，你说具体指标怎么样？其实是没有个准数的，到第二阶段后，我们要做的全面和细致，要清晰知道算法的性能边界是什么？泛化能力怎么样？要指导研发做提升。这块，要有体系的测试，什么样的算法用什么样的指标表征性能，配套的数据标注，评估脚本都得配上。这块投入挺大的，但如果产品能挺到这个时候还没被叫停，那这些投入就是有价值的。只是，要研究里面的细节，能让机器做的，不要让人做。