Chapter 1

A probabilistic machine in a world that demands determinism

When you open a spreadsheet, you trust the grid. Cell C14 equals the sum of cells C2 through C13 because arithmetic is mechanical, exact, and repeatable. If the formula produced a different total every second time you pressed recalculate, nobody in finance could build a model or defend a valuation.

When you bring a large language model into that same workflow, the tool speaks in sentences rather than formulas. It reads an earnings report, drafts an executive memo, and recites balance-sheet figures with complete poise. Because the voice sounds authoritative, the natural instinct is to treat the screen like an intelligent search engine or an audited corporate database.

It is neither.

To use this technology safely in business and finance, you must discard the metaphor of an electronic brain searching for facts. What sits on the other side of your network connection is a statistical instrument. It does not look up records. It does not verify statements. It predicts what word comes next.

The machine predicts the next word

A large language model is a prediction engine. Its behavior is an observed mathematical fact, not a theory or an opinion.

When you send a sentence to an LLM, the model does not search an internal filing cabinet of verified company data. It does not look up quarterly results in an internal relational database. Instead, it calculates the statistical probability of what word ought to come next, given all the words that came before it. Once it picks that word, it adds it to the sequence and calculates the probabilities all over again.

Sentence generation as a tree of probable next words

Every sentence the model generates is a path through a branching tree of possibilities. Starting from an opening word, the model evaluates candidate next words, selects one, and branches again. Standard financial phrasing emerges because certain paths through the tree carry overwhelming statistical probability from training.

When a financial sentence opens with the phrase The Board of Directors declared a quarterly..., the next word is almost certainly dividend. It will not be refrigerator or galaxy. In the model's vocabulary of standard business terms, the word dividend carries a massive probability score. The word distribution might carry a smaller score, while unrelated nouns score near zero.

"The Board of Directors declared a quarterly..."
  --> dividend     (88%)
  --> cash         ( 8%)
  --> distribution ( 3%)
  --> share        ( 1%)

The model selects among the high-scoring candidates. Once it emits dividend, the running context becomes: The Board of Directors declared a quarterly dividend of...

The model learned those word probabilities from a massive body of training text. During that training phase, the model adjusted billions of numerical parameters so that standard chains of words score higher probabilities than disorderly ones. When you ask it to draft a quarterly summary, it reproduces standard financial syntax because that syntax appeared millions of times in financial disclosures, press releases, and earnings calls.

Because financial reporting follows strict conventions, standard phrases have higher probabilities of emerging. But the machine is still predicting text, not querying a database.

Hallucinations happen because probability paths can branch in unexpected ways

Sometimes the language model does unexpected things and produces completely incorrect output. It invents balance-sheet items, confuses dates, or invents facts with complete confidence. In the technology industry, this failure mode is called a hallucination.

This mathematical probability is the exact reason why commercial chat harnesses print disclaimer banners warning that models can make mistakes. The vendor is not merely covering legal liability. They know the underlying machine has zero native mechanism to verify claims against external facts.

An unexpected branch commits the model to a hallucinated completion

Look at the red path at the bottom of the diagram. It looks like a joke, but it illustrates how hallucinations physically happen. The model does not verify statements against a ledger of facts; its only objective is to calculate statistical likelihoods. When the sequence reaches The company announced..., ninety-nine point nine percent of probability flows toward standard nouns like results or plans. But if a random draw lands on the zero-point-one percent sliver for a pizza party, the model does not apologize or reverse course. It locks onto the new path and lets probability complete the grammatical pattern: "The company announced a pizza party for all regional offices to celebrate fourth-quarter earnings." The grammar is flawless, but the substance is pure confabulation.

In real financial analysis, hallucinations are rarely this obvious. Instead of pizza parties, an unlikely branch leads to an imagined credit facility, an invented twenty-one percent effective tax rate, or a fabricated lawsuit settlement. Because the model speaks fluent financial dialect, the invention sounds completely genuine to an analyst reading the memo. This is why you can never rely on an LLM's authoritative tone: the model speaks with the exact same confidence when reciting audited filings as when inventing figures out of thin air. It is entirely possible for the machine to be confidently wrong.

Running scenario: Summarize an earnings release

Throughout this book, every chapter grounds its technical concepts in a single, continuous test case: the running scenario. You will follow one publicly traded corporation, Acme Industrial Technologies, and trace how language models handle its actual financial filings. In each chapter, you will find a paste-able, observe-only prompt that you can test directly in your own chat interface or script to witness the machine's behavior firsthand.

Our test begins with Acme Industrial Technologies releasing its fourth-quarter earnings report this morning. The press release runs several pages of operational commentary, financial statements, and segment breakdowns. You open your chat harness or submit an API request with an observe-only prompt that includes a noisy excerpt from the earnings release:

Document:
"Acme Industrial Technologies (NYSE: AIT) delivered a resilient finish to the fiscal year despite persistent supply chain friction in European markets. For the fourth quarter ended December 31, consolidated revenue reached $4,280 million, a 6% increase compared to $4,038 million in the prior-year period. Operating income expanded to $640 million from $595 million, reflecting price realization across heavy equipment lines. Full-year backlogs closed at record levels, though management noted cautious capital expenditure trends among regional industrial customers entering the first quarter."

Instructions:
Summarize the fourth-quarter performance for Acme Industrial Technologies.
State the total revenue and the year-over-year growth rate.
Use two concise sentences.

The model receives this prompt and generates its response:

Acme Industrial Technologies reported fourth-quarter revenue of $4,280 million, representing a 6% increase year-over-year. Operating income reached $640 million, supported by price realization across heavy equipment lines.

The output looks immaculate. The revenue figure of $4,280 million is accurate. The six percent growth rate matches the press release. The phrasing reads like a seasoned equity analyst drafted it.

The specimen number, $4,280 million, arrived intact because the prompt provided enough context for the model to link the company name, the quarter, and the reported figure together in a standard earnings summary chain. At this opening stage, the machine performed its prediction task smoothly.

What happens when you run this prompt a second time?

Here is the problem to think about before you move to the next chapter: what happens if you submit this identical prompt ten minutes from now? If you run the query tomorrow morning or paste it into a different analyst's browser window, will the prediction engine produce the exact same $4,280 million figure and identical wording, or can a probabilistic machine deliver a different answer to the exact same question?

The Leader's View: Treat generative text as prediction, not record retrieval

When evaluating an LLM for enterprise financial workflows, the primary operational rule is straightforward: never mistake plausible generation for verified record retrieval.

Ordinary corporate software relies on deterministic databases. When your accounting system runs an SQL query for fourth-quarter revenue, it retrieves an immutable, audited record from a table. The database either returns the exact recorded number or returns a system error. It never guesses, and it never rounds a figure because another number sounded more harmonious.

An LLM behaves differently:

  1. Output is conditional text: The model generates a sequence of probable words. It has no internal verification check that compares its output against truth.
  2. Confidence is a stylistic trait: The model speaks with equal poise whether it predicts an audited GAAP number from provided context or invents a plausible placeholder when context is missing.
  3. Accuracy claims do not transfer: A vendor claiming "99% extraction accuracy" measured that metric on their specific benchmark files. That rate tells you nothing about how the model handles your firm's custom debt schedules or non-standard credit agreements.

Operating rule to mandate

Never pipe raw generative text directly into an enterprise ledger, trading book, or client disclosure. In production systems, separate the prose from the data: use the language model to draft narrative templates and qualitative commentary that humans review and approve, but insert financial numbers deterministically from verified databases and audited source tables. If a workflow must extract numbers from unstructured filings, require a human analyst to verify and sign off on each extracted figure before it enters enterprise storage.

Questions to put to a vendor

When an AI vendor pitches automated financial extraction, ask two direct questions:

  1. What deterministic validation does your product run between the model's text generation and the final report?
  2. When the model encounters an ambiguous figure or missing footnote, does it emit a verifiable error code or does it predict the most plausible number?

Zoom-out: How sub-word tokens divide words and bills

Behind the scenes, language models do not process whole English words as single units. They break text into smaller fragments called tokens.

A token is typically three or four characters long. A short word like bank is a single token, while a technical or compound term like amortization splits into three or four tokens (am, ort, iz, ation). For common English text, a standard rule of thumb is that one token equals about 0.75 words, or 1,000 tokens equals roughly 750 words.

Here is how a standard financial sentence from our running scenario divides into discrete tokens:

Acme  Industrial  Technologies  reported  fourth-quarter  revenue  of  $4,280  million.

This mechanical division matters to finance practitioners for two reasons:

First, token boundaries explain why models frequently fail at basic character-level tasks. A model does not see individual letters; it sees token IDs. This is why early models famously struggled when asked how many times the letter r appears in the word strawberry. To human eyes, the letters are plain to see. But to the language model, strawberry is not a string of ten individual letters; it is two token IDs (straw and berry). Because the model cannot inspect the internal spelling inside a token, it guesses based on statistical likelihood rather than counting characters.

Second, tokens are the currency of AI economics. Vendors do not bill subscriptions by the minute or queries by the paragraph. Cloud providers meter usage strictly by the count of tokens sent into the prompt and tokens returned in the answer. Every word of an attached financial filing consumes tokens from your budget, and every long-winded response adds to the invoice.

To convert this to a working budget, consider the output the machine generates. When you ask a model to draft a concise two-page earnings memo or portfolio summary, it produces roughly 1,500 English words, or about 2,000 output tokens. At frontier model pricing of $25.00 per million output tokens, generating that entire written draft costs exactly $0.05 of machine compute. For comparison, a junior research associate earning $60 an hour might spend two hours drafting that same initial memo, costing the firm $120 in human labor. Understanding how words convert to tokens is what turns vendor pricing sheets from arbitrary units into concrete operational savings.