ChatGPT can make mistakes because it generates likely text rather than verified facts. It has no built-in fact-checker, no live source of truth, and no memory of what it actually read versus what it plausibly invented. It also cannot reliably confirm which files you attached, so you must verify important information and re-check file selections yourself before relying on any output.

That distinction matters more than most users realize. A search engine retrieves pages it can rank and cite. A language model predicts the next token from patterns in training data, then presents the result in fluent, confident prose. Fluency is not evidence. The same mechanism that makes answers readable also makes errors sound authoritative, which is why checking important info is a skill, not a formality.

This explainer goes one level deeper than the usual summary. It covers how the errors arise, how often they occur, where the risk concentrates, the misconceptions people hold, and concrete steps you can take before you trust an answer or choose files for upload.

How the prediction mechanism fails

A language model learns statistical relationships between words from large text corpora. At generation time it scores candidate next tokens and samples among high-probability options. This produces coherent sentences because coherence is what the training data rewarded, not because the model consulted a database.

Several failure modes follow directly from that design. One is hallucination, where the model fills a gap with plausible-sounding content rather than admit uncertainty. Another is confabulated citation, where a real-looking reference, author, or date is assembled from fragments that were never verified together.

A third is overconfidence in committed errors. Once the model has stated something, later sentences tend to stay consistent with that claim, so an early wrong premise can propagate through an entire answer. This consistency is stylistic, not evidentiary. The model is staying on-topic, not confirming a fact.

Training and alignment add pressure toward helpful-sounding responses. Systems are tuned to answer rather than to refuse, which can suppress hedging on questions the model cannot actually resolve. Prompts like "are you sure?" often produce a different answer rather than a corrected one, because the model is responding to tone, not re-running a verification step.

The file-attachment problem

The phrase "choose files" points to a second, separate risk. When you upload a document, the model processes extracted text, not the original file, and it may see only a truncated portion of long files. It cannot always tell you whether an attachment loaded, whether the parser dropped tables or images, or whether it is quoting the file versus its own memory.

"no file chosen" is the reliable state the interface reports before a selection registers. Treat that indicator as the ground truth about attachment status, not a model's claim that it "sees" your document. If the model says it received a file that the interface shows as unchosen, trust the interface.

File-based errors cluster in predictable ways. Tables, footnotes, scanned images, and multi-column layouts are frequent casualties of text extraction. Long documents exceed context limits and get silently shortened. A model can then answer from the portion it saw while implying it read everything, which is the most dangerous form of partial processing.

Quantified context: how often and how badly

Public evaluations consistently show that error rates are question-dependent and often underreported by users. Benchmark studies of factual accuracy have found hallucination rates ranging from single digits on well-covered topics to well over 20 percent on obscure or recent questions, with rates rising sharply for citations, statistics, and niche technical details. The exact figures vary by model, date, and test design, so treat any single number as a range rather than a constant.

The pattern matters more than the precision. Errors concentrate where training coverage is thin: very recent events, proprietary datasets, local regulations, and precise numbers. They thin out where the topic is heavily documented and repeatedly represented, though popularity reduces error rate without eliminating it.

Confidence calibration is the deeper problem. Models tend to sound equally certain on questions they handle well and questions they handle poorly, so a user cannot rank answers by tone. Under time pressure, people accept the fluent answer, which is exactly when checking important info gets skipped.

Where errors concentrate: an edge-case map

Certain request types are high-risk by structure, not by accident. Anything requiring a specific figure, citation, date, or file quote invites fabrication because the format demands precision the model may not possess.

Refs and quotes: page numbers, study authors, statutes, and court holdings are frequently invented or mismatched. Precise statistics: percentages, dollar amounts, and conversion factors are often plausible but wrong. Recent events: anything after the training cutoff is unknown rather than merely outdated. File-specific claims: "as shown in your document" can describe text the parser never captured. Medical, legal, and financial specifics: dosing, deadlines, and eligibility rules carry consequences when wrong. Multi-step math and unit conversion: errors compound across steps and may be internally consistent yet incorrect.

This is not a list of topics to avoid. It is a list of outputs to verify before you act, because these categories combine high fabrication risk with high cost of being wrong.

Common misconceptions, and one professional caveat

The most persistent myth is that an improved model means the mistake problem is solved. Newer systems reduce many error classes, but the mechanism is unchanged: they still generate likely text. A better model shifts the error distribution; it does not install a truth oracle.

Another misconception is that citing a source proves accuracy. A model can produce a citation that looks real and is wrong, and it can cite a genuine source that does not say what was claimed. The presence of a reference is a formatting behavior, not evidence of verification.

A third is that "no file chosen" noise or a model's file claims tell you what happened. They often do not. Only the interface state and your own inspection of the source document are reliable.

The professional caveat: this is a compression-and-prediction system, not a retrieval system with a verification layer. Even well-calibrated confidence is statistical, and the model cannot audit its own factual basis in real time. Treat every output as a draft that needs a check proportionate to the stakes.

Comparing verification approaches

Different verification methods catch different errors, and no single method is complete. The table below ranks common approaches by what they detect and where they fail.

Method Best at catching Weakness Effort Use when
Manual source lookup Fabricated citations, wrong figures Slow, needs access to sources High Stakes are high
Cross-checking two models Obvious inconsistencies Shared training biases Low Early triage
Independent search engine Recent events, real sources Ranking noise, paywalls Medium Facts may have changed
Primary document review File-specific claims Requires the original file Medium Output cites your upload
Structured self-prompt Missing assumptions Model may still confabulate Low Planning and drafting
Expert human review Domain-specific nuance Cost and availability Very high Regulated decisions

The practical rule is to combine methods rather than trust one. A model cross-check flags obvious disagreements cheaply, then primary-document review and manual lookup resolve what remains. Effort should scale with consequence, not with how confident the answer sounds.

A timeline of a typical error

Errors rarely appear as a single wrong sentence. They develop across an interaction, and the time course below shows how a small gap becomes a confident falsehood.

Stage What happens Risk signal
Prompt received Ambiguous request, missing constraints Vague or overloaded question
Retrieval or recall Model draws on training patterns, not live facts No source offered
First claim A plausible detail is generated Specific number with no basis
Elaboration Later sentences stay consistent with the claim Detail grows more specific
File reference Model implies it read the upload Interface shows no file chosen
Confidence framing Hedging drops, tone firms up "Definitely" on a thin topic
User acceptance Output is copied without checking Deadline pressure

The important lesson is that the earliest stage is the cheapest place to intervene. Clarifying the request and asking for sources up front costs seconds; correcting a propagated error after you have acted on it can cost far more.

Practical actions before you trust an answer or choose files

Verification works best as a routine, not a rescue. These steps convert the general warning into specific behavior, and they apply whether you are drafting a memo, checking a statistic, or working with an uploaded file.

State the constraints explicitly: ask for sources, dates, and confidence, and request "unknown" over a guess. Separate recall from retrieval: for anything recent or numeric, ask the model to search or to flag that it cannot verify. Inspect the attachment state: confirm the interface no longer shows "no file chosen" before you rely on file-based answers. Quote and locate: ask the model to quote the exact passage from your file, then confirm the passage exists. Cross-check consequential claims against a primary source or a second independent tool. Scale effort to stakes: casual drafting needs a skim, while regulated or financial decisions need documented verification.

One threshold worth remembering: if an error would change a decision, a payment, a dose, or a legal position, treat the output as unverified until a human or primary source confirms it. Below that threshold, spot checks are proportionate. Above it, no amount of fluent phrasing substitutes for a check.

Limitations and what this cannot tell you

This explainer describes mechanisms that are stable across model generations, but it cannot give you a fixed error rate for your specific tool, date, or question. Those numbers move with model updates, retrieval features, and test methodology, and presenting any single figure as current would be misleading.

It also cannot certify any particular answer as correct. Verification depends on the source you consult, and some claims, especially very recent or proprietary ones, may be unverifiable through public means. In those cases the honest conclusion is that the model's output is a hypothesis, not a finding.

File handling adds a further limit. Parser behavior, context limits, and interface indicators vary by product and change over time, so the "no file chosen" check is a principle rather than a guarantee. Confirm attachment status in the interface you are actually using.

Finally, better prompting improves reliability but does not eliminate fabrication. Treat the warning in the title as a permanent operating condition, not a temporary bug to wait out. Checking important info is the durable skill.

This article is general educational information about how language models produce and misstate information. It is not a diagnosis, treatment plan, legal opinion, or investment recommendation, and it does not promise any outcome from using or verifying AI tools. For decisions with medical, legal, financial, safety, or similarly high-stakes consequences, consult a qualified local professional and confirm critical facts against primary sources.