AI Drug Discovery's New Phase: From Larger Models to Self-Evolving Micro-World Models

1. Trend Background: Competition Shifts from Parameter Scale to Closed-Loop Capability

Over the past few years, general-purpose large models have improved mainly through parameter scale, training data, and compute investment. This path has proven effective in domains such as language and code. Drug discovery, however, has distinctly different constraints. Whether a candidate molecule can become a drug depends on its behavior inside biological systems, and that behavior can only be validated through experiments. Text corpora cannot replace wet-lab data, and model scale alone cannot replace experimental feedback.

Recent industry developments point in several common directions. First, general-model vendors have begun offering model versions specifically optimized for life science scenarios and are building data and workflow collaborations with laboratories and pharmaceutical companies. Second, some AI R&D teams are trying to have models participate directly in experiment design, task scheduling, and result analysis, turning model outputs into executable experimental instructions. Third, capital is beginning to pay attention to a new type of R&D organization based on “small teams plus automation tools,” in which a small number of people use intelligent systems to coordinate multiple external experimental resources and advance early candidate drugs.

These trends show that the industry discussion has moved from “whether the model is large enough” to “whether the system can form a closed loop.” A closed loop includes hypothesis generation, experiment execution, data recovery, model updates, and correction of the next round of hypotheses. Whoever can complete a loop faster is more likely to accumulate effective data and judgment experience.

2. Core Concept: What Is a Micro-World Model?

A micro-world model can be understood as a model that predicts and simulates system behavior at the molecular, protein, cellular, and even simple tissue scales. It differs from common general-purpose language models in three ways.

First, its inputs and outputs are mainly structured scientific objects, such as molecular graphs, sequences, 3D conformations, experimental readouts, and in vitro assay results. Second, the model must explicitly handle physicochemical constraints, such as energy, solubility, toxicity thresholds, and metabolic pathways, to avoid generating chemically infeasible structures. Third, the value of the model depends on how closely its predictions match real experiments, so evaluation must be based on experimental data rather than training-set metrics alone.

The meaning of “self-evolution” here needs to be defined strictly. It does not mean that the model changes its own structure without supervision. Instead, it means that, under controlled conditions, the system reliably feeds new experimental results back into the dataset and model update process, and decides whether to release a new version through version management, evaluation gates, and human review. In other words, self-evolution is a continuous learning capability in an engineering workflow, not uncontrolled self-modification.

3. Reference Architecture for Closed-Loop R&D

A deployable closed-loop system usually contains five layers: objective definition, hypothesis generation, experiment scheduling, data governance, and evaluation and decision-making. The pseudocode below shows the core interactions among these five layers to help developers understand the control flow.

# Illustrative code: basic control flow for closed-loop R&D
def closed_loop_research(objective, model, lab_queue, dataset, max_rounds=10):
    for round_id in range(max_rounds):
        # 1. Generate candidate hypotheses based on the objective and current model
        candidates = model.propose(objective, top_k=50)
        # 2. Select by uncertainty and cost to control experiment scale
        selected = select_by_acquisition(candidates, budget=lab_queue.capacity)
        # 3. Submit experiment tasks and wait for structured results
        tasks = lab_queue.submit(selected)
        results = lab_queue.collect(tasks, timeout_hours=168)
        # 4. Clean and ingest data, recording experimental conditions and version information
        dataset.append(clean_and_validate(results))
        # 5. Evaluate on an independent validation set and update the model only after passing the gate
        metrics = evaluate(model, dataset.holdout())
        if metrics.passes_gate():
            model = retrain(model, dataset)
            save_version(model, round_id, metrics)
        if objective.is_met(results):
            break
    return model, dataset

Three aspects of this code are especially important. First, hypothesis selection must consider both predicted benefit and experimental cost; otherwise, the system will spend limited wet-lab resources on low-value candidates. Second, before data is ingested, experimental conditions, batch information, and equipment information must be recorded; otherwise, later models cannot distinguish real patterns from experimental noise. Third, model updates need evaluation gates. Without gates, the system may keep “evolving” through accidental fluctuations while drifting further away from real biological patterns.

4. Data Governance Is a Prerequisite for Closed Loops

Whether a closed loop can operate depends heavily on data quality. Life science data commonly has several problems: experimental protocols are not standardized, the same metric may be defined differently across laboratories; metadata is missing, making it impossible to reconstruct temperature, batch, and operator information; and negative samples are rarely recorded, so models learn only from successful cases.

From an engineering perspective, teams should start in several areas. First, establish a unified experimental data schema that structurally describes the inputs, conditions, outputs, and quality-control metrics of each experiment. Second, keep version records for both raw data and processed data so that the data snapshot used for a given model training run can be traced. Third, actively record failed experiments and negative results; such data is especially important for correcting overly optimistic model judgments. Finally, for data involving patient information or controlled samples, access control and de-identification should follow relevant regulations and institutional policies.

At the infrastructure layer, object storage can be used to store raw images and sequencing files, message queues can connect experimental devices with compute tasks, workflow orchestration tools can manage multi-step processes, and logging services and monitoring alerts can track the status of each experiment. These are general cloud-native capabilities. Enterprises can choose specific implementations based on their existing technology stack—for example, using cloud compute and storage resources to build an internal data platform—but the key lies in the data model and process design, not in a particular toolset.

5. Evaluation System: From Metrics to Experimental Validation

Model evaluation is the part of the closed loop most prone to problems. A common mistake is to focus only on offline metrics, such as accuracy or correlation on a prediction task, without testing performance in prospective experiments. A sound evaluation system should have three layers.

The first layer is offline evaluation. Use time-split or structure-split datasets to avoid similar molecules or data from the same project appearing in both training and test sets; otherwise, results will be inflated. The second layer is small-scale prospective validation. Run experiments on a batch of candidates recommended by the model, calculate the hit rate, and compare it with random selection or expert-guided selection. The third layer is stability testing across batches and laboratories to confirm that model conclusions do not depend on a single device or operator.

In addition, each model version should have a traceable evaluation report that records the training data range, evaluation metrics, known failure scenarios, and usage limitations. This information is also important for auditing and later reuse.

6. Risks and Governance

Closed-loop systems introduce three main categories of risk. The first is scientific risk. A model may produce high-confidence incorrect predictions outside the training distribution, especially in regions with novel molecular structures and sparse data. Uncertainty estimation should therefore be introduced, and predictions outside the applicable domain should be clearly flagged.

The second is biosafety and compliance risk. Once an automated experimental platform has strong task-generation capability, permission boundaries must be set at the system level, the types of experiments that can be executed must be restricted, and complete operational audit logs must be retained. For experimental designs that could be misused for harmful purposes, compliance review should be conducted before task submission.

The third is organizational and responsibility risk. When many decisions are assisted by a system, the responsible person for each step must be clearly defined, including hypothesis review, experiment approval, and result confirmation. A system can accelerate decisions, but it cannot replace the judgment of the responsible party.

7. Practical Recommendations for Developers and Enterprises

For teams considering entering this field, the following sequence can be used.

1. First review existing experimental workflows and identify the most time-consuming steps that rely most on manual judgment; use them as the first automation targets for the closed loop.
2. Establish data standards and metadata specifications to ensure that every experiment can be recorded in a structured way. Investment in this step usually determines the upper limit of all subsequent work.
3. Start with a small-scale pilot. Choose a research question with clear boundaries and set explicit success criteria and a budget cap.
4. Bring models, datasets, and evaluation reports into unified version management so that every update can be rolled back.
5. Work with compliance, legal, and security teams to define permission and audit rules early in the project, not just before launch.

For developers who provide only technical support, the focus can be on data pipelines, task scheduling, evaluation frameworks, and observability. These capabilities are relatively independent of specific model choices, have lower migration costs, and are better able to support long-term R&D.

8. Conclusion

Competition in AI drug discovery is shifting from model parameters to system capability. A truly valuable system is one that can continuously connect hypotheses, experiments, and data, and complete iterations under controlled gates. Micro-world models provide predictive capability for biological systems, while self-evolution mechanisms require engineering teams to build reliable data governance, evaluation, and security systems.

For developers, this means the center of gravity is moving from training a larger model to building a more reliable R&D system. For enterprises, the key early decision is not which model to choose, but whether they can build high-quality data assets and auditable experimental workflows. Those who establish these foundations first will have a better chance to accumulate real advantages in the next stage of competition.