2. 实验室数据特征与平台需求分析

实验室数据平台的第一道难关不是“存不下”，而是“看不懂、对不齐、用不起来”。同一个实验室里，液相色谱仪输出的是带时间戳的强度序列，电子天平输出的是单点数值，显微镜输出的是多通道图像，实验记录本里是半结构化文本，而 LIMS 里则是结构规整的样品与检测项记录。这些数据在采样频率、量纲、精度、生命周期和语义上差异极大，如果不在平台设计之初就完成特征梳理与需求提炼，后续的采集、存储、治理、分析和服务都会反复返工。

一、多模态数据的特征画像

从平台工程视角看，实验室数据可以按“结构形态 + 时间属性 + 体量级”三个维度建立画像。仪器数据通常分为两类：一类是时序信号，如色谱、光谱、电化学工作站输出的采样序列，特点是采样率高、单文件体积大、需要保留原始波形；另一类是结构化结果，如天平读数、pH 计读数、酶标仪孔板值，特点是字段固定、单条记录小、但批次数量多。实验记录以文本为主，包含实验目的、步骤、观察现象和结论，往往带有自由表述和缩写，需要保留原文并抽取关键字段。图像数据包括显微照片、凝胶电泳图、薄层色谱板照片，单张可达数十 MB，且常与样品编号、拍摄参数绑定。此外还有质谱峰列表、核磁谱图、流式细胞术的 FCS 文件等半结构化数据。

这些数据的共同特征是：来源异构、格式多样、时间戳不统一、元数据缺失严重。例如，某台高效液相色谱仪导出的 CSV 文件可能只有“Time, Signal”两列，样品信息却记录在纸质记录本上；而另一台仪器的输出文件头里已经嵌入了样品名、方法名和采集时间。平台必须能同时容纳“有元数据”和“无元数据”两种情况，并提供补录与关联机制。

二、从数据特征到平台需求的推导

特征梳理的目的不是做一份数据字典，而是把“数据长什么样”翻译成“平台必须做什么”。以时序信号为例，色谱数据通常以 10～100 Hz 采样，一次 30 分钟的运行会产生约 1.8 万到 18 万个数据点，若直接存入关系数据库的普通表，单次实验就会产生大量行记录，查询和聚合都会变慢。因此存储层需要区分：原始文件进对象存储，解析后的信号进时序数据库，样品与方法元数据进关系库。这不是技术选型偏好，而是由数据特征直接推导出的架构约束。

再以图像数据为例，一张 2048×2048 的 16 位显微图像约 8 MB，一个实验批次可能产生 200 张，合计 1.6 GB。平台如果只存缩略图，后续无法做定量分析；如果只存原图而不建索引，又无法按样品、时间、通道快速检索。因此治理层必须建立“图像—样品—实验—项目”的关联索引，并在采集时自动写入拍摄参数、通道信息和标尺。这些字段不是可选项，而是后续图像分析能否复现的前提。

文本记录的需求推导更微妙。实验记录中的“溶液略显浑浊”“反应 15 min 后颜色加深”这类描述，无法直接进入结构化查询，但它们是判断实验是否异常的重要依据。平台需要提供原文保留 + 关键字段抽取的双轨机制：原文以不可变对象存储，抽取出的“现象类型、时间点、严重程度”等字段进入结构化表，供检索和统计使用。抽取结果必须标注来源段落和置信度，避免把模型输出当成原始事实。

三、需求提炼的优先级与落地顺序

面对五类需求，平台建设不可能同时铺开。合理的优先级判断依据是：先解决“数据进得来、找得到”，再解决“算得准、用得好”。采集层和存储层是地基，治理层是承重墙，分析层和服务层是上层建筑。如果采集阶段没有统一样品编号，后续所有关联都是空谈；如果存储阶段没有保留原始文件，分析结果就无法回溯验证。

具体落地时，可以先从一条实验线切入。例如选择“高效液相色谱测定某化合物含量”这一条线，梳理其完整数据流：仪器导出 CSV → 采集程序读取并补录样品编号 → 原始 CSV 存入对象存储 → 解析后的时间-信号序列写入时序库 → 峰面积计算结果写入关系库 → 实验记录文本抽取关键条件 → 平台按样品编号聚合展示。这条线跑通后，再把模式复制到天平、酶标仪和显微镜。每接入一类新仪器，只需要新增对应的解析器和元数据映射规则，而不需要改动存储和治理的核心结构。

四、需求清单的字段化表达

为了让需求可验证、可验收，建议把每条需求写成“对象 + 条件 + 动作 + 结果”的形式。例如：

这种字段化表达的好处是：开发人员知道要做什么，测试人员知道怎么验，实验人员知道平台能帮自己解决什么问题。需求不再是“支持多模态数据”这样模糊的口号，而是可以逐条勾选、逐条验收的具体能力。

五、常见偏差与规避

需求分析阶段最容易出现的偏差有三种。第一种是只盯仪器、忽略记录，导致平台变成“仪器数据仓库”，实验过程中的判断依据反而丢失。第二种是追求一步到位的结构化，强行要求实验人员按固定模板填写记录，结果模板被绕过或填写质量下降。第三种是把分析需求前置，在采集和治理尚未稳定时就要求做智能预警，最终因为数据质量不可靠而无法落地。

规避方法并不复杂：在需求评审时，让实验人员带着一份真实的原始数据来，现场走一遍“从文件到可查询结果”的路径。凡是走不通的环节，就是需求遗漏或定义不清的地方。平台需求分析的终点不是一份文档，而是一条经过验证的最小数据链路。这条链路能跑通，后续的扩展才有可靠的基础。