人工智能技术在企业中的广泛应用带来了工作效率提升与决策能力优化，但同时也带来了数据安全方面的隐忧。AI 系统通常需要大量敏感信息进行训练与推理，若缺乏有效管控，数据极有可能被泄露或滥用。

AI 数据泄露的技术成因与潜在风险

随着人工智能（AI）技术在企业中的广泛应用，越来越多的组织开始借助 AI 工具提升工作效率与决策能力。然而，AI 的引入也带来了新的、复杂的数据安全挑战。AI 系统，特别是生成式 AI，其智能程度越高、处理的数据量越大，潜在的数据泄露风险也越突出。这些风险已非理论推演，而是正在真实发生的安全事件，主要体现在以下几个方面，每个风险点都能找到对应的现实案例：

1.1 意外泄露敏感信息：供应链与模型自身的漏洞

AI 系统在训练或运行过程中可能接触到内部机密数据，并可能在输出中不当地复现这些信息。这种泄露不仅来自模型本身，更可能来自其脆弱的生态系统。

一个典型案例是，2025 年 11 月，数据分析服务商 Mixpanel 遭遇安全漏洞，导致其客户 OpenAI 的部分 API 用户信息泄露。黑客通过 SMS 钓鱼攻击入侵了 Mixpanel 的内部系统。尽管 OpenAI 强调自身系统未被入侵，但第三方服务商的失守，依然导致用户姓名、邮箱、位置等敏感信息外泄。这凸显了 AI 供应链风险：企业即使自身防护严密，其依赖的模型供应商、数据分析平台、云服务商等任何一个环节的漏洞，都可能成为数据泄露的突破口。

此外，AI 模型本身也可能成为泄露渠道。2025 年 9 月，安全研究人员 Radware 演示了名为“Shadow Leak”的攻击，通过“提示注入”技术，成功诱骗 OpenAI 的 “深度研究” 代理从其有权限访问的用户 Gmail 收件箱中提取并外发敏感邮件。这证明了，一旦 AI 代理被授予数据访问权限，它就可能被恶意指令操控，在用户毫无察觉的情况下泄露数据。

1.2 数据滥用与误处理：权限失控与“过度代理”

AI 可能因算法偏差、指令误解或被恶意利用，对敏感数据进行错误处理。其核心在于 “权限”的失控。

当 AI 模型（尤其是智能代理）被赋予调用工具（如查询数据库、发送邮件）的能力时，就产生了新的攻击面。攻击者可能通过精心设计的提示，诱使 AI 代理滥用其权限执行危险操作，例如无限制地访问和导出数据。OWASP（开放网络应用安全项目）将此列为“过度代理”风险。企业内部如果缺乏严格的基于角色的访问控制，员工可能无意中让 AI 处理其本无权限查看的机密文件，三星公司就曾发生过工程师将机密代码上传至 ChatGPT 导致泄露的事件。

1.3 合规性风险：高昂的财务与声誉代价

若未能妥善管理 AI 与数据之间的交互，企业极易违反 GDPR、HIPAA 等全球日益严格的数据保护法规，面临巨额的财务处罚与声誉损失。

这种风险是直接且严峻的。例如，2025 年，信贷机构 Experian 因未经授权大规模收集和使用荷兰公民个人数据，被处以 270 万欧元罚款。2026 年初，法国电信公司 Free Mobile 因数据泄露事件及后续处理不当，被法国监管机构 CNIL 处以高达 4200 万欧元的罚款。这些案例表明，监管机构对数据保护的执行力度空前，处罚金额足以对企业运营产生实质性影响。在 AI 场景下，若企业使用包含个人身份信息（PII）的数据训练模型，或 AI 处理结果涉及个人隐私而未加保护，都等同于在合规的“雷区”中行走。

这些触目惊心的实例清楚地表明，AI 数据泄露风险是立体、多层面的。它考验的不仅是传统的数据存储安全，更是对数据流动全程的可见性、对访问权限的精准控制、以及对异常行为的即时响应能力。这也正是现代数据安全平台如 Lepide 所致力于解决的核心问题。接下来，我们将详细探讨 Lepide 如何针对上述具体风险，构建起一道动态、智能的 AI 数据防泄露体系。

### Lepide 如何构建 AI 数据防泄露体系

面对前述复杂且真实存在的 AI 数据风险，企业需要一套能够贯穿 AI 应用生命周期的动态防护体系。Lepide 数据安全平台正是为此而生，它通过 “部署前治理-运行中监控” 的双轨策略，为企业安全、合规地使用生成式 AI 提供坚实基础。

2.1 部署前治理：奠定“最小权限”安全基石

在启动任何 AI 工具（如 Microsoft Copilot）之前，最关键的一步是厘清数据资产并收紧访问权限。盲目的授权是数据泄露最大的温床。

Lepide 平台的核心始于全面的数据发现与清点。它能持续扫描 Active Directory、Microsoft 365、文件服务器及云存储，自动识别、分类散落在各处的敏感数据（如 PII、财务信息、知识产权），并绘制出清晰的“数据地图”。这让企业第一次真正看清：敏感数据在哪里？谁有权访问？

发现并分类 AI 生成的数据

基于此洞察，Lepide 的集成式权限审计与管理功能便发挥了关键作用。平台能迅速分析出所有用户的显式及隐式权限，直观暴露那些不必要、过宽或已失效的“过度权限”。管理员可在几秒钟内，一键将这些权限撤销或调整至符合“最小权限原则”的状态。这意味着，在 AI 工具上线前，就已从源头上切断了其通过授权用户账号不当接触广泛敏感数据的可能性，为 AI 应用划定了一个安全的初始操作空间。

分析用户权限

2.2 运行中监控：实现异常行为的实时洞察与响应

当 AI 工具投入使用后，静态的权限控制不足以应对动态风险。Lepide 提供持续的用户与实体行为分析。

平台通过建立每个用户和系统账号（包括 AI 服务账号）的行为基线，实时监控所有数据访问与操作活动。当检测到异常行为时——例如，某个用户账号突然通过 AI 接口大量访问平时不接触的机密文件，或在非工作时间高频查询数据——Lepide 会立即触发精准告警。这种监控不仅针对 AI 的直接交互，还覆盖了其运行环境，例如跟踪 Active Directory 中权限的异常变更，这可能是攻击者提权并利用 AI 泄露数据的前兆。

实时检测和响应异常

所有此类活动，连同正常的数据访问、修改、分享记录，都会被详细的审计日志捕获。Lepide 能将这些海量日志转化为结构化的合规报告（如满足 GDPR、HIPAA 要求），不仅为事件追溯提供铁证，也为周期性安全评估和合规审计提供完整依据。

2.3 集成与自动化：构建闭环安全响应

为将防护从“洞察”升级为“处置”，Lepide 支持与现有安全生态系统（如 SIEM、SOAR、ITSM 工具）深度集成。当平台检测到高风险异常行为（如疑似通过 AI 进行的的数据外传尝试）时，可依据预设剧本自动启动响应流程，例如：临时冻结涉事账号、隔离受影响终端、或向安全运营中心发送高优先级工单。这种自动化响应机制极大地缩短了从威胁发现到遏制的时间窗口，将潜在泄露事件扼杀在萌芽状态。

2.4 构建面向未来的 AI 安全框架

综上所述，Lepide 为企业提供的并非孤立的功能点，而是一个完整的安全赋能框架。它通过 “数据发现 → 权限管控 → 持续监控 → 智能响应” 的闭环，将安全治理深度融入 AI 应用流程。这使得企业能够在采用生成式 AI 插件或任何创新方法时，有能力预先评估和缓解风险，从而充满信心地拥抱 AI 生产力，无需以牺牲数据安全为代价。

行动呼吁：开启您的安全 AI 之旅

面对 AI 浪潮，观望与冒进皆不可取。主动构建体系化的防护能力，是将技术红利转化为竞争优势的关键。Lepide 数据安全平台为您提供了经过验证的路径。

现在即可与我们的安全工程师一同探讨如何定制化地防范 AI 增强型数据泄露，保护您最核心的数据资产。

附录：关于 AI 数据泄露的常见问题

Q1: 为何防范生成式 AI 的数据泄露至关重要？

数据泄露可能导致直接的财务损失、违反 GDPR/HIPAA 等法规带来的巨额罚款与诉讼、难以挽回的品牌声誉损害，以及商业秘密和知识产权的丧失。防范 AI 泄露，即是保护企业的生命线。

Q2: 员工可能如何无意中通过 AI 工具引发数据泄露？

常见情形包括：将未脱敏的客户数据或内部文件粘贴至 AI 对话窗口；指令 AI 帮助分析或撰写包含敏感信息的邮件；使用 AI 处理代码、合同等机密文档而未进行检查；以及盲目使用未经安全评估的 AI 插件或集成工具。

Q3: 如果怀疑正在发生 AI 数据泄露，应如何应对？

立即按照公司事件响应计划行动：第一时间通知安全与合规团队；保存证据（记录涉及的数据、使用的 AI 工具及操作过程）；在安全团队指导下，隔离受影响账户或系统，防止泄露扩大；并启动全面的调查与事后复盘。

本文由体验技术团队Hexqi原创。

前言

TinyEngine 是一款面向未来的低代码引擎底座，致力于为开发者提供高度可定制的技术基础设施——不仅支持可视化页面搭建等核心能力，更可通过 CLI 工程化方式实现深度二次开发，帮助团队快速构建专属的低代码平台。

无论是资源编排、服务端渲染、模型驱动应用，还是移动端、大屏端、复杂页面编排场景，TinyEngine 都能灵活适配，成为你构建低代码体系的坚实基石。

最近我们正式发布 TinyEngine v2.10 版本，带来多项功能升级与体验优化：模型驱动、登录鉴权、应用中心等全新特性，同时还有Schema面板与画布节点同步、出码源码即时预览、支持添加自定义 MCP 服务器等功能进行了增强，以让开发协作、页面搭建变得更简单、更高效。

• 开源地址：https://github.com/opentiny/tiny-engine（欢迎 Star ⭐）
• 官方网站：https://opentiny.design/tiny-engine

版本特性总览

核心特性

• 模型驱动：零代码创建 CRUD
• 多租户与登录鉴权能力
• 新增应用中心与模板中心

功能增强

• 出码支持即时查看代码
• 自定义 MCP 服务器，扩展 AI 助手能力
• 画布与 Schema 面板支持同步滚动
• 页面 Schema CSS 字段格式优化
• 图表物料更新，组件属性配置平铺优化
• 多项细节优化与 Bug 修复

体验升级

• 新官网：UI 全面焕新
• 新文档：域名迁移与样式升级
• 新演练场：真实前后端，完整功能体验

新特性详解

1. 【核心特性】模型驱动：零代码极速创建CRUD页面（体验版本）

背景与问题

在传统的后台管理系统开发中，创建一个包含表单、表格和完整 CRUD(增删改查) 功能的页面往往需要开发者：

• 重复配置相似的表单和表格组件
• 手动绑定数据源、编写事件处理逻辑
• 数据模型变更时，同步修改多个组件配置

这种重复性劳动不仅耗时，还容易出错。

核心功能

模型驱动特性通过声明式的数据模型配置，自动生成对应的 UI 组件和数据交互逻辑，实现真正的"零代码"生成数据管理页面。

核心模块：

支持的模型字段类型：String（字符串）、Number（数字）、Boolean（布尔）、Date（日期）、Enum（枚举）、ModelRef（关联模型）

价值亮点

• 开发效率大幅提升：通过配置模型即可生成完整的 CRUD 页面，无需手动配置每个组件
• 后端自动生成：使用默认接口路径时，自动生成数据库表结构和 CRUD 接口
• UI 与接口自动绑定：拖拽组件选择模型后，UI 自动生成，接口自动绑定，一站式完成前后端搭建
• 支持嵌套模型：字段可关联其他模型，实现复杂数据结构（如用户关联部门）（后续实现）
• 标准化输出：基于统一模型生成的 UI 组件保证了一致性
• 灵活扩展：可自定义字段类型和组件映射

使用场景

• 后台管理系统的数据管理页面
• 需要频繁进行增删改查操作的业务场景
• 需要快速原型的项目

快速上手

1. 创建数据模型

打开模型管理器插件，创建数据模型（如"用户信息"）：

• 配置模型基本信息：中文名称、英文名称、描述
• 添加模型字段（如姓名、年龄、邮箱等）
• 配置字段类型、默认值、是否必填等属性

2. 配置接口路径（可选）

创建模型时，可以选择：

• 使用默认路径：系统自动使用后端模型接口作为基础路径，并在后端自动生成对应的 SQL 表结构和 CRUD 接口
• 自定义路径：指定自己的接口基础路径，对接已有后端服务

3. 拖拽模型组件到页面

在物料面板中选择模型组件拖拽到画布：

• 表格模型：生成数据列表
• 表单模型：生成数据录入表单
• 页面模型：生成包含搜索、表格、编辑弹窗的完整 CRUD 页面

4. 绑定模型，自动生成

选中组件后，在右侧属性面板：\
1） 点击"绑定模型数据"，选择刚才创建的模型\
2） 系统自动生成 UI 界面\
3） 系统自动绑定 CRUD 接口\
4） 一站式完成前后端搭建

5. 预览页面

预览即可看到包含搜索、新增、编辑、删除、分页功能的完整数据管理页面。

核心流程图

graph LR
    A[创建数据模型] --> B{选择接口路径}
    B -->|默认路径| C[后端自动生成<br/>SQL表结构+CRUD接口]
    B -->|自定义路径| D[对接已有后端]
    C --> E[拖拽模型组件到页面]
    D --> E
    E --> F[绑定模型]
    F --> G[系统自动生成UI]
    F --> H[系统自动绑定接口]
    G --> I[预览完整CRUD页面]
    H --> I

    style A fill:#e1f5fe
    style C fill:#fff3e0
    style G fill:#f3e5f5
    style H fill:#f3e5f5
    style I fill:#e8f5e9

用户只需关注

定义好数据模型，前后端自动生成：

• ✅ 无需手动编写表单 HTML
• ✅ 无需手动编写表格渲染逻辑
• ✅ 无需手动编写 API 调用代码
• ✅ 无需手动编写数据验证规则
• ✅ 无需手动编写分页排序逻辑

让用户专注于业务逻辑和模型设计，而非重复的 UI 代码编写。

2. 【核心特性】多租户与登录鉴权能力

功能概述

TinyEngine v2.10 引入了完整的用户认证系统，支持用户登录、注册、密码找回，并结合多租户体系，让您的设计作品可以实现云端保存、多设备同步和团队协作。

登录注册

• 用户登录：基于用户名/密码的身份认证，Token 自动管理
• 用户注册：支持新用户注册，注册成功后提供账户恢复码用于找回密码
• 密码找回：通过账户恢复码重置密码，无需邮件验证

组织管理

• 多组织支持：用户可属于多个组织，灵活切换不同工作空间
• 组织切换：动态切换组织上下文，组织间数据隔离
• 创建组织：一键创建新组织，邀请团队成员加入

登录鉴权流程

系统采用 Token 认证机制，通过 HTTP 拦截器实现统一的请求处理和权限验证：

sequenceDiagram
    participant 用户
    participant 前端应用
    participant HTTP拦截器
    participant 后端API

    用户->>前端应用: 1. 输入用户名/密码登录
    前端应用->>后端API: 2. POST /platform-center/api/user/login
    后端API-->>前端应用: 3. 返回 Token
    前端应用->>前端应用: 4. 保存 Token 到 localStorage

    Note over 前端应用,后端API: 后续请求自动携带 Token

    前端应用->>HTTP拦截器: 5. 发起业务请求
    HTTP拦截器->>HTTP拦截器: 6. 检查 Token 并注入 Authorization 头
    HTTP拦截器->>后端API: 7. 携带 Token 的请求
    后端API-->>HTTP拦截器: 8. 返回数据 或 认证失败(401)

    alt 认证失败
        HTTP拦截器->>前端应用: 9. 清除 Token，显示登录弹窗
        前端应用->>用户: 10. 提示重新登录
    end

访问入口

1）登录界面：访问 TinyEngine 时系统会自动弹出登录窗口，未登录用户需完成登录或注册。

2）组织切换：登录后可通过以下方式切换组织：

• 点击顶部工具栏的用户头像，选择「切换组织」
• 在用户菜单中直接选择目标组织

3）退出/重新登录：已登录用户可以点击右上角头像在菜单点击"退出登录"，进入登录页面重新登录

使用场景

1）个人使用：登录后即可享受云端保存、多设备同步等功能，设计作品永不丢失。

2）团队协作：

• 创建组织：为团队或项目创建独立组织空间
• 数据隔离：不同组织的资源完全隔离，清晰区分个人与团队项目

💡 提示：新注册用户默认属于 public 公共组织，所有数据公共可见，您也可以创建自定义组织隔离数据。

开发者指南

1）环境配置：

• 开发环境：通过 pnpm dev:withAuth 命令启用登录认证，pnpm dev 默认不启用（mock server）
• 生产环境：自动启用完整登录认证系统

也可以修改配置文件来启动或关闭登录鉴权：

export default {
  // enableLogin: true // 打开或关闭登录认证
}

2）多租户机制：

• 用户可属于多个组织，通过 URL 参数标识当前组织上下文
• 组织间数据完全隔离，切换组织可查看不同资源
• 当 URL 未携带应用 ID 或组织 ID 时，系统自动跳转到应用中心

3. 【核心特性】应用中心与模板中心

应用中心和模板中心是此次版本新增的两大核心功能模块。通过应用中心可以集中管理您创建的所有低代码应用，为不同的场景创建不同的应用；模板中心则让优秀页面设计得以沉淀为可复用资产，团队成员可以基于模板快速搭建新页面，大幅提升协作效率。

应用中心

登录后进入应用中心，集中管理您创建的所有低代码应用。

功能亮点：

• 统一管理：在一个界面查看、创建、打开所有应用
• 快速切换：无需手动输入 URL，一键进入任意应用编辑器
• 组织隔离：不同组织的应用数据隔离，清晰区分个人与团队项目

模板中心

模板中心让页面设计资产得以沉淀和复用，提升团队协作效率。

核心价值：

• 设计复用：保存优秀页面设计为模板，避免重复造轮子
• 快速启动：基于模板创建新页面，继承已有布局和样式
• 团队共享：组织内共享设计资产，统一 UI 风格和设计规范

访问入口

在编辑器中点击左上角菜单按钮，悬停即可看到应用中心和模板中心入口，点击即可前往。

使用说明

自动跳转规则：

• 如果访问编辑器时未携带应用 ID 或组织 ID 参数，系统会自动跳转到应用中心
• 您可以在应用中心创建新应用，或打开已有应用进入编辑器

组织权限说明：

• public 组织：默认公共组织，所有用户的应用对所有人可见
• 自定义组织：用户新建的组织默认仅创建者可见，需手动邀请成员加入
• 切换组织可以查看不同组织下的应用和资源

特性开关

如果不需要使用应用中心与模板中心，可以在注册表中进行关闭:

// registry.js
export default {
  [META_APP.AppCenter]: false, // 关闭应用中心
  [META_APP.TemplateCenter]: false // 关闭模板中心
  // ...
}

4. 【增强】出码即时预览 - 导出前预览所见即所得

出码功能新增源码预览能力，用户在导出代码前可以实时查看生成的源码内容，提升代码导出体验和准确性。

功能特性

• 左右分栏布局：左侧树形文件列表，右侧 Monaco 代码编辑器预览
• 智能初始化：打开对话框时自动显示当前编辑页面对应的文件代码
• 实时预览：点击树形列表中的任意文件，即可在右侧预览其代码内容
• 灵活选择：支持勾选需要导出的文件

使用方法

1） 在编辑器中点击「出码」按钮\
2） 打开的弹窗中左侧树形列表显示所有可生成的文件，当前页面对应文件自动展示在右侧\
3） 点击任意文件预览源码，勾选需要导出的文件\
4） 点击「确定」选择保存目录完成导出

5. 【增强】自定义 MCP 服务器 - 扩展 AI 助手能力

之前版本中，TinyEngine已经提供内置MCP 服务，可以通过MCP工具让AI调用平台提供的各种能力。 本次特性是在TinyEngine 中支持添加自定义 MCP (Model Context Protocol) 服务器，可以通过配置轻松集成第三方 MCP 服务，扩展 AI 开发助手的工具能力。

功能特性

• 灵活配置：通过注册表简单的配置即可添加自定义服务器
• 协议支持：支持 SSE 和 StreamableHttp 两种传输协议
• 服务管理：在 AI 插件的配置界面即可管理 MCP 服务器的开关状态
• 工具控制：可查看并切换各个工具的启用状态

使用步骤

1） 准备您的 MCP 服务器（需符合 MCP 协议规范）

2） 在项目的 registry.js 中添加配置

// 使用示例
// registry.js
export default {
  [META_APP.Robot]: {
    options: {
      mcpConfig: {
        mcpServers: {
          'my-custom-server': {
            type: 'SSE',              // 支持 'SSE' 或 'StreamableHttp'
            url: 'https://your-server.com/sse',
            name: '我的自定义服务器',
            description: '提供xxx功能的工具',
            icon: 'https://your-icon.png'  // 可选
          }
        }
      }
    }
  }
}

3） 刷新编辑器，在 AI 插件 MCP 管理面板中即可看到新添加的服务器

4） 启用服务器，选择需要的工具，即可在 AI 助手中开始使用！

场景示例

您可以集成企业内部 MCP 服务、社区 MCP 服务、第三方 MCP 工具等，扩展 AI 助手的业务能力。

例如，下面是一个添加图片搜索MCP服务后使用AI生成带图片页面的场景示例：

6. 【增强】画布与 Schema 面板支持同步滚动

Schema 面板新增"跟随画布"功能，启用后当在画布中选中组件时，Schema 面板会自动滚动到选中组件的对应位置并高亮显示。

使用场景

• 快速定位：当页面元素较多时，能快速找到对应组件的 Schema 配置
• 双向对照：可视化视图与 JSON 代码视图对照，便于理解页面结构

使用方法

打开 Schema 面板，勾选面板标题栏的"跟随画布"复选框启用。在画布中点击切换元素，即可看到 Schema 面板跟随变化。

效果如下：

7. 【优化】页面 Schema CSS 字段格式优化

页面 Schema 中的 CSS 样式字段由字符串格式优化为对象格式，提升样式配置的可读性和可维护性。系统会自动处理对象与字符串的相互转换，出码时自动转换为标准 CSS 字符串格式，同时完美兼容之前的字符串格式。

优化场景

• AI场景更友好：AI生成代码及修改样式场景，能够更快速地进行增量生成及修改
• 编辑更直观：对象格式支持属性智能提示和语法高亮，编辑体验更佳
• 阅读更清晰：结构化的对象格式易于查看和修改样式属性
• 维护更便捷：新增或修改样式规则时，无需手动拼接 CSS 字符串

格式对比

之前（字符串格式）：

"css": ".page-base-style { padding: 24px; background: #FFFFFF; } .block-base-style { margin: 16px; } .component-base-style { margin: 8px; }"

现在（对象格式）：

"css": {
  ".page-base-style": {
    "padding": "24px",
    "background": "#FFFFFF"
  },
  ".block-base-style": {
    "margin": "16px"
  },
  ".component-base-style": {
    "margin": "8px"
  }
}

兼容性说明

• 两种格式完全兼容，可在同一项目中混用
• 系统自动识别格式类型并进行转换
• 出码时统一转换为标准 CSS 字符串格式
• 页面样式设置等场景使用都与之前保持一致，不受该特性影响

8. 【增强】图表物料更新，组件属性优化

图表物料进行了如下优化：

• 添加三种常用图表组件物料：仪表盘、拓扑图、进度图
• 图表组件的配置面板优化，将原有的图标配置属性由整体 options 配置拆分为独立的属性配置项（颜色、数据、坐标轴等），使配置更加清晰直观。

9. 【新体验】新演练场 - 完整的前后端体验

演练场进行了全面升级，从原来的前端 Mock 数据改为完整的前后端部署，带来真实的体验环境。

升级亮点：

• 完整的前后端部署：不再是拦截接口 Mock 数据，而是真实的服务端环境
• 支持用户登录：可以使用真实账户登录演练场
• 数据隔离：用户数据基于租户进行共享或隔离，更符合实际使用场景
• 功能完整体验：之前无法体验的功能现在都可以正常使用，如AI助手插件自然语言生成页面

新演练场地址：https://playground.opentiny.design/tiny-engine/

通过下面两个入口都可以访问：

• 官网https://opentiny.design/tiny-engine/点击 "立即体验" 自动跳转新版演练场
• 演练场首页https://playground.opentiny.design/点击TinyEngine 进入演练场" 前往

如您希望继续使用旧版演练场，依旧可以通过下面地址继续访问：
旧版演练场：https://opentiny.design/tiny-engine#/tiny-engine-editor

10. 【新体验】新官网 - UI 全面焕新

TinyEngine 官网首页 UI 全面焕新，带来更现代、更清爽的视觉体验。

• 全新设计：首页内容刷新，并采用现代化的设计语言，视觉更加清爽美观
• 响应式布局：完美适配各种屏幕尺寸，移动端访问更友好

访问新版官网：https://opentiny.design/tiny-engine

11.【新体验】新文档 - 全新文档体验

TinyEngine 文档与其他OpenTiny产品文档统一迁移至新docs子域名：

新域名：https://docs.opentiny.design/tiny-engine/

文档变化：

• 整体更统一，方便查找切换其他文档
• 同时也进行了全面的样式优化，阅读体验更佳

12. 【其他】功能细节优化\&bug修复

• 修复物料baseUrl问题 by @hexqi
• 移除me接口冗余请求头 by @xuanlid
• 登录页响应式优化 by @lichunn
• 修复本地开发代理问题 by @hexqi
• 修复工具调用参数问题 by @hexqi
• 优化应用窗口打开方式 by @xuanlid
• 区块/页面管理预览修复 by @xuanlid
• 代码检查优化 by @hexqi
• 重定向文档地址更新 by @xuanlid
• 图表属性默认值支持 by @xuanlid
• 文档样式优化 by @xuanlid
• AI助手对话相关问题修复 by @hexqi
• 应用ID传参修复 by @lichunn

• 文档更新

  • 修改物料同步方案文档 by @lu-yg
  • 过期文档问题处理 by @xuanlid
  • 新增应用预览/资源管理文档 by @betterdancing

结语

回首这一年，TinyEngine 在开源社区的成长离不开每一位开发者和贡献者的支持。v2.10 版本作为春节前的最后一次发布，我们为大家带来了多项重磅特性：

致谢

本次版本的开发和问题修复诚挚感谢各位贡献者的积极参与！同时邀请大家加入开源社区的建设，让 TinyEngine 在新的一年里成长得更加优秀和茁壮！

新春祝福

值此新春佳节即将到来之际，TinyEngine 团队衷心祝愿大家：

🧧 新年快乐，万事如意！ 🧧

愿新的一年里：

• 代码如诗行云流水
• 项目如期顺利上线
• Bug 远离，需求清晰
• 团队协作高效顺畅
• 事业蒸蒸日上，生活幸福美满！

🎊 春节快乐，阖家幸福！ 🎊

让我们在春节后带着满满的热情和能量，继续在未来道路上探索前行！

关于OpenTiny

欢迎加入 OpenTiny 开源社区。添加微信小助手：opentiny-official 一起参与交流前端技术～\
OpenTiny 官网：https://opentiny.design\
OpenTiny 代码仓库：https://github.com/opentiny\
TinyEngine源码：https://github.com/opentiny/tiny-engine

欢迎进入代码仓库 Star🌟TinyEngine、TinyVue、TinyPro、TinyNG、TinyCLI、TinyEditor\
如果你也想要共建，可以进入代码仓库，找到 good first issue标签，一起参与开源贡献\~

高压电线电力巡检六类目标的图像识别数据集分享（适用于目标检测任务）

数据集分享

如需下载该数据集，可通过以下方式获取：

• 网盘链接: https://pan.baidu.com/s/1rNbncL8NWHBL9NeXMMkFkw?pwd=inck 提取码: inck

引言

在电力巡检领域，图像智能识别技术正逐步替代传统人工巡检方式，以实现更高效、更可靠的运行维护管理。随着电力系统规模的不断扩大和高压输电线路的广泛铺设，输电线路的安全运行已成为保障社会稳定和经济发展的关键环节。传统的人工巡检方式存在诸多不足，如效率低下、作业危险性高、检测结果主观性强等，难以满足现代电网对安全、智能、高效巡检的需求。

近年来，随着人工智能、计算机视觉和无人机技术的迅猛发展，基于图像识别的电力巡检系统逐渐兴起，成为电力运维智能化的重要方向。在这一背景下，高质量、贴近实际场景的图像识别数据集成为推动智能巡检技术落地的基础与前提。

为了满足电力图像识别模型训练与测试需求，我们构建并发布了高压电线电力巡检六类图像识别数据集，覆盖典型巡检目标，提供完整标注信息，旨在为研究者和工程实践者提供标准化、实用性的电力场景数据资源，推动智能电网建设与电力安全保障的发展。本文将对该数据集进行详细介绍，包括数据集背景、概述、结构、特点、适用场景等内容，旨在为相关研究和应用提供参考。

数据集背景

电力系统是国家重要的基础设施，承担着为社会生产和人民生活提供电力能源的重要任务。高压输电线路作为电力系统的骨干网络，其安全运行直接关系到整个电力系统的稳定性和可靠性。据统计，我国高压输电线路总长度已超过100万公里，覆盖全国各个地区。面对如此庞大的输电网络，传统的人工巡检方式已经难以适应现代电网的发展需求。

传统的人工巡检方式主要依靠巡检人员徒步或乘车进行线路巡查，通过肉眼观察线路设备的运行状态。这种方式存在以下问题：

1. 效率低下：人工巡检速度慢，周期长，难以实现对大面积线路的快速覆盖
2. 作业危险性高：巡检人员需要在高山、丛林等复杂地形中作业，面临坠落、触电等危险
3. 检测结果主观性强：巡检结果依赖于巡检人员的经验和责任心，容易出现漏检、误检等情况
4. 数据管理困难：人工巡检产生的数据多为纸质记录，难以实现数字化管理和分析

随着无人机技术的发展，电力巡检开始采用无人机进行航拍，然后通过人工分析航拍图像的方式进行巡检。这种方式虽然提高了巡检效率和安全性，但仍然需要大量的人工参与，难以实现真正的智能化。

基于深度学习的图像识别技术为电力巡检智能化提供了新的解决方案。通过训练深度学习模型，可以自动识别航拍图像中的线路设备和故障，实现巡检的自动化和智能化。然而，要开发出准确、可靠的电力巡检图像识别模型，高质量、多样化且已标注的数据集是关键基础。

目前，公开可用的电力巡检图像数据集存在以下问题：

1. 样本数量不足：许多数据集样本数量较少，难以支持深度学习模型的充分训练
2. 类别覆盖有限：部分数据集只覆盖少数几种设备或故障类型，难以满足实际巡检需求
3. 标注质量参差不齐：一些数据集的标注不够准确或不一致，影响模型训练效果
4. 数据划分不合理：部分数据集没有进行合理的数据划分，不便于模型的训练和评估
5. 场景单一：许多数据集的图像拍摄场景较为单一，难以适应实际应用中的复杂场景

为应对这些挑战，我们构建了本数据集，旨在为电力巡检图像识别算法的研究与落地提供高质量的数据支持。

数据集概述

本数据集是一个专注于高压电线电力巡检的高质量图像识别数据集，包含2000张高质量图像，覆盖六类典型巡检目标。所有图像均已完成YOLO格式标注，并按照训练集、验证集和测试集进行了合理划分，可直接用于深度学习模型的训练、验证和测试。

基本信息

• 图片总数：2000张
• 图像格式：JPG
• 标注格式：YOLOv5/YOLOv8支持的 .txt 文本格式（一图一标）
• 类别数量：6类

• 类别标签：

  1. 电缆破损
  2. 绝缘子破损
  3. 正常电缆
  4. 正常绝缘子
  5. 杆塔
  6. 植被遮挡

• 数据划分比例：

  • 训练集：1400张
  • 验证集：300张
  • 测试集：300张
• 图像分辨率：不固定，常见为1280×720及其变种
• 图像来源：无人机巡检拍摄、模拟数据合成、实地采样数据混合构建

文件结构

本数据集采用标准的文件夹结构进行组织，具体如下：

datasets/
├── images/
│   ├── train/
│   ├── val/
│   └── test/
├── labels/
│   ├── train/
│   ├── val/
│   └── test/
└── dataset.yaml

其中，images文件夹存放不同划分的图像文件，labels文件夹存放对应的YOLO格式标注文件，dataset.yaml文件包含数据集的配置信息。

类别配置

以下是数据集的类别配置（dataset.yaml）：

path: ./datasets
train: images/train
val: images/val
test: images/test

nc: 6
names: ['电缆破损', '绝缘子破损', '正常电缆', '正常绝缘子', '杆塔', '植被遮挡']

数据集详情

类别分布

本数据集包含六类典型的电力巡检目标，各类别的样本数量和说明如下：

标注质量

所有图像均使用LabelImg工具进行手动精标，标注内容包括目标的类别和边界框坐标。标注遵循以下原则：

1. 准确性：边界框准确覆盖目标区域，类别标注正确
2. 一致性：标注风格统一，避免标注标准不一致的情况
3. 完整性：确保图像中的所有目标都被标注，避免漏标
4. 规范性：采用YOLO标准格式标注，便于模型训练

数据特点

本数据集具有以下显著特点：

1. 场景真实：图像均来自实际电力巡检场景，具有较高的真实感和代表性
2. 覆盖全面：涵盖了电力巡检中常见的六类目标，包括正常和异常状态
3. 标注规范：所有图像均采用YOLO标准格式标注，标注精度高
4. 数据划分合理：按照7:1.5:1.5的比例划分为训练集、验证集和测试集
5. 开箱即用：已完成数据预处理和标注，可直接用于模型训练和评估
6. 分辨率适中：图像分辨率适中，既保证了目标的清晰度，又便于模型处理

数据处理流程

为确保数据集的质量和可用性，我们在构建过程中遵循了严格的数据处理流程，具体步骤如下：

flowchart TD
    A[数据采集] --> B[数据清洗]
    B --> C[图像预处理]
    C --> D[目标标注]
    D --> E[数据划分]
    E --> F[格式转换]
    F --> G[质量验证]
    G --> H[数据集发布]

1. 数据采集：通过无人机航拍、实地拍摄等方式收集电力巡检图像，确保覆盖不同场景和目标
2. 数据清洗：对收集到的图像进行清洗，去除模糊、曝光过度或不足的图像
3. 图像预处理：对清洗后的图像进行去噪、增强等处理，提高图像质量
4. 目标标注：使用LabelImg工具对图像中的目标进行手动标注，包括类别和边界框
5. 数据划分：按照7:1.5:1.5的比例将数据划分为训练集、验证集和测试集
6. 格式转换：将标注结果转换为YOLO标准格式，并生成dataset.yaml配置文件
7. 质量验证：对处理后的数据进行质量检查，确保标注的准确性和一致性
8. 数据集发布：打包发布数据集，提供下载链接

数据集特点

本数据集具有以下显著特点：

1. 高质量标注

所有图像均采用标准YOLO格式标注，准确标出目标位置与类别。标注过程由专业人员完成，确保标注的准确性和一致性。每个目标都有清晰的边界框，类别标签正确无误，为模型训练提供了可靠的基础。

2. 合理划分结构

数据集已按照训练集、验证集和测试集进行了合理划分，比例为7:1.5:1.5。这种划分方式符合深度学习模型训练的常规要求，便于模型的训练、验证和测试。用户可以直接使用划分好的数据，无需进行额外的处理。

3. 场景覆盖全面

数据集覆盖了电力巡检中常见的六类目标，包括：

• 电缆破损：覆盖电缆外皮破损、断裂等异常情况
• 绝缘子破损：包括瓷质绝缘子损坏、脱落、裂纹等
• 正常电缆：表面光滑、无破损、结构完整的电缆
• 正常绝缘子：状态良好、无缺陷的绝缘器元件
• 杆塔：包括铁塔、输电支架等整体结构目标
• 植被遮挡：表示输电线路被树枝、藤蔓等遮挡

这些目标涵盖了电力巡检中需要关注的主要对象，能够满足大多数电力巡检图像识别任务的需求。

4. 图像质量高

数据集的图像均来自实际电力巡检场景，具有较高的真实感和代表性。图像分辨率适中，既保证了目标的清晰度，又便于模型处理。部分图像还包含了不同光照、天气条件下的场景，增强了数据集的多样性和挑战性。

5. 应用价值广泛

数据集适用于多种电力巡检相关的任务，包括：

• 目标检测：检测图像中的线路设备和故障
• 缺陷识别：识别电缆、绝缘子等设备的故障
• 智能巡检：实现巡检的自动化和智能化
• 故障预警：提前发现潜在的故障隐患
• 数据可视化：辅助分析线路运行状态

6. 支持主流框架

数据集采用YOLO标准格式标注，可直接用于YOLOv5、YOLOv8等主流目标检测框架的训练和测试。用户无需进行格式转换，即可开始模型训练，提高了数据集的易用性。

7. 开箱即用

数据集已完成数据预处理和标注，按照训练集、验证集和测试集进行了合理划分，并生成了dataset.yaml配置文件。用户可以直接下载使用，无需进行额外的处理，提高了数据集的便捷性。

适用场景

本数据集可广泛应用于以下研究与工程应用场景：

1. 目标检测模型训练与测试

可直接用于训练YOLOv5、YOLOv8等目标检测模型，用于实际部署或研究验证。通过在本数据集上训练模型，可以提高电力巡检目标检测的准确率和效率，为相关应用提供技术支持。

2. 电力智能运维系统构建

可作为电力智能运维系统的训练数据，支持系统的开发和优化。例如，可以构建基于深度学习的电力巡检系统，实现对线路设备的自动检测和故障识别，提高运维效率和安全性。

3. 缺陷检测与告警系统研究

可用于缺陷检测与告警系统的研究，探索如何自动识别线路设备的故障并及时发出告警。例如，可以研究不同类型故障的特征提取方法，提高故障检测的准确率和速度。

4. 迁移学习与小样本学习实验

可用于迁移学习和小样本学习实验，探索如何利用有限的样本训练出性能良好的模型。例如，可以研究如何将在本数据集上训练的模型迁移到其他电力场景，或者如何从少量样本中学习有效的特征表示。

5. AI + 电力领域竞赛使用

可作为AI + 电力领域竞赛的标准数据集，为竞赛提供统一的评估基准。例如，可以举办基于本数据集的电力巡检图像识别竞赛，促进相关技术的发展和交流。

6. 智慧巡检与边缘计算部署

可用于智慧巡检与边缘计算部署研究，探索如何将训练好的模型部署到边缘设备上，实现实时的电力巡检。例如，可以研究模型压缩、量化等技术，减少模型大小和计算复杂度，使其适合在边缘设备上运行。

7. 电力系统状态评估

可用于电力系统状态评估研究，探索如何通过图像识别技术评估电力系统的运行状态。例如，可以分析线路设备的外观状态，评估设备的健康程度和剩余寿命。

8. 无人机巡检路径规划

可用于无人机巡检路径规划研究，探索如何优化无人机的巡检路径，提高巡检效率。例如，可以分析图像中的目标分布，为无人机规划最优的巡检路径。

模型训练建议

针对本数据集的特点，我们提出以下模型训练建议：

1. 模型选择

对于电力巡检目标检测任务，建议使用以下模型：

• YOLOv8：性能均衡，适合大多数应用场景
• YOLOv11：最新版本，精度和速度都有提升
• Faster R-CNN：精度较高，适合对精度要求高的场景
• EfficientDet：效率较高，适合资源受限的场景

2. 数据增强

建议使用以下数据增强技术：

• 随机翻转：水平翻转和垂直翻转，增加数据多样性
• 随机裁剪：随机裁剪图像的一部分，增强模型对目标不同大小的适应能力
• 随机旋转：随机旋转图像，增强模型对目标不同角度的适应能力
• 亮度和对比度调整：随机调整图像的亮度和对比度，增强模型对不同光照条件的适应能力
• 颜色抖动：随机调整图像的颜色，增强模型对不同颜色变异的适应能力
• 马赛克增强：将多张图像拼接成一张，增加小目标的数量

3. 训练策略

• 批量大小：根据硬件资源选择合适的批量大小，建议使用8-32
• 学习率：初始学习率设置为0.001，使用余弦退火策略调整学习率
• 优化器：使用AdamW优化器，权重衰减设置为0.0005
• 训练轮数：建议训练100-300轮，根据验证集性能动态调整
• 早停策略：当验证集性能连续多个轮次没有提升时，停止训练

4. 评估指标

使用以下指标评估模型性能：

• mAP@0.5：IoU阈值为0.5时的平均精度
• mAP@0.5:0.95：IoU阈值从0.5到0.95，步长为0.05时的平均精度
• 精确率：正确预测的正样本占总预测正样本的比例
• 召回率：正确预测的正样本占总实际正样本的比例
• F1-score：精确率和召回率的调和平均值

5. 模型优化

• 模型剪枝：去除冗余的神经元和连接，减少模型大小
• 模型量化：将模型权重从32位浮点数量化为8位整数，减少模型大小和计算复杂度
• 知识蒸馏：利用大模型的知识指导小模型的训练，提高小模型的性能
• 部署优化：针对不同部署平台进行优化，如TensorRT、ONNX Runtime等

应用案例

案例一：智能电力巡检系统

基于本数据集训练的YOLOv8模型，开发了一款智能电力巡检系统。该系统通过无人机航拍获取线路图像，然后利用训练好的模型自动识别图像中的线路设备和故障。系统会生成巡检报告，标记出故障位置和类型，并提供维修建议。该系统已在多个电力公司试用，巡检效率提高了60%以上，故障检测准确率达到90%以上。

案例二：电力故障预警系统

将训练好的模型集成到电力故障预警系统中，实时监测线路设备的运行状态。系统通过分析无人机航拍图像，识别设备的异常状态，并根据异常程度发出不同级别的预警。该系统已在某省电网公司部署，成功预警了多起潜在故障，避免了停电事故的发生。

案例三：电力设备管理系统

利用本数据集训练的模型，开发了一款电力设备管理系统。该系统通过图像识别技术，自动记录线路设备的类型、数量和状态，建立设备台账。系统还可以跟踪设备的运行历史，预测设备的剩余寿命，为设备维护和更换提供决策支持。该系统已在多家电力公司使用，设备管理效率提高了50%以上。

案例四：边缘计算巡检终端

将训练好的轻量化模型部署到边缘计算巡检终端，实现实时的电力巡检。终端通过摄像头拍摄线路图像，然后利用本地部署的模型自动识别图像中的设备和故障。该终端已在多个巡检班组试用，巡检人员可以实时获取巡检结果，提高了巡检效率和准确性。

数据集扩展与未来规划

本数据集是我们在电力巡检图像识别领域的初步尝试，未来我们计划从以下几个方面对数据集进行扩展和完善：

1. 增加样本数量：进一步扩大数据集规模，增加更多的图像样本，提高数据集的多样性和代表性
2. 扩展类别覆盖：增加更多的设备类型和故障类型，如变压器、断路器、隔离开关等设备的故障
3. 添加多模态数据：结合红外成像、热成像等多模态数据，构建更加全面的电力巡检数据集
4. 引入时序信息：添加同一设备在不同时间的图像，捕捉设备状态的变化，支持时序分析
5. 提供预训练模型：基于扩展后的数据集，训练并发布预训练模型，方便用户直接使用
6. 开发标注工具：开发专门的电力巡检图像标注工具，提高标注效率和准确性
7. 建立社区平台：建立电力巡检图像数据集社区平台，鼓励用户贡献数据和标注，共同完善数据集

技术挑战与解决方案

在构建和使用本数据集的过程中，我们遇到了以下技术挑战，并提出了相应的解决方案：

1. 数据采集困难

挑战：电力线路分布广泛，环境复杂，数据采集难度大
解决方案：采用无人机航拍、实地拍摄等多种方式相结合的方法，覆盖不同地形和环境下的线路

2. 标注工作量大

挑战：数据集包含2000张图像，标注工作量大
解决方案：使用LabelImg工具进行标注，优化标注流程，提高标注效率

3. 类别不平衡

挑战：不同类别的样本数量存在差异，如杆塔样本数量较多，而植被遮挡样本数量较少
解决方案：采用数据增强技术，增加小样本类别的样本数量，缓解类别不平衡问题

4. 目标尺度变化大

挑战：电力巡检图像中的目标尺度变化大，如远处的杆塔和近处的电缆
解决方案：使用多尺度训练策略，增强模型对不同尺度目标的适应能力

5. 背景复杂

挑战：电力巡检图像背景复杂，如山区、丛林等环境中的线路
解决方案：采用数据增强技术，增加模型对复杂背景的鲁棒性

结语

电力巡检是保障电力系统安全运行的重要环节，智能巡检技术的发展对于提高巡检效率和安全性具有重要意义。本数据集通过系统性地收集、整理和标注高压电线电力巡检图像，为电力巡检智能化发展提供了坚实的数据基础。

本数据集专为电力巡检任务设计，聚焦高压电线场景下的六类关键目标，包括破损与正常状态的电缆、绝缘子，以及杆塔和植被遮挡等，全面覆盖典型巡检问题。其具备高质量标注、合理划分结构、应用价值广泛、支持主流框架等特点，可直接用于YOLOv5/YOLOv8等目标检测模型训练。

我们希望通过本数据集的发布，能够促进电力巡检图像识别技术的发展，推动智能电网建设与电力安全保障的进步。我们诚邀学术界与工业界的研究者在此基础上深入探索，共同推动电力AI应用的深入发展。

总结

本次发布的《高压电线电力巡检六类目标的图像识别数据集》为电力智能化、智能巡检、AI视觉模型研究等领域提供了一个高质量、结构规范的图像识别基准数据集。数据集共包含2000张已标注图像，覆盖6类常见电力巡检目标，采用标准YOLO格式，已按训练、验证、测试集划分完毕，可直接应用于YOLOv5、YOLOv8等主流目标检测框架。

该数据集不仅适合用于常规的目标检测任务，也适合开展迁移学习、小样本学习、轻量化部署等前沿研究，特别契合电力巡检、缺陷识别、智能运维等AI+电力应用场景。我们将持续更新并配套提供训练脚本与部署方案，欢迎研究者和开发者在合法合规范围内广泛使用与改进本数据集。

通过本数据集的使用和相关技术的应用，我们相信电力巡检智能化水平将会得到显著提升，为电力系统的安全运行和可靠供电提供更加有力的保障。

七种常见虫子的图像识别数据集分享（适用于目标检测任务）

数据集分享

通过网盘分享的文件：AI虫子种类识别数据集

链接: https://pan.baidu.com/s/1pKwBxIptk3PE6OUk5HxzCw?pwd=4ih3

引言

在农业智能化与生态研究领域，虫害识别一直是计算机视觉技术的重要应用方向。不同种类的昆虫对作物、林木等有着截然不同的影响，及时准确地识别虫子种类对于灾害预警、防治投放具有重要的实际意义。然而，传统的昆虫分类方法通常需要专家的知识和经验，不仅费时费力，而且效率低下。

随着深度学习技术的迅速发展，基于图像的自动化昆虫分类方法逐渐成为研究热点。这种方法不仅可以提高分类的效率和准确性，还能为昆虫学研究和生态监测提供有力支持。然而，公开可用的虫子图像数据集较为稀缺，尤其是面向小样本、边缘设备部署场景下的高质量虫子目标检测数据集更是凤毛麟角。

为满足这一需求，我们整理并清洗了一套包含近3000张图片的虫子识别数据集，涵盖七种常见虫子种类。该数据集已按照训练集、验证集和测试集进行了合理划分，每张图像都包含清晰的YOLO格式标注文件，可直接用于深度学习模型的训练与测试，特别适合YOLOv5、YOLOv8、YOLOv11等模型的训练与测试。本文将对该数据集进行详细介绍，包括数据集背景、概述、结构、特点、适用场景等内容，旨在为相关研究和应用提供参考。

数据集背景

昆虫是地球上最多样化的生物类群之一，其种类繁多，分布广泛，对生态系统的稳定性和农业生产具有重要影响。据估计，全球昆虫种类超过100万种，占所有已知动物种类的70%以上。在农业生产中，昆虫扮演着双重角色：一方面，许多昆虫是农作物的害虫，会对农业生产造成严重损失；另一方面，一些昆虫是益虫，如蜜蜂、瓢虫等，对农作物的授粉和害虫防治具有重要作用。

传统的昆虫识别方法主要依赖于专家的形态学鉴定，这种方法不仅需要丰富的专业知识和经验，而且效率低下，难以满足大规模监测和快速识别的需求。随着计算机视觉和深度学习技术的发展，基于图像的自动化昆虫识别方法逐渐成为研究热点。这种方法通过训练深度学习模型，从昆虫图像中自动提取特征并进行分类，具有高效、准确、可扩展性强等优点。

然而，要开发出准确、可靠的昆虫识别模型，高质量、多样化且已标注的数据集是关键基础。目前，公开可用的虫子图像数据集存在以下问题：

1. 样本数量不足：许多数据集样本数量较少，难以支持深度学习模型的充分训练
2. 类别覆盖有限：部分数据集只覆盖少数几种常见虫子，难以满足实际应用需求
3. 标注质量参差不齐：一些数据集的标注不够准确或不一致，影响模型训练效果
4. 数据划分不合理：部分数据集没有进行合理的数据划分，不便于模型的训练和评估
5. 场景单一：许多数据集的图像拍摄场景较为单一，难以适应实际应用中的复杂场景

为应对这些挑战，我们构建了本数据集，旨在为昆虫识别算法的研究与落地提供高质量的数据支持。

数据集概述

本数据集是一个专注于虫子种类识别的高质量数据集，包含近3000张高清虫子图像，覆盖七种常见虫子种类。所有图像均已完成YOLO格式标注，并按照训练集、验证集和测试集进行了合理划分，可直接用于深度学习模型的训练、验证和测试。

基本信息

• 图像总数：近3000张
• 图像格式：JPG（部分为PNG）
• 分辨率：大多在720p以上
• 注释格式：YOLO格式 .txt，与图像同名
• 类别数量：7类常见虫子

• 数据划分：

  • 训练集（train）：2089张
  • 验证集（val）：447张
  • 测试集（test）：448张

文件结构

本数据集采用标准的文件夹结构进行组织，具体如下：

dataset/
├── images/
│   ├── train/
│   ├── val/
│   └── test/
├── labels/
│   ├── train/
│   ├── val/
│   └── test/

其中，images文件夹存放不同划分的图像文件，labels文件夹存放对应的YOLO格式标注文件。这种结构设计不仅便于数据的管理和浏览，也符合主流深度学习框架的数据加载要求。

数据集详情

标注格式

本数据集采用YOLO格式进行标注，每个标注文件对应一张图像，文件名与图像文件名相同，后缀为.txt。标注文件的每一行表示一个目标，格式如下：

<类别编号> <中心点x坐标> <中心点y坐标> <宽度> <高度>

其中，坐标值和宽高均为相对于图像宽度和高度的归一化值，范围在0到1之间。例如，某张图像的标注文件内容为：

3 0.512 0.439 0.187 0.274

表示第4类虫子在图像中的相对位置与大小。

数据来源

本数据集的图像来源包括：

1. 实地拍摄：在农田、果园、森林等实际场景中拍摄的虫子图像
2. 公开资源：从公开的虫子图像数据库中收集的图像
3. 人工处理：对收集到的图像进行清洗、去噪、增强等处理

所有标注均由专业人员完成，确保了高准确性和实用性。

样本特点

本数据集的样本具有以下特点：

1. 多样性：涵盖了七种常见虫子种类，每种虫子都有多个样本
2. 场景丰富：图像拍摄场景多样，包括不同光照、角度、背景下的虫子图像
3. 质量高：所有图像均为高清拍摄，虫子特征清晰可辨
4. 标注准确：所有图像均由专业人员标注，确保标注的准确性和一致性
5. 小样本平衡：部分小样本类别适合用于数据增强、Few-shot等研究场景

数据处理流程

为确保数据集的质量和可用性，我们在构建过程中遵循了严格的数据处理流程，具体步骤如下：

flowchart TD
    A[数据收集] --> B[数据清洗]
    B --> C[图像预处理]
    C --> D[虫子标注]
    D --> E[数据划分]
    E --> F[格式转换]
    F --> G[质量验证]
    G --> H[数据集发布]

1. 数据收集：从多个来源收集虫子图像，包括实地拍摄、公开资源等
2. 数据清洗：对收集到的图像进行清洗，去除模糊、遮挡严重的图像
3. 图像预处理：对清洗后的图像进行去噪、增强、尺寸统一等处理
4. 虫子标注：由专业人员对图像中的虫子进行标注，包括类别和边界框
5. 数据划分：按照7:1.5:1.5的比例划分为训练集、验证集和测试集
6. 格式转换：将标注结果转换为YOLO标准格式
7. 质量验证：对处理后的数据进行质量检查，确保标注的准确性和一致性
8. 数据集发布：打包发布数据集，提供下载链接

数据集特点

本数据集具有以下显著特点：

1. 样本充足：总计近3000张图像，每个类别均有足够的样本量，确保模型训练的充分性
2. 类别多样：涵盖了七种常见虫子种类，基本覆盖了农业生产中常见的害虫和益虫
3. 标注规范：所有图像均采用YOLO格式标注，标注精度高，格式统一
4. 数据划分合理：按照训练集、验证集和测试集进行了合理划分，符合深度学习模型训练的常规要求
5. 场景真实：图像均来自实际场景，具有较高的真实感和代表性
6. 格式标准：采用YOLO标准格式标注，可直接用于主流深度学习框架
7. 开箱即用：已完成数据预处理和标注，可直接用于模型训练和评估
8. 小样本支持：部分小样本类别适合用于数据增强、Few-shot等研究场景

适用场景

本数据集可广泛应用于以下研究与实际应用场景：

1. YOLO系列模型训练

可直接用于训练YOLOv5、YOLOv8、YOLOv11等目标检测模型，用于实际部署或研究验证。通过在本数据集上训练模型，可以提高虫子识别的准确率和效率，为相关应用提供技术支持。

2. 多类虫子识别分类研究

可用于多类虫子识别分类研究，探索不同深度学习模型和算法在虫子识别任务上的性能。例如，可以比较不同卷积神经网络架构、注意力机制、数据增强方法等对虫子识别性能的影响。

3. 数据增强/迁移学习实验

可用于数据增强和迁移学习实验，探索如何利用有限的样本训练出性能良好的模型。例如，可以研究不同数据增强方法对小样本虫子识别性能的影响，或者利用在大型数据集上预训练的模型进行迁移学习，提高虫子识别的性能。

4. 小样本学习研究

部分小样本类别的存在使得本数据集适合用于小样本学习研究，探索如何从少量样本中学习有效的特征表示。例如，可以研究元学习、少样本学习等方法在虫子识别任务上的应用。

5. AIoT边缘设备部署测试

可用于AIoT边缘设备部署测试，探索如何将训练好的模型部署到资源受限的边缘设备上。例如，可以研究模型压缩、量化、剪枝等技术，减少模型大小和计算复杂度，使其适合在边缘设备上运行。

6. 农业害虫识别模型开发

可直接应用于农业害虫识别模型的开发，实现对农田、果园、森林等场景中害虫的自动识别和监测。例如，可以开发基于移动设备的害虫识别App，帮助农民快速识别害虫并采取相应的防治措施。

7. 生态虫类分类研究

可用于生态虫类分类研究，探索不同生态环境中虫子的分布和多样性。例如，可以利用训练好的模型对野外采集的虫子图像进行自动分类，为生态监测和生物多样性研究提供数据支持。

8. 学生科研课题和AI竞赛

适合用作学生科研课题、AI竞赛、学术研究中的标准基准测试集。例如，学生可以利用本数据集开展深度学习相关的科研项目，或者参加AI竞赛，提高实践能力和创新能力。

模型训练建议

针对本数据集的特点，我们提出以下模型训练建议：

1. 模型选择

对于目标检测任务，建议使用以下模型：

• YOLOv8：性能均衡，适合大多数应用场景
• YOLOv11：最新版本，精度和速度都有提升
• YOLOv5：经典版本，社区支持丰富

对于资源受限的场景，可以考虑使用YOLOv8n、YOLOv11n等轻量级模型。

2. 数据增强

建议使用以下数据增强技术：

• 随机翻转：水平翻转和垂直翻转，增加数据多样性
• 随机裁剪：随机裁剪图像的一部分，增强模型对虫子不同大小的适应能力
• 随机旋转：随机旋转图像，增强模型对虫子不同角度的适应能力
• 亮度和对比度调整：随机调整图像的亮度和对比度，增强模型对不同光照条件的适应能力
• 颜色抖动：随机调整图像的颜色，增强模型对不同颜色变异的适应能力
• 马赛克增强：将多张图像拼接成一张，增加小目标的数量

3. 训练策略

• 批量大小：根据硬件资源选择合适的批量大小，建议使用8-32
• 学习率：初始学习率设置为0.001，使用余弦退火策略调整学习率
• 优化器：使用AdamW优化器，权重衰减设置为0.0005
• 训练轮数：建议训练100-300轮，根据验证集性能动态调整
• 早停策略：当验证集性能连续多个轮次没有提升时，停止训练

4. 评估指标

使用以下指标评估模型性能：

• mAP@0.5：IoU阈值为0.5时的平均精度
• mAP@0.5:0.95：IoU阈值从0.5到0.95，步长为0.05时的平均精度
• 精确率：正确预测的正样本占总预测正样本的比例
• 召回率：正确预测的正样本占总实际正样本的比例
• F1-score：精确率和召回率的调和平均值

5. 模型优化

• 模型剪枝：去除冗余的神经元和连接，减少模型大小
• 模型量化：将模型权重从32位浮点数量化为8位整数，减少模型大小和计算复杂度
• 知识蒸馏：利用大模型的知识指导小模型的训练，提高小模型的性能
• 部署优化：针对不同部署平台进行优化，如TensorRT、ONNX Runtime等

应用案例

案例一：智能害虫监测系统

基于本数据集训练的YOLOv8模型，开发了一款智能害虫监测系统。该系统通过安装在农田中的摄像头，实时采集田间图像，然后利用训练好的模型自动识别图像中的害虫种类和数量。系统会根据识别结果，生成害虫监测报告，并在害虫数量超过阈值时发出预警，提醒农民及时采取防治措施。该系统已在多个农场试用，有效提高了害虫监测的效率和准确性，减少了农药的使用量。

案例二：移动设备害虫识别App

利用本数据集训练的轻量化模型，开发了一款移动设备害虫识别App。用户只需拍摄害虫照片，App就能自动识别害虫种类，并提供相应的防治建议。该App已在多个应用商店上线，受到了农民和园艺爱好者的广泛欢迎。通过使用该App，用户可以快速识别害虫，采取针对性的防治措施，减少害虫对作物的损害。

案例三：生态监测系统

将训练好的模型集成到生态监测系统中，用于监测自然保护区和森林中的虫子种类和分布。系统通过安装在野外的摄像头，定期采集虫子图像，然后利用训练好的模型自动识别虫子种类。系统会将识别结果上传到云端，生成生态监测报告，为生态保护和生物多样性研究提供数据支持。该系统已在多个自然保护区试用，为生态监测工作提供了有力的技术支持。

案例四：农业无人机巡检

将训练好的模型部署到农业无人机上，实现对大面积农田的快速巡检。无人机通过搭载的摄像头，采集农田图像，然后利用训练好的模型实时识别图像中的害虫。巡检完成后，无人机返回基地，生成害虫分布热力图，为农民提供精准的防治指导。该应用已在多个大型农场试用，有效提高了巡检效率，减少了人工成本。

数据集扩展与未来规划

本数据集是我们在虫子识别领域的初步尝试，未来我们计划从以下几个方面对数据集进行扩展和完善：

1. 增加虫子种类：进一步扩展虫子种类，涵盖更多农业生产中常见的害虫和益虫，以及生态系统中的其他虫子种类
2. 扩大数据集规模：增加图像数量，提高数据集的多样性和代表性，特别是增加小样本类别的样本数量
3. 添加多模态数据：结合红外成像、光谱分析等多模态数据，构建更加全面的虫子识别数据集
4. 引入动态视频数据：添加虫子活动的视频数据，捕捉虫子的动态行为，提高模型对时序信息的理解能力
5. 提供预训练模型：基于扩展后的数据集，训练并发布预训练模型，方便用户直接使用
6. 开发标注工具：开发专门的虫子标注工具，提高标注效率和准确性
7. 建立社区平台：建立虫子识别数据集社区平台，鼓励用户贡献数据和标注，共同完善数据集

结语

虫子识别是农业智能化和生态研究中的重要任务，具有广泛的应用前景。一个高质量的数据集是推动虫子识别技术发展的关键基础。本数据集通过系统性地收集、整理和标注近3000张虫子图像，为虫子识别算法的研究与落地提供了有力支持。

本数据集不仅具备清晰的标注与合理的类别分布，还可灵活用于多种计算机视觉任务，适合快速实验验证与模型迭代训练。我们希望通过本数据集的发布，能够促进虫子识别技术的发展，推动相关应用的落地。

我们将持续优化该数据集，并欢迎大家在实际项目中加以应用、反馈和改进建议。通过共同努力，我们相信虫子识别技术将会取得更大的突破，为农业生产和生态保护做出更大的贡献。

总结

本次发布的《七种常见虫子的图像识别数据集》为农业智能化、生态环境监测、AI视觉模型研究等领域提供了一个高质量、结构规范的图像识别基准数据集。数据集共包含近3000张已标注图像，覆盖7类常见虫子，采用标准YOLO格式，已按训练、验证、测试集划分完毕，可直接应用于YOLOv5、YOLOv8、YOLOv11等主流目标检测框架。

该数据集不仅适合用于常规的目标检测任务，也适合开展迁移学习、小样本学习、轻量化部署等前沿研究，特别契合农业害虫识别、生态虫类分类等实际应用需求。我们将持续更新并配套提供训练脚本与部署方案，欢迎研究者和开发者在合法合规范围内广泛使用与改进本数据集。

AI虫害识别，从此高效精准。

全文链接：https://tecdat.cn/?p=44991
原文出处：拓端数据部落公众号

文本智能分析实战：从嵌入到聚类的全流程解析

在信息爆炸的当下，如何高效处理海量无标注文本数据并按主题归类，是企业提升信息管理效率的核心需求。传统文本聚类方法如TF-IDF仅依赖词频统计，无法区分“自然树”与“决策树”这类多义词；Word2Vec虽能捕捉词间关系，却难以整合长文本的整体语义。随着大语言模型技术的成熟，预训练模型生成的文本嵌入为解决这一痛点提供了新路径，它能精准捕获上下文语义，将文档编码为富含整体含义的数值向量。

本文将结合实际项目经验，详细讲解如何使用Scikit-learn库，结合SentenceTransformer生成的文本嵌入，应用K-Means和DBSCAN算法完成文本聚类，并通过PCA实现可视化分析。本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整代码与数据已分享至交流社群。阅读原文进群，可与900+行业人士交流成长；还提供人工答疑，拆解核心原理、代码逻辑与业务适配思路，帮大家既懂 怎么做，也懂 为什么这么做；遇代码运行问题，更能享24小时调试支持。

假设你突然接手了一批未分类的文档，需要按主题快速分组。传统文本聚类方法各有局限：TF-IDF只统计词频，忽略语义，比如“树很大”既可能指自然植物，也可能指机器学习模型，它无法区分；Word2Vec能学习词间关系，但对长文本的整体语境整合能力不足。
此时，大语言模型生成的文本嵌入优势凸显。以Sentence Transformer为例，它能捕获文本的上下文语义，将整篇文档编码为一个数值向量，且这些模型经过海量文本预训练，自带丰富的通用语言知识。
接下来我们逐步完成文本聚类项目，先准备Python库，再加载数据、生成嵌入、聚类分析，最后评估效果。
首先导入所需模块：

import pandas as pdimport numpy as npfrom sentence_transformers import SentenceTransformerfrom sklearn.cluster import KMeansfrom sklearn.decomposition import PCAfrom sklearn.metrics import silhouette_score, adjusted_rand_scorefrom sklearn.preprocessing import LabelEncoderimport matplotlib.pyplot as pltimport seaborn as sns# 设置可视化风格sns.set_style("whitegrid")plt.rcParams['figure.figsize'] = (12, 6)......# 省略部分可视化配置代码

这里导入了数据处理库pandas、numpy，生成嵌入的SentenceTransformer，聚类算法KMeans和DBSCAN，降维用的PCA，评估指标轮廓系数和调整兰德指数，以及可视化工具matplotlib和seaborn。
接着加载数据集，我们使用公开的新闻文本数据集，其中每篇文章都有对应的主题标签：

加载后可见数据集包含数千篇文档，分为多个主题类别，这些真实标签可用于后续评估聚类效果。
现在进入核心环节：生成文本嵌入和聚类分析。
首先生成嵌入，我们选用轻量级预训练模型，它能将每篇文档转换为384维的数值向量：

# 加载预训练的嵌入模型print("正在加载嵌入模型...")embed_model = SentenceTransformer('all-MiniLM-L6-v2')

在生成的向量空间中，语义相似的文档距离更近，便于后续聚类算法分组。

相关文章

大语言模型LLM高级Prompt临床科研辅助研究——AdaBoost、LightGBM、MLP等模型的食道癌预测、遗传性听力损失诊断及心肌病识别|附代码数据

原文链接：https://tecdat.cn/?p=44689

先使用K-Means算法聚类。K-Means需提前指定聚类数量，这里我们利用已知的真实类别数，实际应用中也可通过肘部法等选择合适值：

调整兰德指数（ARI）用于衡量聚类结果与真实类别的一致性，值越接近1效果越好，从结果可见K-Means在该数据集上表现良好。
再尝试DBSCAN算法。它是基于密度的聚类，无需提前指定聚类数，能自动确定聚类数量并标记离群点为噪声，但对参数敏感，需仔细调试：

为直观展示聚类效果，用PCA将高维嵌入降至2维，绘制真实类别、K-Means和DBSCAN聚类的对比图：

从可视化结果可见，在该数据集上默认参数的K-Means效果优于DBSCAN。原因有二：一是DBSCAN易受“维度灾难”影响，384维嵌入对密度-based方法挑战较大；二是该新闻数据集主题区分明显，聚类间相对分隔，适合K-Means算法。
实际项目中可根据数据特点选择算法，也可调试DBSCAN参数优化效果。Sentence Transformer等大语言模型嵌入能有效捕捉文本语义，为后续任务奠定良好基础。
 

全文链接：https://tecdat.cn/?p=44985
原文出处：拓端数据部落公众号

在大语言模型技术快速普及的当下，通用大模型在垂直行业的落地面临着三大核心痛点：一是云端API调用存在数据隐私泄露风险，尤其医疗、金融等强监管行业对数据本地化有硬性要求；二是云端服务存在网络延迟与持续的token计费成本，长期使用性价比极低；三是通用大模型在垂直领域的专业推理能力不足，无法直接适配行业场景的业务需求。
我们在过往服务企业客户的过程中发现，开源大模型的本地化部署与轻量化微调，是解决上述痛点的最优路径。本文基于阿里最新开源的Qwen3大模型，从零基础的本地环境搭建、交互式应用开发，到医疗垂直领域的轻量化微调全流程，形成了一套可直接落地的工程化方案。方案兼顾了普通消费级硬件的适配性与专业场景的性能要求，即使是入门级的学生与开发者，也能快速复现完整流程。
本文内容改编自过往客户咨询项目的技术沉淀并且已通过实际业务校验，该项目完整代码与数据已分享至交流社群。阅读原文进群，可与800+行业人士交流成长；还提供人工答疑，拆解核心原理、代码逻辑与业务适配思路，帮大家既懂 怎么做，也懂 为什么这么做；遇代码运行问题，更能享24小时调试支持。
本文将先讲解Qwen3本地化部署的核心价值与具体实现方法，再基于Gradio开发可切换推理模式的交互式应用，最后通过LoRA低秩适配技术完成模型在医疗推理场景的轻量化微调，验证方案的行业落地效果。

本文全流程脉络流程图

Qwen3本地化部署的核心价值与实现方案

Qwen3是阿里推出的新一代开源大语言模型，支持100+种语言，在推理、代码生成、翻译任务上的表现可对标DeepSeek-R1、Gemini 2.5等头部模型，同时提供了从0.6B到235B全量级的模型版本，完美适配从边缘设备到企业级服务器的各类硬件环境。
相比云端大模型服务，Qwen3本地化部署具备五大不可替代的优势：

1. 数据隐私安全：所有交互数据全程保留在本地设备，无任何数据外传风险，完全满足医疗等行业的合规要求
2. 低延迟响应：本地推理无需网络往返，消除了API调用的网络延迟，交互体验更流畅
3. 长期成本可控：无token计费与云端服务费用，一次部署可无限次使用，大幅降低长期使用成本
4. 全流程可控：可自主配置prompt模板、选择模型版本、切换推理模式，完全掌握模型的运行逻辑
5. 离线使用能力：模型下载完成后，无网络环境也可正常运行，适配无公网的业务场景
   本次部署选用Ollama作为核心工具，它是一款轻量化的本地大模型运行工具，支持Windows、macOS、Linux全平台，国内可直接访问官网下载安装包，无访问限制，通过简单的命令行即可完成模型的下载、运行与服务发布。

部署步骤与核心实现

步骤1：Ollama环境安装

从Ollama官网下载对应系统的安装包，按照安装向导完成部署后，在终端输入以下命令验证安装是否成功：

ollama --version

该命令会输出当前安装的Ollama版本号，确认环境安装无误。

步骤2：Qwen3模型下载与本地运行

Ollama官方已适配全系列的Qwen3模型，可根据自身硬件配置选择对应版本，消费级笔记本推荐4B、8B版本，高性能设备可选择14B、32B版本。
在终端输入以下命令，即可自动完成模型下载与启动：

# 启动默认8B版本Qwen3ollama run qwen3# 硬件资源有限可选择4B轻量化版本ollama run qwen3:4b

Qwen3全系列模型适配信息如下表所示：

步骤3：本地API服务发布（可选）

若需要将本地模型对接其他应用，可通过以下命令启动API服务，服务默认地址为http://localhost:11434，支持通过HTTP接口调用模型能力：

ollama serve

多方式本地推理实现

完成模型部署后，可通过三种方式实现本地推理，适配不同的使用场景。

方式1：终端CLI直接推理

可直接在终端输入prompt完成交互，通过/think标签开启深度分步推理，/no_think标签获取快速响应，示例命令如下：

echo "巴西的首都是哪个城市？ /think" | ollama run qwen3:8b

方式2：HTTP API接口调用

在ollama serve服务启动后，可通过curl命令调用API接口实现推理，适合后端服务集成与自动化场景，示例代码如下：

方式3：Python SDK调用

Python环境下可通过Ollama官方SDK实现模型调用，适合本地实验、原型开发与自定义应用搭建，先通过pip完成SDK安装：

核心调用代码如下：

相关文章

大语言模型LLM高级Prompt临床科研辅助研究——AdaBoost、LightGBM、MLP等模型的食道癌预测、遗传性听力损失诊断及心肌病识别|附代码数据

原文链接：https://tecdat.cn/?p=44689

基于Gradio的Qwen3本地交互式应用开发

Qwen3支持/think深度推理与/no_think快速响应双模式，同时具备100+语言的翻译能力，我们基于Gradio开发了一款轻量化本地Web应用，包含两大核心功能模块：推理模式切换界面、多语言翻译处理界面。

核心功能代码实现

代码已完成变量名、函数名全量修改，注释汉化，同时省略了异常处理等非核心代码，注明省略内容。

1. 推理模式切换模块开发

2. 多语言翻译模块开发

3. 双模块整合与应用启动

# 整合两个功能模块为标签页界面full_app = gr.TabbedInterface( [reasoning_interface, multilingual_interface], tab_names=["推理模式切换", "多语言翻译"])# 启动本地Web应用full_app.launch(debug = True)

应用启动后，会自动在浏览器打开本地Web界面，效果如下图所示：

基于LoRA低秩适配的Qwen3医疗推理领域轻量化微调

通用大模型在医疗专业场景中，容易出现推理逻辑不严谨、专业术语使用错误、临床决策不符合规范等问题，通过垂直领域微调可大幅提升模型的医疗专业能力。本次微调基于FreedomIntelligence/medical-o1-reasoning-SFT（医疗o1推理SFT数据集），采用4-bit量化+LoRA低秩适配技术，在单张A100显卡上仅需40分钟即可完成训练，实现了低成本的垂直领域模型优化。

微调环境与平台说明

本次微调使用RunPod云GPU平台完成，该平台国内无法直接访问，国内替代方案包括AutoDL、恒源云、阿里云GPU云服务器、腾讯云GPU实例，均可提供同配置的A100显卡环境，操作流程与本文完全一致。

1. 环境初始化

进入GPU实例的Jupyter Lab后，先安装所需的Python依赖库，命令如下：

pip install -U accelerate peft trl bitsandbytes transformers datasets huggingface_hub

安装完成后，通过Hugging Face Token完成账号登录，Hugging Face国内可通过hf-mirror.com镜像站访问，国内替代平台包括魔搭ModelScope、飞桨AI Studio，均提供开源模型与数据集的免费下载服务。

2. 模型与分词器加载

采用4-bit量化技术加载Qwen3-32B模型，大幅降低显存占用，核心代码已完成变量名修改与注释汉化，省略了非核心配置项：

3. 数据集加载与预处理

本次使用医疗推理数据集，设计了包含分步思考的prompt模板，引导模型学习医疗场景的严谨推理逻辑，核心代码如下，省略了数据清洗与异常值处理代码：

格式化后的数据集样本如下图所示：

4. LoRA低秩适配配置与训练

LoRA技术通过冻结基础模型的全量参数，仅训练少量低秩分解矩阵，在保证微调效果的同时，大幅降低训练的显存占用与时间成本，核心配置代码如下：

微调前先对基础模型进行推理测试，结果显示基础模型的思考过程冗长且无明确结论，与医疗场景的专业推理要求差距较大：

训练过程中GPU资源占用与训练损失变化如下图所示，单张A100显卡训练仅耗时42分钟，训练损失持续下降，模型收敛效果良好：

5. 微调效果验证

训练完成后，对微调后的模型进行同样本推理测试，结果显示模型的思考过程简洁严谨，回答精准，完全符合医疗专业推理的要求，微调效果显著：


最后可将微调后的LoRA模型与分词器上传至Hugging Face Hub，完成模型的保存与分享，核心代码如下：

final_model_name = "Qwen-3-32B-Medical-Reasoning"llm_model.push_to_hub(final_model_name)text_tokenizer.push_to_hub(final_model_name)

总结

本文完整实现了Qwen3大模型从本地化部署、交互式应用开发到医疗垂直领域轻量化微调的全流程，通过Ollama工具实现了消费级硬件上的模型本地运行，基于Gradio开发了可灵活切换推理模式的交互式应用，最终通过LoRA低秩适配技术，以极低的算力成本完成了模型在医疗推理场景的专业能力优化。
整套方案具备极强的可复现性与落地价值，既适合学生与入门开发者学习大模型的部署与微调全流程，也可直接适配企业级的垂直领域大模型本地化落地需求。本文所有代码均可直接运行，完整的项目代码与数据集已分享至交流社群。

奶酪奶油工厂的生产管理 MES（Manufacturing Execution System，制造执行系统）是连接企业计划层（如ERP）与车间控制层的关键信息系统，用于对乳制品（特别是奶酪和奶油）的生产过程进行实时监控、调度、追踪与优化。以下是万界星空针对奶酪奶油工厂特点设计的 MES 系统核心功能模块及实施建议：

一、奶酪奶油工厂的生产特点
原料敏感：鲜奶等原料易变质，需严格温控与保质期管理。
工艺复杂：涉及巴氏杀菌、发酵、凝乳、压榨、熟成（奶酪）、离心分离（奶油）等多道工序。
批次追溯要求高：食品安全法规（如HACCP、ISO 22000）要求全程可追溯。
设备自动化程度不一：可能混合使用手动、半自动和全自动设备。
清洁要求严苛：CIP（就地清洗）频繁，需记录清洗周期与效果。

二、MES 系统核心功能模块
1、生产订单管理
接收 ERP 下达的生产工单（如：奶油500kg、切达奶酪200块）。
自动排产，考虑设备可用性、人员班次、原料库存。
2、配方与工艺路线管理
维护标准配方（BOM）和工艺流程（Routing）：
奶油：原料奶 → 分离 → 标准化 → 巴氏杀菌 → 冷却 → 包装
奶酪：原料奶 → 杀菌 → 发酵 → 凝乳 → 切割 → 排乳清 → 成型 → 盐渍 → 熟成
支持版本控制与变更审批。
3、批次与物料追踪（Traceability）
从原料批次（如牧场A 20260210 批次鲜奶）到成品批次（如奶油 20260213-B001）全程正向/反向追溯。
记录关键参数：温度、pH值、时间、操作员、设备ID。
4、过程监控与数据采集（SCADA集成）
实时采集发酵罐温度、离心机转速、CIP清洗电导率等数据。
异常报警（如杀菌温度低于72℃持续15秒）自动停线或通知。
5、质量管理（QMS集成）
在线质检点设置（如脂肪含量、水分、微生物指标）。
不合格品自动隔离并触发返工或报废流程。
6、设备维护与OEE分析
记录设备运行状态、故障停机时间。
计算OEE（设备综合效率），识别瓶颈工序。
7、清洗管理（CIP Tracking）
自动记录每次CIP的时间、清洗液浓度、温度、持续时间。
未完成CIP禁止启动下一批次生产。
8、报表与合规支持
自动生成符合 FDA、EU 或 GB 标准的生产日志。
支持审计追踪（Audit Trail）：谁在何时修改了什么参数。

三、技术架构建议
部署方式：本地部署或工业云（需满足数据安全与低延迟）。
集成接口：
向上对接 ERP（SAP/用友/金蝶）
向下对接 PLC/SCADA（如西门子、罗克韦尔）
对接 LIMS（实验室信息管理系统）
移动端支持：车间平板/手持终端扫码报工、质检录入

四、实施注意事项
先梳理现有工艺流程与痛点（如追溯困难、换线时间长）。
分阶段上线：先核心模块（订单+追溯+监控），再扩展质量与维护。
员工培训：尤其一线操作员需熟悉条码/RFID操作。
数据标准化：统一物料编码、设备编码、工序代码。
如您有具体需求（如工厂规模、现有系统、预算范围），可私信联系我们定制解决方案。

作者：谭宇

枫清科技（Fabarta）技术合伙人兼CTO

——本文AI含量0%， 请放心阅读。

引言

回顾过去一年，实在不知道取什么标题，所以姑且以“AI 又一年”敷衍了。

2025年年初，DeepSeek 以一己之力将 AI 带入了大众视野，做到了路边大爷大妈都开始讨论的程度，DeepSeek一体机层出不穷，虽然最终在应用层面并未改变格局，但其贡献不可磨灭，其低成本高性能的特性，让本轮 AI 具备了极大的应用潜力，和世纪初的互联网泡沫绝然不同。从这个角度来说，DeepSeek 坚决打破了AI观望论，各企业都开始认真思考 AI+ 的问题。

接下来的Manus 将这波热潮再次推高，各类打工人纷纷高呼‘狼来了’，老板则琢磨能裁掉多少员工，然而，——前途是光明的，道路是曲折的。

GPT-5 从预期上半年发布一直延迟到8月，并未再掀起更高的热度，最近发布的 Opus 4.5 / GLM 4.7 / Minimax M2.1 算是为年初的 AI 热潮作了一个交待，虽然总体上离大众期待还有差距，但也取得了长足的进步， AI 带来的大变革已经轰然拉开序幕。

Notion CEO Ivan Zhao 在年终回顾文章《Steam, Steel, and Infinite Minds》中有非常好的描述：

在蒸汽机发明之前，纺织厂的动力是通过水车驱动的，所以一定要建立在河流附近。蒸汽机出现后，工厂主最初仅替换动力源(水车），效能提升有限。真正的突破来自于工厂主意识到使用蒸气机可彻底摆脱水力约束，将工厂建在工人、港口和原料附近，并围绕蒸汽机重构生产流程（电力普及后更进一步通过小型电机将动力分布式化），才真正引爆了第二次工业革命。

他得出结论：

对于AI来说，现在就像蒸汽机刚刚出现的时候，我们仍然处于换水轮的阶段。 我们还没有想到摆脱过去的限制(纺织厂必须建立在水源附近)后公司应该如何运作。所以现阶段的提升是有限的，但历史洪流不可阻挡。

这篇文章不长，非常值得一读，推荐大家亲自阅读并思考。这对于技术人员来说其实并不陌生，其实就是"native" 的概念，互联网刚出现的时候，大家都要“互联网化”， 云计算出现后，大家都喊出要 “Cloud native"， 数字化时代又喊着要数字化，数据是最重要的资产，本质上都是新的生产力出现后，围绕着新的生产力重塑生产关系，如今又面临着 “AI native"，大的方向没有问题，只是实践的过程中往往会困难重重，因为：

“未来总戴着过去的伪装，令人难以辨识与预测，早期的电话通话简洁如电报。早期的电影看起来像拍摄的戏剧（这正是麦克卢汉所言'透过后视镜驶向未来'）。今天流行的人工智能形态，恰如昔日Google搜索框“。

“我们现在正深陷于每一次新技术转型时都会出现的那个不舒适的过渡阶段。”

这非常好的描述了过去一段时间AI实践的现状，本质上都在不断的尝试，摸索与犯错不可避免，因为没有人知道确切的终局应该长什么样子，或者说终局本来就是不断持续摸索出来的，这正是”AI+产业“的巨大机会。

作为AI+产业的实践者，Fabarta 在2025 服务了涵盖金融、制造、能源等多个行业的企业，其中不乏央/国企客户、龙头企业，并与多家大型企业组建联合实验室，共同探索AI+产业的发展路径。这个过程中也观察到不少现象与收获了一些感悟，且写出来与大家分享。

Fabarta AI 实践观察

从RAG 到 Agent

大多数企业接触AI都是从RAG和知识库起步，其价值是让大模型访问其并不具备的私有知识，产品形态从最初的知识库开始转变为Agent的上下文， 这正是过渡阶段典型的产物，Fabarta在建设企业RAG或知识库遇到几个困难点：

• 产品价值不够彰显。 作为最初构建的AI应用，企业会在这个阶段投入很多基础设施，特别是在中国，很多企业都需要私有化部署，整体投入会比较大，企业仅单纯产出知识库会觉得投入产出比很低。
• 知识来源复杂。 送给大模型的语料质量参差不齐。企业之前的文件大多是PDF或办公软件的制品，这对大模型来说并不友好，我们投入了大量的精力来处理高质量的解析，从传统的OCR pipeline到多模态大模型解析，但始终有解析不了的情况出现。如果从终态来看，要么未来大模型能力足够强，能够自行解析这些内容；要么整个企业内容环境发生变化，所有资料都以适配大模型的格式（markdown、code 等）准备。
• 回答的准确度因人、因业务场景而异。 不同人要求的风格、准确度并不一致，有时候可能因为领导的一个bad case 导致整个产品评价不高。
• 企业内部模型问题。 国内的企业普遍不信任云上的大模型，而内部的模型能力往往参数较小，这对于应用层来说就要做大量的工程手段，而这些都随着模型的发展趋于无效。

总体上来说，单纯知识库构建已经不是企业的重点，而且这个领域深耕面临着技术过渡的问题。更多的是作为Agent的上下文的来源。

从短时Agent 到后台长期运行

Agent 本质，是将原本由人工梳理的复杂业务逻辑，逐步放权给 AI 自主执行。

最初构建的Agent可能非常简单，比如Agentic RAG。但很快就会走到“一个Agent就是原来的一个业务系统” 的层面。 企业不再满足Agent的形态还是问答，而是有完整的业务定义、上下文、工具和UI展示。赋予Agent的权限也越来越大。目前落地效果最好的 Agent，应该说还是 Coding Agent，他拥有：

• 读写文件权限。
• 执行命令的权限，这样整个操作系统的能力都可以为其所用。
• 写代码并执行的权限，拥有无限想象空间。
• 极佳的验证与反馈：编译/ 测试用例以及详细的错误信息。
• 连贯而完整的上下文，所需依赖都能在代码仓库中找到。

而将其放到业务系统中，就会面临：

• 上下文缺失。一个业务可能依赖其他几个业务系统，Agent难以获取完整的业务上下文。
• 验证缺失。Agent无法判断自身执行结果的对错，缺失反馈。
• 这是今天Agent进入核心业务的主要障碍。

开始从外围到核心业务渗透

AI 已经开始逐步渗透进核心业务流程。AI 应用前期主要集中在问答、数据查询类场景，且不会对原有业务流程产生影响，但现在已经逐步进入科研、经营分析与决策、风险控制、单据校验等核心业务流程之中。

以Fabarta自身构建的跨境智能业务为例，可以全流程让Agent自主填单、自主校验、自主提交或要求补充信息。

在化工新材料、生物医药等行业，开始将AI能力融入到科研流程、安全生产等各环节中。尤其针对AI+科研领域，通过通用智能体实现对于论文、专利的检索、精读以及科研报告生成；通过场景智能体实现聚合物生成与筛选，反应釜和流化床的优化等。AI4S领域的AI应用可以助力提升科研效率，节省生产成本。

在教育行业，无论是在K12还是K20， 都在将AI纳入日常的教学工作中，由AI来完成从教育到测评的全过程。

很多企业在将经营分析与决策、行业研究等主要工作交给相关的Agent完成。

虽然还只是开始，但已经可以看出AI进入关键业务领域的趋势，为此需要考虑到大量的预处理及围栏的工作，这些都有望随着技术的发展、业务范式的转移而得到改善，实现由点及面的 AI Native 全链路变革。

Coding Agent在外溢到通用办公领域

Fabarta在2025年7月推出了个人专属智能体，用于在本地电脑上处理日常工作，将本地文件智能处理作为核心亮点，该功能也是 Fabarta 先于行业推出的，在年末，随着cowork的推出，类似能力与方向也得到了验证，在Fabarta个人专属智能体推出的时候，我们就有相应的思考：

• 当前主流的AI应用并非以“用户”为中心，而是以“模型”为中心，这也导致其在用户体验上存在明显痛点。 比如用户只能主动上传受限制的文档，AI应用再基于这些文档产出一些中间产物，用户再将这些中间产物整合进自己最终产出物上。整个流程在灵活度、效率上都不是最优。
• 当前主流AI应用是AI将人引入到了它的工作流中，而并非是让AI进入到人的工作流里。 比如当今绝大部分AI应用都没有做到贴近用户，形成用户真正的“个人助手”，这类应用或许会提供内容保存入口，但无法做到越用越懂用户。这个过程中只有用户的主动沉淀，AI 并不会进行被动学习与深度的用户理解。所以从这个角度来看，并非 AI 成为了用户的助手，反而是人成为了 AI工作流中的一环。
• 个人数据、企业数据乃至公域数据之间的交互困难。 在实践过程中，个人数据与企业数据之间的交互特别重要。各大模型厂商的AI应用基本都提供了联网搜索能力，虽然仍然有很多交互上的问题，比如要达到好的效果，基本上需要用户自己控制联网搜索的开启时机，不过也算是基本解决了公域数据使用的问题。但企业数据和个人数据并没有很好的连通手段， 我们完成工作的方式基本上可以归结为结合个人积累的素材、企业数据、公域数据来产出。但是目前主流的AI应用没有办法将三者很好的结合起来。

年末随着Anthropic 推出Cowork， 各大厂商也相应推出类似的产品，这一块在2026年必将得到进一步的发展。

模型微调再次成为企业认真考虑的选项

在企业应用大模型的初期，RAG热潮压倒微调，OpenAI等模型厂商虽然提供了微调API，但应用情况却十分有限。直至25年初，以DeepSeek-R1的发布作为一个转折点，微调的技术体系发生了结构性变革。以模型蒸馏，GRPO为代表的后训练算法，引发微调算力成本的结构性质变。同时，LlamaFactory，ms-swfit，verl等微调框架日趋完善，将‘复杂高端的训练算法’拆解为可组合的集装箱化工程模块。这些因素重塑了微调在大模型产业化应用中的形态，使其从高算力成本、高算法门槛的技术，演变为可全民参与的民主化微调能力，企业在这一选项上有了新的考虑。

然而，技术可行性的提升，并不意味着企业可以直接套用通用方案落地业务，这中间隔着整个工业场景的复杂性，与大量客户的访谈中，我们逐步意识到，与通用方案相比，其独特的复杂性在于：业务任务分布高度集中，且规则边界极其复杂，同时显性的SOP 与隐性的业务经验并存；训练数据的结构化程度，决定了微调模型的效果质量上限；模型的主要风险并非知识缺失，而是在多约束、多条件的边界场景下，容易产生推理漂移。

这意味着，企业需要的不是"微调参数"，而是围绕数据体系、结构约束到模型行为对齐的系统工程。枫清科技在化工与新材料研发、企业运营智能文档处理、跨境电商贸易报关，以及电磁频谱活动认知与分析等领域，通过一系列客户项目，持续探索实践了将通用微调技术转化为可交付、可复用的企业级应用能力。详见模型微调：工业场景下的落地实践

• 在化工新材料领域，针对SMILES 语法、分子式、IUPAC 命名等化学领域关键标识 token 进行差异化损失计算，强化结构精确表达能力，构建统一的专业能力底座，支撑智能体平台的科研任务。
• 在电磁频谱活动认知与分析领域，将分散在文档中的隐性知识转化为三元组结构，构建结构化微调语料，通过图谱适配模块将频谱法规、用频规则等结构化知识注入注意力层，实现稳定的多约束推理。
• 在企业单证运营领域，由学生模型生成推理轨迹，在其易出错的环节（数字位数、连续重复、字段边界）进行规则检测，并通过教师模型给出反馈，直接纠正分布偏差，小数据规模下实现高精度识别，轻量模型可部署。

实践表明，工业场景的微调本质是"数据→结构→行为"的系统工程。当微调技术从实验室走向产业，企业获得的不仅是更好的模型，更是可控、可复用、可演进的AI能力体系。

实践中的典型困难

企业对于100%准确率的执着

这个问题的本质在于对大模型能力的边界认知问题，很多客户会像要求传统软件功能一样要求智能体，凡事追求100% 的准确率，这也让我们耗费了大量成本进行解释和后续优化。 但这并非说大模型在业务应用上没有边界，关键是我们怎么在这个限制下进行工作。 Fabarta在实践中使用了多种技术：

• 基于过去多年在数据的领域，结合AI 的特性让数据实现 AI Ready，典型的如面向智能体的数据指标体系建设。
• 通过图来构建更精确的上下文。恢复数据间原本会被拆解、撕碎的关联关系。
• 构建企业的统一语义层来统一业务术语与AI系统。
• 建立完善的人机反馈（Human in loop）机制。

有很多问题并非单点突破就能解决，企业必须立足全局，顺应AI 的应用范式来重构业务流程。这需要 AI 服务提供商与客户不断地沟通磨合、双向输入。

对于热点的过度追踪

在这个阶段，完全不必担心FOMO(Fear of missing out)的问题，先发优势与后发优势各有其价值。大部分企业无法享受先发优势，但可以很实在的把握后发优势。今天AI领域可以说是“AI一天，传统一年”， 如果只是一味追求热点，可能上个热点的实验还没有完成，立即就出了下一个热点。真正有价值的工具与技术，既不会突然爆火，也不会轻易消亡，我们在服务过程中，也会不断收到客户发来的各类新闻和公众号文章，大部分其实都没有什么价值。所以我们要和企业建立一个良好的互动，并和客户一起达成‘慢半拍并不要紧、亲手尝试比道听途说更靠谱’的共识。

变与不变问题的辨别

如果无法厘清行业的变与不变，企业就只能不断地追逐技术热点。我们必须分辨哪些是随着模型能力的增强会消失的，比如为了让工具调用更稳定而做的各种权宜之计（tricks），这类方法在落地时我们就应明确，其只是临时的 workaround，并不值得投入过多精力，但提示词工程、上下文管理、memory 管理这类能力，并不会随着模型能力的提升而消失，反而会越来越重要，这就是我们该重点投入的领域。

展望

随着《Steam, Steel, and Infinite Minds》同步发布的还有另一篇文章《The Trillion-Dollar Opportunity: Context Graphs》，探讨的是当下一个极具热度的话题，即 AI Agent 是否会取代现有的企业系统（Agents Kill Everything），作者同意 Agent 不会完全取代企业当前使用的记录系统（systems of record，比如 CRM、账单系统、员工管理系统等），但他认为目前企业使用的系统都只记录发生了什么，而没有记录为什么发生，但“为什么发生”对于Agent非常重要。而 Agent 处于业务执行链路中，因此有机会捕获完整的决策轨迹，在文中举了几个例子，比如：

• 行业特殊定价：企业内部可能存在‘由于医疗公司采购周期极长，我们会额外给予10% 折扣’的共识，但这通常只存在于老员工的脑子里或入职培训中，而不在 CRM 系统里。
• 历史先例引用：销售团队决定为某公司制定特定交易结构，理由是‘上季度为X 公司制定的交易结构很成功，我们应保持一致’，但没有任何系统将这两笔交易关联，也未记录这种决策一致性的原因。
• 跨系统合成(Cross-system Synthesis) 的决策场景，

￮ 工单升级决策：一名支持主管在决定是否升级工单时，会查看Salesforce（了解客户ARR 价值）、Zendesk（查看未解决的投诉）、Slack（阅读有关流失风险的讨论）以及PagerDuty（确认最近的故障记录）。

￮  隐形审批链：副总裁通过Zoom 电话或Slack 私聊批准了某项折扣，最终CRM 中只记录了一个“结果价格”，而背后的审批人、审批原因等关键背景信息，在系统记录中完全缺失。

所以作者认为，智能体正通过捕获决策轨迹（而非仅采集静态数据）构建上下文图谱。这类新一代记录系统，能够捕捉到传统软件无法记录的例外业务逻辑和跨系统决策背景。上一代企业软件催生了万亿美金市值的产业生态，也诞生了Workday、SAP 这样的软件巨头。而如今处于业务执行链路的初创公司，将凭借这些优势挑战传统巨头，打造下一个万亿美元级的企业软件基石。

这一讨论本身就印证了一个趋势：Agent 正逐步深入企业核心业务领域。 当然对于国内来说，这个问题可能更复杂也可能更简单。说其更复杂，是因为国内企业的数据分布更为分散，传统软件系统的建设本就不完善；说其更简单，则是因为正逢系统建设不完善，企业完全可以顺势重建 AI-native 的业务系统。

更多

2026 年初兴起的新一轮 OpenClaw 热潮，可谓是重复了 2025 年初的技术发展轨迹。但行业风向已然改变，此次热潮并非由模型能力升级引发，而是由产品形态的创新驱动，2026必将又是 “AI 又一年”。

点赞 + 关注 + 收藏 = 学会了

整理了一个n8n小专栏，有兴趣的工友可以关注一下 👉 《n8n修炼手册》

有没有发现 n8n 的聊天窗只有一个输入框，好像没有上传文件的功能。

那是因为没开启“Allow File Uploads”。双击「When chat message received」节点，在“Parameters”里找到“Options”，点击“Add Field”开启“Allow File Uploads”。

回到工作流面板，打开聊天窗口就能看到这里有一个上传文件的按钮。

但需要你用多模态大模型，才能识别图片内容。我用 Kimi-k2.5 演示一下。

上传一张小恐龙图片。

问它“这张图里的动物是什么？”。

Kimi-k2.5 很快就识别出来了。

以上就是本文的全部内容啦，想了解更多n8n玩法欢迎关注《n8n修炼手册》👏

如果你有 NAS，我非常建议你在 NAS 上部署一套 n8n，搞搞副业也好，帮你完成工作任务也好 《『NAS』不止娱乐，NAS也是生产力，在绿联部署AI工作流工具-n8n》

点赞 + 关注 + 收藏 = 学会了

马年将至，百灵 Ming-flash-omni-2.0 正式焕新登场！在这个辞旧迎新的时刻，让我们先请出 Ming-flash-omni-2.0 为大家送上一份特别的“马年祝福”！

01 Ming-flash-omni-2.0 速览

本次发布的百灵全模态大模型 Ming-flash-omni-2.0，基于 Ling-2.0（MoE 架构，100B-A6B）架构训练。相比之前发布的 Preview 版本，Ming-flash-omni-2.0 实现了全模态能力的代际跃迁，无论是在复杂的视觉理解、充满情感的语音交互，还是极具创意的图像编辑上，Ming-flash-omni-2.0 的实测表现均已跻身开源领先水准。

长期以来，多模态大模型领域存在一个难题：通用的“全模态大模型”（Omni-MLLMs）往往在特定领域的表现不如“模态专用大模型”（Specialist MLLMs）。Ming-omni 系列的研发初衷，正是为了填补这道鸿沟。从 Lite 版本到 Flash Preview，我们验证了模型规模对性能的提升作用；而从 Preview 到如今的 2.0 版本，我们通过海量数据的精细化打磨，进一步触达了性能的天花板。Ming-flash-omni-2.0 的诞生证明了：一个统一架构的全模态模型，完全可以既是博学的通才，又是特定模态的专家。

02 特色能力

Ming-flash-omni-2.0 兼具领先的通用泛化性能与深度的领域专长，特别是在视觉百科知识力、沉浸式语音生成及高动态图像创作领域，展现出极强的专业竞争力。

视觉百科：看懂万物，更懂你所见

Ming-flash-omni-2.0 不仅仅是看见图像，更能调动背后的专家级知识库，实现“所见即所知”。它能：

• 懂自然：精准识别花草鸟兽，从珍稀植物的品种溯源、濒危动物的特征识别，科普知识随手可得；
• 懂生活：从解析地方名菜风味到全球地标的精准匹配，满足好奇心与实用性；
• 懂专业：文物古玩精准辨识，识别年代、器型与工艺细节，成为工作中的高效助手。

当博学的“百科全书”叠加了极致的“视觉捕捉”，Ming-flash-omni-2.0 展现出了极强的时空语义理解能力:

可控语音生成：有情绪，有温度，声临其境

告别机械的电子音，Ming-flash-omni-2.0 让声音充满了表现力。它不仅能说话，还能根据你的指令调整情绪、语调甚至背景氛围。

• 让文字拥有温度与情绪：你可以通过指令控制方言、语速、情感，同时支持普通话、粤语、四川话的自然切换。
• 千人千面的声音定制：支持基于自然语言描述的音色定义（涵盖年龄、性别、情感质感等维度），想要特定的音色？只需一段自然语言描述即可生成对应风格的音色，或者从内置的 100+ 精品音色与经典角色音色中挑选，它都能精准还原、自然演绎。
• 全能的声音艺术家：Ming-flash-omni-2.0 作为业界首个将语音、音效和背景音乐生成融为一体的模型，实现了三类声学信号统一自回归 + 连续音频表征来生成，营造出声临其境的听觉体验。

图像创作：所想即所见，光影随心变

Ming-flash-omni-2.0 实现全能型图像处理能力，大幅提升生图、改图及分割的性能表现，赋予了你对画面的绝对掌控权。

• 氛围感重构：拒绝千篇一律的游客照。一句话，就能把平平无奇的照片变成“节日大片”或“故事感写真”，只需一句简单的指令——如烟花、海鸥、日出日落、花瓣雨、落叶纷飞、毛毛细雨或漫天飞雪，模型便能在完美保持人物与场景特征一致性的同时，为画面自然注入沉浸式的环境氛围。
• “任意门”般的场景合成：想去阿尔卑斯滑雪？无需P图高手，模型能精准理解你的指令，将人物无缝融入全新的背景中。
• 智能的“橡皮擦”：无论是杂乱的人群还是多余的物体，它都能精准移除，并自动补全背景细节，还原照片最纯净的美。

通过融合 Ming-flash-omni-2.0 的语音与图像生成能力，还可以实现“音画一体”的创作体验。所见有形，所感有声，让视觉的张力与听觉的温情在此刻深度交织。

03 技术深解：Ming-flash-omni-2.0 如何实现突破？

我们整理了驱动 Ming-flash-omni-2.0 性能飞跃的核心技术细节。

全模态感知的强化

• 像素级细粒度感知: 针对易混淆的图像（如珍稀动植物），我们引入了亿级高质量数据，并采用“难例挖掘”策略，通过将相似样本拼接为多图布局进行对比学习，促进模型在对比学习中学会分辨微小的特征差异。
• 音频细粒度感知增强: 引入高质音频-文本数据，对语音的年龄、性格、风格、语速、语调、职业、情绪、方言等维度进行精细标注，强化 Ming-flash-omni-2.0 对人声和音色的感知和可控生成能力。
• 结构化知识对齐: 通过引入知识图谱，将图像实体、音频描述与结构化的专家知识对齐，确保模型不仅“看到”，更能“懂得”。
• 视频时序建模: 引入 Time-Interleaved VideoRoPE 机制，就像给视频帧打上了精准的时间戳，显著增强了模型对动态事件的捕捉能力。

泛音频统一生成框架

Ming-flash-omni-2.0 作为业界首个全场景音频统一生成模型，可在同一条音轨中同时生成语音（Speech）、环境音效（Audio）与音乐（Music）。针对语音、音效与音乐在频带分布及序列长度上的显著差异的难题，我们提出了异构音频信号联合建模方案：

• 低帧率/高保真连续表征：自研 12.5Hz 超低帧率连续语音 Tokenizer，实现了对高频 Audio/Music 信号的高保真重构。该机制不仅降低了特征冗余，更在统一的潜在空间内实现了异构音频信号的标准化表征。
• Patch-based 压缩与曝光偏差缓解：引入Patch-by-Patch 四帧压缩策略，将生成序列长度进一步缩减。这一设计有效缩短了自回归建模的路径，显著缓解了超长音频生成任务中常见的曝光偏差累积问题，通过非对称的 DiT head condition 和 patch size 解决多种类型音频统一建模。
• 极低频推理优化：在推理阶段，模型实现了 3.1Hz 的业界极低推理帧率。这不仅极大降低了计算开销，而且使模型在保持高音质输出的同时，具备了实时的生成速度与极致的计算效率。

视觉生成、编辑和分割的深度融合

Ming-flash-omni-2.0 首创将生成、编辑、分割融入单一原生模型，实现架构级深度统一的同时，模型在生成、编辑及分割的典型指标上均达领先水平，并兼顾了生成图像的视觉真实感。

• 原生单流与动态感知：采用单流设计，在统一 Token 空间内利用全量注意力机制打通三大任务，并引入基于动作标签的平衡采样策略，针对高动态场景（如旅拍）实现任务间深度对齐。这一融合有效消除了复杂动作生成的僵硬感，确保了人物体态的自然与画面的动态张力。

• 扩散模型强化学习鲁棒性优化： 针对强化学习易出现的“奖励欺骗”问题，构建三重稳健机制。

  1）冷启动：利用确定性的“编辑式分割”任务建立模型的基础空间认知与定位能力；

  2）统一奖励空间建模：集成多维度评价指标，防止模型因过度优化单一奖励而陷入过拟合或退化解；

  3）离线分布正则化：通过引入约束项，确保生成内容始终锚定在真实图像分布内，大幅提升结果的视觉保真度。

04 后续规划

Ming-flash-omni-2.0 代表了我们在全模态模型探索上的阶段性进展，在多项核心指标上取得了突破。但与大模型普遍存在的幻觉挑战类似，当前版本在知识准确性、特定 IP 内容的识别与生成，以及英文音色克隆的逼真度方面仍有提升空间。此外，指令遵循能力也需进一步优化，以更好地支持复杂任务的精准执行。未来我们将持续优化 Ming-Omni 系列，向全模态智能的深水区挺进，在多任务融合中实现新的智能涌现。

05 开源相关信息

Ming-flash-omni-2.0 模型权重和推理代码已开源：

🤗Hugging Face：

https://huggingface.co/inclusionAI/Ming-flash-omni-2.0

🤖ModelScope：
https://www.modelscope.cn/models/inclusionAI/Ming-flash-omni-2.0

📦GitHub：
https://github.com/inclusionAI/Ming

欢迎大家试用反馈，共同推进开源全模态模型的发展。

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

有些人刷短视频解压，有些人刷八卦上头，而有的人（懂的都懂）会定期翻 OpenJDK 的 commit log——属于那种“看别人修 bug 也能获得快乐”的硬核爱好。最近就有这么一个提交，能让人滑着滑着突然停住：一个几十行的小修，直接把 30x–400x 的性能差距抹平了。

提交信息长这样（链接转纯文本）：
https://github.com/openjdk/jdk/commit/858d2e434dd

关键点一句话：Linux 下 ThreadMXBean.getCurrentThreadUserTime() 以前走 /proc 读文件+解析，现在改成 clock_gettime() 一把梭。
听着朴实无华，但效果非常“离谱地好”。

这锅到底有多大

同门两兄弟，一个像跑车，一个像拖拉机

先认识两位主角：

• ThreadMXBean.getCurrentThreadCpuTime()：拿“当前线程总 CPU 时间”（user + system）
• ThreadMXBean.getCurrentThreadUserTime()：只拿“当前线程 user 时间”

你可能会以为：两者应该差不多吧？都是“线程 CPU 时间”嘛。
结果历史实现告诉你：想多了。

原始 bug 报告直接给出差距：
https://bugs.openjdk.org/browse/JDK-8210452

里面量化得很狠：

getCurrentThreadUserTime 比 getCurrentThreadCpuTime 慢 30x–400x

并发一上来，差距还会被放大，属于“越忙越慢，越慢越崩”。

旧实现

为了拿个 user time，JVM 竟然去读 /proc

旧版 Linux 实现藏在 os_linux.cpp 里，本质流程是：

1. 拼路径 /proc/self/task/<tid>/stat
2. open() 打开文件
3. read() 读进 buffer
4. 处理一个“恶意格式”：线程名里可能有括号，所以要找最后一个 )
5. sscanf() 抽第 13/14 个字段（user/sys tick）
6. tick 换算成纳秒

那段被删掉的代码大概长这样

static jlong user_thread_cpu_time(Thread *thread) {
  pid_t  tid = thread->osthread()->thread_id();
  char *s;
  char stat[2048];
  size_t statlen;
  char proc_name[64];
  int count;
  long sys_time, user_time;
  char cdummy;
  int idummy;
  long ldummy;
  FILE *fp;


  os::snprintf_checked(proc_name, 64, "/proc/self/task/%d/stat", tid);
  fp = os::fopen(proc_name, "r");
  if (fp == nullptr) return -1;
  statlen = fread(stat, 1, 2047, fp);
  stat[statlen] = '0';
  fclose(fp);


  // Skip pid and the command string. Note that we could be dealing with
  // weird command names, e.g. user could decide to rename java launcher
  // to "java 1.4.2 :)", then the stat file would look like
  //                1234 (java 1.4.2 :)) R ... ...
  // We don't really need to know the command string, just find the last
  // occurrence of ")" and then start parsing from there. See bug 4726580.
  s = strrchr(stat, ')');
  if (s == nullptr) return -1;


  // Skip blank chars
  do { s++; } while (s && isspace((unsigned char) *s));


  count = sscanf(s,"%c %d %d %d %d %d %lu %lu %lu %lu %lu %lu %lu",
                 &cdummy, &idummy, &idummy, &idummy, &idummy, &idummy,
                 &ldummy, &ldummy, &ldummy, &ldummy, &ldummy,
                 &user_time, &sys_time);
  if (count != 13) return -1;


  return (jlong)user_time * (1000000000 / os::Posix::clock_tics_per_second());
}

看到这里你大概已经开始皱眉：为了拿一个时间，居然要走文件系统、内核拼字符串、用户态 sscanf 解析……
这不是性能敏感路径里最忌讳的“豪华套餐”吗？

对比：CPU time 那位“亲兄弟”一直就很优雅

同样是拿时间，getCurrentThreadCpuTime() 从古至今都干净得像刚洗完的盘子：

jlong os::current_thread_cpu_time() {
  return os::Linux::thread_cpu_time(CLOCK_THREAD_CPUTIME_ID);
}


jlong os::Linux::thread_cpu_time(clockid_t clockid) {
  struct timespec tp;
  clock_gettime(clockid, &tp);
  return (jlong)(tp.tv_sec * NANOSECS_PER_SEC + tp.tv_nsec);
}

一句 clock_gettime()，没有文件 IO、没有解析、没有一堆 syscalls 组合拳。

为什么差这么多：一次 syscall vs 一串 syscall + VFS + 字符串 + 解析

旧 /proc 路径大概干了这些活：

• open() syscall
• VFS 分发 + dentry 查找
• procfs 动态生成内容
• 内核把数字格式化成字符串
• read() syscall，把内容拷回用户态
• 用户态 sscanf() 解析
• close() syscall（还可能牵扯锁、futex 等）

而 clock_gettime(CLOCK_THREAD_CPUTIME_ID) 路径基本是：

• 单次 syscall → 直接走内核里一条更短的函数链，读调度实体里的时间信息

所以差距不在“要不要进内核”（两者都要），而在进内核之后做了多少额外工作。

那问题来了：当年为啥不用 clock_gettime 拿 user time？

答案很“标准化”：POSIX 规定 CLOCK_THREAD_CPUTIME_ID 返回的是总 CPU 时间（user + system）。
“只要 user 时间”这件事，在 POSIX 意义上并没有一个通用开关。

但 Linux 有自己的“私房菜”：clockid_t 的位编码。这个编码在 Linux 内核里稳定很多年，但你在 man page 里不一定能看到它的完整说明——要想懂，得看内核源码那种“祖传注释”。

新实现

用 pthread_getcpuclockid 拿到 clockid，再把类型位翻成 VIRT（user-only）

Linux 从 2.6.12（2005 年）开始，就在 clockid_t 里编码了“时钟类型/线程或进程”等信息。pthread_getcpuclockid() 会给你一个 POSIX 合规的 clockid（通常是 SCHED：user+system）。
接着只要把低位类型从 10 翻成 01（VIRT：user-only），再交给 clock_gettime()，就能得到 user time。

新代码核心如下：

static bool get_thread_clockid(Thread* thread, clockid_t* clockid, bool total) {
  constexpr clockid_t CLOCK_TYPE_MASK = 3;
  constexpr clockid_t CPUCLOCK_VIRT = 1;


  int rc = pthread_getcpuclockid(thread->osthread()->pthread_id(), clockid);
  if (rc != 0) {
    // Thread may have terminated
    assert_status(rc == ESRCH, rc, "pthread_getcpuclockid failed");
    return false;
  }


  if (!total) {
    // Flip to CPUCLOCK_VIRT for user-time-only
    *clockid = (*clockid & ~CLOCK_TYPE_MASK) | CPUCLOCK_VIRT;
  }


  return true;
}

static jlong user_thread_cpu_time(Thread *thread) {
  clockid_t clockid;
  bool success = get_thread_clockid(thread, &clockid, false);
  return success ? os::Linux::thread_cpu_time(clockid) : -1;
}

对比旧实现：

• 没有 /proc
• 没有 fread buffer
• 没有 sscanf
• syscalls 数量也从“一串”变成“基本一个”

简直是“删代码删出性能”。

真实性能：从 11 微秒降到 279 纳秒，直接 40 倍起飞

为了量化差距，修复里还顺手带了 JMH benchmark（这点很加分：没有基准的优化，容易变成自我感动）。

原 benchmark 示例：

@State(Scope.Benchmark)
@Warmup(iterations = 2, time = 5)
@Measurement(iterations = 5, time = 5)
@BenchmarkMode(Mode.SampleTime)
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@Threads(16)
@Fork(value = 1)
public class ThreadMXBeanBench {
    static final ThreadMXBean mxThreadBean = ManagementFactory.getThreadMXBean();
    static long user; // To avoid dead-code elimination

    @Benchmark
    public void getCurrentThreadUserTime() throws Throwable {
        user = mxThreadBean.getCurrentThreadUserTime();
    }


    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(ThreadMXBeanBench.class.getSimpleName())
                .build();
        new Runner(opt).run();
    }
}

旧版本（/proc 路径）结果大意是：平均 ~11 微秒。
修复后结果：平均 ~0.279 微秒（也就是 279 纳秒）。
算下来差不多 40x 改善（在 30x–400x 区间内，符合历史报告范围）。

配套 profile 也很直观：旧版像“syscall 自助餐”，新版像“只吃一道菜”。

彩蛋：还能再榨出 13%？内核 fast-path：PID=0 时跳过 radix tree 查找

性能到了纳秒级还继续抠？这就很“工程师”。
在修复后的 profile 里还能看到一个小热点：内核里会做一次 radix tree lookup 去定位目标线程的 pid 结构。原因是：pthread_getcpuclockid() 返回的 clockid 编码了具体 TID，内核拿到后要去查。

但内核有个更快的分支：如果 clockid 里编码的 PID/TID 是 0，内核把它解释成“当前线程”，直接走 current task，跳过查找。

/*
 * Functions for validating access to tasks.
 */
static struct pid *pid_for_clock(const clockid_t clock, bool gettime)
{
[...]


  /*
  * If the encoded PID is 0, then the timer is targeted at current
  * or the process to which current belongs.
  */
  if (upid == 0)
      // the fast path: current task lookup, cheap
      return thread ? task_pid(current) : task_tgid(current);


  // the generalized path: radix tree lookup, more expensive
  pid = find_vpid(upid);
  [...]

于是有人提出一个“更野但更快”的想法：既然 OpenJDK 已经在改 clockid 的低位类型了，那干脆自己构造一个 PID=0 的 clockid 走 fast-path。

clockid 编码示意：

clockid (原理示意)：


// Linux Kernel internal bit encoding for dynamic CPU clocks:
// [31:3] : Bitwise NOT of the PID or TID (~0 for current thread)
// [2]    : 1 = Per-thread clock, 0 = Per-process clock
// [1:0]  : Clock type (0 = PROF, 1 = VIRT/User-only, 2 = SCHED)
static_assert(sizeof(clockid_t) == 4, "Linux clockid_t must be 32-bit");
constexpr clockid_t CLOCK_CURRENT_THREAD_USERTIME = static_cast<clockid_t>(~0u << 3 | 4 | 1);

然后把 getCurrentThreadUserTime() 直接改为用这个 CLOCK_CURRENT_THREAD_USERTIME 调 clock_gettime()。

结果呢？benchmark 从 81.7ns 降到 70.8ns，约 13% 提升。
绝对值不大，但属于“白给的快”。

当然，这也带来一个工程上的灵魂拷问：为了这点收益，值不值得在 JVM 里依赖更多 Linux 内核 ABI 细节？
这类优化就很像把车轮胎气压从 2.3 调到 2.35：能快，但你得接受“更挑环境”的风险感。

三条硬核经验：写性能代码时，别只信标准，别只信直觉

这次修复能这么漂亮，背后有三条特别“值钱”的经验：

1）别只读 POSIX，要敢读内核源码
标准告诉你“可移植的下限”，内核源码告诉你“可用的上限”。两者之间有时差着 400 倍。

2）别迷信老实现里的假设
当年的 /proc 解析可能是合理折中，但假设会“固化”成代码，一固化就是十几年。隔段时间回头看，往往能捡到大便宜。

3）优化要带基准，要留证据
这次提交很关键的一点：带了 JMH benchmark。否则这种改动很容易被质疑为“玄学改法”。

结尾：JDK 26 可能给你“免费加速包”

这个改动在 2025-12-03 落地，距离 JDK 26 冻结只差一天。文章里也给了时间点：JDK 26 预计 2026 年 3 月发布。
如果你的系统里确实用到了 ThreadMXBean.getCurrentThreadUserTime()（比如 profiling、监控、诊断工具链），那这波升级基本等于：白捡一个数量级的延迟下降。

喜欢就奖励一个“👍”和“在看”呗~

开发者朋友们大家好：

这里是 「RTE 开发者日报」，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的技术」、「有亮点的产品」、「有思考的文章」、「有态度的观点」、「有看点的活动」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。

本期编辑：@瓒an、@鲍勃

01 有话题的技术

1、谷歌发布 Gemini 3 Deep Think，编程水平排名世界第八

今天凌晨，谷歌发布了 Gemini 3 Deep Think 的重大升级。作为专用于复杂任务的推理模式，该版本试图解决科学与工程领域的诸多挑战。据悉，去年 9 月加入 Google DeepMind 的清华物理系校友姚顺宇也参与了此次研发。

在编程领域，Gemini 3 Deep Think 在 Codeforces 平台上取得了 3455 的 Elo 分数，位列世界第八。这意味着全球仅有 7 名人类选手能在此类比赛中击败它，而此前最佳模型 OpenAI o3（约一年前数据）的排名仅为第 175 位。

该模型在多项学术基准测试中刷新了纪录：

• 通用与抽象推理：在「人类的最后考试」基准测试中，不使用工具取得了 48.4% 的 SOTA 成绩；在 ARC-AGI-2 中达到 84.6%。值得注意的是，其在 ARC-AGI-1 上的每任务成本仅为 7.17 美元，相比 OpenAI o3-preview 「高计算」版本降低了数百倍。
• 科学竞赛：在 2025 年国际数学、物理和化学奥林匹克竞赛笔试中均获金牌水平，并在高等理论物理 CMT-Benchmark 测试中得分 50.5%。

谷歌同时展示了 Deep Think 在科研中的实际应用。罗格斯大学数学家 Lisa Carbone 利用其识别出一篇专业论文中人工评审未发现的逻辑缺陷；杜克大学 Haozhe Wang 的实验室则利用其优化半导体工艺，实现了厚度大于 100 微米薄膜的精确生长目标。此外，该模型还能将草图转化为可 3D 打印的实体模型。

目前，全新 Deep Think 已面向 Google AI Ultra 订阅用户及部分 API 合作伙伴开放。

（@机器之心）

2、小红书开源工业级语音系统 FireRedASR2S：集成四大核心组件

2026 年 2 月 12 日，小红书正式发布并开源了工业级一体化语音识别系统 FireRedASR2S。该项目基于 Apache-2.0 许可协议，相关的模型权重与推理代码目前已在 Hugging Face 和 ModelScope 等平台开放下载。

FireRedASR2S 将单点语音能力扩展为了完整的处理生态，系统内部集成了ASR（自动语音识别）、VAD（语音活动检测）、LID（语种识别）和 Punc（标点预测）四个核心组件。这些模块在架构设计上保持自包含与独立性，开发者既可以将其整合为端到端的工作流，也能脱离主系统单独调用任意单个模块。

根据官方公布的基准测试数据，各核心组件的具体能力表现如下：

• FireRedASR2：支持普通话、20 多种方言与口音、中英文语码转换以及歌词识别。该模块提供 LLM（结合大语言模型以优化无缝交互）与 AED（平衡性能与效率，支持词级时间戳）两个版本。评测显示，其普通话平均字符错误率（CER）低至 2.89%，方言平均 CER 为 11.55%，整体表现优于 Doubao-ASR、Qwen3-ASR-1.7B 与 Fun-ASR 等竞品。
• FireRedVAD：支持超百种语言的非流式与流式语音活动检测，涵盖语音、歌声及音乐，并具备音频事件检测能力。其 F1 分数高达 97.57%，领先其他开源基准。
• FireRedLID：覆盖 100 多种语言及 20 多种中文方言，语种检测准确率达到 97.18%，客观数据超越了 Whisper 与 SpeechBrain-LID。
• FireRedPunc：提供多领域的中英文标点预测服务，平均 F1 分数达到 78.90%，显著优于 FunASR-Punc。

在实际应用与部署环节，系统要求输入 16kHz 16 位单声道 PCM 格式音频。对于输入长度，AED 版本最高支持 60 秒的音频，而 LLM 版本目前支持最长 30 秒的输入。后续，开发团队还将陆续公开技术报告与微调代码。

GitHub:
https://github.com/FireRedTeam/FireRedASR2S

HuggingFace:
https://huggingface.co/FireRedTeam/FireRedASR2-AED

( @GitHub)

3、涉嫌侵犯开源项目 FFmpeg 的版权，瑞芯微被 GitHub 冻结代码库

2026 年 2 月，国内芯片设计企业瑞芯微（Rockchip）因涉嫌侵犯开源项目 FFmpeg 的版权，其相关代码库被 GitHub 平台冻结。这一事件再次引发行业对开源软件合规使用的关注。

经查，瑞芯微在产品开发过程中使用了 FFmpeg 的核心组件 libavcodec 代码，但在使用过程中存在多项违规操作：

• 删除版权信息：删除了代码原作者信息及版权声明；
• 篡改许可证：擅自将原代码的 LGPL 许可证更改为 Apache 协议。

尽管 LGPL 协议允许商业场景使用，但明确要求使用者必须保留原始版权声明、按需提供源代码，并保持许可证的一致性。瑞芯微的操作直接违反了这些条款。事实上，该违规行为早在 2024 年初就已被发现。当时，瑞芯微工程师 HermanChen 曾公开道歉，称对许可证冲突缺乏了解，并承诺整改。然而，在随后的近两年时间里，瑞芯微并未采取实质性整改措施。最终，FFmpeg 项目方依据《数字千年版权法案》（DMCA）向 GitHub 发起正式投诉，导致瑞芯微相关项目库被冻结。

数据显示，目前 97% 的代码库包含开源组件，其中 63% 存在许可证冲突。业内专家指出，许多企业开发者对 GPL、MIT、Apache、LGPL 等主流许可证的区别认知不足，错误地认为开源代码可随意修改分发，从而埋下法律风险。

不同许可证规则差异显著。以此次涉事的 LGPL 为例，它允许闭源软件动态链接使用，仅要求修改库本身代码时开源修改部分；而 Apache 协议虽支持商业闭源，但更侧重专利保护，且与 GPL 系列协议存在兼容性冲突，二者不可随意替换。此次事件表明，开源合规管理已成为企业发展的必修课，企业需建立完善的审查机制，明确协议边界，规避版权风险。

（@人人极客社区）

4、蚂蚁百灵开源发布万亿参数思考模型 Ring-2.5-1T ，主打深度思考与长程智能体执行

今天中午，蚂蚁百灵正式发布并开源了首个混合线性架构的万亿参数思考模型 Ring-2.5-1T。作为迈向通用智能体时代的关键一步，该模型在预训练和强化学习层面均进行了大规模扩展。

相比前代产品 Ring-1T，Ring-2.5-1T 在三个核心维度实现了大幅提升：

• 高效生成：基于高效的 1:7 MLA + Lightning Linear Attention 架构，在超过 32K 的生成长度下，访存规模降低 10 倍以上，生成吞吐提升 3 倍以上。
• 深度思考：在 RLVR 基础上引入 dense reward 反馈机制。自测结果显示，其在 IMO 2025（获 35 分）和 CMO 2025（获 105 分）中均达到金牌水平。
• 长程执行：通过大规模全异步智能体强化学习（fully-async agentic RL）训练，显著增强了复杂任务的长程自主执行能力，可适配 Claude Code 及 OpenClaw 等框架。

在架构层面，Ling 2.5 采用增量训练方式，将 Ling 2.0 的 GQA 升级为混合线性注意力结构。改造后，尽管激活参数量从 51B 增至 63B，但推理效率仍大幅提升。测试显示，无论在单机 8 卡 H20-3e 还是 H200 环境下，其长程推理的吞吐优势均十分显著。

为验证其长程执行能力，开发团队将 Ring-2.5-1T 接入 Claude Code，仅用两小时便自动完成了一个微型版操作系统（TinyOS）的开发，并能进一步实现 bash 功能。此外，该模型在数学、代码、逻辑等高难推理任务以及智能体搜索（如 GAIA2-search）等长程任务执行上，均达到了开源领域的领先水平。

目前，Ring-2.5-1T 仍存在 token efficiency 和指令遵循方面的局限性。其模型权重已在 Hugging Face 和 ModelScope 开源，相关体验页及 API 服务也将在 Ling Studio 与 ZenMux 陆续上线。

HuggingFace:

https://huggingface.co/inclusionAI/Ring-2.5-1T

（@百灵大模型）

02 有亮点的产品

1、自然语言几分钟构建 AI 智能体：VM0 正式开启公开测试

2026 年 2 月 6 日，VM0 宣布正式开启公开测试。在经历了约两个月的内部构建与私密测试后，该平台现已向更多开发者开放。

VM0 是一款基于自然语言构建 AI 智能体的工具，并配备了支持智能体全天候（24/7）运行的沙盒环境。 用户只需用自然语言描述具体需求，VM0 便会自动处理运行时、执行操作及环境配置。即使用户关闭了电脑，其部署的智能体应用也会保持持续运行状态。

在构建体验上，该平台试图同时满足不同类型用户的需求：

• 面向 Vibe Coder 和快速实验：对于刚接触 AI 智能体或希望快速测试想法的用户，平台提供了几分钟即可上手的体验。无需繁重的环境设置或提前阅读长篇文档，仅需执行一条简单的初始命令（npm install -g @vm0/cli && vm0 onboard），即可运行首个智能体。
• 面向专业开发者：如果需要获取更多控制权，VM0 提供了一套完整的开发工具包。开发者可以将 VM0 接入现有的基础设施中，并在实际需要时进行规模化扩展。

由于目前产品仍处于测试阶段，官方正积极向早期用户征集错误报告、细节打磨建议以及功能反馈，这些反馈将直接塑造产品的下一步走向。此外，VM0 正在建设一个由社区驱动的 Cookbook，鼓励开发者分享其实际构建的案例，例如客户支持智能体、数据分析工作流或内部工具等。

根据公布的路线图，VM0 下一步的发展计划包括：推出自托管运行程序、简化的智能体分享功能、支持更多模型提供商、VM0 平台智能体构建器、VM0 Slack 集成以及 VM0 连接器。

相关链接：
https://docs.vm0.ai/docs

( @VM0 Blog)

2、AI 数字孪生初创公司 Simile 获 1 亿美元融资，用 AI 模拟真实用户反馈

AI 数字孪生初创公司 Simile 宣布完成 1 亿美元融资。本轮融资由 Index Ventures 领投，Bain Capital Ventures 等机构投资者跟投，AI 先驱李飞飞与 OpenAI 联合创始人 Andrej Karpathy 也参与了投资。

企业在推出新产品前，通常需要收集潜在客户的反馈，但这类调研往往耗时费力，且难以触及特定目标受众（如世界 500 强高管）。为此，Simile 构建了一个 AI 模型，利用个人数据来模拟人们对新产品、功能变更等商业动态的反应。目前，其首批客户包括 CVS Health Corp。 和澳大利亚最大的移动互联网提供商 Telstra Group。

该 AI 模型主要帮助企业简化以下测试流程：

• 用户界面更新评估：开发者可在向真实客户全面推出更新前，观察模拟用户对界面变更的反应。
• 财报电话会议准备：据首席执行官 Joon Sung Park 透露，在一次模拟电话会议中，该模型准确预测了分析师 10 个问题中的 8 个，能够帮助上市公司高管提前做好准备。

Simile 由 Joon Sung Park、Michael Bernstein 和 Percy Liang 共同创立。这三位计算机科学家此前曾开发过模拟环境 Smallville，证明了 AI 智能体不仅能模拟个体行为，还能模拟群体行为。据报道，Simile 耗时七个月开发该模型，其训练数据来源于对数百人的采访记录、交易日志以及科学期刊文本。

Index Ventures 合伙人 Shardul Shah 表示，Simile 建立了高保真模型来解答真实人类会做什么以及为什么这样做，这在各类组织中有着广泛的应用需求。除了模拟买家行为，AI 生成模拟正被广泛应用于更多领域，例如 Simile 的投资人李飞飞曾于 2024 年创办 World Labs，用于生成三维虚拟环境以训练工业机器人。

( @SiliconAngle)

03 有态度的观点

1、DeepMind CEO：AI 在未来十五年会解决人类棘手难题

近日，Google DeepMind CEO 德米斯 · 哈萨比斯接受《财富》杂志的采访时，其提到：人类正站在「科学发现新黄金时代」的边缘，尽管未来 10 到 15 年将经历剧烈的行业洗牌与阵痛，但最终将迎来一场足以媲美「文艺复兴」的技术变革。

哈萨比斯在访谈中提出了「激进富足」的概念。他预言 AI 将通过对科学方法的深度内化，解决人类最棘手的难题：

• 医疗革命： 未来 15 年内，AI 将使个性化医疗成为常态，攻克重大疾病。
• 能源突破： AI 将加速核聚变与太阳能新材料的研发，彻底解决能源危机。
• 宇宙探索： 算力的突破将最终支持人类「在星际间穿梭，探索银河系」。

采访中，哈萨比斯也提到了 Google 在当今 AI 圈的一些风险以及挑战。

面对 OpenAI 等竞争对手的崛起，哈萨比斯坦言谷歌必须面临「创新者困境」。他强调：「如果我们不进行自我颠覆，别人就会动手。你最好按自己的节奏来。」

据悉，随着 Gemini 系列模型及 Nano Banana 图像生成模型的发布，Alphabet（Google 母公司）股价在去年飙升约 65%，哈萨比斯认为公司已跨越了 AI 助手辅助高阶研究的「分水岭」。

( @APPSO)

阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么

写在最后：

我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。

对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。

作者提示: 个人观点，仅供参考