Large Language Models and Procedural Reasoning: How Generative AI Supports Stepwise Workflows

Last Updated June 21, 2026

Large language models and procedural reasoning explain how generative systems produce, transform, summarize, classify, retrieve, and reason through language-like tasks by using learned statistical representations at scale. A large language model is not a database, a person, a symbolic proof engine, or a guaranteed reasoning system. It is a trained computational model that predicts and generates sequences from patterns learned across large corpora, model architectures, optimization routines, feedback processes, prompts, and deployment constraints.

This matters because language models are increasingly used as reasoning interfaces. They draft, search, classify, explain, translate, summarize, plan, call tools, produce code, simulate arguments, support workflows, and assist institutional decisions. Their outputs can feel procedural because they can break tasks into steps, follow instructions, generate intermediate plans, and adapt to context. But apparent reasoning is not the same as verified reasoning.

This article introduces large language models as a major development in algorithmic and computational reasoning. It explains next-token prediction, transformers, attention, embeddings, prompts, context windows, instruction tuning, reinforcement learning from feedback, chain-of-thought prompting, tool use, retrieval augmentation, hallucination, evaluation, oversight, procedural autonomy, governance, and representation risk.

This article explains large language models, transformers, attention mechanisms, tokenization, embeddings, context windows, prompts, instruction tuning, reinforcement learning from feedback, retrieval-augmented generation, chain-of-thought prompting, tool use, procedural decomposition, hallucination, evaluation, benchmarks, human oversight, governance, and representation risk. It emphasizes that language models can support reasoning workflows, but their outputs require verification, documentation, boundaries, and institutional accountability.

Why Large Language Models Matter

Large language models matter because they have turned language into a major computational interface. Users can ask questions, provide instructions, request transformations, generate code, summarize documents, compare options, draft plans, extract structure, or call tools through natural-language interaction. This changes how people encounter algorithms: not as hidden backend systems only, but as conversational, procedural, and workflow-oriented systems.

Their importance also comes from their reach. LLMs appear in search, writing tools, coding environments, customer support, education, research assistance, knowledge management, data analysis, health-adjacent information workflows, legal-adjacent drafting, public administration experiments, and organizational automation.

LLMs matter because they make computational reasoning feel conversational. That makes verification, boundaries, and accountability more important, not less.

Back to top ↑

Large Language Models Defined

A large language model is a machine-learning system trained to model patterns in language and related symbolic sequences. Most contemporary LLMs are based on transformer architectures. They convert text into tokens, map tokens into numerical representations, process them through attention-based layers, and generate outputs by estimating likely continuations under context and learned parameters.

The phrase “large” refers to scale: large training corpora, many model parameters, large compute budgets, wide deployment contexts, and broad task coverage. Scale can produce flexible behavior, but scale does not make the system inherently truthful, causal, morally accountable, or reliable in every setting.

An LLM is not one thing only. It is a trained model embedded in a larger system of prompts, tools, policies, infrastructure, monitoring, and human use.

Back to top ↑

Procedural Reasoning Defined

Procedural reasoning means reasoning through steps, rules, transformations, checks, conditions, and intermediate states. In traditional algorithms, procedures are explicit: sort these values, search this graph, apply this recurrence, verify this condition. In LLM systems, procedural reasoning can appear through generated plans, explanations, code, intermediate reasoning traces, tool calls, or structured workflows.

The challenge is that LLM procedures may be generated rather than guaranteed. A model can produce a plausible sequence of steps without actually satisfying all constraints. It can write a correct-looking explanation for an incorrect result. It can sound confident while missing a hidden assumption.

LLMs can support procedural reasoning, but the procedure must be checked against evidence, constraints, and intended use.

Back to top ↑

Tokens, Attention, and Transformers

Language models process text as tokens. Tokens may correspond to words, word parts, punctuation, symbols, spaces, code fragments, or other units. The model maps these tokens into vectors and transforms them through layers.

The transformer architecture made attention central. Attention mechanisms allow a model to weight relationships among tokens in context. This helps models represent long-range dependencies, compare parts of a sequence, and condition generation on relevant context. Attention does not mean human attention. It is a mathematical mechanism for weighted information flow.

Transformers are powerful because they turn language into structured numerical computation. They are limited because that computation still depends on training data, objectives, prompting, and evaluation.

Back to top ↑

Pretraining, Instruction Tuning, and Feedback

Large language models are usually developed through multiple stages. Pretraining teaches the model broad language and world-pattern regularities by predicting masked or next tokens from large datasets. Instruction tuning teaches the model to respond more usefully to tasks written as instructions. Feedback-based training can further shape outputs toward helpfulness, safety, preference, or policy objectives.

Each stage changes model behavior. A base model may generate continuations. An instruction-tuned model may follow task requests. A feedback-trained assistant may avoid certain outputs, prefer certain answer styles, or learn conversational conventions.

Training does not merely improve performance. It encodes priorities, values, constraints, and institutional choices into the system.

Back to top ↑

Prompts, Context, and Task Interfaces

A prompt is the user-facing or system-facing instruction that shapes model behavior. Prompts can include tasks, examples, constraints, source material, formatting requirements, roles, policies, tool instructions, and evaluation criteria. The prompt is not just text; it is part of the computational interface.

The context window is the current input the model can use. It may contain user requests, system instructions, retrieved documents, previous turns, tool outputs, code, tables, or structured data. The model cannot reliably use information that is not available in context, unless it is encoded in its parameters or retrieved through tools.

Prompting is procedural design. It structures how the model receives a problem, transforms context, and produces an output.

Back to top ↑

Chain-of-Thought and Stepwise Output

Chain-of-thought prompting and related methods ask models to produce or internally use intermediate reasoning steps. Stepwise outputs can improve transparency for some tasks because they show how a response was assembled. They can also help users inspect assumptions, identify arithmetic mistakes, compare alternatives, and request corrections.

But stepwise output is not proof of correct reasoning. A model can produce a plausible explanation after arriving at a wrong answer. It can skip hidden assumptions, rationalize mistakes, or invent support. In some systems, the model may use hidden reasoning processes while returning a concise answer. In other cases, the user may receive a structured explanation, checklist, derivation, or plan.

Stepwise output is useful when it supports verification. It is risky when it is treated as evidence of genuine understanding by itself.

Back to top ↑

Retrieval, Tools, and External Systems

LLMs become more useful when connected to external systems. Retrieval-augmented generation can bring relevant documents into context. Tool use can allow calculations, code execution, database queries, web searches, calendar actions, file analysis, or structured workflows. Agents can plan across multiple tool calls and environments.

These extensions change the system from a language model into a broader procedural system. The reliability of the output now depends on retrieval quality, tool correctness, permission boundaries, data freshness, action constraints, logging, and human oversight.

Tool use can reduce hallucination in some contexts, but it also adds new failure modes. A tool-using model must be evaluated as a system, not as text generation alone.

Back to top ↑

Hallucination, Error, and Verification

Hallucination occurs when a model produces information that is unsupported, false, fabricated, misattributed, or misleading while presenting it fluently. Hallucination is not just an occasional defect. It is connected to the generative nature of language modeling: the model produces plausible continuations, not guaranteed facts.

Verification is therefore central. Users should check sources, calculations, code execution, legal or medical claims, factual assertions, citations, dates, and any output used for consequential decisions. Systems should provide retrieval, citations, uncertainty signals, refusal behavior, testing, and escalation paths when stakes are high.

The practical question is not whether LLMs can ever be useful despite hallucination. It is which workflows make their outputs checkable before they matter.

Back to top ↑

Evaluation, Benchmarks, and Limits

LLMs are evaluated through benchmarks, human preference studies, task tests, safety probes, red-team exercises, retrieval evaluations, calibration checks, factuality tests, coding tests, mathematical reasoning tasks, robustness tests, and real-world monitoring. Evaluation is difficult because language-model behavior depends on prompt, context, tool availability, decoding settings, task framing, and user expectations.

Benchmarks can reveal capabilities, but they can also mislead. A model may perform well on a benchmark but fail in deployment. A benchmark may be contaminated, overfit, culturally narrow, outdated, or poorly aligned with the actual use case. Evaluation should be broad, contextual, and repeated.

An LLM should not be evaluated only by how impressive it sounds. It should be evaluated by how reliably it supports a defined task under realistic conditions.

Back to top ↑

Human Oversight and Decision Support

LLMs are often safest when used as decision-support systems rather than decision-makers. They can help organize information, suggest alternatives, draft language, identify questions, structure evidence, propose tests, generate checklists, and surface uncertainties. But humans and institutions remain responsible for decisions, especially in high-stakes contexts.

Human oversight must be substantive. A person clicking approve without time, expertise, authority, or access to evidence is not meaningful oversight. Oversight requires visible sources, reviewable reasoning artifacts, clear responsibility, training, escalation, and the ability to reject the model’s output.

A human-in-the-loop design is only meaningful if the human can understand, question, and change the outcome.

Back to top ↑

Governance and Responsible Use

LLM governance must address more than model capability. It should cover intended use, prohibited use, source grounding, data privacy, security, prompt injection, tool permissions, copyright and attribution, monitoring, red teaming, documentation, incident response, human review, and affected-person rights.

Because LLMs operate through language, they can move across domains quickly. A system built for drafting may be used for advice. A summarizer may become a decision-support tool. A chatbot may become an institutional interface. Governance must anticipate use drift.

Responsible LLM deployment treats the model as part of an institutional system, not as an isolated text generator.

Back to top ↑

Representation Risk

Representation risk appears when LLM outputs are mistaken for understanding, authority, neutrality, or evidence. Language models compress patterns from many sources into fluent outputs. That fluency can make uncertain claims appear settled, contested values appear technical, and speculative reasoning appear verified.

The risk is especially strong because language is persuasive. A model can produce polished explanation, careful tone, and structured reasoning even when evidence is weak. Institutions may then use the output to justify decisions without sufficient review.

LLMs can help represent knowledge, but they can also overrepresent certainty. Responsible use keeps representation tied to evidence and accountability.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

A language model often estimates a distribution over the next token:

A full sequence probability can be factorized as:

Self-attention can be expressed as:

A training objective can be written as minimizing negative log likelihood:

A retrieval-augmented response can be represented conceptually as:

A verification score can be modeled as:

These formulas show why LLM reasoning should be treated computationally: it involves probability, representation, attention, context, retrieval, generation, and verification.

Back to top ↑

Python Workflow: LLM Reasoning Audit

The Python workflow below creates a dependency-light audit for LLM-style procedural outputs. It does not call an external model. Instead, it evaluates synthetic model responses against expected procedural requirements, source-grounding checks, citation presence, risk flags, and verification status. This keeps the workflow reproducible while illustrating how LLM reasoning outputs can be audited.

# large_language_models_procedural_reasoning_audit.py
# Dependency-light workflow for auditing LLM-style procedural outputs,
# source support, constraint satisfaction, verification status, and risk flags.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
from statistics import mean
import csv
import json
import re
from datetime import datetime, timezone

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"
JSON_DIR = ARTICLE_ROOT / "outputs" / "json"


@dataclass(frozen=True)
class LLMAuditConfig:
    article: str = "large_language_models_and_procedural_reasoning"
    minimum_steps: int = 3
    require_citations_for_factual_claims: bool = True
    risk_terms: tuple[str, ...] = ("guaranteed", "always", "never", "proven", "certain")


def timestamp_utc() -> str:
    return datetime.now(timezone.utc).isoformat()


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        path.write_text("", encoding="utf-8")
        return
    fieldnames = sorted({key for row in rows for key in row.keys()})
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=fieldnames, extrasaction="ignore")
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    path.write_text(json.dumps(payload, indent=2, sort_keys=True), encoding="utf-8")


def sample_outputs() -> list[dict[str, object]]:
    return [
        {
            "case_id": "summary_001",
            "task": "summarize sourced policy note",
            "output": "Step 1: identify scope. Step 2: extract claims. Step 3: compare evidence. The policy note says implementation depends on agency capacity [source:a].",
            "expected_sources": "source:a",
            "stakes": "medium",
            "requires_factual_support": 1
        },
        {
            "case_id": "code_002",
            "task": "generate data-cleaning function",
            "output": "Step 1: parse rows. Step 2: validate required fields. Step 3: return normalized records. Add tests for missing values.",
            "expected_sources": "",
            "stakes": "medium",
            "requires_factual_support": 0
        },
        {
            "case_id": "health_003",
            "task": "answer high-stakes health question",
            "output": "This treatment is guaranteed to work and you should always use it.",
            "expected_sources": "source:h",
            "stakes": "high",
            "requires_factual_support": 1
        },
        {
            "case_id": "research_004",
            "task": "compare two papers",
            "output": "Step 1: identify methods. Step 2: compare datasets. Step 3: review limitations. Paper A uses observational data [source:p1]; Paper B uses randomized assignment [source:p2].",
            "expected_sources": "source:p1;source:p2",
            "stakes": "medium",
            "requires_factual_support": 1
        },
        {
            "case_id": "planning_005",
            "task": "draft implementation plan",
            "output": "Step 1: define owner. Step 2: map dependencies. Step 3: set review checkpoint. Step 4: document risks.",
            "expected_sources": "",
            "stakes": "low",
            "requires_factual_support": 0
        }
    ]


def count_steps(output: str) -> int:
    return len(re.findall(r"Step\s+\d+", output, flags=re.IGNORECASE))


def extract_sources(output: str) -> set[str]:
    return set(re.findall(r"\[source:([A-Za-z0-9_\-]+)\]", output))


def expected_source_set(expected_sources: str) -> set[str]:
    if not expected_sources:
        return set()
    return {item.replace("source:", "").strip() for item in expected_sources.split(";") if item.strip()}


def risk_flags(output: str, config: LLMAuditConfig) -> list[str]:
    lowered = output.lower()
    return [term for term in config.risk_terms if term in lowered]


def audit_output(row: dict[str, object], config: LLMAuditConfig) -> dict[str, object]:
    output = str(row["output"])
    steps = count_steps(output)
    found_sources = extract_sources(output)
    expected_sources = expected_source_set(str(row["expected_sources"]))
    missing_sources = sorted(expected_sources - found_sources)
    flags = risk_flags(output, config)
    requires_sources = int(row["requires_factual_support"]) == 1

    procedural_score = min(1.0, steps / config.minimum_steps)
    source_score = 1.0
    if requires_sources:
        source_score = 1.0 if expected_sources and not missing_sources else 0.0
    risk_score = 0.0 if flags else 1.0
    high_stakes_penalty = 0.25 if row["stakes"] == "high" and flags else 0.0
    overall_score = max(0.0, mean([procedural_score, source_score, risk_score]) - high_stakes_penalty)

    status = "pass" if overall_score >= 0.80 else "review"
    if row["stakes"] == "high" and (flags or source_score < 1.0):
        status = "escalate"

    return {
        "case_id": row["case_id"],
        "task": row["task"],
        "stakes": row["stakes"],
        "steps_found": steps,
        "procedural_score": round(procedural_score, 6),
        "source_score": round(source_score, 6),
        "risk_score": round(risk_score, 6),
        "overall_score": round(overall_score, 6),
        "missing_sources": ";".join(missing_sources),
        "risk_flags": ";".join(flags),
        "status": status,
        "interpretation": "LLM outputs should be reviewed for procedural structure, source support, risk language, stakes, and escalation needs."
    }


def governance_register() -> list[dict[str, str]]:
    return [
        {"item": "intended_use", "review_question": "What tasks may the LLM support?", "status": "required"},
        {"item": "source_grounding", "review_question": "Which claims require citations or retrieved evidence?", "status": "required"},
        {"item": "tool_permissions", "review_question": "What tools or actions may the model initiate?", "status": "required"},
        {"item": "human_review", "review_question": "Who checks outputs before consequential use?", "status": "required"},
        {"item": "escalation", "review_question": "When must the output be escalated to expert review?", "status": "required"},
        {"item": "use_boundary", "review_question": "Where should the system not be used?", "status": "required"}
    ]


def main() -> None:
    config = LLMAuditConfig()
    rows = sample_outputs()
    audits = [audit_output(row, config) for row in rows]
    summary = {
        "article": config.article,
        "timestamp_utc": timestamp_utc(),
        "cases_reviewed": len(audits),
        "cases_passed": sum(1 for row in audits if row["status"] == "pass"),
        "cases_requiring_review": sum(1 for row in audits if row["status"] == "review"),
        "cases_escalated": sum(1 for row in audits if row["status"] == "escalate"),
        "mean_overall_score": round(mean(float(row["overall_score"]) for row in audits), 6),
        "interpretation": "LLM procedural outputs should be treated as reviewable artifacts, not self-validating reasoning."
    }

    write_csv(TABLES / "llm_sample_outputs.csv", rows)
    write_csv(TABLES / "llm_reasoning_audit.csv", audits)
    write_csv(TABLES / "llm_governance_register.csv", governance_register())
    write_csv(TABLES / "llm_audit_summary.csv", [summary])

    write_json(JSON_DIR / "llm_audit_config.json", asdict(config))
    write_json(JSON_DIR / "llm_reasoning_audit.json", audits)
    write_json(JSON_DIR / "llm_audit_summary.json", summary)

    print("LLM reasoning audit complete.")
    print(TABLES / "llm_audit_summary.csv")


if __name__ == "__main__":
    main()

This workflow illustrates a simple principle: LLM outputs should be reviewed as artifacts with procedural structure, evidence requirements, risk flags, and escalation conditions.

Back to top ↑

R Workflow: Reasoning Evaluation Summary

The R workflow reads the generated CSV outputs, summarizes the audit statuses, visualizes score patterns, and writes an additional diagnostic table.

# large_language_models_procedural_reasoning_summary.R
args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")
dir.create(tables_dir, recursive = TRUE, showWarnings = FALSE)
dir.create(figures_dir, recursive = TRUE, showWarnings = FALSE)

audit_path <- file.path(tables_dir, "llm_reasoning_audit.csv")
summary_path <- file.path(tables_dir, "llm_audit_summary.csv")

if (!file.exists(audit_path)) {
  stop(paste("Missing", audit_path, "Run the Python workflow first."))
}

audit <- read.csv(audit_path, stringsAsFactors = FALSE)
summary <- read.csv(summary_path, stringsAsFactors = FALSE)

png(file.path(figures_dir, "llm_audit_status_counts.png"), width = 1000, height = 750)
status_counts <- table(audit$status)
barplot(status_counts,
        ylab = "Count",
        main = "LLM Procedural Reasoning Audit Status")
grid()
dev.off()

png(file.path(figures_dir, "llm_audit_score_components.png"), width = 1200, height = 850)
score_matrix <- t(as.matrix(audit[, c("procedural_score", "source_score", "risk_score", "overall_score")]))
barplot(score_matrix,
        beside = TRUE,
        names.arg = audit$case_id,
        las = 2,
        ylab = "Score",
        main = "LLM Audit Score Components")
legend("bottomright",
       legend = rownames(score_matrix),
       cex = 0.75,
       bty = "n")
grid()
dev.off()

r_summary <- data.frame(
  cases_reviewed = summary$cases_reviewed[1],
  cases_passed = summary$cases_passed[1],
  cases_requiring_review = summary$cases_requiring_review[1],
  cases_escalated = summary$cases_escalated[1],
  mean_overall_score = summary$mean_overall_score[1],
  diagnostic_note = "LLM outputs should be reviewed for source support, procedural adequacy, risk language, and escalation requirements."
)

write.csv(r_summary, file.path(tables_dir, "r_llm_reasoning_summary.csv"), row.names = FALSE)
print(r_summary)

The R layer turns procedural output review into a visible diagnostic summary that can support governance, auditing, and workflow improvement.

Back to top ↑

GitHub Repository

The companion repository contains reproducible workflows, synthetic data, audit outputs, calculators, documentation, and multilingual examples for this article.

Back to top ↑

A Practical Method for Reviewing LLM Reasoning

LLM reasoning should be reviewed as a workflow, not just as an answer. A good review asks what the task was, what sources were used, what steps were taken, what tools were involved, what could go wrong, and who remains responsible.

This method treats LLM output as a draft, hypothesis, plan, or aid to reasoning — not as self-authenticating knowledge.

Back to top ↑

Common Pitfalls

LLM failures often arise when people treat fluent outputs as finished reasoning. A model can help generate a procedure, but that procedure must be evaluated.

The safest LLM workflows are designed around verification, not persuasion.

Back to top ↑

Why LLMs Require Computational Judgment

Large language models are major systems in the history of algorithmic and computational reasoning because they make language itself a programmable interface. They can summarize, classify, draft, translate, code, explain, retrieve, plan, and assist reasoning across many domains. They can also hallucinate, overgeneralize, conceal uncertainty, reproduce bias, misuse sources, and produce confident error.

The central question is not whether LLMs reason exactly as humans do. The better question is how they can support reliable procedures under explicit constraints. That requires prompts, evidence, tools, tests, citations, review, and governance. It also requires humility: a model that can produce a polished answer has not necessarily produced a verified answer.

LLMs should be treated as powerful computational instruments. They extend what people can draft, inspect, compare, and automate. But responsible reasoning still depends on evidence, interpretation, accountability, and human judgment.

Back to top ↑

Related Articles

• Neural Networks and Representation Learning
• Machine Learning as Algorithmic Inference
• Training, Testing, and Generalization
• Evaluation, Benchmarks, and the Limits of AI Measurement
• Automated Reasoning, Symbolic AI, and Hybrid Systems

Back to top ↑

Further Reading

• Vaswani, A. et al. (2017) ‘Attention is all you need’, Advances in Neural Information Processing Systems, 30.
• Brown, T.B. et al. (2020) ‘Language models are few-shot learners’, Advances in Neural Information Processing Systems, 33.
• Devlin, J., Chang, M.-W., Lee, K. and Toutanova, K. (2019) ‘BERT: pre-training of deep bidirectional transformers for language understanding’, Proceedings of NAACL-HLT 2019, pp. 4171–4186.
• Wei, J. et al. (2022) ‘Chain-of-thought prompting elicits reasoning in large language models’, Advances in Neural Information Processing Systems, 35.
• Liang, P. et al. (2022) ‘Holistic evaluation of language models’, Stanford Center for Research on Foundation Models.
• National Institute of Standards and Technology (2024) Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. Gaithersburg, MD: NIST.

Back to top ↑

References

• Bai, Y. et al. (2022) ‘Constitutional AI: harmlessness from AI feedback’. Anthropic. Available at: https://www.anthropic.com/research/constitutional-ai-harmlessness-from-ai-feedback.
• Brown, T.B. et al. (2020) ‘Language models are few-shot learners’, Advances in Neural Information Processing Systems, 33. Available at: https://papers.nips.cc/paper_files/paper/2020/hash/1457c0d6bfcb4967418bfb8ac142f64a-Abstract.html.
• Devlin, J., Chang, M.-W., Lee, K. and Toutanova, K. (2019) ‘BERT: pre-training of deep bidirectional transformers for language understanding’, Proceedings of NAACL-HLT 2019, pp. 4171–4186. Available at: https://aclanthology.org/N19-1423/.
• Liang, P. et al. (2022) ‘Holistic evaluation of language models’. Stanford Center for Research on Foundation Models. Available at: https://crfm.stanford.edu/helm/.
• National Institute of Standards and Technology (2024) Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. Gaithersburg, MD: NIST. Available at: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence.
• Stanford Institute for Human-Centered Artificial Intelligence (2026) The 2026 AI Index Report. Stanford, CA: Stanford HAI. Available at: https://hai.stanford.edu/ai-index/2026-ai-index-report.
• Vaswani, A. et al. (2017) ‘Attention is all you need’, Advances in Neural Information Processing Systems, 30. Available at: https://papers.nips.cc/paper/7181-attention-is-all-you-need.
• Wei, J. et al. (2022) ‘Chain-of-thought prompting elicits reasoning in large language models’, Advances in Neural Information Processing Systems, 35. Available at: https://proceedings.neurips.cc/paper/2022/hash/9d5609613524ecf4f15af0f7b31abca4-Abstract-Conference.html.

Back to top ↑