AI LLMs in Drug R&D: Capability Boundaries and Engineering Deployment

1. Signal interpretation: From selling tools to entering the process

A leading large language model team publicly disclosed two developments. First, its model has been used in research and development tasks such as molecular design, manufacturing document review, regulatory submission, and clinical trial planning, with some early data released. Second, by acquiring an extremely small biotechnology entity, the team connected model capabilities directly to its own R&D pipeline. Together, these moves signal a shift in the role of AI in life sciences.

Over the past three years, the dominant industry narrative has been that AI provides tools and pharmaceutical companies use them: models are delivered as APIs, plug-ins, or platform features, and R&D staff invoke them within existing workflows. The efficiency ceiling of this model is constrained by how people move AI output back into the process. The alternative approach—building an internal entity and embedding the model into the process—changes AI from a tool into a process participant. Tasks that were previously handled by people, such as hypothesis generation, document drafting, compliance pre-review, and protocol drafting, are first run by the model by default, with people reviewing and making decisions.

For technical teams, the question is no longer whether to use large models, but three more specific questions: which R&D tasks are genuinely suitable for model delegation, how to connect models to existing data and systems, and how to quantify and accept the benefits they bring. This article is organized around these three threads.

2. Capability boundaries: Segment tasks before deployment

The drug R&D chain is extremely long, often spanning around ten years from target discovery to market approval. Asking whether AI can do drug R&D as a single question does not produce useful answers. The R&D stages must be broken down to determine whether the task pattern in each stage matches the strengths of large models.

2.1 High-fit: Text-heavy, knowledge-dense, and externally verifiable

Tasks in this category share several features: inputs and outputs are mainly documents, correctness has clear external references such as regulatory clauses, historical batch records, prior submission files, and internal standard operating procedures, and the cost of failure is controllable because drafts are reviewed by professionals. Typical tasks include:

• Checking consistency between quality and technical documents, such as whether batch production records match process specifications or whether deviation investigation reports are logically closed;
• Mapping regulatory clauses to internal documents, such as identifying which internal procedural files need revision after a new guidance is issued;
• Checking completeness of submission document chapters and unifying terminology;
• Quickly reviewing literature and patents, and mapping competitor pipelines;
• Drafting initial versions of clinical protocol text and checking internal consistency among inclusion and exclusion criteria, endpoint definitions, and statistical analysis plans.

In these tasks, the core value of the model is reading quickly and finding inconsistencies, rather than knowing the final answer.

2.2 Medium-fit: Design tasks requiring experimental data closure

Molecular design and optimization belong to this category. Models can propose candidate structures and modification suggestions based on structural representations, structure-activity relationship data, literature, and patent information. They can also support retrosynthetic route planning and early druggability risk screening, such as structural alerts related to solubility, metabolic stability, and cardiotoxicity risk. However, these suggestions must be validated by wet-lab experiments. Model outputs can only be hypotheses, not conclusions.

The key engineering problem at this level is not the model itself, but the data loop. Experimental throughput, characterization cycle time, and the degree of structured experimental data determine how quickly the model can iterate. If experimental data remains scattered in PDF reports on individual computers, even the strongest model cannot form a learning loop.

2.3 Low-fit/high-risk: Decisions requiring signed accountability

Final judgments involving human subject safety, legal responsibility for regulatory submissions, and process release decisions must be signed by qualified personnel. Models can support material preparation, logic self-checks, and risk checklist generation, but they cannot replace signature responsibility. Defining this layer clearly is a prerequisite for all subsequent compliance design.

Stage	Typical tasks	Fit	Main risks
Target discovery	Literature, patent, and omics data integration; hypothesis ranking	Medium-high	Incomplete evidence chains can lead to incorrect prioritization
Molecular design and optimization	Candidate structure generation, property prediction, retrosynthesis suggestions	Medium	Requires wet-lab closure; outputs are hypotheses only
Process and quality documents	Consistency checks, deviation reports, change impact analysis	High	Omission errors are difficult to self-detect
Regulatory submission	Completeness of submission materials, terminology consistency, draft responses to questions	High	Wording errors can create compliance risks
Clinical protocols and operations	Protocol drafting, inclusion/exclusion checks, site feasibility, data cleaning rules	Medium-high	Involves subject safety and statistical rigor
Pharmacovigilance	Initial screening of individual case safety reports; signal detection support	Medium-high	Underreporting has severe consequences and requires strong review

3. Technical breakdown of four high-value scenarios

3.1 Molecular design and iteration

Engineering usually requires a combination of three capabilities: molecular representation and retrieval, property prediction models, and generation and optimization strategies. Large models play the role of orchestrator and explainer. They translate natural-language intent from chemists—for example, improving metabolic stability, retaining existing target affinity, and avoiding known hepatotoxic structural alerts—into executable retrieval conditions and constraints. They summarize predictions from multiple sources, generate structural modification hypotheses with rationale, and draft experimental plans.

A common implementation pattern is multi-candidate generation, constraint-based scoring, and human adjudication. The model and specialized prediction models each propose candidates; the system scores and ranks them by physicochemical properties, synthetic accessibility, patent novelty, structural alerts, and other dimensions; and chemists make the final choice. A critical design mistake is to have the large model directly output the optimal molecule. It does not have reliable quantitative structure-property prediction capability. Its proper role is hypothesis generation and process orchestration.

3.2 Manufacturing and technical document review

This is one of the highest-return scenarios because documents are long, rules are explicit, and the value of finding errors is high. A typical pipeline includes:

1. Document parsing and structured chunking by semantic units such as sections, tables, and attachments, rather than fixed character counts;
2. Building a searchable clause library and historical document library, including current regulations, internal standards, prior batch records, and historical audit findings;
3. Generating a problem list through segment-by-segment comparison, with each issue carrying a source location and supporting citation;
4. Cross-validating model conclusions with a rule engine for numeric ranges, units, version numbers, and mandatory fields;
5. Human review and archiving, with review conclusions fed back into evaluation sets and prompt or rule improvements.

A simplified implementation skeleton:

def review_document(doc_path, kb_index, rules, schema):
    """Run a three-stage review of a single technical document: retrieval, generation, and rule-based verification."""
    findings = []
    for unit in semantic_chunk(doc_path, max_tokens=1200):     # Split into semantic units
        context = kb_index.search(unit.text, top_k=6)          # Retrieve relevant clauses and historical records
        draft = llm.generate(
            system="You are an assistant for reviewing pharmaceutical technical documents. Judge only based on the provided material. Do not infer content beyond the material. If you cannot determine an issue, mark it as pending manual review.",
            context=context,
            user=unit.text,
            schema=schema,                                     # Constrain output to a structured format
            temperature=0.0,
        )
        for item in validate_against_schema(draft, schema):    # Validate structural compliance
            item["checked_by_rules"] = rules.check(unit, item)  # Apply deterministic rule checks
            findings.append(item)
    return audit_log(findings)                                  # Keep a full traceable audit log

There are three design priorities: retrieval quality sets the ceiling, and tuning chunking and retrieval strategies often yields more benefit than switching models; structured output makes results consumable by downstream systems and avoids unarchivable free text; rule-based review is key to controlling false positives, and review results relying only on model judgment are difficult to pass quality department evaluation.

3.3 Regulatory submission document production

The value of submission materials lies in internal consistency: data must be consistent across modules, chapters, main text, and attachments. Large models are well suited to act as consistency and completeness checkers. They can verify whether table data matches main text statements, whether cross-references exist, whether terminology and measurement units are unified, whether mandatory chapters are complete, and whether responses to regulatory questions address each comment item by item.

A practice that is often overlooked is building a submission-document knowledge graph. Entities such as indications, dosage forms, process steps, quality attributes, test items, and stability data are structured together with their relationships. Checking cross-chapter contradictions then becomes a constraint validation problem on the graph, offering significantly better explainability and determinism than purely generative judgment.

3.4 Clinical protocol design and trial operations

Feasible tasks at this layer include drafting an initial protocol structure, checking logical consistency of inclusion and exclusion criteria—such as whether an exclusion criterion duplicates or conflicts with other criteria—suggesting visit schedules and data collection forms, aggregating and comparing site feasibility information, standardizing safety narratives, drafting data cleaning rules in the data management plan, and improving readability of participant communication materials.

The intervention boundary must be clear: the model does not participate in dose decisions, safety judgments, or the formation of statistical conclusions. Before any output enters the investigator decision chain, it must be signed off by medical, statistical, and regulatory personnel. The engineering requirement for such processes is that human-in-the-loop review must be auditable: who confirmed what content, and when, must be fully traceable.

4. Reference architecture: An R&D knowledge foundation

4.1 Layered design

A reusable R&D knowledge foundation can be organized into five layers:

• Access layer: document parsing (PDF, OCR of scanned files, table restoration), experimental instrument data ingestion, and integration with existing business systems such as laboratory information management systems, document management systems, and clinical trial management systems, all unified through API gateways and identity authentication.
• Data and knowledge layer: object storage and version management for raw documents; structured experimental data in a lakehouse; vector indexes for semantic retrieval; graph databases for entity relationships; and metadata and lineage records to ensure every conclusion can be traced back to source files and versions.
• Model layer: general-purpose large models for understanding and generation; specialized small models for high-determinism tasks such as property prediction, classification, and extraction; and embedding models for retrieval representations. All are called through a unified gateway to enable task routing and cost optimization.
• Orchestration layer: task orchestration and tool invocation to connect models to deterministic tools such as retrieval, structural search, prediction services, and statistical computation; state machines, retries, idempotency, and human approval nodes.
• Governance layer: permissions and data classification, prompt and model version management, full-chain logging and auditing, monitoring and alerting, and evaluation-set management.

On Baidu AI Cloud, this architecture can be implemented by combining general-purpose product categories: object storage and data lakes for raw documents and experimental data, a message queue to decouple document ingestion from index building, a container platform to host model gateways and orchestration services, log and monitoring services for observability, and key management and permission systems for tiered access. In technology selection, it is advisable to maintain interface abstraction and avoid hard-wiring business logic into a specific managed service.

4.2 Retrieval-augmented generation: Not optional, but a baseline

In pharmaceutical and regulatory scenarios, generation without retrieval is basically unusable. The reason is straightforward: clauses are updated, internal enterprise standards have unique authority, and a model’s parametric memory is neither complete nor citable. Retrieval-augmented generation replaces what the model knows with what was retrieved, ensuring that every conclusion has a locatable source.

Key engineering details include:

• Chunking strategy: chunk by semantic units such as sections, clauses, and table rows, and retain heading-level paths as metadata so citations can point to Chapter X, Section Y rather than a vector ID;
• Hybrid retrieval: keyword retrieval for exact matching of clause numbers, proper nouns, dosage units, and other precise terms, combined with semantic retrieval and fused ranking. Pure vector retrieval performs poorly for exact terminology matching;
• Reranking: after retrieving 20 candidates, use a small model to rerank and keep the top 5, significantly improving context quality;
• Citation enforcement: make the citation field mandatory in structured output. Missing citations are treated as invalid outputs and trigger retries;
• Timeliness: regulatory versions and guidance revisions must include effective dates. Retrieval should filter by date to avoid citing superseded clauses.

4.3 Structured output and deterministic checks

Free text cannot enter a pipeline. All downstream-consumable outputs should be constrained to a fixed structure:

{
  "type": "object",
  "required": ["findings", "citations", "needs_human_review"],
  "properties": {
    "findings": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["location", "issue_type", "risk", "evidence", "suggestion"],
        "properties": {
          "location":    {"type": "string", "description": "Section path and paragraph location"},
          "issue_type":  {"type": "string", "enum": ["data_inconsistency", "missing_content",
                                                     "terminology", "cross_reference", "other"]},
          "risk":        {"type": "string", "enum": ["high", "medium", "low"]},
          "evidence":    {"type": "string", "description": "Original text fragment or clause number; must be verifiable"},
          "suggestion":  {"type": "string"}
        }
      }
    },
    "citations":         {"type": "array", "items": {"type": "string"}},
    "needs_human_review": {"type": "boolean"}
  }
}

Three gates are required: schema validation rejects outputs that do not conform; citation verification checks whether cited fragments actually exist in the source text and blocks most fabricated citations; rule-based review uses deterministic code to validate numeric ranges, mandatory fields, and version consistency. Only results that pass these three gates will be accepted into formal workflows by quality departments.

4.4 Tool invocation and experimental feedback loops

Models should be able to call deterministic tools rather than perform calculations internally. Common tool interfaces include molecular structure retrieval and similarity calculation, prediction services for physicochemical properties and toxicity alerts, retrosynthetic route queries, sequence and structure database retrieval, statistical computation, and document comparison tools. A simplified tool declaration:

{
  "name": "predict_property",
  "description": "Predict physicochemical properties and druggability risks for a given molecular structure, returning interval estimates and confidence scores",
  "parameters": {
    "type": "object",
    "required": ["structure", "properties"],
    "properties": {
      "structure":  {"type": "string", "description": "A linear text representation or structure file content of the molecule"},
      "properties": {"type": "array", "items": {"type": "string"}}
    }
  }
}

Tool invocation must be restricted to a predefined allowlist, parameters must be constrained by a schema, returned results must be labeled as model predictions rather than facts, and predictions must be clearly distinguished from experimental data in the user interface. This is a key design control to prevent downstream misuse.

5. Proving quantifiable value: Metrics, evaluation sets, and processes

Quantifiability is central to whether such projects can continue to receive investment. However, many teams handle this step carelessly: they count API calls and user satisfaction but cannot answer whether quality has truly improved.

5.1 Metric system

Category	Metric	Definition and collection method
Quality	Issue recall	Number of valid issues found by the model / total number of valid issues labeled by experts
Quality	False positive rate	Number of reported issues that are not confirmed after review / total number of reported issues
Quality	Citation verifiability	Proportion of citations that can be located in the original text
Efficiency	Stage cycle time	Natural elapsed time from task initiation to review approval, collected by stage
Efficiency	Rework rate	Number of submissions returned for document issues / number of submissions
Cost	Cost per task	Unit cost of model calls, retrieval, and compute resources per task
Adoption	Suggestion acceptance rate	Number of suggestions confirmed and accepted by humans / total number of suggestions
Risk	Human interception rate	Proportion of erroneous outputs intercepted by humans before release

It is recommended to cover at least two baselines: a fully manual process and a non-generative process consisting of retrieval, templates, and rules. Comparing only against doing nothing cannot demonstrate the incremental value of the model itself.

5.2 Evaluation sets and methods

Evaluation sets should be annotated by domain experts, stratified by R&D stage and difficulty, and include explicit lists of issues that should be found and issues that should not be falsely reported. Evaluation sets must be updated regularly to prevent prompts from overfitting fixed samples.

CASES = load_dataset("gold_review_set_v1")   # Expert-labeled golden set, stratified by document type
def run_eval(pipeline, cases):
    agg = defaultdict(list)
    for case in cases:
        out = pipeline.run(case["doc_path"])
        agg["recall"].append(match_recall(out, case["gold_issues"]))
        agg["fp_rate"].append(false_positive_rate(out, case["gold_issues"]))
        agg["citation_valid"].append(citation_coverage(out, case["doc_path"]))
        agg["latency_s"].append(out.latency)
    return {
        k: {"mean": mean(v), "p95": percentile(v, 95)} if k == "latency_s" else mean(v)
        for k, v in agg.items()
    }

Online validation uses blind evaluation and controlled comparison: some documents in the same batch go through the new process, while others go through the original process, and review experts do not know the source. The focus is not only on the number of issues found, but also on the proportion of high-quality issues. In addition, teams should monitor metric drift after model or prompt version updates and treat every change as a release that requires revalidation.

6. Five common pitfalls

Fabricated citations and confident errors. Models can generate plausible but nonexistent clause numbers or original text fragments. The only reliable response is citation verification and retrieval enforcement, not merely instructing the model not to fabricate in the prompt.

Missing validation and compliance systems. In regulated environments, software used for quality-related decisions often needs to be included in computerized system validation. This involves requirements specifications, risk assessment, validation plans and reports, change control, and traceability of electronic records and electronic signatures. Such work must be planned early in the project; retrofitting it later is extremely costly. At the same time, teams must clarify whether model output is auxiliary information or decision support, because the former has a significantly lighter validation burden.

Data boundaries and privacy. Unpublished compound structures, patient information, and process parameters are highly sensitive data. Clear data classification, encryption in transit and at rest, access auditing, anonymization and minimization strategies, and explicit terms about whether data may be used for model training are required.

Optimizing only the model, not the data. The benefits of retrieval quality and data structuring usually outweigh switching to a stronger model. If experimental data remains in unstructured report form, no upper-layer intelligence can form a closed loop.

Vendor lock-in. Model capabilities iterate quickly and prices fluctuate. Hard-coding business logic and prompts into a specific model can become technical debt within half a year. It is advisable to abstract calls through a unified model gateway, retain the ability to switch between multiple models, and accumulate domain knowledge in retrieval libraries, evaluation sets, and rule engines—assets that remain valid even when models change.

7. Why a very small team can run an R&D process

A biotechnology entity operated by a single-digit number of staff can be technically feasible because repetitive labor in R&D processes can be highly automated: hypothesis generation, candidate screening, document drafting, compliance self-checks, initial trial protocol drafts, and data cleaning rules. In the past, these tasks consumed a large amount of junior researchers’ working hours.

But this feasibility should be understood accurately. It holds under the premise that automation takes over repetitive steps while professionals retain decisions and signatures, not that AI replaces pharmaceutical companies. The entities responsible for regulatory accountability, ethics review, human subject safety, and manufacturing quality release remain people. The correct engineering goal is to move professional attention from material handling to judgment and decision-making, while making all automated steps explainable, traceable, and auditable.

8. Phased implementation roadmap

Phase	Objective	Deliverables	Acceptance focus
1. Pilot	Validate feasibility in one high-frequency text scenario	Parsing and retrieval pipeline, evaluation set v1, baseline metrics	Recall and false positive rate compared with a manual baseline
2. Closed loop	Connect to existing systems and human review nodes	Structured output, rule-based review, review traceability	Citation verifiability, human interception rate, cost per task
3. Expansion	Cover multiple document types and multiple R&D stages	Knowledge graph, cross-chapter consistency checks, version and timeliness management	Detection of cross-stage consistency defects
4. Governance systematization	Incorporate validation and change-control processes	Validation documents, monitoring and alerting, model version management	Audit traceability and no metric drift

It is recommended to start with quality and technical document review because such text is highly structured, has clear correct-answer references, carries controllable failure costs, and allows benefits to be quantified quickly. Scenarios such as molecular design and clinical protocols should be advanced after data loops and governance systems are mature.

9. Conclusion

The key change as large models enter drug R&D is not model capability itself, but their integration into an engineering process with clear evaluation standards, closed data loops, and responsibility boundaries. Technical teams should not deliver a one-off demonstration, but four things: a high-quality searchable knowledge base, an output pipeline that enforces structuring and verifiability, an evaluation system covering both quality and efficiency, and a governance mechanism capable of withstanding regulatory audit. Only when these four things are solidly implemented can the benefits of model iteration be truly accumulated in the R&D pipeline. Otherwise, any isolated capability demonstration will struggle to cross the threshold from pilot to normal operations.