企业官网建设流程全解析

1. 文本检测之CRAFT检测算法：从原理到落地的完整拆解

文本检测这个方向，说它是OCR流水线里最容易被低估的一环，一点都不夸张。很多人做OCR项目，注意力全放在识别模型上，觉得检测无非就是找个框把字圈出来，能有多难。结果一上真实场景就傻眼了：弯曲的招牌文字、密集排列的商品标签、低对比度的文档扫描件、透视变形的路牌，这些情况用传统的矩形框检测方案基本全军覆没。CRAFT（Character Region Awareness for Text Detection）就是在这个背景下进入视野的，它的核心思路跟主流检测器有本质区别——不直接回归文本框，而是先预测每个字符的区域和字符之间的连接关系，再通过后处理把字符拼成完整的文本实例。

这个算法我第一次接触是在处理一批自然场景图片的时候，当时试过基于回归的方案和基于分割的方案，前者对密集文本和弯曲文本的召回率一直上不去，后者在字符间距较大的场景下容易把一句话拆成好几段。CRAFT的字符级建模思路恰好在这两个痛点之间找到了平衡点。它适合谁呢？如果你正在做OCR相关的项目，需要处理自然场景文本、商品包装文字、文档版面分析、工业铭牌识别等任务，并且对弯曲文本和密集文本的检测效果有要求，那CRAFT值得花时间深入研究。即便你最终不直接用这个模型，理解它的设计思路对做检测类任务也有很大的启发。

2. 核心设计思路与方案选型拆解

2.1 为什么不用传统的矩形框回归

传统文本检测方案大致分两类：一类是基于通用目标检测框架（如Faster R-CNN、SSD、YOLO系列）做文本框回归，另一类是基于分割的方法直接预测文本区域掩码。这两类方案各有各的局限。

基于回归的方案，本质上是用一个矩形去拟合文本区域。但文本这东西有个特点——它的形状太灵活了。水平文本还好说，一旦遇到弯曲文本、弧形排列的文字、透视变形后的文本，矩形框就会引入大量背景噪声。你想想，一个弯曲的招牌文字，用矩形框圈出来，框里可能有一半是天空或者墙面，这给后续的识别环节带来了巨大的干扰。而且当两个文本实例靠得很近时，矩形框容易重叠，NMS之后可能把两个独立的文本实例合并成一个，或者把一个完整的文本实例切成两半。

基于分割的方案，直接预测像素级的文本区域，理论上可以处理任意形状。但问题在于，分割出来的区域是连通的像素块，当字符间距较大或者文本行之间有粘连时，分割结果很难区分“这是一个文本实例”还是“这是两个相邻的文本实例”。后处理阶段需要复杂的连通域分析和启发式规则来分组，调参成本很高。

CRAFT的设计者显然想清楚了这两个问题。它的核心洞察是：文本是由字符组成的，字符是文本的最小语义单元。如果模型能准确地找到每个字符的位置，并且知道哪些字符属于同一个文本实例，那文本检测的问题就转化成了“字符检测+字符分组”两个子问题。这个思路的好处在于，字符级别的监督信号比文本行级别的监督信号更细粒度，模型能学到更精确的边界信息；同时，字符之间的连接关系（affinity）提供了一种天然的分组依据，不需要依赖复杂的后处理规则。

2.2 字符区域与亲和力的双通道设计

CRAFT的网络结构输出两个通道的热力图：一个是字符区域得分图（Region Score），另一个是字符亲和力得分图（Affinity Score）。这两个通道的设计是整个算法的灵魂。

字符区域得分图的作用是标记每个字符的中心区域。注意，这里不是精确的字符边界框，而是用高斯热力图的方式，在字符中心位置生成一个峰值，向四周衰减。这样做的好处是，即使字符边界标注不是特别精确，模型也能学到稳定的字符中心特征。你可以把它理解成：模型不需要知道字符的精确轮廓，只需要知道“这里有一个字符”。

字符亲和力得分图的作用是标记相邻字符之间的连接区域。具体来说，对于同一文本实例中相邻的两个字符，在它们之间的区域生成一个亲和力峰值。这个设计非常巧妙——它实际上是在告诉模型：“这两个字符是一伙的”。在后处理阶段，只要沿着亲和力高的方向把字符区域连起来，就能自然地形成完整的文本实例。

这两个通道是共享同一个特征提取骨干网络的，只是在最后分出了两个预测头。骨干网络通常用VGG16或ResNet，经过特征金字塔结构融合多尺度特征，最终输出原图1/2或1/4分辨率的热力图。共享骨干的设计保证了两个通道的特征表达是一致的，不会出现字符区域和亲和力区域对不上的情况。

2.3 弱监督与强监督的结合策略

CRAFT的训练策略也值得说道。完全依赖字符级标注来训练是不现实的——标注成本太高了，而且很多公开数据集只有文本行级别的标注。CRAFT的做法是：在合成数据集上用字符级标注做强监督训练，在真实数据集上用文本行标注做弱监督训练。

弱监督的核心思路是：如果我知道一个文本行的边界框，那我可以根据字符数量估计每个字符的大致位置，生成伪字符标签。具体来说，对于水平文本行，把边界框按字符数量均分，每个格子中心作为字符中心；对于任意四边形标注的文本行，先估计字符数量，然后沿文本方向等分。这种伪标签的质量肯定不如人工标注，但胜在数据量大，能让模型见到更多真实场景的多样性。

强监督和弱监督的结合比例也需要调。合成数据虽然标注精确，但域差距明显，模型在合成数据上训久了，到真实场景会水土不服。真实数据的伪标签虽然噪声大，但域匹配好。实践中通常采用混合采样的方式，让模型在每个batch里同时见到合成样本和真实样本，保持对真实场景的敏感度。

3. 核心细节解析与实操要点

3.1 骨干网络与特征融合的关键参数

CRAFT的骨干网络选择直接影响检测精度和推理速度。原论文用的是VGG16-BN，这个选择在当时是权衡了精度和速度的结果。VGG16的结构简单，特征提取能力强，但参数量偏大，推理速度在GPU上大概能到10-15 FPS（输入分辨率1280×768）。如果对速度有更高要求，可以换成ResNet50或者更轻量的MobileNetV3，但精度会有一定下降。

特征融合部分，CRAFT采用了类似U-Net的跳连接结构，把骨干网络不同阶段的特征图上采样后拼接。具体来说，VGG16的conv4、conv5、conv6（把fc6和fc7转成卷积层）的输出被分别上采样到同一分辨率，然后拼接。这种多尺度融合的设计是为了同时捕捉大字符和小字符——浅层特征分辨率高，适合检测小字符；深层特征语义强，适合检测大字符和判断字符的归属。

实操中有一个容易踩的坑：输入图像的分辨率设置。CRAFT对输入分辨率比较敏感，分辨率太低会导致小字符检测不到，分辨率太高会显著增加显存占用和推理时间。我的经验是，对于自然场景文本，长边设置在1280-1600之间比较合适；对于文档类图像，长边设置在960-1280之间就够了。如果显存不够，可以先把图像缩放到短边720或800，再送入网络。

3.2 热力图生成与高斯核参数选择

训练时，字符区域和亲和力的真值热力图是通过高斯核生成的。对于每个字符，在其边界框内生成一个二维高斯分布，峰值在字符中心，标准差与字符尺寸相关。原论文中，高斯核的标准差设置为字符框尺寸的1/3左右。这个参数很关键——标准差太大，热力图会过度平滑，相邻字符的区域会粘连；标准差太小，热力图峰值过于尖锐，模型学到的特征不够鲁棒。

亲和力的热力图生成稍微复杂一些。对于相邻的两个字符，先找到它们中心点连线的中点，然后以这个中点为峰值生成高斯分布。亲和力区域的范围通常比字符区域窄一些，因为字符之间的间隙本来就小。如果两个字符靠得很近，亲和力区域可能会和字符区域重叠，这是正常的，后处理时会根据得分阈值来区分。

注意：高斯核的标准差不要设成固定值，一定要根据字符尺寸自适应。我试过用固定标准差，结果大字符的热力图峰值太尖，小字符的热力图又太散，模型收敛很慢。

3.3 后处理：从热力图到文本框的完整流程

CRAFT的后处理是整个算法里最需要调参的部分，也是实际落地时最容易出问题的地方。完整流程大致分四步：

第一步：二值化。对字符区域得分图和亲和力得分图分别设定阈值，得到二值掩码。字符区域的阈值通常设0.7左右，亲和力的阈值设0.4左右。这两个阈值不是固定的，需要根据实际场景调整。如果场景中文本比较密集，阈值可以适当调高，避免不同文本实例粘连；如果文本比较稀疏，阈值可以调低，保证召回率。

第二步：连通域分析。对二值化后的字符区域掩码做连通域分析，每个连通域对应一个字符或字符的一部分。这里要注意，有些字符（比如“i”、“j”）可能被分成多个连通域，需要根据位置关系合并。

第三步：亲和力连接。遍历每个连通域，检查其与相邻连通域之间的亲和力得分。如果亲和力得分超过阈值，就把这两个连通域标记为同一文本实例。这个过程类似于并查集的合并操作，最终每个文本实例对应一组连通域。

第四步：文本框生成。对每个文本实例的所有连通域，计算它们的最小外接矩形或最小外接多边形。如果需要任意形状的文本框，可以用凸包算法生成多边形；如果只需要矩形框，直接取外接矩形即可。

实操心得：后处理阶段最容易出问题的是“过分割”和“欠分割”。过分割是指一个完整的文本实例被拆成多个，通常是因为亲和力阈值设得太高，或者字符之间的间隙太大导致亲和力得分低。欠分割是指多个文本实例被合并成一个，通常是因为字符区域阈值设得太低，不同文本实例的字符区域粘连了。调参时建议先固定一个阈值，观察bad case，再针对性调整。

3.4 训练数据准备与标注格式转换

CRAFT的训练数据需要两种标注格式：字符级标注和文本行级标注。字符级标注通常来自合成数据集，格式是每个字符的边界框坐标；文本行级标注来自真实数据集，格式是每个文本行的边界框坐标（可以是水平矩形或任意四边形）。

如果你手头只有文本行标注，需要先转换成CRAFT需要的格式。转换的核心是估计每个文本行中的字符数量和位置。对于水平文本行，可以根据文本行的宽高比和平均字符宽高比来估计字符数量；对于任意四边形文本行，需要先做透视变换把文本行矫正成水平，再估计字符位置。这个估计过程肯定有误差，但CRAFT的弱监督训练对伪标签的噪声有一定的容忍度。

合成数据方面，常用的做法是用文本渲染引擎生成大量带有精确字符标注的图像。渲染时要注意字体多样性、背景多样性、文字颜色和背景颜色的对比度变化、以及各种几何变换（旋转、缩放、透视）。合成数据的质量直接影响模型的预训练效果，不要随便生成几千张就完事，至少要到十万量级才能让模型学到稳定的字符特征。

4. 实操过程与核心环节实现

4.1 环境搭建与依赖安装

先说一下环境。CRAFT的原版实现是基于PyTorch的，也有TensorFlow版本，但PyTorch版本维护得更活跃，建议优先选PyTorch。我用的环境是Python 3.8 + PyTorch 1.10 + CUDA 11.3，这个组合比较稳定。

# 创建虚拟环境 conda create -n craft python=3.8 -y conda activate craft # 安装PyTorch（根据你的CUDA版本调整） pip install torch==1.10.0 torchvision==0.11.0 torchaudio==0.10.0 # 安装其他依赖 pip install opencv-python pillow numpy scipy shapely pip install wandb # 可选，用于训练可视化

如果你要用预训练模型做推理，还需要下载CRAFT的预训练权重。权重文件通常包含骨干网络和两个预测头的参数，大小在80MB左右。下载后放到指定目录，推理脚本会自动加载。

注意：PyTorch版本和CUDA版本的匹配很重要。我遇到过因为版本不匹配导致推理时显存泄漏的问题，换了匹配的版本就正常了。建议严格按照PyTorch官网的版本对照表来装。

4.2 推理流程的完整代码实现

下面是一个完整的推理流程，从图像读取到最终文本框输出。我把它拆成了几个函数，方便你按需修改。

import cv2 import numpy as np import torch from craft_model import CRAFT # 假设模型定义在craft_model.py中 def load_model(weight_path, device='cuda'): """加载CRAFT模型""" model = CRAFT() model.load_state_dict(torch.load(weight_path, map_location=device)) model = model.to(device) model.eval() return model def preprocess_image(image, target_size=1280): """图像预处理：缩放和归一化""" h, w = image.shape[:2] scale = target_size / max(h, w) new_h, new_w = int(h * scale), int(w * scale) # 确保尺寸是32的倍数 new_h = (new_h // 32) * 32 new_w = (new_w // 32) * 32 resized = cv2.resize(image, (new_w, new_h)) # 归一化 mean = np.array([0.485, 0.456, 0.406]) std = np.array([0.229, 0.224, 0.225]) normalized = (resized / 255.0 - mean) / std tensor = torch.from_numpy(normalized).permute(2, 0, 1).float().unsqueeze(0) return tensor, (h, w), (new_h, new_w) def postprocess(region_score, affinity_score, region_thresh=0.7, affinity_thresh=0.4): """后处理：从热力图生成文本框""" # 二值化 region_binary = (region_score > region_thresh).astype(np.uint8) affinity_binary = (affinity_score > affinity_thresh).astype(np.uint8) # 连通域分析 num_labels, labels = cv2.connectedComponents(region_binary) # 构建亲和力图谱 # 这里简化处理，实际实现需要用并查集合并连通域 boxes = [] for label_id in range(1, num_labels): mask = (labels == label_id) ys, xs = np.where(mask) if len(xs) < 10: # 过滤太小的连通域 continue x_min, x_max = xs.min(), xs.max() y_min, y_max = ys.min(), ys.max() boxes.append([x_min, y_min, x_max, y_max]) return boxes def detect_text(image_path, model, device='cuda'): """完整的文本检测流程""" image = cv2.imread(image_path) image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB) tensor, orig_size, new_size = preprocess_image(image) tensor = tensor.to(device) with torch.no_grad(): region_score, affinity_score = model(tensor) # 转回numpy region_score = region_score[0, 0].cpu().numpy() affinity_score = affinity_score[0, 0].cpu().numpy() # 后处理 boxes = postprocess(region_score, affinity_score) # 把框映射回原图尺寸 h_orig, w_orig = orig_size h_new, w_new = new_size scale_x = w_orig / w_new scale_y = h_orig / h_new final_boxes = [] for box in boxes: x_min, y_min, x_max, y_max = box final_boxes.append([ int(x_min * scale_x), int(y_min * scale_y), int(x_max * scale_x), int(y_max * scale_y) ]) return final_boxes

这段代码里，后处理部分做了简化，实际的CRAFT后处理需要实现完整的亲和力连接逻辑。核心思路是：先用并查集把字符连通域按亲和力关系合并，再对每个合并后的集合生成外接框。

4.3 关键参数调优的实操记录

我在一个商品包装文字检测的项目里，对CRAFT的关键参数做了系统性的调优。场景特点是：文本密集、字体多样、背景复杂、存在大量小字符。以下是调优过程中的关键记录。

输入分辨率的影响。初始设置长边1280，小字符（高度小于15像素）的召回率只有72%。把长边提到1600后，小字符召回率提升到86%，但推理时间从每张120ms增加到190ms。最终折中设置在1440，召回率83%，推理时间150ms。

字符区域阈值的影响。阈值从0.6调到0.8，精确率从78%提升到91%，但召回率从89%下降到76%。原因是高阈值把一些低对比度的字符区域过滤掉了。最终设置在0.72，精确率86%，召回率85%。

亲和力阈值的影响。这个参数对过分割和欠分割的影响最大。阈值0.3时，欠分割严重，多个文本实例被合并；阈值0.5时，过分割明显，一个文本行被拆成多段。最终设置在0.4，配合字符区域阈值0.72，整体F1值达到0.85。

实操心得：调参时不要一次性调多个参数，每次只调一个，观察指标变化。另外，不同场景的最优参数差异很大，不要指望一套参数走天下。建议针对你的目标场景标注100-200张验证集，用网格搜索的方式找最优参数组合。

4.4 模型微调的训练流程

如果你手头有标注数据，对CRAFT做微调能显著提升特定场景的检测效果。微调的关键是数据配比和学习率设置。

数据配比方面，建议合成数据:真实数据 = 1:2 到 1:3。合成数据提供精确的字符级监督，真实数据提供域适应能力。如果真实数据太少，可以先用合成数据预训练，再用真实数据微调。

学习率方面，微调时用初始学习率的1/10左右。原论文用Adam优化器，初始学习率1e-4，微调时设1e-5。训练epoch数控制在50-100之间，太多容易过拟合。

# 微调训练的核心配置 optimizer = torch.optim.Adam(model.parameters(), lr=1e-5) scheduler = torch.optim.lr_scheduler.StepLR(optimizer, step_size=30, gamma=0.5) # 损失函数：字符区域和亲和力分别计算MSE损失 def craft_loss(region_pred, affinity_pred, region_gt, affinity_gt): region_loss = torch.nn.MSELoss()(region_pred, region_gt) affinity_loss = torch.nn.MSELoss()(affinity_pred, affinity_gt) return region_loss + affinity_loss

训练过程中要监控验证集上的F1值，如果连续10个epoch没有提升就停止训练。另外，数据增强很重要，随机裁剪、旋转、颜色抖动、模糊都能提升模型的泛化能力。

5. 常见问题与排查技巧实录

5.1 检测框粘连与断裂的排查思路

这是CRAFT落地时最高频的问题。表现是：两个独立的文本实例被合并成一个框，或者一个完整的文本行被拆成多个框。

排查思路分三步走。第一步，检查热力图可视化结果。把字符区域得分图和亲和力得分图叠加到原图上，观察问题区域的得分分布。如果两个文本实例之间的亲和力得分异常高，说明模型把它们的字符误判为同一实例；如果一个文本行内部的亲和力得分异常低，说明模型没有学到字符之间的连接关系。

第二步，检查训练数据的标注质量。如果训练数据中两个文本实例的标注框有重叠，模型会学到错误的亲和力关系。同样，如果一个文本行的标注框不完整，模型学到的字符区域会缺失。

第三步，调整后处理参数。粘连问题通常通过提高字符区域阈值或降低亲和力阈值来解决；断裂问题则相反。如果调参解决不了，说明模型本身有问题，需要重新训练或微调。

5.2 小字符漏检的优化方案

小字符漏检是CRAFT在自然场景中的常见问题。原因通常是多尺度的：输入分辨率不够、特征金字塔的浅层特征利用不充分、训练数据中小字符样本太少。

优化方案按优先级排列：优先提高输入分辨率，这是最直接有效的方法，但要注意显存和速度的平衡。其次，在训练数据中增加小字符样本的比例，可以通过数据增强（随机缩放）来模拟小字符。第三，调整特征融合的权重，让浅层特征的贡献更大。最后，如果以上都不行，可以考虑在CRAFT后面接一个专门的小字符检测分支，但这会增加模型复杂度。

注意：小字符检测和推理速度是一对矛盾。如果你的场景对小字符检测要求很高，就要接受推理速度的下降。我试过用超分辨率预处理来提升小字符检测效果，效果不错但推理时间翻倍，最终没有采用。

5.3 弯曲文本检测的边界处理

CRAFT对弯曲文本的检测能力比矩形框回归方案强很多，但也不是没有边界。当文本弯曲程度很大（比如圆形排列的文字）时，字符之间的亲和力关系会变得复杂，后处理阶段容易出错。

处理弯曲文本的关键在于后处理阶段的文本框生成方式。不要用最小外接矩形，而是用最小外接多边形或凸包。具体来说，对每个文本实例的所有字符连通域，提取它们的轮廓点，然后用凸包算法生成多边形框。如果凸包效果不好，可以尝试用Alpha Shape算法，它能更好地贴合弯曲形状。

另外，弯曲文本的亲和力阈值需要单独调。因为弯曲文本的字符间距通常比水平文本大，亲和力得分会偏低，需要适当降低阈值。我的经验是，弯曲文本场景下亲和力阈值设0.3-0.35比较合适。

5.4 常见问题速查表

5.5 独家避坑技巧

技巧一：热力图可视化是调参的指南针。不要盲目调参，先把热力图叠加到原图上，肉眼观察问题区域。很多时候，你看一眼热力图就知道问题出在字符区域还是亲和力区域，调参方向立刻明确。

技巧二：用少量数据快速验证参数。不要在全量数据上调参，选50-100张有代表性的图片，快速迭代参数。找到大致范围后，再在全量数据上精调。

技巧三：保存中间结果。推理时把字符区域得分图、亲和力得分图、二值化掩码、连通域标记图都保存下来。出问题时可以逐层排查，比重新跑一遍推理高效得多。

技巧四：合成数据的质量比数量重要。我见过有人生成了100万张合成数据，但字体只有几种，背景也很单一，结果模型在真实场景上表现很差。合成数据要注重多样性：字体至少50种以上，背景要涵盖室内、室外、纯色、纹理等，文字颜色和背景颜色的对比度要覆盖高、中、低三档。

技巧五：微调时冻结骨干网络的前几层。骨干网络的浅层学到的是通用特征（边缘、纹理），这些特征在大多数场景下都适用，不需要重新学。微调时冻结前几层可以防止过拟合，同时减少训练时间。

技巧六：后处理阶段加一个文本框过滤规则。根据实际场景设置文本框的最小尺寸、最大宽高比、最小面积等过滤条件，能有效去除误检。比如商品标签场景，文本框宽高比超过10:1的基本都是误检。

技巧七：多尺度推理融合。对同一张图用两个不同分辨率分别推理，然后把结果做NMS融合，能同时兼顾大字符和小字符的检测。代价是推理时间翻倍，但对精度要求高的场景值得。

技巧八：注意图像预处理的一致性。训练时的归一化参数（均值、标准差）必须和推理时一致，否则热力图得分会整体偏移，导致阈值失效。我踩过这个坑，训练时用了ImageNet的均值方差，推理时忘了加，结果所有得分都偏低，调了半天阈值才发现问题。

技巧九：CRAFT的输出分辨率是原图的1/2或1/4，映射回原图时要注意对齐。如果映射有偏差，文本框会整体偏移几个像素。建议在映射时用双线性插值，而不是简单的最近邻。

技巧十：如果场景中有大量垂直文本，需要对训练数据做特殊处理。CRAFT原版对垂直文本的支持一般，因为亲和力的生成方式是沿水平方向连接的。处理垂直文本时，可以在数据增强阶段把垂直文本旋转成水平文本，推理后再旋转回去。

6. 与其他文本检测方案的对比与选型建议

6.1 CRAFT vs 基于回归的方案

基于回归的方案（如TextBoxes++、RRPN）在水平文本和规则排版场景下速度优势明显，推理速度通常比CRAFT快2-3倍。但在弯曲文本和密集文本场景下，CRAFT的F1值通常能高出10-15个百分点。选型建议：如果场景以水平文本为主，对速度要求高，选回归方案；如果场景中弯曲文本和密集文本占比超过20%，选CRAFT。

6.2 CRAFT vs 基于分割的方案

基于分割的方案（如PSENet、DB）在任意形状文本检测上表现很好，尤其是DB（Differentiable Binarization）在速度和精度上都很均衡。CRAFT相比DB的优势在于字符级建模带来的精确边界，劣势在于后处理更复杂、调参成本更高。选型建议：如果追求开箱即用和快速落地，DB可能更合适；如果对检测精度有极致要求，愿意花时间调参，CRAFT的上限更高。

6.3 CRAFT的适用边界

CRAFT不是万能的。它在以下场景中表现一般：极端长文本（超过100个字符的文本行）、字符间距极不均匀的文本、艺术字体和手写体（训练数据覆盖不足时）。如果你的场景主要是这些，可能需要考虑其他方案或者对CRAFT做针对性微调。

7. 工程化落地的经验总结

7.1 推理服务的性能优化

CRAFT的推理服务在生产环境中需要做性能优化。最有效的优化手段是模型量化和TensorRT加速。FP16量化能把推理速度提升30-40%，精度损失在1%以内。TensorRT加速能把速度再提升2-3倍，但需要把模型转换成ONNX再转TensorRT，转换过程中可能会遇到算子不支持的问题。

另一个优化方向是批处理。CRAFT的推理是逐张进行的，如果并发请求多，可以把多张图拼成一个batch一起推理。但要注意，不同尺寸的图需要padding到同一尺寸，padding太多会浪费计算资源。建议按尺寸分桶，同一桶内的图一起推理。

7.2 与识别模块的衔接

CRAFT的输出是文本框，后续通常接识别模块（如CRNN、Transformer-based识别器）。衔接时要注意两点：文本框的矫正和文本框的排序。

文本框矫正方面，对于任意四边形框，需要用透视变换把文本区域矫正成水平矩形，再送入识别模块。矫正后的尺寸要统一，通常高度设为32或48像素，宽度按比例缩放。

文本框排序方面，识别模块通常按从左到右、从上到下的顺序处理文本框。如果文本框顺序乱了，识别结果也会乱。排序算法可以用简单的行分组+行内排序，也可以用基于文本行方向的排序。

7.3 持续迭代的数据闭环

CRAFT上线后，需要建立数据闭环来持续提升效果。具体做法是：收集线上推理的bad case（漏检、误检、框不准的样本），人工标注后加入训练集，定期微调模型。这个闭环跑起来后，模型的效果会随着数据积累持续提升。

bad case的收集要有针对性。不要随机采样，而是按场景、按问题类型分层采样。比如，如果发现弯曲文本的漏检率高，就重点收集弯曲文本的bad case。每轮迭代解决一个主要问题，逐步提升整体效果。

实操心得：数据闭环的关键是标注效率。如果每轮迭代都要标注几千张图，成本太高。建议用主动学习的方式，让模型挑出“最不确定”的样本让人工标注，这样用最少的标注量获得最大的效果提升。

7.4 部署环境的注意事项

CRAFT的部署环境需要注意几点。GPU显存：推理时显存占用与输入分辨率成正比，1280×768的输入大约占2-3GB显存。如果并发请求多，需要做显存管理。CPU推理：CRAFT在CPU上推理很慢，单张图可能要1-2秒，不建议在生产环境用CPU。模型版本管理：微调后的模型要版本化管理，方便回滚和对比。

最后分享一个我在实际项目中总结的小技巧：CRAFT的推理结果可以用一个简单的置信度过滤来提升精确率。具体来说，对每个检测框，计算框内字符区域得分的平均值，如果平均值低于某个阈值（比如0.5），就认为这个框是误检，直接过滤掉。这个简单的后处理规则在我的项目中把误检率降低了30%左右，而且几乎不影响召回率。