What is a large language model?
A large language model, or LLM, is a neural network trained on vast amounts of text. Most current generative LLMs work by repeatedly predicting the next token in a sequence. That produces fluent answers, summaries and drafts, but does not guarantee factual correctness. For document analysis, outputs requiring accuracy must be checked against source material outside the model.
A large language model is a neural network trained on very large amounts of text. Most current generative models produce their output autoregressively, and the central operation is deceptively simple: given a sequence of tokens, the model predicts a likely next token. It then adds that token to the sequence and predicts again. Repeated many times, this process can produce a covenant summary, a comparison table, a drafting suggestion or an answer to a question.
That description matters because it separates what an LLM does from what its output may appear to represent. A well-formed answer can look like the result of research, calculation or legal analysis. At the point of generation, however, the model is producing a statistically plausible continuation of the text it has received. Plausibility is built into the mechanism. Verification is not.
For professional document work, that distinction is the operating constraint. A model can be useful because it handles language flexibly. The same flexibility means that accuracy cannot be inferred from tone, detail or drafting quality. If an answer must be correct, the workflow needs a checking step outside the model.
What does next-token prediction mean?
A token is a unit of text processed by the model. It may be a word, part of a word, a punctuation mark or another short text fragment. When an LLM receives a prompt, the prompt is converted into tokens. The model uses those tokens, together with the patterns encoded during training, to assign probabilities to possible next tokens.
Suppose the prompt begins:
The agreement permits restricted payments only if
A model may assign relatively high probability to continuations involving conditions, baskets, leverage tests or the absence of a default. Which continuation it selects depends on the prompt, its training, its configuration and any source text included in its context. After selecting one token, it performs the calculation again for the enlarged sequence.
The model does not ordinarily retrieve a complete answer stored as a single record. It constructs the response token by token. This allows it to adapt language to unfamiliar questions and combine concepts in new forms. It also explains why small changes in instructions or context can change the result.
Generation settings can affect how the next token is selected. A lower-randomness setting generally favours more probable continuations. A higher-randomness setting permits more variation. Neither setting turns the model into a factual database. Reducing variation may make answers more consistent, but a consistently generated proposition can still be unsupported.
Why does prediction produce such fluent language?
During training, an LLM processes a large quantity of text and adjusts internal parameters to improve next-token prediction. Those parameters encode patterns across language: grammar, document structure, common associations, styles of explanation and relationships among concepts.
Legal and financial documents are highly patterned. Defined terms recur. Provisions use recognisable syntax. Exceptions, provisos and cross-references follow familiar forms. A model trained on extensive text can reproduce these structures and respond in language that resembles professional drafting.
This capability is broader than autocomplete in the everyday sense. The model can condition each new token on a long preceding sequence, allowing it to maintain a topic, follow formatting instructions and produce multi-paragraph analysis. It can transform text from one form into another: provision to summary, two clauses to comparison, or a set of findings to a memorandum.
But fluency measures whether the continuation fits linguistic patterns. It does not establish whether the continuation accurately describes a particular agreement. A model can produce a sentence with the cadence and vocabulary of a credit agreement analysis while misstating the governing basket, missing an exception or inventing a cross-reference.
Why are fluency and correctness separate?
The model's objective creates an asymmetry. It must output a next token to continue the response, even when the available context does not support a reliable answer. Unless the surrounding system imposes another control, the generation process has no independent requirement to locate evidence, reconcile conflicting clauses or decline to answer.
Consider a request to identify capacity under an investment covenant. A credible answer may require more than finding the word “Investments.” The analysis may need to trace defined terms, builder basket components, available amount conditions, ratio-based permissions, reclassification language, shared baskets and restrictions triggered by a default. It may also require arithmetic using current financial inputs that are not in the agreement.
An LLM can draft an answer that resembles this analysis without completing every underlying step. The response may be wrong in several distinct ways:
| Failure mode | What the output may do |
|---|---|
| Unsupported assertion | State a condition or permission not found in the supplied document |
| Omission | Summarise the main rule but miss an exception, proviso or incorporated definition |
| Cross-reference error | Attribute language to the wrong clause or describe a reference inaccurately |
| Calculation error | Apply the wrong input, sign, period or basket component |
| Source blending | Combine the supplied text with a familiar pattern from other documents |
| False precision | Supply a defined term, threshold or citation that sounds exact but lacks support |
These failures are often called hallucinations. The label can obscure the practical point: the model is still doing what its design asks it to do—producing plausible text. The error arises when plausible generation is treated as verified analysis.
What do training and fine-tuning contribute?
Training gives the model its broad capacity to process and generate language. Through repeated prediction tasks, the model develops internal representations that support drafting, classification, summarisation and question answering. The scale of the model refers broadly to the number of adjustable parameters and the amount of computation and data involved, not to a guarantee about any particular answer.
Fine-tuning is additional training directed at narrower examples or behaviours. It can make a model more likely to follow a preferred format, use domain terminology, classify provisions consistently or avoid certain response patterns. Related techniques can shape how the system follows instructions and handles unsafe or irrelevant requests.
Training and fine-tuning affect behaviour, but neither inherently supplies current transaction facts or proves that an answer matches a source document. A model fine-tuned on credit agreements may recognise covenant structures more readily. It can still confuse two baskets, overlook a qualifier or generate an unsupported threshold.
The distinction can be stated simply:
| Component | What it contributes | What it does not establish |
|---|---|---|
| Pre-training | General language patterns and broad conceptual relationships | Accuracy about the document currently under review |
| Fine-tuning | More consistent domain behaviour, terminology or output structure | Proof that a particular conclusion follows from the source |
| Prompting | Task instructions and relevant context | An independent check of the generated answer |
| External verification | Evidence, calculations and rule-based tests | The model's linguistic flexibility |
Better prompting can reduce ambiguity and focus the model on relevant material. It cannot alter the basic fact that the response remains generated text.
Does giving the model the document solve the problem?
Providing the source document is necessary for many document-analysis tasks, but it is not sufficient. The text must fit within the model's available context, and the relevant provisions must be identified. Long agreements create dependencies across definitions, schedules, exceptions and incorporated terms. A clause viewed alone may not support a reliable conclusion.
Retrieval systems address part of this problem by locating passages that appear relevant and placing them in the model's context. This can ground the answer in the agreement rather than relying only on patterns learned during training. It also creates an opportunity to return citations alongside the response.
Retrieval introduces its own questions. Did the search find every relevant clause? Did it retrieve the definition used by the clause? Was an amendment or joinder omitted? Does the cited passage actually support the proposition? If the wrong material enters the context, a well-drafted answer may faithfully elaborate on incomplete evidence.
Citations therefore need to be testable, not decorative. A useful citation identifies the source location closely enough for a reviewer or system to inspect the underlying language. The proposition should match the cited text, including its qualifiers. Merely asking the model to provide citations does not establish that the citations exist or support the answer.
What should verification look like in practice?
The checking method should follow the consequence of error. A brainstorming prompt may need little control. An extraction feeding an investment-capacity calculation requires more. A covenant conclusion used in an investment decision, negotiation or legal memorandum requires traceable support and professional review.
A robust workflow separates generation from verification:
- Identify the documents, versions and amendments that govern the task.
- Retrieve the operative provision, relevant definitions, exceptions and cross-references.
- Ask the model to produce a structured output with source locations and explicit assumptions.
- Validate quoted language, defined terms and citations against the document.
- Perform arithmetic and rule-based tests outside the model where possible.
- Escalate ambiguity, conflicting provisions and judgment-dependent conclusions to a qualified reviewer.
The external step is important. Asking the same model to “double-check” its answer may produce a useful revision, but it is not independent verification. The second response is generated by the same basic mechanism and may preserve the original unsupported assumption.
External checks can be mechanical. A system can confirm that a cited passage exists, recompute a total from extracted inputs, test whether every cross-reference resolves or flag output that lacks supporting text. Human review remains necessary where the result depends on interpretation, transaction context or legal judgment.
What is the right mental model for professional use?
Treat an LLM as a flexible language engine inside a larger analysis process. It is well suited to turning unstructured text into candidate answers, proposed classifications and readable drafts. It is not, by itself, the system of record or the final authority on what a document permits.
This framing avoids two common errors. The first is dismissing the technology because it can be wrong. Many useful professional tools produce intermediate results that require control procedures. The second is trusting an answer because it is fluent, specific and responsive. Those qualities show that the model generates language effectively; they do not prove the underlying conclusion.
For credit-document analysis, the most useful outputs expose their basis. They distinguish extracted text from interpretation, identify assumptions, link conclusions to operative language and leave calculations open to reproduction. The model supplies linguistic flexibility. The surrounding workflow supplies provenance, deterministic checks and review.
The core rule is straightforward: use fluency to accelerate the work, but use evidence to establish correctness.
Common questions
What does an LLM actually do?
Most current generative LLMs repeatedly predict which token should come next, based on the prompt, the preceding tokens and patterns learned during training. Repeating that prediction produces sentences, summaries, tables and other structured text.
Why can an LLM give a fluent but incorrect answer?
The model is optimised to produce a plausible continuation, not to prove that each statement is supported by a source. Fluent language and factual correctness are therefore separate properties, even when the response sounds precise and confident.
How should an LLM output be checked in document analysis?
Material claims should be tied to identifiable source passages and tested using a process outside the model's generation step. Depending on the task, that may include deterministic extraction, calculations, database checks, citation validation or human review.
Related
See this run against your own documents.
Book a demo