AI 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 后，它可能输出多层特征：

客户端、Skill 与 MCP：大模型如何调用本地能力

Sat, 16 May 2026 08:35:00 +0800

很多人第一次接触大模型工具调用时，容易把几个角色混在一起：大模型是不是直接读取了本地文件？Skill 是不是一个可执行插件？MCP Server 是不是直接连到了模型？

实际链路更清晰，也更安全：模型只看见客户端发给它的上下文和工具定义；真正访问本地文件、数据库、命令行或服务的是客户端；MCP 是客户端调用本地能力的一种标准接口；调用结果再被客户端作为新消息发回模型。

总览：先看完整链路

一次完整交互可以拆成四步：

客户端读取用户问题，并加载本地 Skill、系统提示词、可用工具列表。
客户端把这些信息整理成一次模型请求，发给大模型。
大模型判断需要调用工具时，不直接执行本地动作，而是返回一个 tool_call 请求。
客户端根据 tool_call 调用本地 MCP Server，把结果作为 tool 消息回填给模型，模型再基于结果继续回答。

这里最重要的边界是：模型提出“我要调用什么”，客户端决定“能不能调用、怎么调用、结果如何回传”。

Skill 是什么：给模型看的操作说明

Skill 可以理解成一份本地能力说明书。它通常不是让模型直接执行的程序，而是一组面向模型的规则、流程、约定和示例。

例如，一个写博客的 Skill 可能告诉模型：

# Blog Writing Skill

- 写中文技术文章。
- 文件名必须是英文小写 slug。
- 创建文章前先读取已有标签。
- 图片必须通过 blog MCP 上传。
- 创建后再次读取文章确认 frontmatter 和图片引用。

客户端在发起模型请求前，会把匹配到的 Skill 内容放进上下文。于是模型知道：当前任务不是随便写一段 Markdown，而是要按照这个博客系统的规范完成“查标签、写正文、上传图片、创建文章、验证结果”这些步骤。

注意，Skill 本身不等于工具。它更像操作手册：告诉模型什么时候应该做什么、输出应该长什么样、有哪些约束不能违反。

MCP 是什么：给客户端调用的本地能力接口

MCP Server 则更接近真正的本地工具提供者。它把本地能力包装成结构化接口，比如：

{
 "name": "blog.create_post",
 "description": "创建一篇 Hugo 博客文章",
 "input_schema": {
 "type": "object",
 "properties": {
 "title": { "type": "string" },
 "content": { "type": "string" },
 "tags": {
 "type": "array",
 "items": { "type": "string" }
 },
 "draft": { "type": "boolean" }
 },
 "required": ["title", "content"]
 }
}

客户端启动或连接 MCP Server 后，会拿到这些工具定义。随后客户端可以把工具名、描述和参数结构告诉模型，让模型知道有哪些工具可用。

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

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]，也就是文字内容。如果后续要做测评或业务校验，建议保留完整结果，不要过早只取纯文本。

大模型周边概念速通：MCP、Skill、Agent、Tool 到底是什么

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

大模型应用发展到现在，很多词会一起出现：MCP、Skill、Agent、Tool、Prompt、Resource、Memory、Guardrail、Handoff、Plugin、Connector。它们看起来都像“给 AI 增强能力”的东西，但实际所在的层级完全不同。

如果把大模型应用想成一个软件系统：大模型负责理解和生成，Agent 负责决策和调度，Tool 负责执行动作，MCP 负责把外部能力标准化接进来，Skill 负责沉淀一套可复用的任务方法。理解这些边界之后，再看各种 AI IDE、智能客服、自动化助手、博客发布机器人，就不会被概念绕晕。

总览：先看一条完整链路

一次典型的大模型应用调用，可以拆成这条链路：

用户请求
 -> 应用 / Agent
 -> 组装 Prompt、历史记录、上下文 Resource、Memory
 -> 调用大模型
 -> 大模型决定是否调用 Tool
 -> Tool 可能来自本地代码、平台内置能力，或 MCP Server
 -> 工具返回结果
 -> Agent 继续推理、校验、生成最终回答

这里最容易混淆的是三层：

层级	解决的问题	典型概念
模型层	负责语言理解、推理、生成	LLM、大模型、多模态模型
编排层	决定怎么完成任务	Agent、Prompt、Memory、Guardrail、Handoff
能力接入层	连接外部数据和动作	Tool、MCP、Resource、Connector、Plugin、Skill

一句话概括：大模型是大脑，Agent 是工作流控制器，Tool 是手，MCP 是标准插口，Skill 是做事手册和工具包。

大模型：能力核心，但不是完整应用

大模型，也就是 LLM 或多模态模型，核心能力是根据上下文预测和生成内容。它可以读文字、写代码、解释日志、分析图片、生成计划，但它本身通常不直接拥有你的文件系统、数据库、浏览器、Git 仓库、公司内部系统权限。

所以，大模型应用真正要解决的是：

给模型什么上下文。
允许模型调用哪些能力。
模型何时该自己回答，何时该查数据或执行动作。
工具调用前后如何校验安全性和结果质量。
多步骤任务失败时如何恢复。

这就是 Agent、Tool、MCP、Skill 等概念出现的原因。