AI 設計的胜肽候選結果可信嗎？

What peptide research can teach developers about machine learning, data quality, and the gap between prediction and reality.

I've been spending time in two worlds that don't always overlap as much as you'd expect: software development and peptide research.

I'm a dev in the peptide space, working on websites and scientific content for projects like Orion Peptides. One thing that keeps getting my attention is how quickly AI is changing the way we approach biological problems.

We can now use computational models to explore protein structures, predict molecular interactions, and generate candidate peptide sequences. From a developer's perspective, that's fascinating. We're taking complex biological systems and trying to make them more searchable, modelable, and predictable.

But there's a question I think deserves more attention:

When an AI model generates a promising biological candidate, what would it actually take to trust the result?

In software, passing a test doesn't prove that an application is free of bugs. In machine learning, a high score on a benchmark doesn't guarantee that a model will perform well on unfamiliar data.

And in biology, a promising computational prediction is not the same as a validated experimental result.

That gap between prediction and reality is where I think some of the most interesting engineering problems are emerging.

1. Peptide design is an interesting machine learning problem

First, a quick explanation for anyone who hasn't spent much time around biology.

Peptides are short chains of amino acids. Their sequences and chemical properties influence how they fold, interact with other molecules, and behave in biological environments.

Researchers study naturally occurring peptides and design new candidates for a wide range of purposes, from investigating antimicrobial activity to exploring potential therapeutic applications.

Traditionally, discovering a promising candidate can involve substantial laboratory work, informed by existing biological knowledge and previous experiments.

AI introduces another approach.

Depending on the model, researchers can use machine learning to:

• Identify patterns in known peptide sequences.
• Predict certain structural or biochemical properties.
• Rank candidate sequences according to a defined objective.
• Generate new sequences that satisfy selected computational constraints.
• Prioritize which candidates deserve further investigation.

The appeal is obvious. Instead of relying exclusively on trial and error, researchers can use computational methods to narrow a large search space.

But there's an important distinction between predicting a property and generating a molecule that actually exhibits that property in a biological system.

A model might learn that certain sequence patterns are associated with a particular activity in its training data. That doesn't guarantee that a newly generated sequence will show the same activity when tested.

The model has learned patterns. Whether those patterns generalize to genuinely new candidates is a separate question.

1. Generating a sequence is not the same as designing a working molecule

This is where I think the conversation gets interesting from a developer's perspective.

Imagine building a model that generates peptide sequences and assigns each one a predicted activity score.

The interface looks great. The model produces thousands of candidates. Each candidate has a score, perhaps alongside predictions about stability, solubility, or other properties.

You could build a dashboard around this in a relatively familiar way:

• A generation service produces candidate sequences.
• A validation layer checks the outputs.
• A prediction model assigns scores.
• A ranking service sorts the candidates.
• A database stores sequences, model versions, and results.
• A user interface lets researchers explore the output.

From a software engineering perspective, this is a perfectly understandable pipeline.

The problem is that the interface can make the output look more definitive than it really is.

A score of 0.95 might look impressive. But what does it mean?

Is it a calibrated probability? Is it a similarity score? Is it a model-specific ranking value? Was the model evaluated on independent data? Does the score correspond to a laboratory measurement, or is it simply another model's prediction?

Without that context, the number can create a false sense of confidence.

A prediction score is only as meaningful as the question it measures and the evidence supporting it.

This isn't unique to peptide design. It's a general problem in machine learning whenever a complex real-world outcome gets reduced to a convenient number.

1. AlphaFold is a useful example of both progress and limitations

One of the best-known examples of AI's impact on biological research is AlphaFold, which predicts protein structures from amino acid sequences.

Its development has been a major advance in structural biology. The original AlphaFold2 research demonstrated striking accuracy in predicting many protein structures, and the resulting tools have helped researchers investigate biological questions at scale.

But a structure prediction is still a prediction.

A 2024 paper in Nature Methods, titled “AlphaFold predictions are valuable hypotheses and accelerate but do not replace experimental structure determination”, compared predicted structures with experimental crystallographic evidence.

The authors found that some predictions agreed closely with experimental data, while others differed even when the model assigned high confidence to its predictions.

They also discussed limitations involving molecular interactions, chemical modifications, and environmental conditions.

The lesson isn't that AlphaFold is unreliable or that AI has failed in biology. Quite the opposite. These models can be extremely useful.

The lesson is that usefulness and certainty are different things.

A computational model can help researchers decide where to look, which hypotheses to investigate, and which experiments might be most informative. It doesn't automatically replace the evidence needed to establish what a molecule actually does.

This is a distinction developers should keep in mind whenever a model produces an output that looks authoritative.

1. The real challenge starts with the data

We often focus on the model architecture when discussing AI.

Should we use a transformer? A generative model? A diffusion-based approach? Can we improve performance with a different representation or training strategy?

Those are legitimate questions, but I suspect the less glamorous parts of the pipeline deserve just as much attention.

What data was the model trained on, and how reliable is it?

Biological datasets can combine information from different experimental methods, laboratories, publications, and computational predictions.

That creates several challenges.

Inconsistent measurements

Two studies might investigate similar properties but use different experimental conditions, assays, controls, or definitions of success.

If the resulting observations are treated as directly comparable without accounting for those differences, a model can learn misleading relationships.

Missing context

A peptide sequence on its own doesn't tell you everything about the experiment in which it was studied.

The measurement may depend on the assay, target, environment, formulation, or other experimental details.

If that information isn't captured, a model might learn associations that don't generalize beyond the original context.

Data leakage

This is a familiar problem in machine learning.

If information from the evaluation set has indirectly influenced training, a model can appear more capable than it really is.

In peptide research, randomly splitting individual sequences into training and test sets may be insufficient when closely related sequences appear on both sides. The model might perform well partly because it has already encountered very similar examples.

Depending on the research question, evaluation may need to account for sequence similarity, biological families, or other relationships between examples.

Publication and selection bias

Published datasets aren't necessarily representative of all experiments that have been conducted.

Positive findings may be more visible than negative results, and some types of candidates may be studied more extensively than others.

A model trained on such data can inherit these imbalances.

None of these problems means that biological machine learning is inherently flawed. They mean that data engineering is part of the scientific work, not just preparation before the interesting part begins.

1. How would I think about building a trustworthy pipeline?

If I were evaluating a software system that supports AI-assisted peptide research, I'd want to know much more than which model it uses.

I'd want to understand the entire process from input data to final interpretation.

Here's one way to break it down.

Step 1: Track the provenance of the data.

Every record should ideally have a traceable source, a clear description of what was measured, and relevant experimental context.

If a value comes from a computational prediction rather than a laboratory experiment, that distinction should remain visible.

Step 2: Make validation explicit.

The system should check whether inputs and outputs meet the expected format and constraints.

For peptide sequences, that might include validating the alphabet, recording sequence length, and identifying whether unusual residues or chemical modifications are represented.

Passing these checks establishes that the data is structurally acceptable. It does not establish biological activity.

Step 3: Separate predictions from observations.

This is a big one.

A database shouldn't make it difficult to distinguish between an experimentally measured result, a prediction generated by a model, and a conclusion inferred from other data.

Those are different types of evidence.

I would want them represented explicitly in the data model, rather than relying on a label in the user interface to communicate the difference.

Step 4: Record model versions and evaluation methods.

If a prediction changes after a model update, can we explain why?

Can we reproduce the original result? Do we know which training data, model version, configuration, and evaluation procedure were involved?

Reproducibility becomes particularly important when multiple tools are chained together.

Step 5: Design for uncertainty.

Instead of displaying one score without explanation, the interface should communicate what the score represents, where the model has been evaluated, and what its limitations are.

Confidence estimates should not be presented as guarantees, and uncertainty should not disappear simply because the output has been converted into a polished chart.

Step 6: Keep experimental validation separate.

Ultimately, claims about a peptide's actual biological properties require suitable evidence from experiments.

The design of those experiments depends on the specific scientific question. The important engineering point is that the pipeline should not silently transform a computational prediction into an experimentally established fact.

This is how I would approach the problem: build a system that preserves the distinction between what we know, what we predict, and what still needs to be tested.

1. Where does Orion Peptides fit into this?

This is where my own work intersects with the subject.

I work on websites and scientific content in the peptide space, including projects like Orion Peptides https://orionpeptide.com/. That experience has made me more interested in the information surrounding a scientific product, not just the product description itself.

A website can display a sequence, a purity figure, a certificate of analysis, or a research claim. But what does each piece of information actually establish?

For example, a reported purity value doesn't automatically establish molecular identity, biological activity, sterility, or suitability for a particular research application. Those questions require different forms of evidence.

Likewise, a scientific article describing a promising mechanism doesn't necessarily demonstrate that the same effect occurs in a different experimental setting.

This is partly a content problem, but it is also a data problem.

How do we represent evidence accurately? How do we connect a claim to its source? How do we keep information traceable as products, documents, and research findings change?

These are familiar engineering questions, even when the underlying subject is biology.

I'm not suggesting that working on a peptide website is the same as designing a new therapeutic molecule. It isn't. But working around scientific information gives developers a useful perspective on how easily data can lose context when it's simplified for an interface.

And as AI makes it easier to generate scientific summaries, predictions, and candidate molecules, preserving that context becomes even more important.

1. The next step isn't just better models. It's better validation.

There's a tendency to measure progress in AI by asking whether a new model is larger, faster, or more accurate on a particular benchmark.

Those measures can be useful, but they don't tell the whole story.

For AI-assisted peptide design, I'd also want to know:

• Does the model generalize to candidates that differ meaningfully from its training data?
• Are evaluation datasets independent and appropriate for the intended task?
• Can another team reproduce the computational results?
• Are negative results and limitations reported clearly?
• How often do the model's predictions agree with independent experimental measurements?
• Can the complete process be audited, from the original data through to the final claim?

Recent reviews of generative peptide design highlight many of these broader challenges, including dataset construction, evaluation standards, multi-objective optimization, and the transition from computational generation to experimental validation.

For developers, this creates opportunities beyond training the next model.

There is work to do in scientific data infrastructure, reproducible pipelines, dataset versioning, evaluation frameworks, provenance tracking, and interfaces that communicate uncertainty without hiding it.

Some of the most valuable improvements may come from making existing models easier to evaluate and their results easier to trust.

Final thoughts

AI-assisted peptide design is a fascinating example of what happens when machine learning meets a complex scientific problem.

Models can help researchers explore candidate sequences, make predictions, and prioritize questions that might otherwise take considerable time to investigate.

But a generated sequence isn't proof of function. A predicted structure isn't a complete description of a molecule's behaviour. And a high model score isn't a substitute for independent validation.

For me, the interesting engineering challenge is how to build systems that make these tools useful without making their limitations invisible.

Working in the peptide space, including on projects like Orion Peptides, has made me appreciate how much the surrounding information matters. The quality of the data, the traceability of the evidence, and the way results are presented can all influence how a scientific claim is understood.

I'd be interested to hear how other developers think about this.

If you were building an AI-powered scientific discovery platform, what would you consider essential before trusting its predictions?

Would you focus first on dataset quality, model evaluation, reproducibility, experimental validation, or something else entirely?

I'm especially interested in hearing from developers working in machine learning, bioinformatics, data engineering, and scientific software.

*Disclosure: This article discusses my professional context in the peptide space, including work on websites such as Orion Peptides. It is intended as a technical discussion of AI, software engineering, and scientific validation, not as a product recommendation or a claim about the effectiveness of any peptide.