AI in Research: Real-World Usage Distribution Across Tasks, Disciplines, and Tools

1. Survey overview: what AI is actually used for in research

A large language model R&D company recently disclosed a usage-side study of AI in research scenarios. The measurement window was August 2 to September 30, 2026. It covered about 207,000 research-related sessions: about 129,000 conversational and collaborative sessions, and about 78,000 coding-tool sessions aimed at terminals and code repositories.

The data-processing approach deserves special mention. The system retained only classification labels such as discipline, research subfield, and task type. It did not extract or store research data, research hypotheses, experimental methods, preliminary findings, or unpublished paper content. Conclusions were released only as aggregated statistics. This means the profile describes the distribution of researchers’ clicks and interactions with AI, not changes in the quality of research output.

From this, three key conclusions can be drawn:

• Task side: Data analysis and academic writing are the dominant consumption areas. Front-end activities such as data collection and research hypothesis generation have much lower AI participation.
• Discipline side: Computational and quantitative fields have the highest penetration. Laboratory-dependent and qualitative research fields have low penetration.
• Tool side: Usage of coding tools in research is highly concentrated in computationally intensive subfields.

One point must be clarified before reading such a report: session count is a usage-intensity indicator, not an effectiveness indicator. High usage frequency means that the task aligns well with model capabilities; it does not mean that the output quality has been validated. The sections below break this down.

2. Task distribution: why data analysis and writing form the “main channel”

First, look at the data. In conversational and collaborative research sessions, data analysis accounted for 33.7%, while writing and communication tasks accounted for 32%. In coding sessions, data analysis rose to 48.1%. As a reference, researchers reported that about 27.6% of their full-time work is spent on data analysis. AI usage intensity broadly matches this time allocation, indicating that this is a cross point of time-intensive and high-value work.

There are three structural reasons why data analysis ranks first.

First, the task boundary is clear. Cleaning, aggregation, statistical testing, and visualization all have clear inputs and outputs, as well as deterministic criteria. Model output can be immediately falsified or confirmed.

Second, the input and output are naturally suited to context carrying. Tables, logs, measurement sequences, and configuration files are inherently text-based structures. With a script execution environment, the model can “read first, then compute,” rather than guessing from memory.

Third, the toolchain is already standardized. Script environments, notebook-style interaction, and version management are established habits. The integration threshold is low, and researchers do not need to change their existing workflow.

Writing and communication account for 32%. The logic is similar, but the risk structure is different.

Academic writing can be decomposed into subtasks such as structural reorganization, language polishing, format normalization, responding to peer-review comments, and polishing grant application text. Their common feature is “high repetition, low exploration,” and quality can be assessed through relatively objective proxies such as readability, logical consistency, and format compliance. However, academic writing has extremely high requirements for factual accuracy, citation authenticity, and data consistency. Therefore, a reasonable role for AI is to intervene at the “draft and structure layer,” not to replace the “fact-source layer.”

3. Discipline distribution: the usage gap between quantitative research and qualitative/experimental research

The discipline-side gap is more pronounced than the task-side gap. In research sessions, computer science accounted for 11.9%, higher than engineering at 8.4% and medicine at 7.7%. After normalizing by the researcher base of each discipline, computer science, mathematics, and statistics still had usage ratios above their share of researchers.

The skew in coding tools is even more extreme:

• Researchers in computer science directions represent about 4.3% of global researchers, but contribute 32.7% of coding-related research sessions.
• AI and machine learning directions account for about 1.2% of researchers, corresponding to about 5% of conversational research sessions and about 15.2% of coding research sessions.
• Usage ratios in arts, humanities, and some social science directions are generally low.

The explanation cannot simply be that “people in computer science are more willing to adopt new tools.” The real constraint is the degree to which a task can be digitized.

The research pipeline in quantitative disciplines can be summarized as “data → code → charts → conclusions.” Every step produces text-based intermediate artifacts, which align closely with the capability boundary of large models. In this context, the model is almost a “free accelerator.”

In laboratory-dependent fields, researchers spend much of their time on wet-lab operations, instrument scheduling, sample preparation, ethics approvals, and clinical coordination. The share of text-based steps where AI can intervene is lower. Engineering and medicine do not lack text tasks—medical record writing, regulatory document verification, and structured imaging reports are examples—but their deployment pace is strongly constrained by compliance, data classification, and responsibility attribution. Diffusion is therefore naturally slower.

A common misjudgment is that low usage does not mean low demand. “Not daring to use it for compliance reasons” and “not needing to use it for task reasons” are fundamentally different problems, and their solutions are different: the former relies on data governance and permission systems; the latter relies on scenario reconstruction.

4. Why “data collection and research hypothesis generation” remain underused

Limited AI participation in front-end research activities usually comes from four constraints:

• Data is not within the model’s view: Private databases, raw instrument output, and protected data subject to ethical constraints often cannot enter the model through normal interaction channels.
• Scientific hypotheses require counterintuitive intuition: General models tend to produce “reasonable but mediocre” incremental combinations, while high-value hypotheses often come from anomalous observations within a field and cross-domain analogies.
• The feedback loop is too long: Experimental cycles are measured in weeks or months, and the cost of errors is asymmetric, making it impossible to form a rapid “generate-verify-correct” iteration.
• Traceability requirements: Conclusions must be traceable to specific sources and methods. Direct “answers” from a model are not acceptable in research review.

A practical judgment is therefore to let the model act as a candidate generator and retrieval integrator, while leaving judgment to researchers. Hypotheses can be generated in batches, but prioritization, falsifiability design, and resource-allocation decisions should be made by humans.

5. Engineering view: generic architecture layers for a research AI assistance platform

If the above capabilities are to be built into team-level infrastructure, the following layers can be used as a reference. Each layer uses common industry product categories and is not tied to a single vendor:

1. Access layer: Three entry points coexist—conversational assistants, code assistance tools, and batch job interfaces. They cover exploratory questioning, script writing, and large-scale data processing, respectively.
2. Orchestration layer: Responsible for task decomposition, tool invocation, loop control, and mandatory insertion of human confirmation nodes.
3. Data and knowledge layer: Raw data is stored in object storage, a literature library and private knowledge base index are built, and retrieval-augmented methods provide context, avoiding mixing private data into general reasoning context.
4. Model service layer: A unified access gateway supports multi-model routing (routing complex reasoning and low-cost, high-frequency tasks separately), quota management, and key custody.
5. Observability and governance layer: Invocation logs, monitoring alerts, and metric dashboards, with audit trails for sensitive operations.

The following is illustrative pseudocode only. It demonstrates the orchestration skeleton and does not correspond to the real interface of any specific product:

# Illustration: an agent orchestration skeleton for “literature review + statistical recomputation”
def research_assist(query: str, corpus_uri: str, max_steps: int = 6):
    ctx = load_index(corpus_uri)                 # Load only the retrieval index; raw data does not leave the domain
    plan = decompose_task(query)                 # Task decomposition: retrieve / compute / verify
    for step in plan[:max_steps]:
        if step.kind == "retrieve":
            ctx.add(retrieve(step.query, top_k=5))       # Evidence snippets with source citations
        elif step.kind == "compute":
            ctx.add(run_in_sandbox(step.script))         # Controlled execution; no external network or unauthorized read/write
        elif step.kind == "verify":
            ctx.add(check_citations(ctx))                # Verify citation authenticity and numerical consistency
        if step.needs_human_review:                      # Mandatory human approval at high-risk nodes
            ctx.pause_for_approval()
    return draft_with_citations(ctx)                     # Output a draft with sources and reproducibility notes

Three design points are often overlooked: private data should participate in reasoning only as indexes and evidence snippets; script execution must occur in an isolated sandbox with restricted network and file permissions; high-risk nodes need “hard gates” at the orchestration layer rather than relying on prompt-based constraints to make the model self-disciplined.

6. Implementation recommendations and practice checklist

1. Authorize by verifiability. Low-risk tasks (format cleanup, code snippet generation, chart beautification) can be allowed by default. Medium-risk tasks (literature summaries, data cleaning scripts, explanations of statistical criteria) require spot checks and version traceability. High-risk tasks (clinical interpretation, conclusive statements, confidential data processing) must undergo human review.
2. Build a small-scale evaluation set. Maintain 50–200 expert-labeled samples from the domain. Regression metrics should include factual consistency, citation verifiability, code first-pass rate, and rework time, to prevent the situation where “the demo is impressive, but production fails.”
3. Classify data and enforce minimum necessity. Divide data into four levels: public, internal, restricted, and confidential. Define which level of data can enter which type of model. De-identify personally identifiable information and maintain audit trails throughout the process.
4. Control cost. Route high-frequency short requests to lightweight models and upgrade to long-chain reasoning only when needed. Cache retrieval results and use queues to smooth peak loads for batch tasks.
5. Measure effectiveness, not just activity. Evaluate benefits using three metrics: task adoption rate, human rework rate, and time saved per task, rather than looking only at invocation volume.
6. Assess the form factor. These capabilities are usually composed of generic cloud capabilities—object storage, message queues, container platforms, logging, monitoring and alerting, and identity and permission management. As an example, Baidu AI Cloud provides support at the level of the generic product categories above. The specific research agent orchestration, domain knowledge base construction, and evaluation system still need to be designed and iterated by the research team.

7. Conclusion

The core value of this survey is not a specific percentage figure. It reveals a pattern: the speed at which AI releases value in research is positively correlated with task verifiability and with the degree of task textification; it is not correlated with whether a discipline is computational-intensive, but is highly correlated with whether the research workflow has already been digitized.

For technical teams, this means three things: capability priorities should be ranked by “verifiability × time share”; data access and permission governance must precede model selection; and the evaluation system must be built in parallel with the business. AI will not replace researchers’ judgment, but it has already taken over two of the most labor-consuming mechanical activities: data analysis and text production. Handing these two segments to tools is precisely what frees human attention for the places that truly require judgment.