报告派生弱标签，岩心裂缝分割的自动化训练方案

岩心裂缝分割弱标签语义分割

于 2026-08-30 03:52:03 修改

·本内容遵循CC 4.0 BY-SA版权协议

岩心裂缝分割这个任务，卡点通常不在模型，而在标签。岩心图像需要地质专业人员逐像素绘制 Mask，标注成本高、主观性强，很多工程单位积累了海量勘察报告和岩心照片，却缺少可用的逐像素标签。最近看到一篇专门解决这个问题的研究工作：Automated Borehole Core Analysis with Report-Derived Weak Labels and Supervised Crack Segmentation。

它的核心思路非常直接：把已有的岩心勘察报告文本作为弱标签来源，自动生成训练数据，再训练一个监督式裂缝分割模型。这样既不需要从零开始人工标注，又能把“报告文本、岩心图像、裂缝检测”串成一条自动化分析流水线，非常适合地质勘察、矿产勘探、岩土工程、基建检测等场景。

这篇博文会围绕这套方案做一次完整拆解：先讲核心能力和技术原理，再给出一套可落地的环境准备、训练推理流程、功能验证方法、接口与批量任务设计，最后补上常见问题排查和工程化建议。如果你正在做岩心图像分析、裂缝检测，或者想了解“如何用弱标签降低分割标注成本”，这篇文章可以收藏备用。

1. 核心能力速览

先给一张规格表，快速判断这套方案适不适合你的场景。

能力项	说明
项目类型	岩心图像自动分析 / 裂缝语义分割
核心任务	从岩心图像中分割出裂缝区域
输入数据	岩心钻孔图像 + 工程勘察报告文本
输出结果	逐像素裂缝掩码（Mask），可叠加可视化
关键技术	报告派生弱标签、监督式裂缝分割
标注成本	较低，主要依赖已有勘察报告，人工复核为主
推理硬件	常规 GPU 可覆盖，CPU 可跑小图推理
是否支持 API	可以封装为 HTTP 接口，按项目代码实现
是否支持批量任务	是，目录或队列式批量处理是典型落地形态
适合场景	地质勘察、矿产勘探、岩土工程、基建检测

从表格可以看出，这套方案的核心价值不是某个单一模型，而是“弱标签自动生成 + 裂缝分割模型训练”的组合流程。数据越规整、报告字段越标准，标签质量越高，分割模型的可用性也越强。

2. 项目原理与关键技术拆解

2.1 为什么岩心裂缝分割不好做

岩心图像分析在工程实践中很常见：钻探取芯后，需要判断岩体完整性、裂缝发育程度、风化程度，进而评估地基或矿体质量。传统方式是地质工程师肉眼观察岩心照片，在记录表上描述裂缝位置、宽度、延伸情况，再结合测井数据做综合判断。

这套流程有两个突出问题。

第一，人工看图和人工描述的效率很低。一个钻孔可能几十米岩心，每米拍若干张照片，逐张看、逐张写，费时费力。

第二，裂缝形态不规则，细小的微裂缝在图像上对比度低，不同岩性背景下的裂缝外观差异大。即便让专业人员做逐像素标注，不同人标出来的边界也会有明显差异。

这两个问题直接导致“有图像、有报告，就是没有高质量像素级标签”。而像素级标签恰恰是训练分割模型的必需品。

2.2 报告派生弱标签：Report-Derived Weak Labels

这套方案的核心创新，是用勘察报告文本生成弱标签，绕开大规模人工标注。

从标题中的 Report-Derived Weak Labels 来看，可以拆出四步通用流程。

第一步，报告解析。工程勘察报告通常包含钻孔编号、深度区间、岩性描述、裂缝发育情况、RQD（岩石质量指标）等字段。先把这些文本字段按钻孔、按深度区间结构化，形成“报告条目”。

第二步，信息抽取与对齐。报告中的“裂缝发育”“岩芯破碎”“节理密集”等描述，要和对应的岩心图像区间做空间对齐。对齐规则一般依赖深度区间：如果报告描述的是 10.2 米到 10.8 米这一段，那就取这个深度区间对应的岩心照片作为候选样本。

第三步，弱标签生成。文本描述本身不是像素级标签，需要转化为图像级或区域级提示。最常见的做法是：报告标注“该区间裂缝发育”的图像，整张图或图中区域标记为“包含裂缝”；报告标注“岩芯完整”的图像，标记为“不包含裂缝”。这种标签粒度比较粗，所以叫弱标签。

第四步，标签清洗与校正。弱标签必然包含噪声，比如文本和图像深度对不齐、照片拼接误差、描述颗粒度太粗等。需要设计清洗规则，例如：去除模糊图像，删除与描述明显矛盾的样本，用形态学处理剔除太小的连通域，再结合少量人工抽检修正错误标签。

从论文思路看，这一步是整个流程质量的关键。弱标签不是简单粗暴地把文本转成 Mask，而是要让“报告内容”和“图像内容”尽可能对齐，否则后续监督训练会被错误标签带偏。

2.3 监督式裂缝分割：Supervised Crack Segmentation

报告派生弱标签生成之后，进入监督式裂缝分割的训练环节。

裂缝分割本质上是一个二分类语义分割任务：每个像素预测属于裂缝还是背景。常用的实现方案是编码器-解码器结构，编码器负责提取图像特征，解码器负责恢复分辨率并输出逐像素概率图。

从工程角度，这类任务可以选择的网络结构包括：

UNet 及变体：结构简单、显存友好，适合中小规模数据集
DeepLab 系列：空洞卷积扩大感受野，对大裂缝和长条裂缝更友好
基于 Transformer 的分割模型：效果好，但对数据量和显存要求更高

训练细节上，需要重点关注四点。

一是损失函数。裂缝像素通常只占整张图像的很小比例，正负样本严重不均衡。除了标准交叉熵损失，可以考虑 Dice Loss、Focal Loss 或组合损失，避免模型把所有像素都预测为背景。

二是数据增强。岩心图像包含不同岩性、不同光照、不同湿度条件。随机裁剪、旋转、翻转、颜色抖动、亮度对比度调整，都能提升泛化能力。

三是后处理。模型输出的概率图需要经过阈值化、连通域分析、开闭运算等操作，去掉孤立噪点和细小伪影，得到平滑的裂缝掩码。

四是评估。建议使用 mIoU、Dice Score、Precision、Recall 作为核心指标。工程场景经常要额外关注 Recall，因为漏掉一条裂缝可能比多分割一小块背景更严重。

2.4 两阶段流程判断

从标题里的“and”可以看出，这套方案是两阶段组合：先基于报告生成弱标签，再用弱标签训练监督分割模型。

这个设计有一个明显好处：一旦弱标签生成流程跑通，新的钻孔数据只要附带报告，就能自动产生训练样本，模型可以持续迭代。相比一次性人工标注数据集，这种方式更适合工程单位的数据积累节奏。

但也要注意一个边界：弱标签始终是近似标签。如果报告本身描述不准确，或者照片和报告深度区间对不上，那么后续模型的上限也会受限。因此，“报告驱动生成标签 + 少量人工复核修正”比纯自动流程更稳妥。

3. 适用场景与使用边界

3.1 适合谁

这套方案最适合有历史数据积累的单位：已经保存了大量岩心照片和勘察报告文本，但缺少像素级标注。通过报告派生弱标签，能把历史数据转化为模型训练资源。

典型场景包括：

地质勘察院、岩土工程公司：批量归档钻孔岩心照片，建立岩体质量快速筛查能力
矿产勘探项目：辅助判断矿体周围岩体完整性，优先筛选裂缝发育区段
检测机构：对已有工程影像做二次分析，补充定量裂缝统计结果

3.2 不适合什么

如果项目数据量很少，或者根本没有标准化勘察报告，直接套用弱标签流程并不划算。这种情况下，花时间做几百张高质量人工标注，再训练一个小模型，效果可能更好。

另外，如果目标不是岩心图像，而是路面裂缝、混凝土桥梁裂缝、隧道衬砌裂缝，这套方法可以参考，但需要重新适配图像采集条件和标签规则。不同场景的裂缝形态差异很大，不能指望一个模型通吃。

3.3 数据与合规边界

岩心照片和勘察报告通常属于工程数据，可能涉及项目保密要求。使用这些数据时需要注意：

训练数据必须获得数据所有者授权
对外发布模型、演示材料时要脱敏处理
涉及人脸、车辆、定位信息等非目标内容时，先做区域遮挡
自动分析结果用于工程决策前，必须经过专业人员复核

这个原则也适用于后续的 API 部署和批量分析，权限与隐私控制不能省。

4. 环境准备与前置条件

4.1 硬件环境

裂缝分割属于图像分割任务，深度学习框架需要消耗显存。推荐优先使用 NVIDIA GPU 环境，训练阶段 8GB 以上显存会更从容，推理阶段 4GB 到 6GB 也可以跑。

CPU 环境可以跑小图推理，但批量场景会很吃力。如果只是验证流程，CPU 足够了；如果要处理成百上千张岩心照片，建议准备 GPU。

更稳妥的判断是：显存占用取决于模型结构、图像分辨率、批大小。实际以本机测试为准，不要盲目相信某个固定数值。

4.2 软件依赖

这是一套典型的 Python + PyTorch 项目，核心依赖如下：

依赖库	用途
Python	基础运行环境，建议 3.8 及以上
PyTorch	深度学习训练与推理框架
torchvision	图像变换、预训练模型
OpenCV	图像读取、形态学处理
Pillow	图像格式兼容
NumPy	数组与掩码计算
tqdm	训练与批处理进度条
FastAPI / Flask	可选，封装 API 服务

建议使用 conda 或 venv 建一个独立环境，避免依赖冲突。

BASH

conda create -n borehole python=3.8 -y

conda activate borehole

pip install torch torchvision opencv-python pillow numpy tqdm

# API 服务按需安装

pip install fastapi uvicorn

4.3 数据准备

建议建立如下目录结构，方便训练、评估和批处理：

BASH

data/

├── images/ # 原始岩心图像

├── reports/ # 勘察报告文本或解析后的结构化字段

├── masks/ # 人工或弱标签生成的掩码

├── output/ # 预测结果

└── splits/ # 训练/验证/测试划分

图像和报告的深度区间要能对应起来。如果报告是 PDF，需要先做文本抽取；如果是数据库字段，直接导出结构化表格即可。

4.4 验证环境清单

检查项	检查内容
GPU 驱动	nvidia-smi 能看到显卡
CUDA 可用	torch.cuda.is_available() 返回 True
Python 版本	python --version
依赖安装	pip list 确认关键库存在
数据目录	路径存在且有读写权限
端口空闲	如果起 API，确认端口未被占用

5. 从论文到可运行流程

5.1 官方仓库与复现策略

如果论文公开了代码，直接按仓库 README 操作是最快路径。下载代码后重点看三块：数据预处理脚本、弱标签生成脚本、训练配置。

如果暂时没有官方代码，可以按下面的通用流程自己复现。整体思路分四步：数据预处理、弱标签生成、模型训练、推理评估。

5.2 弱标签生成示例

下面是一个通用的弱标签生成思路示例，按“报告字段 + 深度区间标记”生成二值掩码。实际操作时，需要根据报告字段名称做调整。

PYTHON

import cv2

import numpy as np

import json

def generate_weak_mask(image_path, report_item, image_depth_interval):

"""

根据报告描述生成弱标签掩码。

这里只做区域级标记：区间内若有裂缝描述，整图标记为包含裂缝。

更精细的做法需要结合图像局部特征做像素级生成。

"""

image = cv2.imread(image_path)

h, w = image.shape[:2]

mask = np.zeros((h, w), dtype=np.uint8)

desc = report_item.get("description", "")

crack_keywords = ["裂缝", "发育", "破碎", "节理", "裂隙"]

flag = 0

for kw in crack_keywords:

if kw in desc:

flag = 1

break

if flag:

# 弱标签：区域全标记为裂缝，后期可用形态学清洗

mask[:] = 255

return mask

report_item = {"depth_from": 10.2, "depth_to": 10.8, "description": "岩芯破碎，裂缝发育"}

mask = generate_weak_mask("data/images/core_10.2_10.8.jpg", report_item, None)

cv2.imwrite("data/masks/core_10.2_10.8.png", mask)

这个示例只是为了说明弱标签的最小逻辑。真实场景中建议在生成掩码后增加清洗步骤：去掉边缘小块、过滤模糊图像、与相邻区间做一致性检查。

5.3 模型训练模板

训练阶段可以直接采用 PyTorch 的标准分割训练模板。下面给出一个最小可运行的训练框架。

PYTHON

import torch

import torch.nn as nn

from torch.utils.data import Dataset, DataLoader

class CrackDataset(Dataset):

def __init__(self, image_paths, mask_paths, transform=None):

self.image_paths = image_paths

self.mask_paths = mask_paths

self.transform = transform

def __len__(self):

return len(self.image_paths)

def __getitem__(self, idx):

import cv2

image = cv2.imread(self.image_paths[idx])

image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB)

mask = cv2.imread(self.mask_paths[idx], cv2.IMREAD_GRAYSCALE)

image = torch.from_numpy(image).permute(2, 0, 1).float() / 255.0

mask = torch.from_numpy(mask).float().unsqueeze(0) / 255.0

return image, mask

class SimpleUNet(nn.Module):

def __init__(self):

super().__init__()

# 这里仅为结构占位，实际应替换为完整 UNet 或预训练分割模型

self.encoder = nn.Sequential(

nn.Conv2d(3, 32, 3, padding=1), nn.ReLU(),

nn.MaxPool2d(2)

)

self.decoder = nn.Sequential(

nn.Conv2d(32, 32, 3, padding=1), nn.ReLU(),

nn.ConvTranspose2d(32, 1, kernel_size=2, stride=2)

)

def forward(self, x):

return self.decoder(self.encoder(x))

model = SimpleUNet()

criterion = nn.BCEWithLogitsLoss()

optimizer = torch.optim.Adam(model.parameters(), lr=1e-3)

实际训练时，建议使用预训练编码器，并加入 Dice Loss 处理类别不平衡。日志里要记录 loss、mIoU、Dice 等指标，方便判断收敛状态。

5.4 推理与可视化

训练完成后，推理阶段需要加载权重，输出概率图，再转成二值掩码。

PYTHON

import cv2

import torch

import numpy as np

def predict(model, image_path, device="cuda"):

model.eval()

image = cv2.imread(image_path)

image_rgb = cv2.cvtColor(image, cv2.COLOR_BGR2RGB)

input_tensor = torch.from_numpy(image_rgb).permute(2, 0, 1).unsqueeze(0).float() / 255.0

input_tensor = input_tensor.to(device)

with torch.no_grad():

prob = torch.sigmoid(model(input_tensor)).squeeze().cpu().numpy()

mask = (prob > 0.5).astype(np.uint8) * 255

return mask, prob

mask, prob = predict(model, "data/images/core_10.2_10.8.jpg")

cv2.imwrite("data/output/core_10.2_10.8_pred.png", mask)

输出掩码之后，可以在原图上叠加红色半透明 Mask，直观展示裂缝位置，方便人工复核。

6. 功能测试与效果验证

6.1 弱标签质量验证

测试目标：确认报告文本生成的弱标签是否和图像内容基本一致。

操作步骤：

随机抽 20 条报告记录
逐条生成弱标签掩码
将掩码叠加到原图上
人工检查裂缝区域是否落在掩码范围内

判断标准：超过 70% 的样本中，肉眼可见的裂缝主体区域被弱标签覆盖。如果命中率过低，先检查深度对齐逻辑，再检查报告描述关键词是否覆盖充分。

常见问题：报告写的是“岩芯较完整”，但照片里局部有碎块，导致弱标签漏标。这种噪声只能通过迭代清洗减少。

6.2 裂缝分割效果验证

测试目标：验证模型能否准确分割出裂缝区域。

建议准备 50 到 100 张人工精标注图像作为评测集，计算 mIoU、Dice、Precision、Recall。

PYTHON

# 用 python 计算指标示例

def compute_dice(pred_mask, gt_mask):

pred = pred_mask > 0.5

gt = gt_mask > 0.5

intersection = (pred & gt).sum()

dice = 2 * intersection / (pred.sum() + gt.sum() + 1e-6)

return dice

# 遍历测试集计算平均 Dice

操作步骤：

准备测试集图像和真实掩码
批量推理得到预测掩码
计算 mIoU 和 Dice
随机输出 10 组可视化图，人工检查边界质量

判断标准：mIoU 达到 0.5 以上，且关键裂缝没有被遗漏，说明模型可用。工程场景下，如果漏检明显，优先调低阈值提高召回率。

6.3 批量任务测试

测试目标：确认批量分析岩心照片时流程是否稳定。

建议准备一个包含 100 张图像的目录，按顺序批量预测，记录成功率、单图耗时、显存占用峰值。

PYTHON

import os

import cv2

import traceback

input_dir = "data/images_test"

output_dir = "data/output_test"

os.makedirs(output_dir, exist_ok=True)

failed = []

for img_name in os.listdir(input_dir):

if not img_name.lower().endswith((".jpg", ".png", ".jpeg")):

continue

try:

img_path = os.path.join(input_dir, img_name)

mask, prob = predict(model, img_path)

cv2.imwrite(os.path.join(output_dir, img_name.replace(".jpg", "_mask.png")), mask)

except Exception as e:

failed.append({"image": img_name, "error": str(e)})

traceback.print_exc()

print("失败数量：", len(failed))

print("成功数量：", len(os.listdir(input_dir)) - len(failed))

批量任务必须打印失败日志并保留失败原因，不能静默跳过。

6.4 失败场景分析

以下情况基本必然出现：

照片过暗、过曝，裂缝不可辨
图像拼接处出现错位，深度区间和图像实际范围不一致
报告描述只写了“局部破碎”，没有对应像素区域
岩性过于复杂，模型把矿物纹理误识别为裂缝

出现这些问题时，不要急着调模型，先检查数据质量。质量差的数据，再好的模型也救不回来。

7. 接口 API 与批量任务

7.1 为什么要把分割模型封装成 API

岩心裂缝分割很少是单机离线工具，更多时候需要接入内部管理系统或数据平台。封装成 API 后，前端上传照片，后端返回裂缝掩码和统计指标，其他系统也可以直接调用，不需要关心模型推理细节。

7.2 FastAPI 服务示例

下面给出一套通用的模型推理 API 模板。具体字段需要按实际项目修改。

PYTHON

from fastapi import FastAPI, UploadFile, File

from PIL import Image

import io

import base64

import cv2

import numpy as np

import torch

app = FastAPI()

device = "cuda" if torch.cuda.is_available() else "cpu"

# 假设 model 已在别处加载

# model = load_your_model()

# model.to(device)

# model.eval()

def process_image(image_bytes):

img = Image.open(io.BytesIO(image_bytes)).convert("RGB")

img = np.array(img)

# 这里需要接入实际推理代码

# mask, prob = predict(model, img)

mask = np.zeros(img.shape[:2], dtype=np.uint8) # 占位

return mask

@app.post("/api/segment")

async def segment_image(file: UploadFile = File(...)):

image_bytes = await file.read()

mask = process_image(image_bytes)

_, encoded = cv2.imencode(".png", mask)

return {

"status": "ok",

"mask_base64": base64.b64encode(encoded.tobytes()).decode("utf-8")

}

@app.get("/health")

async def health():

return {"status": "alive"}

启动服务：

BASH

uvicorn app:app --host 127.0.0.1 --port 8000

调用示例：

PYTHON

import requests

url = "http://127.0.0.1:8000/api/segment"

files = {"file": open("data/images/core_test.jpg", "rb")}

response = requests.post(url, files=files, timeout=30)

data = response.json()

print(data["status"])

需要提醒的是，上面的示例中模型部分只是占位。实际部署时把训练好的模型加载进来，替换 process_image 中的推理逻辑即可。

7.3 批量任务实现

批量任务有两种实现方式。

同步批处理：脚本遍历目录，逐张调用模型或直接调用内部函数，适合中小规模数据。这种方式实现简单，但处理大量数据时无法实时查看进度。

队列异步处理：使用 Celery、Redis Queue 或简单的线程池，把图像路径放入队列，后台线程消费任务，结果写回输出目录。适合大规模数据处理。

批量处理建议加入以下机制：

每处理完一张记录一条日志，包括文件路径、耗时、是否成功
失败任务单独存放，不阻塞后续任务
输出结果按输入目录结构保存，方便对齐原始数据

JSON

{

"input_dir": "./data/images",

"output_dir": "./data/results",

"model_type": "unet_resnet50",

"threshold": 0.5,

"save_overlay": true,

"batch_size": 1

}

8. 资源占用与性能观察

8.1 显存占用观察方法

训练和推理时，最直接的方式是用 nvidia-smi 查看显存占用。

BASH

nvidia-smi

可以加个循环，每隔两秒刷新一次，观察峰值显存。

BASH

watch -n 2 nvidia-smi

如果服务容器化，也可以用 docker stats 查看容器内 GPU 使用情况。观察重点是峰值显存和长期稳定值，防止训练过程中显存持续上涨导致 OOM。

8.2 分辨率、批大小对性能的影响

性能影响可以这样理解：

图像分辨率越高，显存占用和耗时线性上升
批大小越大，吞吐量越高，但显存风险也越大
模型编码器越深，准确率可能越好，但推理速度越慢

工程上建议先用小分辨率试跑完整流程，再逐步提升到目标分辨率。比如先 512×512 验证流程，再尝试 1024×1024。

8.3 降低显存占用和加速推理的方法

如果显存不足，按顺序尝试下面这些手段：

降低输入图像分辨率
减小批大小到 1
使用混合精度训练（AMP）
推理时使用半精度（FP16）或量化
避免在推理过程中保存过多中间张量
使用 torch.no_grad() 关闭梯度计算

PYTHON

# 混合精度训练示例

from torch.cuda.amp import autocast, GradScaler

scaler = GradScaler()

for images, masks in dataloader:

optimizer.zero_grad()

with autocast():

outputs = model(images)

loss = criterion(outputs, masks)

scaler.scale(loss).backward()

scaler.step(optimizer)

scaler.update()

如果换了优化手段后发现结果明显变差，先检查是否关闭了数据增强、学习率是否合适，再考虑是否有必要恢复全精度。

9. 常见问题与排查方法

问题现象	可能原因	排查方式	解决方案
训练时显存不足	分辨率或批大小过大	nvidia-smi 查看显存	降低分辨率、减小 batch_size、使用 AMP
模型不收敛	学习率过高或数据标签噪声大	观察 loss 曲线	降低学习率、清洗弱标签
裂缝漏检严重	阈值过高或裂缝像素占比太低	检查概率图和 Recall	降低阈值、改用 Dice Loss
弱标签和图像不对应	深度区间解析错误	抽查报告与图像区间	修正对齐逻辑，增加人工复核
批量任务中途卡住	内存不足或数据读取异常	查看日志和进程状态	单线程切换多线程，加异常重试
API 调用超时	推理耗时过长或并发过高	查看服务端日志	增加超时时间、限制并发、换 GPU
CPU 推理极慢	无 GPU 或模型过大	测量单张耗时	缩小模型、降分辨率、换 GPU
结果掩码有很多孤立噪点	后处理不够	查看掩码连通域情况	增加开运算和连通域面积过滤

10. 最佳实践与使用建议

10.1 从最小可运行配置开始

第一次跑通流程不要追求高精度。先拿少量数据，把“报告解析、弱标签生成、模型训练、批量推理、结果可视化”这条链路走通，确认每个环节都能正常输入输出，再逐步扩大数据规模。

保存一份最小可运行配置，包括数据样例、模型配置、启动命令。这样以后换机器或换环境，可以快速恢复开发状态。

10.2 目录与文件管理要严格

岩心数据量一大，路径规划混乱会浪费大量时间。建议按钻孔编号、深度区间作为文件名前缀，例如 core_10.2_10.8.jpg，掩码文件保持一一对应。输出目录区分临时结果和最终结果，避免混用。

10.3 批量任务必须加日志和重试

批量处理的代码一定要记录每张图的处理时间、成功失败状态、失败原因。不要用 print 简单输出，建议写入日志文件。失败任务要能单独重新执行，避免整个批处理重跑。

10.4 接口服务要控制访问范围

API 服务默认只监听 127.0.0.1，不要直接暴露到公网。如果需要在内部网络使用，要加鉴权，并限制上传文件大小和请求频率。

BASH

# 安全启动方式：仅本地监听

uvicorn app:app --host 127.0.0.1 --port 8000

10.5 工程决策必须有人工复核

自动分割得到的裂缝统计可以作为辅助参考，但在工程报告、安全评估、设计决策中，必须由专业地质工程师审核。这也是使用这套工具时最重要的边界。

11. 总结与下一步

这套方案最值得尝试的点，是把“勘察报告文本”和“岩心图像分割”打通，用弱标签替代大规模人工标注，降低了裂缝检测从零起步的成本。结合批量分析流程和 API 封装，可以直接嵌入现有的数据管理系统，形成自动化分析能力。

如果你想快速验证，优先做两件事：第一，准备 100 张左右带报告的岩心照片，跑通弱标签生成流程；第二，用这些弱标签训练一个基础分割模型，看 mIoU 和可视化效果是否达到可用水平。最容易踩的坑是报告和图像深度区间对不上，这个环节要花时间做清洗和复核。

后续可以扩展的方向包括：把岩性分类、RQD 估算、裂缝宽度测量融进同一套流程；引入主动学习，让人工复核集中在模型最不确定的样本上；把批量分析做成定时任务，自动处理每天新增的岩心数据。别急着一步到位，先把弱标签和分割模型跑稳定，再逐步加功能。