跳到主要内容
MACT.ai

解决方案

构建智能产品.

AI 与物理世界相遇的七个领域。每个领域都有明确的方法、验证过的场景、一套技术组合,以及落过地的项目。

  • 01

    AI 产品

    智能长在架构里,而不是后来贴上去的。

    问题

    大多数 AI 功能都是后期加进去的,模型因此受制于早已定好的算力、延迟与数据决策。结果就像在产品上挂了一个 demo。

    方法

    我们从第一次架构评审就围绕模型来设计产品——什么跑在哪里、每次交互成本多少、它怎么失败,以及它在思考时用户看到什么。

    验证过的场景

    • 对话式硬件

      以语音为主要交互的设备。唤醒词与音频处理留在本地;识别与推理走流式,第一段音频到达就开始播放。我们把首音延迟当作产品指标来盯。

    • 辅助作业

      面向操作者的产品,模型给建议、由人确认。真正有工程含量的是置信度怎么呈现和兜底路径怎么走,而不是模型本身。

    • 自主决策

      模型不经复核就行动的闭环产品。上线之前必须有确定性护栏、有界的动作空间和完整的审计记录。

    能力

    • AI 产品架构
    • 模型选型与评测
    • 延迟与成本预算
    • 概率系统的交互设计

    技术

    LLMVLMRAGFine-tuningAI AgentsEval
  • 02

    AIoT

    出厂之后还会继续变聪明的联网设备。

    问题

    联网硬件常常一发货就被冻结。没有安全的升级机制和真实遥测,产品无法改进,问题也看不见。

    方法

    我们把设备、云端与升级通道当成一个系统来做,让行为可以在现场改进,支持分批下发,也留好退路。

    验证过的场景

    • 分布式设备监控

      分散在多个站点、上行不可靠的节点。控制与安全逻辑在本地运行,云端下发意图、观察结果,所以断网影响的是上报,不是运行。

    • 消费级联网产品

      配网体验直接决定留存。我们按真实家庭网络下的首次使用者来设计配网流程,BLE 配对失败时有 captive 兜底。

    • 多代次混合设备群

      硬件版本会不断累积。从第一版就带版本的设备协议,让三代硬件共用一个设备群、一个控制台和一条 OTA 通道。

    能力

    • 设备与云端架构
    • 设备群管理与开通
    • 分批 OTA 与回滚
    • 遥测与可观测性

    技术

    MQTTWebSocketOTADevice CloudBLEWi-Fi
  • 03

    Edge AI

    在真实的功耗与内存预算里跑真实的模型。

    问题

    在工作站上跑得好的模型,很少能塞进嵌入式目标。量化拖到后期才做,精度掉下来,进度只能硬扛。

    方法

    我们很早就把候选模型放到真实芯片上跑基准,然后做量化与优化,精度全程对齐一套固定评测集。

    验证过的场景

    • 隐私受限的推理

      数据完全不能离开设备。整条链路都在本地运行,只传结构化结果——这改变的是芯片选择,不只是软件。

    • 延迟敏感的控制

      推理嵌在控制环里,往云端跑一趟根本不成立。我们按最坏情况而不是平均值做延迟预算,并在持续热负载下验证。

    • 成本受限的量产品

      NPU 预算由零售价决定。我们从最便宜、但能满足要求的芯片往上找,而不是从最强的往下砍。

    能力

    • 目标板实测
    • 量化与剪枝
    • NPU 与 DSP 部署
    • 运行时与算子优化

    技术

    ONNXTFLiteTensorRTINT8NPURKNN
  • 04

    计算机视觉

    从传感器到决策,整条路径都要做工程。

    问题

    视觉精度通常在模型跑起来之前就丢掉了——丢在光学、曝光、时序和图像链路上,而不是网络权重里。

    方法

    我们把光学、传感器、ISP 调校与模型当成一条链路,并用产品真实使用环境里拍到的素材去验证。

    验证过的场景

    • 固定安装监测

      场景已知、安装方式已知、光照不可控。精度的大头来自在选模型之前,就用真实素材把光学和曝光策略定死。

    • 动作与姿态分析

      信号是时序的,不是逐帧的。检测以较低频率运行,跟踪在两次推理之间维持目标身份,普通算力也能跑出稳定帧率。

    • 检测与测量

      把视觉当作测量仪器。标定、重复性和明确的失效行为,比模型的原始精度更重要。

    能力

    • 光学与传感器选型
    • ISP 调校与曝光策略
    • 检测、跟踪与分割
    • 数据集与评测链路

    技术

    MIPI CSI-2ISPDetectionTrackingCalibration
  • 05

    语音 AI

    在普通硬件上做出即时感的对话。

    问题

    语音产品栽在延迟和噪声上。这两件事在语言模型介入之前,就已经被音频前端和流式架构决定了。

    方法

    唤醒词与音频处理留在设备端;识别、推理与合成都走流式,第一段音频到达就能开始播放,而不是等最后一段。

    验证过的场景

    • 低成本语音助手

      唤醒词塞进 MCU 的内存预算,识别与推理走流式。BOM 通常由音频通路主导,而不是算力。

    • 免手持工业界面

      触摸屏不实用的嘈杂环境。波束成形加上受限的命令文法,在精度和延迟上都胜过通用模型。

    • 多语言设备

      一个产品,几个市场。语言路由在网关侧完成,加一门语言不需要发布固件。

    能力

    • 麦克风阵列与声学设计
    • 端侧唤醒词与 VAD
    • 流式 ASR、LLM 与 TTS
    • 打断与轮次处理

    技术

    ESP32Wake WordAECStreaming ASRTTSOpus
  • 06

    机器人

    Physical AI——感知、规划与控制在同一个系统里。

    问题

    机器人项目常常把感知与控制拆开做,而把它们接起来的集成成本,总在进度最糟糕的时刻到来。

    方法

    我们把感知、规划与运动栈放在一起构建,确定性实时控制与上层智能之间用明确的契约隔开。

    验证过的场景

    • 固定工位操作

      带视觉引导修正的可重复抓放。节拍时间与重复精度是规格;安全由硬件强制。

    • 室内移动自主

      在与人共享的空间里导航。定位、避障,以及一个能否决规划器的安全层,是这类工作的核心。

    • 仪器自动化

      科学与光学仪器里的精密运动,长时间会话下的亚角分精度比速度更重要。

    能力

    • 运动控制与运动学
    • 感知与传感器融合
    • 实时架构
    • 安全与失效行为

    技术

    ROS 2RTOSSLAMSensor FusionMotor Control
  • 07

    智能设备

    经得起制造环节考验的消费硬件。

    问题

    能跑的原型不等于产品。成本、良率、认证与模具都会改变设计,而且通常发生在进度已经承诺之后。

    方法

    我们从一开始就按 BOM、测试与认证路径来设计,并把原型推向试产,而不是推向一场演示。

    验证过的场景

    • 电池优先的产品

      穿戴与便携设备,平均电流决定了其他所有约束。第一周就有实测电流预算,功能取舍才谈得上。

    • 带屏与设备端 UI 的产品

      设备上的界面承载品牌。算力要结合 UI 与推理负载一起选,而且要在画原理图之前定下来。

    • 生态集成产品

      Matter、HomeKit 与 Alexa 的接入会决定射频方案和认证路径,所以生态选择属于架构问题。

    能力

    • 产品与结构架构
    • BOM 与成本工程
    • EMC 与认证准备
    • 试产与测试治具

    技术

    PCBDFMEMCEnclosureTest Fixtures

有想法?
一起做出来.

mact.ai