算法 on 随手记

BiRefNet 深度解读：从图片分割到镜架边缘形态优化

Tue, 09 Jun 2026 00:00:00 +0800

开头：BiRefNet 到底在做什么

BiRefNet 可以先粗略理解成一个高质量前景分割模型。它拿到一张图片之后，不是直接输出一张透明 PNG，而是先输出一张 mask：

白色区域：要保留的主体
黑色区域：要删除的背景
灰色区域：边缘、不确定或半透明过渡

如果我们要做商品抠图，最终流程通常是：

原始图片
↓
BiRefNet 预测 mask
↓
mask 作为 alpha 通道
↓
得到透明背景 PNG

比如一副眼镜放在白色桌面上，BiRefNet 要判断每个像素属于眼镜还是背景。真正的难点不在于“整副眼镜在哪里”，而在于鼻托、镜腿、镜框内侧边缘、镜片孔洞这些细节是否干净、连续、圆润。

这篇文章按一个完全不懂深度学习的人也能理解的方式，解释 BiRefNet 的工作链路，并重点讨论一个很实际的问题：如果模型整体已经抠得很准，但镜架鼻托边缘还有毛刺和不规整，下一步应该怎么修。

总览：BiRefNet 的基本分工

可以先把 BiRefNet 拆成两个大部分：

图片
↓
backbone：提取视觉特征
↓
decoder / refinement：融合特征并生成 mask
↓
输出前景 mask

更通俗一点：

backbone = 看图并提取证据
decoder = 根据证据画出最终 mask

backbone 不直接输出“这个像素是前景、那个像素是背景”。它输出的是很多层特征图。decoder 才负责把这些特征图融合起来，变成最终可用的分割结果。

Backbone：不是空模型，而是视觉特征提取器

很多人第一次听到 backbone，会以为它是一个空权重模型。其实不是。

backbone 是整个网络里的视觉主干，它负责把原始 RGB 像素转换成模型内部能理解的特征。以一张 1024x1024 图片为例，原始输入大概是：

[3, 1024, 1024]

这里的 3 是 RGB 三个颜色通道。进入 backbone 后，它可能输出多层特征：

从标量、向量到张量：深度学习里的“数字容器”到底是什么？

Thu, 14 May 2026 09:55:14 +0800

刚接触深度学习时，很多人会被一堆词劝退：标量、向量、矩阵、张量、维度、形状、通道、批次……这些词看起来像数学课，其实它们背后的核心很简单：深度学习处理的东西，本质上是一堆数字；这些概念只是说明数字被怎样摆放。

你可以先把它们理解成不同大小、不同结构的“数字容器”：

标量：一个数字。
向量：一排数字。
矩阵：一张表格。
张量：更通用的多维数字容器。

这篇文章不要求你有高等数学基础。我们只抓住一个目标：以后看到 shape = (32, 3, 224, 224) 这种写法时，你知道它大概在说什么。

先建立直觉：模型只认识数字

人看到一张猫的图片，会说“这是一只猫”。但神经网络不能直接理解“猫”这个字，也不能像人一样直接理解图像含义。它真正拿到的是数字。

比如一张图片，在计算机里通常可以表示成很多像素点；每个像素点又可以用数字表示颜色。文本、声音、表格数据也一样，最后都要转成数字，模型才能计算。

所以深度学习里的问题，经常会变成：

这些数字怎么组织？模型每一步拿到的数字长什么样？

这就是标量、向量、矩阵、张量这些概念的用处。

标量：一个单独的数字

标量就是一个数。

例如：

3
0.01
-2.7

在深度学习中，很多结果都是标量：

学习率 0.001 是一个标量。
某次训练的损失值 1.26 是一个标量。
一个分类结果的概率 0.87 也可以是一个标量。

标量没有方向，也没有一排、一列、几行几列这些结构。它就是一个孤零零的数字。

如果用“维度”来描述，标量通常可以理解为 0 维。这里的 0 维不是说它不重要，而是说它没有展开成列表或表格。

向量：一排数字

向量是一组按顺序排好的数字。

例如：

[170, 65, 23]

你可以把它理解成一个人的三个特征：身高 170、体重 65、年龄 23。单个数字只能表达一个量，一排数字就可以一起描述一个对象。

在机器学习里，一个样本经常会被表示成一个向量：

[面积, 卧室数量, 楼层, 距离地铁距离]

如果我们要预测房价，就可以把每套房子变成这样一排数字。模型拿到的不是“这套房子不错”这种自然语言，而是一组可以计算的数。

向量通常可以理解为 1 维。这里的 1 维指的是它只有一个方向可以数：从左到右数第 1 个、第 2 个、第 3 个……

RapidOCR 入门：英文 OCR 识别、常规测评与使用注意事项

Wed, 06 May 2026 11:17:28 +0800

OCR 这类工具最容易被误用：看起来只要把图片丢进去就能得到文字，但真正放到项目里时，还会遇到图片质量、方向、字体、语言、速度、批量处理和错误纠正等问题。本文以一个最小的 RapidOCR 英文识别项目为例，整理它适合做什么、怎么跑起来、怎么做常规测评，以及使用时需要注意哪些细节。

本文不是完整排行榜式横向评测，而是偏工程落地的使用说明：先让脚本能稳定运行，再用一组可复现的指标判断它是否满足当前业务。

RapidOCR 是什么

RapidOCR 可以理解为一个轻量级 OCR 推理方案。当前示例项目使用的是 rapidocr-onnxruntime==1.2.3，底层通过 ONNX Runtime 执行 OCR 模型推理，典型链路包括：

文本检测：先在图片中找出可能包含文字的区域。
方向分类：判断文本是否需要旋转或方向修正。
文本识别：对检测出来的文字区域逐行识别。
结果整理：输出文本框、文字内容和置信度等结果。

在这个项目里，我们只保留最常用的输出：把图片中的文字逐行打印出来。它适合做轻量脚本、批处理、小工具、后台任务，也适合在正式接入大系统前做 OCR 方案验证。

适用场景

RapidOCR 更适合这些场景：

识别清晰图片里的英文、数字、短标签、票据字段、车牌周边信息等。
在本地或服务器上离线运行，不想依赖外部 OCR API。
希望用 Python 快速接入，先验证效果，再决定是否封装成服务。
对部署体积、调用方式、推理依赖有一定要求，希望用 ONNX Runtime 这类通用推理后端。

它不太适合直接裸用在这些场景：

图片严重模糊、过曝、反光、压缩严重。
版面复杂，需要结构化还原表格、段落、字段层级。
需要极高准确率的财务、证件、合同等强校验场景。
需要直接理解语义，而不只是把图片转成文字。

这些场景不是不能做，而是要加预处理、后处理、规则校验，甚至引入专门模型或人工复核流程。

最小项目结构

当前项目可以保持很简单：

rapidOCR/
├── README.md
├── ocr.py
├── IMG_20260506_110642.jpg
├── IMG_20260506_110656.jpg
└── venv/

核心脚本 ocr.py 的职责很清楚：接收一张图片路径，调用 RapidOCR，然后把识别出的每行文字打印出来。

import argparse
from rapidocr_onnxruntime import RapidOCR


def main():
 parser = argparse.ArgumentParser(description="OCR text recognition using RapidOCR")
 parser.add_argument("--input", required=True, help="Path to input image file")
 args = parser.parse_args()

 engine = RapidOCR()
 result, _ = engine(args.input)

 if not result:
 print("No text detected.")
 return

 for line in result:
 print(line[1])


if __name__ == "__main__":
 main()

这里的 result 通常包含文本框坐标、识别文本、置信度等信息。示例脚本只打印 line[1]，也就是文字内容。如果后续要做测评或业务校验，建议保留完整结果，不要过早只取纯文本。

MySQL B+ Tree 机制与算法详解

Wed, 29 Apr 2026 00:00:00 +0800

为什么数据库普遍选择 B+ Tree

如果只从算法课本看，查找一个有序集合有很多选择：数组可以二分，哈希表可以做到平均 O(1)，红黑树、AVL 树可以做到 O(logN)。但数据库的核心问题不是“CPU 内存里怎么找”，而是“磁盘或 SSD 上的数据怎么少读几次”。

MySQL 的 InnoDB 存储引擎把表数据和索引组织成页。默认情况下，一个页通常是 16KB。一次查询如果每深入一层索引就需要读取一个页，那么树的高度越低，I/O 次数就越少。B+ Tree 的核心优势就在这里：

每个节点能存放很多 key，树的分叉数很大，高度很低。
所有真实记录都在叶子节点，非叶子节点只负责导航。
叶子节点之间按 key 顺序连接，非常适合范围查询和排序扫描。
节点大小天然适合数据库页，可以和磁盘读写单位对齐。

所以，B+ Tree 不是为了在理论复杂度上压倒所有结构，而是为了适配数据库最昂贵的资源：随机 I/O。

从二叉树到 B+ Tree

普通二叉搜索树每个节点最多两个孩子。即使它保持平衡，一千万条数据的高度也大约是二十多层。放在内存里问题不大，放在数据库里就意味着一次查找可能触发很多次随机页读取。

B Tree 和 B+ Tree 解决的是“分叉太少”的问题。一个节点可以保存多个 key 和多个孩子指针。例如节点中有这些分隔 key：

[10 | 20 | 30]

它可以把搜索空间分成四段：

(-∞, 10) [10, 20) [20, 30) [30, +∞)

这样，一个节点不是二选一，而是多路分发。只要一个页中能放下足够多的 key 和指针，树的高度就会非常低。

B+ Tree 相比 B Tree 又进一步做了一个重要取舍：非叶子节点不存放完整数据记录，只存放用于导航的 key 和子节点页号；所有完整记录都放在叶子节点。这样非叶子节点更小，能容纳更多 key，树也就更矮。

B+ Tree 的基本结构

一棵典型 B+ Tree 可以分成三类节点：