AI成为科学基础设施：从数据到模型服务化的工程实践

创世纪计划第一阶段把278个项目放在同一个命题下讨论，给人印象最深的不是某个模型得分，而是这句话：人工智能正走向科学基础设施。过去我们更习惯把AI看作论文里的算法模块、实验完成后的数据分析工具，现在的问题是，它能不能像数据库、服务器和实验记录本一样，成为科研团队随时调用的底层能力。这篇文章想聊的不是项目宣传口径，而是作为长期做AI工程落地的人，我会怎么理解这轮变化，以及一个团队如果想跟上节奏，应该先做什么。

适合两类人看：一类在高校或研究所负责算法平台建设，另一类在行业团队里想用AI处理实验数据、材料筛选、分子设计、文献推理或者仪器控制。最值得关注的不只是“谁跑出了更高精度”，而是“哪些数据、流程、算力和评估规范被沉淀了下来”。一个AI能力能不能变成基础设施，看的不是模型体积，而是它能否被稳定复现、批量调用和平滑接入现有科研流程。

1. 为什么说AI正在变成科学基础设施，而不是高级插件

1.1 科学AI和通用AI的关键差异

科学AI处理的问题往往有明确物理或化学背景，比如预测材料带隙、估计分子溶解度、从显微镜图像里识别结构、根据历史气象场推演未来云图。这些问题和通用聊天、内容生成不一样：输出必须可以被实验验证，误差需要有边界，预测结果还要能解释到底依赖哪些特征。

通用AI偶尔说错一句，最多影响体验；科学AI如果给了一个错误结论，可能影响一个实验方向，甚至让团队投入很长时间去验证一个不存在的规律。所以科学AI的基础设施化，首先不是堆大模型，而是把“可验证”“可重复”“可追溯”这几个词作为底线。

278个项目如果覆盖了材料、生命、能源、环境等不同领域，它们看起来方向各异，但落到工程层会遇到很多共同问题：数据格式不统一、实验记录不规范、训练脚本不可复现、结果无法对比。只要这些问题没有解决，科学AI就始终停留在“实验室里的个别Demo”阶段，没有办法扩大成平台能力。

1.2 从单点工具到基础设施要跨过的三个门槛

第一个门槛是确定性。同一条命令、同一份输入，换一台机器或重启一次之后，结果应该保持一致。很多项目训练模型时回传的指标跳来跳去，经常不是模型本身有问题，而是随机种子、数据加载顺序、依赖版本、GPU型号在引入波动。

第二个门槛是接口化。一个工具如果只能通过某个人的notebook调用，那它只是个人脚本；如果能让课题组里的其他人通过一个稳定接口提交数据并拿到结果，它才具备基础设施的雏形。接口不需要多复杂，关键是稳定。

第三个门槛是沉淀。数据集、预处理逻辑、训练好的模型、评估报告、失败日志，这些资产要按约定存放和登记。否则做一个新课题时，前面项目的成果无法复用，每个项目都从零开始，所谓基础设施也就名存实亡。

1.3 第一批建设者最应该盯住什么

我会盯住基线、可重复实验和失败记录。

基线非常重要。不管项目用多强的模型，都要先有一个简单基线作为参照。比如表格预测问题可以先跑一个梯度提升树，图像分类问题可以先跑一个训练充分的小网络。AI模型如果连简单基线都打不过，要么是数据有问题，要么是任务定义不合理，这时候继续调深度模型是在浪费算力。

可重复实验意味着代码、数据版本、运行环境三者能完整还原。共享目录里只有一份别人传上来的final_v2.py是不够的，这个脚本依赖哪个Python版本、哪几个库、什么数据子集，都要能查得到。

失败记录经常被忽略。278个项目背后，大概率有大量折返和失败。能够把失败原因、参数范围、问题现象保留下来，对一个平台长期演进的价值不亚于成功案例。

2. 落地科学AI平台，先解决数据、环境和算力，别急着调模型

2.1 数据准备：先统一命名、格式和元信息

我见过太多科学项目是从一个压缩包开始的。压缩包里可能有20个PDF、3个Excel表格、若干张命名不统一的图片，再加上一段只有原始实验者能看懂的字段说明。这种数据直接丢给大模型或者训练脚本，能跑出结果也是碰运气。

比较务实的做法是先定义一套数据接入规范。目录名、文件名建议使用英文小写加下划线，避免空格和中文；文件格式尽量统一，比如表格统一成CSV或Parquet，图像统一成标准格式；每条数据尽量有唯一编号。

还要维护一份元信息文件。简单场景用YAML就够：

dataset_name: demo_material version: 0.1.0 file_format: csv num_samples: 1000 columns: - composition - temperature - target_property missing_value_strategy: drop

这份文件解决的是“这个数据集到底是什么意思”的问题。后续做训练、做评估、做对比，都需要先把数据版本固定下来。科学数据可能涉及个人隐私或机构保密数据，使用前必须完成脱敏和合规审查，不能因为数据量小就跳过。

2.2 环境隔离和依赖锁定

科学AI环境崩溃，很大比例不是模型代码写得不对，而是依赖链不一致。今天装一个包，可能把另一个包的版本改掉；明天换一台服务器，CUDA版本和机器学习框架版本对不上，模型加载直接失败。

建议每个项目开始时都先建一个干净环境。命令行操作习惯用conda或者venv都行，关键是把依赖锁定。项目根目录里至少保留一份明确的依赖清单，如果团队成员主要用Python，可以先记录主要依赖以及已经冻结好的锁文件。可以确认一下PyTorch或TensorFlow在requirements-lock.txt里的版本是否和当前环境一致，同时用nvidia-smi和框架自带的版本查看命令确认GPU驱动、CUDA版本。

这一步看起来麻烦，但它能省掉后面几天排查环境的时间。推理阶段尤其如此：训练好的模型一旦跨机器部署，环境不一致往往导致精度波动，而这并不是模型权重的问题。

2.3 算力规划：先估算资源，再开集群

很多人拿到科学AI平台第一个想法是：我有几百个GPU卡，是不是就能放开训练了。实际上，算力规划要先回答几个问题：模型大概多大、训练数据有多少条、单条样本送到模型里是短文本、图表还是三维结构、预估任务数是多少。

显存不够时的第一反应不应该是不停换更大卡，而是降batch size、降低分辨率、缩短序列长度，或者把不需要保存梯度的推理过程放到纯推理模式。分布式训练也不是越多卡越好，小模型在数据传输和同步上的开销可能比收益还大。

低配置机器也能做科学AI测试，但要把任务规模和并发数降下来。先跑单条任务，确认显存占用和时间指标；再逐步增加样本数量，看内存和磁盘IO有没有成为瓶颈。如果只是验证想法，默认参数通常够用；如果要批量跑实验，就要提前设计任务的调度顺序和资源配额。

3. 从能跑通到能复用：一条更符合真实团队的落地路径

3.1 先用最小案例跑通全链路

我强烈建议不要从一开始就上完整数据集或几百个并发任务。先选一个小规模数据集，把“读取数据—预处理—模型推理或训练—输出结果—保存日志”这条链路完整跑一遍。

跑通之后记录几个关键信息：输入文件的字段、模型的加载方式、运行一次花了多长时间、显存和内存占用是多少、输出文件长什么样。这些记录会成为后续批量任务的重要对照。

这个阶段不需要把代码写得特别优雅。目标只有一个：让全链路被环境和代码完整复现一遍。Notebook能跑通这个链路，这是起点，但它不能替代脚本化和服务化。因为notebook里的单元格执行顺序不是显式管理的，换个人操作可能漏跑一步，最终结果根本对不上。

3.2 把训练、推理、评估拆成独立模块

在项目还不大的时候，就要避免把训练和推理揉在同一个文件里。否则为了验证一个新模型，每次都要重新走一遍训练逻辑，流程非常脆弱。

比较常见的结构是把工作分为几个阶段：

• preprocess：处理原始数据，输出干净的中间数据或特征。
• train：读取已预处理的数据，训练模型并保存权重。
• infer：加载训练好的权重，对新的输入进行推理。
• evaluate：计算评估指标，生成报告。

每个阶段只通过明确的输入输出路径衔接。一个统一配置文件的示例可以是这样：

{ "task_id": "exp_001", "dataset": "input/demo_material.csv", "model_endpoint": "http://127.0.0.1:8000/v1/run", "batch_size": 32, "output_dir": "outputs/exp_001" }

这样做的原因是：你可以在不改变主流程的情况下替换某个模块。今天用A模型，明天换B模型，只需要改配置里的模型名或服务地址；预处理、评估、日志都不用大改。

3.3 用任务队列处理批量实验，而不是用循环硬跑

当样本从几十变成几千，或者团队需要一次性提交几百个独立实验时，不能在单个脚本里写一个大循环了。原因是只要中间某一条数据出错，整个任务都需要从头再来；而且也不知道现在跑到第几个、哪些任务失败、哪些任务成功。

更稳妥的做法是给任务一个唯一ID，按照任务粒度去管理。每个任务执行时，在输出目录下生成统一状态文件。例如：

• running：正在执行。
• success：任务完成，输出文件完整。
• failed：任务出错，错误信息可查。
• skipped：因某些条件不成立而跳过。

对普通科研团队来说，一开始没必要引入特别复杂的任务调度系统。可以先在一个SQLite数据库里记录任务状态，脚本启动时读取待处理任务列表，执行完成后更新状态。当任务量和协作人数继续增加，再考虑接入成熟的任务队列和调度平台。

3.4 评估和监控要落到具体指标

科学AI的系统评估不能只看一个测试集准确率。我更习惯把几个层面的指标同时记录下来：

如果输出结果不稳定，先确认环境版本、随机种子和输入顺序，再判断是不是模型本身存在随机性。如果批量任务里频繁出现输出文件为空，先检查输入数据和权限，不要急着重新训练模型。

4. 科学AI里的Agent能做什么，哪些节点必须人工确认

4.1 Agent适合三类科学任务

AI Agent在大规模科学项目里最早落地的方向，通常不是直接把实验全自动化，而是把科研人员从重复性劳动中解放出来。

一类是文献和知识的自动整理。给Agent一个研究主题，让它从指定的文献库或内部知识库中检索、抽取研究对象、实验方法和数据，并形成结构化表格。很多团队把这类能力用在前期的调研上，确实能节省不少时间。

另一类是跨工具调用的参数搜索。Agent可以阅读任务说明，调用数据处理脚本、调模型接口，改变参数后再看结果，完成一个小闭环。比如材料性质预测中，可以让Agent遍历候选配方，调用预测服务返回结果并排序。

第三类是实验过程的辅助监控。多个实验同时运行时，Agent定时检查日志、识别异常指标、生成简短的进展摘要。它并不直接控制实验设备，但能减少人在屏幕前盯日志的时间。

这些场景对效率和协作都有意义，但也必须接受一个判断：Agent能做的是“辅助决策”，不是替代科学家做最终判断。尤其在实验设计、材料合成、药物筛选这类高风险场景，模型建议必须经过专业人员复核。

4.2 Agent的工程边界：上下文长度、工具权限和状态一致性

Agent最常见的坑是以为它能无限记住上下文。实际使用中，上下文越长，模型越容易忽略关键信息，也越容易把很早之前的内容理解错。更稳妥的做法是让Agent去检索需要的知识片段，而不是把整篇实验手册塞进一轮对话。

工具调用也必须有白名单。不要让Agent在任意目录里执行任意脚本，也不要给它直接的数据库删除权限。内部科学平台里的Agent，应当只能调用预先封装好的只读查询、模型推理、文件上传等接口。这个限制不是为了降低能力，而是为了保证实验结果可追溯、权限边界清晰。

状态一致性是另一个容易被忽略的问题。Agent在多个步骤之间如果依赖某个“中间结论”，这些结论必须来自真实的函数返回值，而不是它自己推测的内容。我在实际项目中见过Agent直接假设上一步产生了某个文件，结果后面所有分析都建立在一个不存在的结果上。根治方式很简单：每一步执行后都显式检查返回状态，一旦异常就中止任务。

4.3 保留人工确认的关键节点

哪些节点必须保留人工确认？我的判断是要看错误影响范围。文档整理错了可以立刻改，但涉及以下情况不能全自动：

• 实验参数会被同步到实际设备。
• 生成的分子或材料配方会进入湿实验。
• 涉及人体、动物或临床相关的结果。
• 结论要对外发布，或者形成内部正式报告。
• 项目资金和排期需要依据Agent建议做决策。

这些节点上，系统要输出完整的日志，包括模型给了什么建议、采取了什么行动、谁在什么时间做了确认。把审批和审计功能做进去，不是官僚主义，而是科学AI基础设施的基本要求。自动化和可控并不矛盾，真正决定效率的，是没有污染和误操作让后期返工。

4.4 AI编程和AI测试是回报最快的落地场景

如果目前还没有办法把一个完整的科学Agent做得足够可靠，我建议先同时铺开AI辅助编程和AI辅助测试。这不是绕路，而是在积累工程底座。

AI编程尤其适合数据处理代码、图表绘制、接口调用和错误修复这一类任务。它们有比较明确的输入输出结构，错误也容易复现。传统脚本来回改可能半小时，用AI助手先生成骨架，再人工补齐领域逻辑，往往几分钟就能跑通第一版。

但我一般会提醒团队：AI生成的代码也要进代码审查和自动化测试，不能因为生成速度很快就直接合并。可以要求生成代码必须附带简单的单元测试，至少覆盖正常输入和一个异常输入。这样既能提高效率，又不会因为代码质量问题给后续科学计算留下隐患。

5. 模型服务化、选型与高频问题排查链路

5.1 开源模型还是云API：不是二选一，而是按场景分层

科学AI平台建设早期，最容易被问住的问题之一就是“用开源模型自己部署，还是直接调用云API”。这个问题的答案通常不是非黑即白，要看数据能不能出域、团队有没有GPU运维能力、任务对延迟和成本有多敏感。

从数据隐私角度看，很多实验数据在正式发表前不能离开机构环境，这时本地部署或私有化可能是更稳妥的选择。如果只是对公开文献做粗筛，回调云API的初期测试成本更低，也更方便做不同模型能力对比。

我的建议是先做小规模POC，把数据放在模拟环境里，分别测一遍效果和成本；不要因为某一类模型宣传得好就一步到位大规模部署。

5.2 把模型服务化，接口比内部实现更重要

模型一旦面向多个课题组提供服务，别人并不关心你是用PyTorch还是TensorFlow写的，关心的是：请求格式是什么、返回结果长什么样、出错时会不会给出可读的错误信息、接口超时了怎么办。

所以在工程化阶段，我会先定义一套最小接口规范。调用方传入必要的输入和任务参数，服务端返回状态码、结果或错误原因。推理服务不能是“调了很久不返回，也不知道是不是挂了”。要有超时设置和明确的重试策略。

对科研场景来说，单次请求的响应时间不一定需要像互联网业务那样毫秒级，但任务状态必须透明。一个批量推理任务可能需要跑几分钟甚至几小时，调用方至少要能查询任务是否还在执行、日志在哪里、输出文件是否已生成。

5.3 高频问题的排查顺序：现象、输入、环境、参数、任务状态

科学AI平台使用过程中，很多问题看起来像模型能力差，其实不是。我平时会按固定顺序排查。

第一步看现象。报错、卡住、无输出、输出明显异常，这些现象的定位方向完全不同。报错看日志尾部，卡住看进程状态和GPU利用率，无输出看输入路径、输出目录和权限。

第二步看输入。文件格式是否和代码预期一致，编码是否是UTF-8，字段名有没有被改过，空行、缺失值、特殊字符是否处理过。一段看起来正常的数据，可能只是在Excel里多了一个不可见字符，就会导致模型推理结果全部为空。

第三步看环境。依赖版本是否变化，CUDA和GPU驱动是否匹配，磁盘空间是否满了，容器挂载目录是否有读写权限。

第四步看参数。batch size是不是设置得太高，超时时间是否过短，并发数是否超过了服务承载能力，模型路径和配置文件里的版本是否一致。

最后再看模型本身。这时候才去怀疑模型权重损坏、预处理逻辑和数据分布不一致。很多人遇到问题就重新训练模型，这是成本最高的方案，也是最后的手段。

5.4 每次任务都要留下足够日志

在278个项目级别的协作规模下，没有日志就没法复盘。我建议每次任务至少记录：任务ID、输入数据版本、运行脚本或代码版本、环境依赖版本、开始和结束时间、使用的模型标识、输出文件路径、最终状态。

日志不需要很复杂，但要保证每个字段都能对上。这样当某条实验结论被质疑时，可以直接回到当时的数据、代码和环境，重新跑一遍看看能不能复现。科学AI基础设施真正区别于“临时脚本”的地方，就在这里。

6. 从278个项目的气氛回到自己的场景，我的取舍建议

6.1 先判断你的需求是不是“基础设施级”

不是所有团队都需要马上建一个完整平台。如果只是一个人在做数据分析，找几段脚本、跑几个notebook，那么把目录整理清楚、环境依赖固定好、随机种子设置好，就够了。

如果现在有多个课题组提需求，大家都在重复做数据处理、模型训练和评估，或者同一个模型要被多个服务调用，这时候才值得投入基础设施。核心判断标准有三个：是不是经常有重复劳动，是不是多人共享一套流程，是不是希望把结果长期沉淀下来。

如果三个答案都是否，轻量方案更好。轻量不代表随意，而是控制复杂度：一个统一的输入输出约定、一个小型任务状态库、一个记录模型和输出文件的目录结构，就已经能解决大部分问题。

6.2 优先投资高复用的数据管线和可重现实验记录

一旦决定往基础设施方向投入，我会建议把优先顺序放在数据管线和可重现执行上，而不是盲目扩充GPU集群。

数据管线包括数据命名规则、版本记录、元信息、清洗逻辑。可重现执行包括环境锁文件、容器化或固定运行环境、标准化命令。如果你有几百个模型候选，想统一做评估，没有这两项能力，连评测结果都很难对齐。

模型仓库不需要一开始做得很重。先把每个模型的配置、权重路径、在验证集上的表现记录下来，建立一个简单的登记表。等模型变多后，再逐步加上模型版本对比和自动评测功能。

6.3 管理预期：不是所有科学问题现在都适合AI

AI成为科学基础设施，不等于所有科研问题都必须用AI解决。有些场景数据量极少，连基本训练集都凑不齐；有些场景没有明确的可验证标准，模型也不知道自己预测得对不对；还有一些场景，实验成本远高于模型试错成本，不能只靠AI给一个“看起来合理”的建议就开始做实验。

科学AI更适合用在能形成反馈闭环的地方：预测可以进行下一步验证，验证结果可以继续更新模型或筛选逻辑。如果一项任务连失败的标准都不清楚，再大规模建设平台也不会有稳定产出。

也要允许项目失败。278个项目背后如果全部被包装成成功案例，反而不符合科研规律。能够留下一个“此路不通”的边界，其实和做出一个高精度模型同样有价值，关键在于有没有把它记录下来。

6.4 真正的分水岭在工程纪律

落到具体执行上，我会更建议先把一个小场景跑稳。不是先上大平台，而是先选一个真实课题，做一次端到端的最小闭环，把所有人为绕过的坑都补上。等这条链路稳定复现后，再增加数据量、增加模型、接入Agent，逐步扩展。

科学AI从“能发论文”走向“科研基础设施”，看起来是一个很大的叙事，但拆开看依然是那些琐碎的事：格式要统一、环境要固定、任务要有日志、模型要可迭代、关键节点要有人确认。把这些事做扎实，278个项目才有可能沉淀出真正可复用的成果。否则，项目再多也只是热闹一场，下一次启动新课题时，又会从零开始。