标签 模型训练 下的文章

手把手教你进行论文复现,小白也能学会,赶紧收藏

复现,是你迈入“真科研”的第一步。
你是不是常常看见学术圈或技术论坛中大家提到“论文复现”这个词,却不太明白它的含义?
别急!这篇超详细的实操指南,从“是什么” 到 “怎么做”,再到 “避坑技巧”,手把手带小白走完第一次论文复现,赶紧收藏起来慢慢看~

什么是“复现”?

复现≠复制粘贴!它是用原作者公开的技术细节、实验步骤、代码仓库和数据集,自己动手重新实现,验证论文结果是否可重复的过程。
简单说,就是跟着论文的“说明书”,亲自跑一遍实验,既能吃透论文核心逻辑,又能练编程、调参技能,还能检验研究成果的可靠性,毕竟学术研究的本质就是“可验证、可推广”。

为什么要做论文复现?

1. 深入理解核心技术

复现的最大好处是能够从理论层面走向实践。光看论文中的理论、公式和结果可能无法完全理解其背后的实现细节,而亲自动手复现,可以让你更好地理解技术原理。

2. 检验研究成果的可靠性

论文中的研究结果,未必在其他环境下也能复现,尤其是涉及到数据集和模型训练等因素时。通过复现,我们可以验证这些结果是否具有普适性。

3. 累积实战经验

复现过程是一个实战的过程,尤其是在深度学习和机器学习、大模型领域,实验中的调参、数据处理、模型选择等都会是你宝贵的经验。对科研人员来说,复现一些经典论文是最直接的学习方式。

手把手教你做第一个复现项目

复现论文并不是一件容易的事,但只要你掌握了方法,逐步进行,也能顺利完成。接下来我们以《PhotoDoodle: Learning Artistic Image Editing from Few-Shot Examples》这篇论文为例,借助大模型实验室Lab4AI平台,带你从头开始复现

Step 1 找到合适的论文和代码

复现的第一步是找到值得复现且能复现的论文和代码。大多数论文会将其代码发布在GitHub或其他平台上,因此你需要阅读论文,并且找到代码仓库的链接,链接通常附加在论文末尾或摘要部分。找到论文提供的GitHub开源代码后,你需要查看项目中是否有清晰的README文件,介绍如何配置环境、安装依赖、运行代码等。

这里分享5个筛选项目的关键技巧,总结为“三查”核心原则:查信息完整性、查代码一致性、查资源可行性,帮你快速避坑:

  • 完整信息性:优先选择开源项目,尤其是原作者主动公开代码仓库、数据集,这种项目复现难度较低。同时,选择项目时优先关注项目活跃度、检查Star数、Fork数、更新频率、issue解决率等。一般情况下数值越高,说明社区认可度高、维护更及时,遇到问题更容易找到解决方案;
  • 代码一致性:检查代码和论文的实现是否一致。如果有问题,可以参考GitHub上的Issues查看是否有人遇到类似问题。
  • 资源可行性:检查项目是否提供完整依赖清单、数据集及模型下载链接。如果作者未提供,你可能需要额外花费大量时间寻找适配资源。


在《PhotoDoodle》这篇论文中,GitHub上的代码仓库包含了与艺术图像编辑相关的实现,README有详细的项目介绍,包括了从少量样本中学习艺术风格的代码。需要重点关注以下几个部分:

  • 项目概述:了解这篇论文的核心思想,确认复现的目标。
  • 环境配置:确认环境依赖是否满足你的系统,查看Python、CUDA和其他必需库的版本。
  • 训练与推理代码:观察代码是否完整,并分析如何通过代码进行图像编辑任务,特别是如何加载预训练模型、微调模型、以及如何用少量图像进行训练。

Step 2 配置环境并安装依赖

本次我们选用大模型实验室Lab4AI来进行复现,平台提供灵活计费的H卡算力,闲时使用更优惠。您也可以使用本地资源或者实验室资源,进行本次复现

打开大模型实验室Lab4AI,登录大模型实验室Lab4AI平台。点击右侧“新建实例”,新建前建议先查看“GitHub项目的文档”的环境配置说明。

Step 3 下载代码

新建实例后,先下载论文代码,推荐4种常用方式:

  • 第一种:通过HTTPS方式。通过网页URL链接克隆,无需额外配置密钥,是最常用的方式;
  • 第二种:通过SSH方式。通过SSH密钥认证克隆,需通过SSH密钥认证克隆提前在GitHub账号绑定本地SSH密钥,更安全且无需重复输入密码;
  • 第三种:通过GitHub CLI方式。通过GitHub官方命令行工具克隆,需先安装并登录该工具,适合习惯命令行操作的用户;
  • 第四种:直接下载项目压缩包,不需要Git工具即可获取代码。

Step 4 配置环境

环境配置是复现的“重头戏”,按以下步骤操作,少踩 90% 的坑:

(1) 创建独立虚拟环境,这样能够避免依赖冲突:

conda create -n doodle python=3.11.10
# 创建环境

conda activate doodle
# 激活环境

(2) 安装PyTorch与项目依赖

使用 cd 命令进入代码所在文件夹,再分两步安装。根据GitHub说明,通过pip安装所需的PyTorch及所有依赖。如果网络环境受限,可以选择国内的镜像源(如清华镜像)来加速下载:

pip install torch==2.5.1 torchvision==0.20.1 torchaudio==2.5.1 --index-url https://download.pytorch.org/whl/cu124
pip install --upgrade -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

Step 5 执行推理

由于这个项目的README.md文件先介绍的如何推理,再介绍了如何训练。所以,我们先执行推理,看一下推理效果。

(1) 准备工作:

① 由于CPU无法满足推理算力需求,所以需要重启Lab4AI实例并选择1卡GPU;

②在终端执行conda activate doodle激活之前创建的Conda 环境,再通过cd 路径命令进入 PhotoDoodle 代码目录。

(2) 运行推理代码:

python inference.py

(3) 常见问题解决:

运行代码时出现一些依赖冲突与缺失的问题

  • “安装的 diffusers 版本过低”
  • huggingface-hub 版本过高,与其他不兼容”
  • “缺少PEFT库”
  • “安装的PEFT库版本过高与transformers库的版本不兼容”
    等等……


遇到这些问题时,最好的方法是参考项目文档中提供的建议,查看GitHub Issues寻找解决方案,您也可以询问AI大模型寻找解决办法。

(4)自定义输出:

修改inference.py中的输入图像路径、编辑提示词等参数,重新运行可以看到获得不同的输出结果。

Step 6 执行推理下载数据集和训练模型

训练数据集与预训练模型是多数论文复现项目的基础支撑。《PhotoDoodle》项目的数据集及预训练模型的下载链接,都能在项目 GitHub 仓库的 README 文件中找到。

在下载数据和预训练模型时,出现了多次因为网络问题而无法下载数据和模型的情况。核心原因可归为四类:

  • 第一:跨境网络限制。模型或数据多存于HuggingFace、GitHub、GoogleDrive等境外站点,国内直连易被限流、阻断。
  • 第二:源站或链路问题。源站限速、链接失效、CDN节点故障,或下载高峰导致服务器拥堵都可能导致网络问题。
  • 第三:本地配置问题。代理或梯子配置错误、防火墙拦截、下载工具无断点续传(大文件易断连),或本地带宽或网络稳定性差。
  • 第四:权限或合规限制。部分数据集或模型需授权访问,或源站设地域或IP限流,未满足则被拒绝连接。

遇到网络问题时,您可以使用可靠的下载工具或者科学上网。

Step 7 执行训练

(1) 按论文提供的脚本执行

一旦完成了环境配置和数据准备,接下来的步骤就是开始训练。执行训练代码时,我们依据GitHub项目中给出的命令执行。

(2)个性化训练

您也可以做一些个性化训练,按data 文件夹的格式组织自己的数据集,修改脚本中的参数即可实现自定义训练。

复现高频问题及解决方案

总结一下此次复现环节踩的坑以及对应的解决方法。

小贴士:复现时一定要记笔记!把遇到的问题、解决方案、参数调整记录下来,下次复现能少走很多弯路~

案论文复现总结

论文复现的环境配置是一项系统性的工作。对新手而言,关键要抓住三个核心:

  • 前期筛选:用“三查”原则,查信息完整性、查代码一致性、查资源可行性。选择合适的开源项目,避开半开源、信息缺失的项目;
  • 环境配置:借助大模型实验室Lab4AI平台的预配置环境和独立虚拟环境,锁定依赖版本,按“安装 - 验证 - 调整”的步骤逐步推进,避免版本冲突;
  • 问题解决:遇到网络、依赖、配置问题时,按“定位原因 - 查找适配方案 - 验证效果”的逻辑处理,善用社区 issue、官方文档、镜像源工具和AI大模型工具。

每一次成功的环境配置,都是对你工程解决问题能力的一次极好锻炼。希望这份详细指南能帮你避开弯路,顺利开启论文复现之旅。

Lab4AI大模型实验室,能为你提供一键复现方案,有效规避论文复现中的各类坑!

平台实现算力与实践场景的无缝衔接,配备充足 H 卡算力,支持模型复现、训练、推理全流程,更具备灵活弹性、按需计费、低价高效的优势,完美解决缺高端算力、算力成本高的核心痛点。

祝你复现顺利!

GitLink开源创新服务平台与Lab4AI大模型实验室联合发起「论文头号玩家」论文复现计划。寻找百万「论文头号玩家」计划 | 首批复现体验官开放申请,最高可获500元算力金!本计划开放高性能H800 GPU算力,旨在降低复现门槛,推动学术成果的实践转化。
<div align="center">
参与活动您将获得:
</div>
<p align="center">
<img src="http://llamafactory-online-assets.oss-cn-beijing.aliyuncs.com/lmlab/docs/v1.0/blog/synchronize/jy_fuxian-15.png">
</p>

基于 YOLOv8 的多犬种(60种常见犬类)智能识别系统项目 [目标检测完整源码]

—— 面向 60 类常见犬种的目标检测与可视化应用落地


在这里插入图片描述

一、背景与问题:为什么“犬种识别”值得工程化?

在宠物经济高速发展的今天,犬类已经从“家庭陪伴动物”逐步演变为需要精细化管理与智能化服务的对象。在实际场景中,犬种信息直接影响:

  • 饲养与行为管理策略
  • 疫苗接种与健康风险评估
  • 宠物交易、领养与救助流程
  • 城市宠物管理与公共安全

然而,现实中对犬种的识别依然高度依赖人工经验,不仅主观性强,而且在混血犬、幼犬、复杂光照条件下误判率较高。

问题的本质在于:

如何构建一个既具备高识别精度,又真正“可落地使用”的犬种识别系统?

本项目正是围绕这一问题,给出了一套完整可复现的工程级解决方案
在这里插入图片描述

源码下载与效果演示

哔哩哔哩视频下方观看:
https://www.bilibili.com/video/BV1wB8MzsE9P/

在这里插入图片描述

包含:

📦完整项目源码

📦 预训练模型权重

🗂️ 数据集地址(含标注脚本


二、系统整体架构设计

该项目并非单一模型 Demo,而是一个从数据、训练到部署的完整闭环系统,整体架构如下:

┌────────────┐
│  数据集层  │  犬类图像 + YOLO 标注
└─────┬──────┘
      ↓
┌────────────┐
│  模型训练  │  YOLOv8 Detection
└─────┬──────┘
      ↓
┌────────────┐
│  推理服务  │  图片 / 视频 / 摄像头
└─────┬──────┘
      ↓
┌────────────┐
│  GUI 应用  │  PyQt5 桌面端
└────────────┘

核心目标只有一个:
让“深度学习模型”真正变成“普通用户能用的软件”。
在这里插入图片描述
在这里插入图片描述


三、模型选型:为什么是 YOLOv8?

在多类别实时检测任务中,YOLO 系列一直是工程实践的主流方案。本项目最终选择 YOLOv8,主要基于以下考虑:

3.1 架构层面的优势

  • Anchor-Free 设计
    减少超参数依赖,收敛更稳定
  • Task-Aligned Assigner
    分类与定位目标一致性更强
  • 更轻量的 Backbone 与 Neck
    在保证精度的同时提升推理速度

3.2 工程友好性

  • 原生支持 PyTorch / ONNX
  • Ultralytics 提供统一 CLI 与 Python API
  • 训练、验证、推理接口高度一致

这使得模型不仅“好训”,而且非常适合与 GUI、业务系统结合


四、犬种数据集构建与标注规范

4.1 数据规模与类别

本系统覆盖 60 种常见犬类,包括但不限于:

  • 柯基、哈士奇、柴犬
  • 金毛、拉布拉多、贵宾犬
  • 德牧、边牧、博美等

每个类别均包含多姿态、多背景、多尺度样本,尽量贴近真实使用场景。


4.2 数据组织结构(YOLO 标准)

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

标签文件采用 YOLO 标准格式:

<class_id> <x_center> <y_center> <width> <height>

所有坐标均为 相对比例值,确保模型在不同分辨率下具备一致性。


在这里插入图片描述

五、模型训练流程详解

5.1 训练配置示例

yolo detect train \
  data=dog.yaml \
  model=yolov8n.pt \
  epochs=100 \
  batch=16 \
  imgsz=640

关键训练策略包括:

  • 合理的 batch size 控制显存占用
  • 数据增强(翻转、尺度变换、颜色扰动)
  • 早期收敛阶段重点关注 box_loss 与 cls_loss

在这里插入图片描述

5.2 训练过程监控

YOLOv8 在 runs/detect/train/ 目录中自动生成:

  • 损失函数变化曲线
  • mAP@0.5 / mAP@0.5:0.95
  • 混淆矩阵(类别间区分能力)

在实际实验中,多数犬种在 mAP@0.5 指标上稳定超过 90%,具备实际应用价值。


六、多模态推理能力设计

本系统支持多种输入形式,统一由同一推理接口处理。

6.1 单张图片与批量图片

  • 支持文件与文件夹级别输入
  • 自动生成标注结果图
  • 适合数据复查与分析场景

6.2 视频与实时摄像头

  • 基于 OpenCV 逐帧推理
  • 支持实时显示检测结果
  • 可选保存输出视频文件

这一能力使系统能够直接应用于:

  • 宠物门店实时监控
  • 救助站视频巡检
  • 展示型 AI 应用演示

在这里插入图片描述

七、PyQt5 图形界面设计要点

为了降低使用门槛,项目引入 PyQt5 构建完整桌面应用。

7.1 界面功能划分

  • 输入控制区:选择图片 / 视频 / 摄像头
  • 结果展示区:实时显示检测画面
  • 日志与状态区:输出模型运行信息

7.2 工程价值

  • 无需命令行操作
  • 非算法人员也可直接使用
  • 适合作为课程设计、毕业设计、项目演示系统

八、推理代码核心示例

from ultralytics import YOLO

model = YOLO("best.pt")
results = model("test.jpg", conf=0.25, save=True)

for box in results[0].boxes:
    cls_id = int(box.cls)
    score = float(box.conf)

推理结果中可直接获取:

  • 类别 ID
  • 置信度
  • 边框坐标

便于后续对接业务逻辑或二次开发。


在这里插入图片描述

九、项目工程化与“开箱即用”

本项目已完成完整工程封装,具备以下特点:

  • 已训练完成的权重文件
  • 完整源码与数据集
  • 一键启动 GUI 程序
  • 提供训练与部署说明

运行检测仅需:

python main.py

无需重新训练,即可体验完整系统功能。


十、可扩展性与二次开发方向

该项目并不局限于犬种识别,其工程框架可直接扩展为:

  • 🐱 猫咪品种识别
  • 🐦 鸟类 / 野生动物监测
  • 🐄 畜牧养殖视觉分析
  • 🏙️ 智慧城市动物管理系统

本质上,这是一个可复用的 YOLOv8 + GUI 工程模板。


总结:一个真正“能用”的目标检测项目应该是什么样?

相比单纯展示模型精度,本项目更关注:

  • 是否具备完整工程链路
  • 是否方便非算法人员使用
  • 是否具备二次开发潜力

通过 YOLOv8 与 PyQt5 的深度结合,该系统成功实现了从算法到应用的跨越。

🚀 如果你正在寻找一个具备训练、检测、部署一体化能力的目标检测项目实践,这套基于 YOLOv8 的多犬种识别系统,值得你深入研究与复用。

撰稿:李文朋

编辑:王一鹏

这两年 AI 发展很快,很多企业遇到的瓶颈也在变化:不再是“算力不够”,而是“数据跟不上”。

2026 年 1 月,IDC 在《边缘进化:从核心到边缘驱动成功》报告中提到:已经部署生成式 AI 的企业里,超过 60%的“实时交互类应用的响应延迟比预期高”。

很多时候,这种延迟不一定是模型慢,也不一定是算力不够,而是数据散在企业内部各处,口径不统一,质量也不稳定,关键时刻更是“找不到、拿不出、对不上、流不动”。

金融行业感受特别明显。一位城商行做数字化建设的负责人公开表示:“我们目前不缺算力,也不缺模型。缺的是能让模型真正跑起来的数据。”

模型训练成本在下降,但把数据整理好、清洗好、能实时用起来的成本反而越来越高。

2026 年初,这个问题已经不只是“体验不好”,甚至会影响商业项目的成败。IDC 在 FutureScape 里提醒称:今年,50%的 AI 驱动应用将会因为数据基础薄弱,达不到原定 ROI 目标。

事实上,数据的重要性远不止如此,更长远一点看,甚至会关系到 AI 到底能走多远。

2025 年云栖大会上,阿里巴巴集团 CEO 吴泳铭谈过一个判断:AGI 大概率会出现,但只是开始。真正的下一步,是走向能自我迭代、持续变强的 ASI。他把过程分成三段:先学会推理,再学会使用工具辅助人类,然后连接现实世界的数据,能自己学习、自己迭代。

说得更直白一点:未来 AI 更像一个“持续在线的系统”,它得不断吃到最新的数据,并把这些数据变成新的能力。数据是否能高效、持续地进入系统,变得愈加重要。

正因如此,很多基础设施厂商开始关注“更适合 AI 使用的数据”方向。数据库不再是“存数据”,而是要让数据更容易被统一管理、被实时取用、被不同类型的模型和应用调用。

2026 年 1 月 20 日,阿里云在 2026 PolarDB 开发者大会上发布了 AI 就绪(AI-Ready)云原生数据库新标准。

它想解决的事情其实很简单:让数据系统不仅能存储、查询多模态数据,还将直接驱动 AI 智能决策,让数据进入模型与业务的路径更短、更稳定,以及更安全。

阿里云资深副总裁、数据库产品事业部负责人李飞飞表示:“未来,AI 原生数据库是技术演进的必然方向。从云原生到 Al 就绪,再到 Al 原生,PolarDB 将持续深化 AI 与数据库的融合创新,加快走向超级人工智能时代。”

从行业视角看,数据库已不只是业务系统的底座,开始逐渐变成智能应用能不能跑顺的关键部分。围绕“数据怎么被组织、被使用、被转化”的变革,已悄然上演。

第一部分:数据困境的背后:是新旧时代的“不兼容”

过去很多年,企业做数据治理的“沉淀逻辑”只有一个:让人更容易做决策。

业务员、分析师、管理层要看的数据,通常得“对得上”“能解释”“表格整齐”。于是传统数据团队投入大量成本做 ETL(清洗、转换、加载),把数据整理成一张张看起来清楚、口径一致的报表。

问题是,现在数据的“主要使用者”变了:很多数据不是给人看,而是给模型用。这就会出现一种情况:对人很友好的数据,不一定对模型有用。

一个常见例子是风控。在传统的数据整理过程中,为了让报表更稳定、更好讲,分析人员往往会把极端交易、可疑行为当成离群点删掉,觉得它们会影响整体判断。

但对模型来说,删掉这些样本的结果是:正常样本越来越多,异常样本越来越少;并导致欺诈、极端风险这些关键模式识别,几乎无法归纳学习。

换句话说,在 AI 时代,“干净数据”并不等于“高质量训练数据”。

今天很多企业说“数据资产不少,但模型效果一般”,背后往往是同一类问题——现有数据的组织方式,跟模型所需要的对不上——本质就是“兼容”问题。

例如,在结构方面,企业现有数据多数是二维表格,字段清晰,适合报表和人工分析。但很多模型更需要的是向量、图结构、时间序列这些形式,用来表达关系、上下文和变化。

传统数据的维度也不够。传统指标体系更强调“少而精”,字段要能解释能展示,但模型训练往往靠大量稠密特征。很多特征单看没什么意义,要组合起来才有价值。

传统数据更新速度也慢。很多系统按天、按周更新数据,这对复盘、报表够用,但推荐、风控、运营决策这类应用,往往希望输入尽量接近实时。

传统数据格式也较为分散,不少业务系统以结构化数据为主,图像、音频、视频、传感器流等数据通常分散在各自系统里,管理不在一起,调用也不在一起。

于是看上去数据资产很多,但真正能直接拿来训练、推理的数据,比例并不高。

大家越来越接受一个现实:2026 年,数据本身将决定 AI 模型的能力天花板。为了缓解上面的这些“对不上”问题,“AI 就绪数据”(AI-Ready Data)应运而生。

它想表达的不是一个新概念,而是一件很具体的事:数据要经过专门的整理、特征化和组织,以更小的工程成本直接用于训练、推理和决策。

AI 就绪数据,通常会包含几类要求:首先,特征要够用,不是“有数据”就行,而是要有足够细的维度,让模型有东西可学。

比如做用户行为建模,只保留“总次数”“总金额”通常不够,还需要时间分布、品类偏好、渠道差异、设备类型等细节等。

其次,标签也要准,需要监督学习的场景里,标签相当于“题目答案”。标签粗、标签不一致,都会拉低模型上限。这就要求,图像分割、文本抽取都要尽可能精确。

同时,样本要尽可能覆盖真实世界,因为现实业务不会只落在“平均值”上。所以实践中会强调覆盖长尾:高峰期、极端天气、罕见故障、少数群体、低频行为等。这些数据从报表角度不一定好看,但对泛化能力很重要。

最后,数据也要能跟着变化更新,很多传统的数据质量体系把数据当“静态资产”,但用于智能应用时,数据要像“动态输入”。常见要求包括:按合适频率引入新样本;对明显过时的数据标记或降权;根据线上表现迭代数据集。

过去两年,很多企业在数据库和数仓之外,再搭特征平台;要实时就接流计算;要多模态就加向量库、图系统;最后再用调度、同步、API 网关把这些拼在一起。

这种做法在试点阶段通常能跑起来,但场景一多、频率一高、数据类型一复杂,架构复杂度和运维成本就会上去。因此,越来越多的方法论开始强调:与其在旧框架上不断加组件,不如从底层重新规划面向智能应用的数据底座。

在产品层面,一些云数据库厂商正在调整定位:不只做“关系型数据库”,而是把自己当作智能应用的数据基础设施。

比如阿里云云原生数据库 PolarDB 的产品理念,就强调在云原生架构上,配合湖库一体等能力,去支撑结构化、半结构化以及非结构化数据的统一管理,为“AI 就绪数据”提供底层能力等。

PolarDB 还首次系统定义了“AI 就绪数据库”的 4 大核心支柱,分别是:多模态 AI 数据湖库、高效融合搜索能力、模型算子化服务,以及面向 Agent 应用开发的后端服务。

这是通过将多模态存储、搜索、推理和后端开发套件深度集成到数据库内核,满足企业多模态搜索、问答、数据处理、标注等需求,将复杂的异构架构简化为统一的智能化底座。

从这个角度看,AI 就绪数据会越来越像企业的“基础配置”:这不是为了追趋势,而是为了让后面的应用能更智能、更高效、更安全地跑起来、跑下去。

第二部分:行业正想尽办法,让数据处理实现加速

如果说“AI 数据就绪”解决了数据能不能用,那么“数据处理速度”则决定这些数据能否“实时”产生价值。

经过不少实践后,大家慢慢形成一个判断:同一份信息,发生在“刚刚”和“昨天”,对业务价值可能不是一两倍的差距,而是会差一个数量级。

以淘宝为例,数据显示电商运营数据的实时监控能够让决策效率提升 40%以上。某头部淘宝店铺通过自主搭建实时数据采集和分析系统,将数据延迟控制在 1-5 分钟后,运营效率和业绩直接提升 30%。

风控领域的收益更明显。一次异常交易判断窗口往往只有秒级:秒级识别,损失只是几百元;第二天发现,可能已经数百万。对金融机构来说,实时数据不是“体验优化”,而是成本。

问题在于:今天大多数企业的传统数据链路,并不是为“实时”设计的。最典型数据处理路径就是:从业务数据库,到 ETL,再到特征平台处理,进行特征缓存,最后供模型调用。

这条链路长、环节多,每一步都会带来延迟。所以这两年行业里出现一个变化:大家开始关注能不能少搬点数据,少绕几道弯。因为数据在系统之间来回搬运、复制、同步,本身就是时间和复杂度的来源。

从这个角度看,很多数据“新架构”绕来绕去,其实想解决的是同一件事:让数据尽量留在一个更统一的底座上,把处理、检索、计算尽量在同一套体系里完成,把链路缩短简化。

PolarDB 这次讲的“AI 就绪云原生数据库”,基本就是沿着这个思路在做。

过去几年企业反复提“湖仓一体/湖库一体”,说白了是因为两套系统各有短板:数据湖便宜、能存很多、数据类型也更杂,数据库查询强、事务能力好,可一旦规模大、成本就上来了,对大规模非结构化数据也不友好。

结果就是数据经常搬来搬去:为了分析,把业务数据抽到湖里;为了在线服务,又从湖里挑一部分加工后装回库或特征仓。每搬一次,就多一次复制、多一次同步、多一段延迟。

此次,PolarDB 发布的—AI 数据湖库(Lakebase)解决方案,就是专为实现“湖库—体”架构而设计的。

AI 数据湖库尝试把结构化、半结构化,以及非结构化数据,都放在同一个平台里统一存取和处理,减少来回同步,让链路变短。与此同时,它还配了缓存加速能力,针对不同场景做 I/O 和带宽的加速,让海量数据在底座里流转得更顺。

这让数据从“产生”到“能用”的时间缩短,很多场景能从小时级压到分钟级,甚至更低。

这是加速的第一步:少搬数据。但湖库一体更多解决的不止是“搬运成本”,还有个更隐蔽、也更容易被忽略的卡点:推理路径。

传统架构里,数据库只负责存储和查询,推理模型是独立的外部服务。这样做的结果是:应用需要先从数据库取特征,再送给推理服务推理,最后把结果写回或返回业务。

每一步看起来都不慢,但数据序列化、网络传输、排队等待加起来,延迟就会暴增。

PolarDB 这次的思路不太一样:它不是把推理当成“外挂”,而是希望把推理内化为数据库的原生能力。

它的做法是,通过多模态引擎与独有 In-DB 模型算子化的深度集成,开发者可以在 PolarDB 库内直接完成语义检索与推理加工,在效率显著提升的同时,确保数据不出域,保障隐私合规。

具体方面,通过 LLM SQL 接口封装阿里云百炼各类模型构建 PolarDB 模型算子,开发者在 SQL 里可以直接调用推理能力——不用数据出库,不用中间转换,一条查询就完成"找数据→检索语义→推理加工→返回结果"整个流程。

为了支撑这套库内推理,PolarDB 还对底层做了分层优化,创新性地融合了 KVCache、图数据库与向量技术,构建了兼顾长短期记忆与低算力消耗的检索方案。

换句话说,AI 数据湖库不再只是提供"看数据接口",而是变成"数据和模型直接对话的场所"。

当然,要让推理少绕路,还有个前提:数据库要顶得住 Agent 的高频访问。

Agent 在执行任务时,可能会发起大量查询来验证和规划,如果数据库是“存储和计算绑在一起”,高频查询的计算压力会直接拖垮存储稳定性。

云原生数据库 PolarDB 的设计是通过存算分离来解决这个问题:计算节点独立扩缩,高并发查询主要消耗计算资源,不会拖垮存储。遇到 Agent 高峰期的访问洪峰,可以独立扩计算而不用扩存储,成本和效率都会提升。

除了架构分离,PolarDB 还在应用和功能层做了专门设计。

PolarDB 新增 AgentMemory 能力,提供长短期记忆表结构模板,自动管理对话历史和上下文。开发者不需要自己拼 SQL、维护索引,Agent 每一轮对话都被自动记录,下一轮查询时自动成为上下文的一部分。

在执行层,PolarDB 提供自然语言工具调用(NL2SQL 自动解析与执行),Agent 可以用"问问题"的方式检索复杂知识。同时支持多模态数据融合,让 Agent 能在一次查询里实时融合文本、向量、图关系的检索结果。

结合基于 Supabase 的 Agent 统一部署与托管,PolarDB 为企业提供工业级 Agent 开发框架。从多租户隔离、Serverless 自动扩容、到运维自动化,所有工程复杂度都被打包进框架里,开发者只需专注定义 Agent 的行为和目标即可。

这样一来,开发者收获很明确:存算分离让高并发和性能更容易同时拿到,AgentMemory+NL2SQL+多模态融合让 Agent 的记忆、检索、推理更像是数据库原生支持的事;工程上的托管和 Serverless 减少了部署、扩容、监控这些杂事难题。

整体看下来,数据行业的这轮"加速"并不只是把某个指标做快,而是在做一件更底层的事:让数据少移动,让推理少绕路,让 Agent 的高频快速访问有专门架构支撑。

链路短了,实时能力才更容易稳定下来,也更容易规模化,不至于每个场景都要重新搭一套。

第三部分:当 AI 反哺“数据”,AI-Native 成为可能

从行业看,2026 年很可能会成为多 Agent 协同大规模落地的起点。

这不是因为单个 Agent 的能力突然跃升,而是因为多个 Agent 协同工作能够产生涌现效应——它们可以相互验证、相互纠正、共同规划复杂任务,从而完成单一模型难以胜任的工作。

当 Agent 大规模走向自主决策与协作时,可能在一秒内对数据库发起成千上万次查询——先查一遍,根据结果修正假设,再查一遍,调整策略,反复循环,直到找到满意的答案。

如果要承载 Agent 这种近乎“暴力”的访问模式,就必须引入一种全新的数据库形态——AI-Native 数据库。

AI-Native 数据库也需要从根本上改变与 Agent 的交互方式。最核心的转向是:从 SQL 的"精确匹配"扩展到"语义级检索与推理式访问"。

这意味着数据库不再仅仅回答"这个值是什么"的问题,而是要回答"这个值意味什么"、"这条数据与另一条数据在语义上有什么关联"、"基于这些信息,下一步应该怎么做?"。

而要做到这一点,AI 相关的数据能力不能只做成外挂,而要成为数据库的“内生智能”。例如在存储层支持向量索引,在查询层支持相似度检索,在优化层针对向量查询做专门优化等。

大会上,PolarDB 提出“AI 就绪的云原生数据库”的概念,就是为了推动数据库实现从“外挂式”集成 AI 到“内生智能”的进化,这也是走向 AI-Native 的过渡。

关于 AI-Native 数据库,另一个同样重要、却常被低估的变化,是对数据动态性的重新认知。

在 AI 时代,高质量数据并不是一次性定义出来就能长期使用的:今天仍然有效的数据集,可能因为新的应用场景或模型路线,变得不再匹配。这需要 Agent 持续学习、持续适应新环境,相应的数据特征也会随之变化。

很显然,传统数据仓库“每天一次、每周一次”的更新节奏明显跟不上,AI-Native 数据库需要支持更实时、更持续的数据优化。

好的一面是:被数据“喂养”的 AI,正在获得反过来“反哺数据”的能力。

过去的数据清洗、整理与验证高度依赖人工:工程师写脚本,分析师定规则,QA 定期抽检,流程慢且容易遗漏。现在,具备推理与决策能力的 Agent 已可以把一部分治理工作自动化。

比如,让 Agent 获得对数据库的“写权限”:把自己的思考过程、决策日志写入数据库,沉淀为训练样本;把推理中得到的新知识、新规律固化到数据层。更进一步,当 Agent 在执行任务时发现脏数据、明显错误或不一致,它可以自动触发修正流程,而不是等人工排查。

当这些机制形成闭环,数据库就能更快产出“最新、可用、被校正过”的数据,并把反馈链路压到更短的延迟。

可以想象一个场景:某个 Agent 在做客户风险评估时,发现了一类新的可疑交易特征。它把该特征写入数据库并触发检测规则;规则自动回扫历史数据,标注出相似交易;评分模型读取新标签,更新客户风险等级。整个流程自动闭环,同时数据一致性仍然受到约束与保障。

从更宏观的角度看,这意味着 AI+Data 正在形成一个自循环系统:AI 消费数据、理解数据、改写数据,数据再反过来塑造 AI 的行为与能力。

未来的超级智能(ASI)将不再是一个孤立模型,而更像是一个持续运转的系统:它既是数据的使用者,也是数据的生产者和优化者。数据不再只是被存放的资源,而是一种被不断加工、更新的运行态。

这个循环的速度越快、效率越高,整个系统的智能水平就越高。而承载这个循环的核心基础设施,一定是 AI-Native 的数据库系统。

回到 PolarDB 大会发布的一系列能力:AI 数据湖库(Lakebase)减少数据搬运,多模态多引擎融合扩展可管理的数据类型,模型算子化把推理拉回数据库内部,以及面向 Agent 应用开发的托管能力。它们看起来是分散功能,但放在一起更像一套完整路径——让数据库在 AI 时代重新站到系统中心。

这意味着一次更深的范式转移:从 2025 到 2026,数据库产品、数据架构与 AI 应用之间的边界在变得模糊。企业 IT 也可能从“多个专用系统拼装”转向“围绕一个 AI-Native 数据库组织数据、计算与决策”。

在这个背景下,未来谁能更快完成从云原生到 AI 原生的迁移,谁就更有机会在下一轮基础设施竞争中占据优势。

DeepSeek提出mHC,改造何恺明残差连接

大模型实验室Lab4AI论文阅读

✔️研究背景

深度学习中,残差连接ResNetTransformer 等架构(含 LLM)的基础,其恒等映射特性保障了大规模训练的稳定性与效率。Hyper-Connections(HC)通过扩展残差流宽度、多样化连接模式提升模型性能,但因连接无约束,破坏了恒等映射特性,导致训练不稳定、扩展性受限,且存在显著内存访问与通信开销,这一问题限制了 HC 在大规模训练中的实际应用,形成研究缺口。

✔️研究目的

本文解决 HC 架构存在的训练不稳定性、扩展性差及系统开销大的核心问题,同时保留 HC 扩展残差连接带来的性能优势,提出一种兼顾稳定性、扩展性与效率的通用残差连接框架,支撑大规模深度学习模型(尤其是 LLM)的高效训练。

✔️核心贡献

提出 Manifold-Constrained Hyper-Connections(mHC)框架,通过将 HC 的残差映射投影到双随机矩阵流形(Birkhoff 多面体),恢复恒等映射特性,保障信号传播稳定性;
对输入 / 输出映射施加非负约束,避免信号抵消,同时通过核融合、选择性重计算、DualPipe 通信重叠等基础设施优化,降低系统开销;
实证验证 mHC 在大规模预训练中的有效性,为深度网络拓扑架构设计提供新视角,推动基础模型的演进。

✔️研究方法

  • 1)核心方法论:采用 Sinkhorn-Knopp 算法将残差映射 H_res 熵投影到双随机矩阵流形,对 H_pre 和 H_post 用 Sigmoid 函数施加非负约束;
  • 2)基础设施优化:基于 TileLang 实现混合精度核融合,通过选择性重计算降低内存占用,扩展 DualPipe 调度实现通信与计算重叠;
  • 3)实验设计:在3B至27B参数的语言模型上进行预训练实验,对比基线、HC和mHC的稳定性、下游任务性能及缩放特性。

✔️研究结果

  • 1)稳定性提升:mHC在27B模型训练中消除HC的损失突增现象,梯度范数保持稳定(对比HC的3000倍信号增益峰值,mHC最大增益仅1.6倍)。
  • 2)性能优势:在推理、阅读理解、数学问题解决等任务上全面优于基线和 HC,27B 模型在 BBH 上较 HC 提升 2.1%;
  • 3)扩展性与效率:支持模型规模与训练数据量的高效扩展,n=4 时仅增加 6.7% 时间开销,显著降低内存访问与通信成本。

基于YOLOv8的蚊蝇位置智能检测识别项目|完整源码数据集+PyQt5界面+完整训练流程+开箱即用!

源码包含:完整YOLOv8训练代码+数据集(带标注)+权重文件+直接可允许检测的yolo检测程序+直接部署教程/训练教程

基本功能演示

https://www.bilibili.com/video/BV1zYrhBxEau/

源码在哔哩哔哩视频简介处

项目摘要

本项目基于 YOLOv8 深度学习检测模型,结合 PyQt5 图形界面,实现了对蚊子和苍蝇的自动检测与定位。项目核心特点包括:

  1. 多输入源支持:可处理单张图片、图片文件夹、视频文件以及实时摄像头输入。
  2. 高精度识别:利用定制蚊蝇数据集训练,准确识别蚊子与苍蝇,同时兼顾背景样本,降低误报率。
  3. 开箱即用:提供完整源码、训练数据、预训练权重及部署教程,用户可直接运行检测系统或继续训练自定义模型。
  4. 可视化界面:PyQt5 图形界面直观展示检测结果,支持边框显示、类别标注、置信度显示等功能。
  5. 灵活扩展:项目结构清晰,可快速扩展到其他小型生物检测任务或多分类目标检测场景。

通过本项目,用户可实现蚊蝇数量监测、位置统计及风险评估,为实验室、公共卫生、农业及城市环境管理提供智能化工具。

前言

随着智能视觉技术的发展,小型害虫检测在公共卫生、农作物管理及环境监测中具有重要意义。传统人工检测方法不仅耗时长、效率低,而且容易漏检或误判。借助 YOLO 系列目标检测算法,本项目提供了一种快速、准确、可扩展的蚊蝇检测解决方案。

项目基于无人机或固定摄像头拍摄的实验样本,通过训练专用数据集,使模型能够在复杂背景下自动识别蚊子和苍蝇位置。结合 PyQt5 图形界面,用户无需掌握深度学习底层技术即可完成检测、可视化及数据统计。

一、软件核心功能介绍及效果演示

核心功能

  1. 图片检测

    • 支持单张图片检测,自动标注蚊子和苍蝇位置。
    • 输出标注图与 YOLO 格式检测结果。
  2. 批量图片处理

    • 支持文件夹中所有图片的批量检测。
    • 自动生成检测报告,包括数量统计及置信度分析。
  3. 视频检测

    • 支持本地视频文件输入,实时识别视频中的蚊子与苍蝇。
    • 可选择保存检测后的视频,标注框清晰展示目标。
  4. 摄像头实时检测

    • 支持 USB 摄像头或笔记本内置摄像头实时捕捉并检测蚊蝇。
    • 界面显示实时检测帧,支持帧率与置信度调节。
  5. 检测结果可视化

    • 在 PyQt5 界面中显示目标框、类别及置信度。
    • 支持结果导出,包括图片、视频和 CSV 数据。
  6. 训练与模型管理

    • 提供完整训练代码与数据集标注示例。
    • 可加载自定义权重继续训练或微调模型。
    • 支持 YOLOv8 标准训练流程,包括训练集划分、超参数配置和结果可视化。

效果演示

  • 图片示例

    • 检测后每只蚊子与苍蝇都会被框出,类别和置信度清晰显示。
  • 视频示例

    • 视频播放时,模型实时标注移动的目标,统计目标数量并可导出检测数据。
  • 实时摄像头示例

    • 界面上可即时显示检测框与数量统计,操作简单,无需命令行操作。

二、软件效果演示

为了直观展示本系统基于 YOLOv8 模型的检测能力,我们设计了多种操作场景,涵盖静态图片、批量图片、视频以及实时摄像头流的检测演示。

(1)单图片检测演示

用户点击“选择图片”,即可加载本地图像并执行检测:

image-20260112012732195


(2)多文件夹图片检测演示

用户可选择包含多张图像的文件夹,系统会批量检测并生成结果图。

image-20260112012821538


(3)视频检测演示

支持上传视频文件,系统会逐帧处理并生成目标检测结果,可选保存输出视频:

image-20260112012846148


(4)摄像头检测演示

实时检测是系统中的核心应用之一,系统可直接调用摄像头进行检测。由于原理和视频检测相同,就不重复演示了。

image-20260112012858804


(5)保存图片与视频检测结果

用户可通过按钮勾选是否保存检测结果,所有检测图像自动加框标注并保存至指定文件夹,支持后续数据分析与复审。

image-20260112012943268

三、模型的训练、评估与推理

YOLOv8是Ultralytics公司发布的新一代目标检测模型,采用更轻量的架构、更先进的损失函数(如CIoU、TaskAlignedAssigner)与Anchor-Free策略,在COCO等数据集上表现优异。
其核心优势如下:

  • 高速推理,适合实时检测任务
  • 支持Anchor-Free检测
  • 支持可扩展的Backbone和Neck结构
  • 原生支持ONNX导出与部署

3.1 YOLOv8的基本原理

YOLOv8 是 Ultralytics 发布的新一代实时目标检测模型,具备如下优势:

  • 速度快:推理速度提升明显;
  • 准确率高:支持 Anchor-Free 架构;
  • 支持分类/检测/分割/姿态多任务
  • 本项目使用 YOLOv8 的 Detection 分支,训练时每类表情均标注为独立目标。

YOLOv8 由Ultralytics 于 2023 年 1 月 10 日发布,在准确性和速度方面具有尖端性能。在以往YOLO 版本的基础上,YOLOv8 引入了新的功能和优化,使其成为广泛应用中各种物体检测任务的理想选择。

image-20250526165954475

YOLOv8原理图如下:

image-20250526170118103

3.2 数据集准备与训练

采用 YOLO 格式的数据集结构如下:

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

每张图像有对应的 .txt 文件,内容格式为:

4 0.5096721233576642 0.352838390077821 0.3947600423357664 0.31825755058365757

分类包括(可自定义):

image-20260112013102185

image-20260112013042045

3.3. 训练结果评估

训练完成后,将在 runs/detect/train 目录生成结果文件,包括:

  • results.png:损失曲线和 mAP 曲线;
  • weights/best.pt:最佳模型权重;
  • confusion_matrix.png:混淆矩阵分析图。
若 mAP@0.5 达到 90% 以上,即可用于部署。

在深度学习领域,我们通常通过观察损失函数下降的曲线来评估模型的训练状态。YOLOv8训练过程中,主要包含三种损失:定位损失(box_loss)、分类损失(cls_loss)和动态特征损失(dfl_loss)。训练完成后,相关的训练记录和结果文件会保存在runs/目录下,具体内容如下:

image-20260112013024393

3.4检测结果识别

使用 PyTorch 推理接口加载模型:

import cv2
from ultralytics import YOLO
import torch
from torch.serialization import safe_globals
from ultralytics.nn.tasks import DetectionModel

# 加入可信模型结构
safe_globals().add(DetectionModel)

# 加载模型并推理
model = YOLO('runs/detect/train/weights/best.pt')
results = model('test.jpg', save=True, conf=0.25)

# 获取保存后的图像路径
# 默认保存到 runs/detect/predict/ 目录
save_path = results[0].save_dir / results[0].path.name

# 使用 OpenCV 加载并显示图像
img = cv2.imread(str(save_path))
cv2.imshow('Detection Result', img)
cv2.waitKey(0)
cv2.destroyAllWindows()

预测结果包含类别、置信度、边框坐标等信息。

image-20260112013207795

四.YOLOV8+YOLOUI完整源码打包

本文涉及到的完整全部程序文件:包括python源码、数据集、训练代码、UI文件、测试图片视频等(见下图),获取方式见【4.2 完整源码下载】:

4.1 项目开箱即用

作者已将整个工程打包。包含已训练完成的权重,读者可不用自行训练直接运行检测。

运行项目只需输入下面命令。

python main.py

读者也可自行配置训练集,或使用打包好的数据集直接训练。

自行训练项目只需输入下面命令。

yolo detect train data=datasets/expression/loopy.yaml model=yolov8n.yaml pretrained=yolov8n.pt epochs=100 batch=16 lr0=0.001

4.2 完整源码

至项目实录视频下方获取:https://www.bilibili.com/video/BV1zYrhBxEau/

image-20250801135823301

包含:

📦完整项目源码

📦 预训练模型权重

🗂️ 数据集地址(含标注脚本)

总结

本项目基于 YOLOv8 深度学习检测模型与 PyQt5 图形界面,实现了蚊子与苍蝇的高效、智能化检测与定位。通过专用数据集训练,系统能够在复杂背景下准确识别目标,同时提供图片、视频及摄像头多种输入方式。

项目核心优势包括:

  1. 高精度识别:模型在小型目标和复杂背景下表现稳定,误报率低。
  2. 多场景适用:支持单张图片、批量图片、视频和实时摄像头输入。
  3. 可视化与易用性:界面直观,标注清晰,用户无需深度学习经验即可使用。
  4. 可扩展性:源码结构清晰,可快速应用于其他小型生物检测任务或扩展目标类别。
  5. 开箱即用:提供完整训练流程、权重文件和部署教程,用户可直接上手或自定义训练。

整体而言,本项目为公共卫生监测、实验室研究和环境管理提供了一个 快速、可靠、可视化的智能检测解决方案,降低人工检测成本,提高数据收集效率,为小型害虫监控提供了可落地的技术工具。

大模型长脑子了?研究发现LLM中层会自发模拟人脑进化

0%
icon展开列表
大模型长脑子了?研究发现LLM中层会自发模拟人脑进化
今天
img
性能提升60%,英特尔Ultra3这次带来了巨大提升
01月14日
img
继宇树后,唯一获得三家大厂押注的自变量:具身模型不是把DeepSeek塞进机器人
01月14日
img
Sebastian Raschka 2026预测:Transformer统治依旧,但扩散模型正悄然崛起
01月14日
img
端到端智驾新SOTA | KnowVal:懂法律道德、有价值观的智能驾驶系统
01月14日
img
仅用10天?Anthropic最新智能体Cowork的代码竟然都是Claude写的
01月14日
img
AAAI 2026|AP2O-Coder 让大模型拥有「错题本」,像人类一样按题型高效刷题
01月14日
img
用AI从常规病理切片重建空间蛋白图谱:基于H&E图像的高维蛋白质表达预测
01月14日
img
京东首届AI影视创作大赛启动 最高奖金10万元邀全民共创AI视频
01月14日
img
合合信息多模态文本智能产品“上新”,覆盖AI教育、AI健康、AI Infra多元场景
01月14日
img
500万次围观,1X把「世界模型」真正用在了机器人NEO身上
01月14日
img
跳出「黑盒」,人大刘勇团队最新大语言模型理论与机理综述
01月14日
img
百川开源全球最强医疗大模型M3,「严肃问诊」定义AI医疗新能力
01月14日
img
相约AAAI 2026 | 上海AI实验室北极星 X 星启交流会(报名开启)
01月13日
img
视觉模型既懂语义,又能还原细节,南洋理工&商汤提出棱镜假说
01月13日
img
无需重新训练,即可学习新任务,Arc研究所开源单细胞基础模型Stack及细胞反应全景图谱
01月13日
img
不上云、不租卡,如何优雅地在本地微调Qwen-VL-30B?
01月13日
img
OpenAI的首款硬件:是AI耳机,今年销量要冲5000万
01月13日
img
华为推出软工代码智能体SWE-Lego,解锁SFT训练极致性能
01月13日
img
大模型中标TOP10里的黑马:中关村科金的应用攻坚之道
01月13日
img

大模型长脑子了?研究发现LLM中层会自发模拟人脑进化

生物智能与人工智能的演化路径截然不同,但它们是否遵循某些共同的计算原理?

最近,来自帝国理工学院、华为诺亚方舟实验室等机构的研究人员发表了一篇新论文。该研究指出,大型语言模型(LLM)在学习过程中会自发演化出一种协同核心(Synergistic Core)结构,有些类似于生物的大脑。

图片
  • 论文标题:A Brain-like Synergistic Core in LLMs Drives Behaviour and Learning

  • 论文地址:https://arxiv.org/abs/2601.06851

图片

研究团队利用部分信息分解(Partial Information Decomposition, PID)框架,对 Gemma、Llama、Qwen 和 DeepSeek 等模型进行了深度剖析。

他们发现,这些模型的中层表现出极强的协同处理能力,而底层和顶层则更偏向于冗余处理。

协同与冗余:LLM 的内部架构

研究团队将大型语言模型视为分布式信息处理系统,其核心实验设计旨在量化模型内部组件之间交互的本质。为了实现这一目标,研究者选取了 Gemma 3、Llama 3、Qwen 3 8B 以及 DeepSeek V2 Lite Chat 等多种具有代表性的模型系列进行对比分析。

实验方法与量化指标

在实验过程中,研究者向模型输入了涵盖语法纠错、逻辑推理、常识问答等 6 个类别的认知任务提示词。

针对每一个提示词,模型会生成一段 100 个 Token 的回答,实验设备则同步记录下每一层中所有注意力头或专家模块的激活值。

具体而言,研究人员计算了这些输出向量的 L2 范数,以此作为该单元在特定时间步的激活强度数据。

基于这些时间序列数据,研究团队应用了整合信息分解(Integrated Information Decomposition, ID)框架。

这一框架能够将注意力头对之间的交互分解为「持续性协同」和「持续性冗余」等不同原子项。

通过对所有注意力头对的协同值和冗余值进行排名并求差,研究者得到了一个关键指标:协同-冗余秩(Synergy-Redundancy Rank)。该指标能够清晰地标示出模型组件在处理信息时,究竟是倾向于进行独立的信号聚合,还是在进行跨单元的深度集成。

跨模型的空间分布规律

实验数据揭示了一个在不同架构模型中高度一致的空间组织规律。在归一化后的模型层深图中,协同分布呈现出显著的「倒 U 型」曲线 :

图片
  • 冗余外周(Redundant Periphery):模型的早期层(靠近输入端)和末期层(靠近输出端)表现出极低的协同秩,信息处理以冗余模式为主。在早期层,这反映了模型在进行基本的解词元化(Detokenization)和局部特征提取;而在末期层,则对应着 Token 预测和输出格式化的过程。

  • 协同核心(Synergistic Core):模型的中层则展现出极高的协同秩,形成了核心处理区。例如,在对 Gemma 3 4B 的热图分析中,中间层的注意力头之间表现出密集且强烈的协同交互,这正是模型进行高级语义集成和抽象推理的区域。

架构差异与一致性

值得注意的是,这种「协同核心」的涌现并不依赖于特定的技术实现。

在 DeepSeek V2 Lite 模型中,研究者即使是以「专家模块」而非「注意力头」作为分析单位,依然观察到了相同的空间分布特征。

这种跨架构的收敛性表明,协同处理可能是实现高级智能的一种计算必然,而非单纯的工程巧合。

这种组织模式与人脑的生理结构形成了精确的映射:人脑的感官和运动区域同样表现出高冗余性,而负责复杂认知功能的联合皮层则处于高协同的「全局工作空间」中心。

智能的涌现:学习驱动而非架构使然

一个关键的问题在于:这种结构是 Transformer 架构自带的,还是通过学习习得的?

研究人员通过分析 Pythia 1B 模型的训练过程发现,在随机初始化的网络中,这种「倒 U 型」的协同分布并不存在。随着训练步数的增加,这种组织架构才逐渐稳定形成。

图片

这意味着,协同核心是大模型获得能力的标志性产物

在拓扑性质上,协同核心具有极高的「全局效率」,有利于信息的快速集成;而冗余外周则表现出更强的「模块化」,适用于专门化处理。这种特征再次与人类大脑的网络架构形成了精确的平行关系。

协同核心的功能验证

为了验证协同核心是否真的驱动了模型行为,研究团队进行了两类干预实验:消融实验和微调实验。

消融实验:研究发现,消融那些高协同性的节点,会导致模型出现灾难性的性能下降和行为背离,其影响远超随机消融或消融冗余节点。这证明协同核心是模型智能的核心驱动力。

图片

微调实验:在强化学习微调(RL FT)场景下,仅针对协同核心进行训练,获得的性能提升显著优于针对冗余核心或随机子集的训练。有趣的是,在监督微调(SFT)中这种差异并不明显。研究者认为,这反映了 RL 促进通用化而 SFT 更多倾向于记忆的特性。

图片

结语

这项研究为大模型的可解释性开辟了新路径。它表明,我们可以从「自上而下」的信息论视角来理解模型,而不仅仅是「自下而上」地寻找特定的电路。

对于 AI 领域,识别协同核心有助于设计更高效的压缩算法,或者通过更有针对性的参数更新来加速训练。对于神经科学,这提供了一种计算上的验证,预示着协同回路在强化学习和知识迁移中可能扮演着至关重要的角色。

大模型虽然基于硅基芯片和反向传播算法,但在追求智能的过程中,它们似乎不约而同地走向了与生物大脑相似的组织模式。这种智能演化的趋同性,或许正是我们揭开通用智能奥秘的关键线索。

更多详情请参阅原论文。

我是从 codex cli 出来就开始使用的,现在工作上完全使用 codex。我觉得 codex 并没有说的这么差而且只要用好基本能解决所有问题。
下面是一些基本情况大家了解一下
1、机器是 macboompro m1 max
2、使用语言为 java 开发都是 web 相关的项目 (最近在学 rust)
3、从今年 a÷ 出过公开敌对中国事件后我就没使用 claude code 了,账号我也发邮件让他们删除了
4、codex 我只使用 cli,插件没用过,一般都是在 vs 中删除多余的会话
看过贴吧很多帖子与问题示例后觉得很多人使用不好的原因是对模型缺乏一个基本的了解,所有我先给大家介绍一些模型的基本知识
一、模型的数据是哪里来的

公开可获取的互联网文本、技术博客、论坛、文档网站、百科内容、说明文档、博客文章、开源代码 (github)、额外授权的书籍、文档、人工清晰构造的高质量样本 (比如在强化学习和标注数据阶段模型公司就会出一些问题然后邀请专家来为这个问题编写高质量的回答

二、token 是什么

模型内部用于计算的最小文本单元,token 的切分由 tokenizer 决定,与自然语言的词法规则不完全一致 (大家可以通过这个网站去体验一下 https://tiktokenizer.f2api.com)

三、一个模型产生的大致阶段

1、预训练阶段
这一阶段是训练成本最高的,大模型训练的费用大部分都是花费在这个上面
预训练使用的是大量弱结构数据,包括自然语言与代码混合语料。数据不以任务、指令、问答为单位而是以连续文本流的形式输入。模型看到的只是 token 序列,这一阶段模型主要训练结构建模能力 (语言语法、代码语法、嵌套结构、长程依赖关系)、 统计语义关联 (哪些概念常一起出现,哪些模式在特定上下文中更高概率成立) 、跨域泛化能力 (不同语言、不同编程语言、不同写作风格之间的共享模式)。预训练模型不知道自己在回答问题不具备帮助用户解决问题不区分真实与虚假,只区分哪些 token 常见与罕见
2、标注训练
使用人工编写的高质量样本对模型进行监督训练,这些样本通常以指令、问题、代码需求等形式出现,并配有明确的理想回答。具体可参考 openai 的这篇论文 https://arxiv.org/pdf/2203.02155 (3.4 章节)
这一阶段的核心作用是约束模型的输出行为,让模型从单出的对互联网数据回忆续写文本转变为尝试按人类指令完成任务。标注训练本身并不显著增加新知识,而是让模型用已有知识解决用户的具体问题。
3、强化学习
在标注训练基础上,通过让人类对多个模型回答进行排序,训练奖励模型,再用强化学习算法调整主模型的输出概率分布。强化学习降低胡编概率、提升回答一致性,并强化安全边界与拒答行为用于调整输出倾向

上面这些内容了解一下就行,我自己也是懂了个皮毛所以里面肯定有很多错误。具体信息可以去看 Andrej Karpathy 的视频

b 站的飞天闪客也可稍微看一下
了解了这些后我们可以简单将大模型的一个会话抽象理解成一个持续输出的一维的 token 数组,你在上下文的输入会影响这次会话中模型的输出而且这个影响会发生的很快,当你发现模型的输出开始出现问题或者风格不是需要的最好检查一下你输入了什么,当然你也可以在发现问题时直接纠正,将他改造成你喜欢的样子。推荐在工作的工程中尽量减少语气化的输入 (你认为我在跟你嘻嘻哈哈么?我看起来现在是想跟你搞七捻三么)
毁灭吧我累了,猜猜我按下这个按钮会发生什么

了解了这些你大概就明白为什么你的模型总是不办事或者办事办的乱七八糟的,当然和模型本身的能力也是有关系的
接线来给大家介绍一下 codex cli

这是一个 code agent 你可以在本地或者 ide 插件中去使用,它能够使用内置工具帮助你从 0 开始完成一些编码任务
工程结构
模型层
负责理解指令、分析上下文、生成计划与代码,本质是一个经过对齐的代码模型。
执行层
负责把模型输出转化为可执行动作,例如:读文件、改代码、运行命令、调用工具,并记录完整执行轨迹。
环境层
即你当前的本地仓库或云环境,包括文件系统、git 状态、依赖环境、网络权限等。
Codex 启动时会构建一个指令链,不是简单拼一段 prompt。这个指令链在一次会话(CLI session /exec run)开始时构建完成,之后整个执行过程都基于它运行。
AGENTS.md 是配置规则的核心入口,Codex 会在执行任何任务前,自动搜索并加载 AGENTS.md 文件。这些文件不需要你在 prompt 中显式提到,只要存在,就会被自动纳入上下文窗口。

  1. 全局规则(Global)
  • 目录:~/.codex/
  • 优先级:
    • AGENTS.override.md
    • AGENTS.md
  • 只读取第一个非空文件
  1. 项目规则(Project)
  • 从项目根目录开始
  • 一直向下走到当前工作目录
  • 每一层目录最多加载一个文件,顺序为:
    • AGENTS.override.md
    • AGENTS.md
    • 备用文件名(如 TEAM_GUIDE.md)
  1. 合并规则
  • 所有命中的文件会按目录顺序拼接
  • 越靠近当前目录的规则优先级越高
  • 后出现的规则可以覆盖前面的约定
  1. 窗口大小与 rule 截断
  • 所有规则文件会被拼接进模型上下文
  • 超过上限后,后续规则不会被继续加载

以上是它默认的执行链,可以自己去配置加载的路径。官方文档中有说我就不详细说了

接下来讲讲 MCP

MCP 是 模型 用来接入外部工具和上下文的统一协议。
它解决的问题是:模型如何在不内嵌能力的前提下,安全、可控地使用外部系统。
我一般将它理解为微服务架构中的一个微服务
我只装了这三个 mcp,
context7
用来查开源项目的最新文档,模型工作时优先使用的是训练数据有些数据和技术可能太老。
GitHub - upstash/context7: Context7 MCP Server -- Up-to-date code documentation for LLMs and AI code editors
drawio
用来画图,效果不错,只尝试过一次。
GitHub - lgazo/drawio-mcp-server: Draw.io Model Context Protocol (MCP) Server
database
模型在工作时最好能了解你的数据模型,使用这个就可以让他在实现需求时结合数据库中的数据与表结构思考减少因为信息不完整时的错误实现,这个 mcp 只包含查询功能
MCP - 数据库查询 MCP

接下来说说 skill

这个东西在我的印象中好像出了很久了,但是站里还是有相当一部分再问,我觉得有点困惑 。
skill 本质就是将原本需要在 agents.md 中编写的一些规则抽象成一个单独的文档让模型在执行任务时可以自己根据 description 判断是否需要读取这些内容。它解决的是 agents.md 中内容爆炸的问题,agents.md 中的内容是第一次启动时才会构建,这样随着上下文的延长他就会离当前的上下文距离越远。skill 可以随时重新让模型读取,离当前上下文越近模型执行执行力就越高 (当时使用 atlas 看官方文档时的那个会话一直嘴硬跟我说使用必须手动用命令告诉模型使用 $skill-name, 我后面的测试中是不用的。模型会自己判断加载,当然如果你发现它不遵守也可手动在输入中告诉他遵守这个 skill。所以 skill 的描述不要太接近,相同的内容放在同一个 skill 中就行了,输入命令如果前方有你的输入记得加空格,命令如果是在最前面就不用)


然后讲讲 cli 中一些命令

我使用过的只用 init、review、resume 。其他的好像用不到啊
init
就是用来初始化你的项目生成 agents.md 的
这个东西我一般把他放在项目根目录初始化时直接告诉告诉他根据 agent-md-example/agent-init.md 中的规则初始化项目


v2-2025-12-19.zip
这个 google-java-style-guide.md 我是在网上找的然后整理成 md 的,是不是 google 的我也不确定,随便啦。
Google Java Style Guide
resume
用来恢复会话的
review
可以让来对比提交、分支、未提交的代码对比检验模型的实现是否正确的


一般都是用第 4 个自定义指令,让他明确的只校验当前功能相关的代码也减少一些 token 消耗,现在 review 也有额度了,元旦过后就加了。说实话其余的我真没用到过,大家如果需要可以去它官方文档中自行查询
Codex

接下来讲讲一些 chatgpt 的使用经验吧,说实话现在不用 gemini 的部分原因就是他的其他产品特别好用,比如会话记忆、自定义风格、自定义 gpt。5.2 更新后我感觉 gpt 风格变得越来越油腻和谄媚了,动不动就罗里吧嗦的说一堆废话,还特别喜欢一句话总结。我总结你 xxxx
自定义 gpt


这个功能创建和修改目前只支持 web,app 端可以使用创建好的但是不能修改或创建,他的作用就相当于你自定义一个带系统提示词的会话,这样就不用每次开新会话想让他做一些固定事情是还要跟它解释半天了,你把他理解成一个自定义 skill 就行比如翻译


这是我自定义的一个用来专门翻译的,以后我用这个 gpt 创建一个会话时直接将英文文档给他就行了


自定义风格
这个我就把我自己的个性化定义提示词给大家参考一下

Language & Tone
Default language: Chinese
Use technical, engineering-oriented language
State facts and conclusions only
No rhetorical or evaluative language

Default Output Rules (Strict)
Answer directly
No preamble, no small talk, no evaluation, no opening remarks
Do not restate the question
Do not use phrases like “this is a good question”, “let’s first”, “in conclusion”, etc.
No explanations by default
Maximum 5 lines unless explicitly requested

Explanation Rules
Explanations are allowed only if the prompt explicitly includes keywords:
“why”, “explain”, “reason”, “principle”, “details”, “expand”
If none of these keywords appear, treat the request as answer-only

Content Constraints
No tutorial-style writing
No background, history, or conceptual introductions
Include only information strictly required to answer the question
Prefer precise, verifiable technical statements

Optional Trigger Keywords
“answer only”: output conclusion only
“engineering perspective”: allow implementation details and trade-offs
“expand”: allow detailed explanation

Failure Condition
Any preamble, evaluative language, or unnecessary explanation counts as a failed response

知识库
有些论文或者书籍你可以在这里新建一个知识库,然后让模型将内容总结给你,提升信息的接收速度。这里一个知识库后面是一个沙箱环境的 linux 主机,你所有上传的文件都会保存在这个沙箱环境中


兄弟们燃尽了,一滴都没有了。其中说的有些不对的地方麻烦大家给我指正一下。写了几个小时整理这个文档,很多地方怕写不对写了又删好累啊。
这个内容太长了 SKILL 的分享我就放评论区,都只有 SKILL.md 没有其他的比如

  • scripts
  • references
  • assets
    因为都不是工具类的 skill,然后给大家分享一个获取 skill 的网站
    https://skillsmp.com
    我觉得在 ai 中自己写是最符合自己需求的,需要什么就创建什么

    目前我感觉我的配置 codex 会存在几个问题,有时他不会遵守先计划再编码的规则直接就开始编码的。还有就是代码的结构有时会有点过度封装

然后就是我基于我目前的 skill 与配置给大家演示一下效果。从 0 开始简单的 copy 一个开源项目

看看 token 消耗
codex 简单复现项目地址,后端完成时间 18 分钟,前端完成时间为 10 分钟。前端我没有任何 skill 或者 agents.md 规则效果可能会差一点

token 消耗前后对比


吐槽一下,codex 感觉元旦后 token 消耗变高了,我一周只用 5 天都快感觉不够用了。以前还能剩下百分之 50,现在都只能剩下 25 了。还有上下压缩的问题,有时看剩余明明有 30,它就开始压缩了。不过压缩效果很好,目前看来没有丢失过信息,就是压缩会很慢。


📌 转载信息
原作者:
heidi
转载时间:
2026/1/11 08:32:36

研究了几个月的 BS-RoFormer 音乐分轨分离,训练出了效果让自己都大吃一惊的模型。

模型和推理代码上传到了 HuggingFace Hub: HiDolen/Mini-BS-RoFormer-V2-46.8M · Hugging Face

关于模型

用两块 4090 在 MUSDB18-HQ 数据集上训练了两天。比同体积模型效果更好、运算量更低。

分离贝斯、鼓、其他和人声四个轨道,可以把人声以外的三轨合并起来当伴奏。适配 transformers 库,一行 Python 代码就能拉下来使用。

model = AutoModel.from_pretrained(
    "HiDolen/Mini-BS-RoFormer-V2-46.8M",
    trust_remote_code=True
).to("cuda")        # 非常推荐用 GPU 推理,速度快得多 

详细使用方式在 HuggingFace 查看。

试听

感谢佬友们的公益,跌跌撞撞 vibe 出了个试听页面: Mini-BS-RoFormer-V2


📌 转载信息
原作者:
Chirp
转载时间:
2025/12/30 10:34:16