Compare contract and specification versions with local AI: every change and what it means

Comparing two versions of a document with local AI

To compare two versions of a contract or a technical specification with AI, a classic comparison first finds every changed passage, and a language model on your own workstation then sorts the changes and explains the ones that matter: a new obligation, a moved deadline, a tighter tolerance, a different liability cap. The model quotes the old and the new wording side by side, and a person in purchasing, legal or engineering decides what to accept. By our users-per-card rule, one NVIDIA RTX PRO 5000 Blackwell with 48 or 72 GB runs Qwen3.8-27B, a 27-billion-parameter model that reads up to 262,144 tokens, for a department.

The situation is common. A supplier returns the framework agreement as a clean PDF and writes that only "minor edits" were made. A customer issues revision C of a requirements specification (in German, the Lastenheft) with forty pages and no change log. Your own legal team receives the counterparty's third draft without tracked changes. Reading both versions line by line takes an afternoon, and the one changed word that matters is easy to miss on page 31.

This guide is for buyers, contract managers and engineers who do that comparison and for the IT colleague who sets it up. Comparing a supplier's terms with your own purchasing terms is a different task, covered in our guide to contract review in purchasing; here the question is what changed between two versions of the same document. Checking packaging and label PDFs against the approved master text is a third task, covered in our guide to packaging artwork checks before print.

What a word comparison shows and what it leaves to you

A comparison program, often called a diff, lists every inserted and deleted word between two texts. Word's Compare function, in its legal blackline mode, "compares two documents and displays what changed between them in a third new document", with the changes shown as tracked changes; the documents being compared stay unchanged, and you choose whether comments and formatting count. LibreOffice Writer's Compare Document marks text that appears only in the newer version as an insertion and removed text as a deletion, again as tracked changes to accept or reject; its help page states that the review function is available for text documents and spreadsheet documents.

Word support article on the legal blackline option, LibreOffice Help on comparing documents and the Python documentation for difflib, read on 30 October 2026; last row our description of the method below.

These tools are exact and complete for what they compare. They do not tell you which changes matter. A renumbered clause produces dozens of marks and means nothing; "shall" turned into "may" is one word and changes an obligation; a tolerance of ±0.05 mm that became ±0.1 mm is a few characters in a table. Word's article does not mention PDF files, and many revised documents arrive as PDFs, so a conversion step comes first.

The diff finds the changes, the model explains them

This method keeps the strength of each. The comparison program finds every change, and the language model reads only those changes with their surroundings and judges them. Because the list of changes comes from the diff, the model cannot add a change that the diff did not find, and every change stays on the list even when the model rates it wrongly.

1. Convert. Both versions are turned into structured text with headings, clause numbers and tables. Docling, an open converter under the MIT licence, reads PDF, DOCX, PPTX, XLSX, HTML and other formats; its description lists "page layout, reading order, table structure" among what it recognises, and it runs locally, in its own words "for sensitive data and air-gapped environments". Its latest release on PyPI, 2.145.0, came out on 29 October 2026.
2. Align. The two versions are matched by section and clause, so that a renumbering does not count as a change of every clause.
3. Diff. For each pair of sections, a comparison lists the changed passages with clause number and page. Python's difflib, part of the language's standard library, produces either a unified diff or a side-by-side HTML table "with inter-line and intra-line change highlights".
4. Explain. For each change, the language model receives the clause in both versions and the definitions it refers to, and returns the type of change (editorial or substantive; obligation, deadline, amount, tolerance, liability, scope), both wordings and one sentence on what changed in effect.
5. Check. A script confirms that every quoted wording appears word for word in its version; a quote that cannot be found sends the line back for review.
6. Decide. The reviewer goes through the list, sorted with substantive changes first, and the lawyer or the responsible engineer gets the lines that need them.

A second mode helps with cross-references. When a definition changes, for example of "delivery date" or "acceptance", clauses elsewhere change their meaning without a word of their own changing. Here the model reads both full versions in one request and answers a precise question: which clauses use the changed definition, and what changes for each. That needs a long context, covered below.

You can order the workstation alone, the setup of Docling, the comparison script and a local model alone, or both together: the workstation delivered with everything installed and configured; write to us and we suggest the best solution for your tasks and budget.

Finding changes in specifications, tables and tolerances

Technical specifications put the important values in tables: dimensions and tolerances, materials, test conditions, acceptance criteria. A comparison of plain text extracted from a PDF table tends to shuffle cells, so that one changed value produces a confusing block of changes. Docling recognises the table structure and exports rows and cells to Markdown, HTML or JSON, so a changed tolerance becomes a changed cell in a named row, which the model can report as "row 'Bore diameter', tolerance from ±0.05 mm to ±0.1 mm".

For speed, Docling publishes a benchmark: on a cloud instance with one NVIDIA L40S, its standard pipeline without OCR converted a 192-page PDF with 95 tables at 3.1 pages per second. A 200-page specification therefore takes about a minute to convert by our estimate, on comparable hardware. Docling's GPU page notes that table structure recognition is "currently not using GPU batching", so time a specification with many tables on your own hardware.

Ask the model to report every changed number with its unit and both values, and let a script check that both values occur in the source text. Drawings referenced by the specification need their own comparison; a scan needs text recognition first, as our guides to PDF parsing with Docling and MinerU and to vision-language models for document AI explain.

Document length, tokens and GPU memory

Language models count text in tokens, pieces of words. Our planning figure is 2 tokens per word for German; a preprint of May 2026 counts 1.76 on average, as our article on tokens per word in European languages reports. A 40-page contract of about 20,000 words is then about 40,000 tokens, and both versions together with instructions about 85,000, by our estimate. In the diff mode each request holds one changed clause with its context, a few thousand tokens by the same estimate; only the cross-reference mode needs both full versions at once.

Qwen3.8-27B is a model of the right size for this work. Its card gives a native context of 262,144 tokens, the licence is Apache 2.0, and two compressed builds exist: Qwen's FP8 version of 30.9 GB, with most weights in 8 bits, and NVIDIA's NVFP4 build of 21.9 GB, which stores most weights in a 4-bit format and is "ready for commercial or non-commercial use". The card does not list supported languages, so test with documents in every language you receive. Thinking mode, in which the model writes out its reasoning before the answer, is on by default and can be switched off per request; test both settings on your own changes.

The GPU memory holds the model and a working area for every request in progress. Our users-per-card rule takes 90 per cent of the memory the driver reports, less 3 GiB per card, less the weights. By our arithmetic from the model's configuration file, one request of 128K tokens, enough for both versions of a long contract, needs about 4.1 GiB of working area. A request of 32K needs about 1.1 GiB and the full 262,144 tokens about 8.1 GiB, with the working area kept in FP8 as in NVIDIA's serving example.

Our estimate by the users-per-card rule; weights from the Hugging Face file pages of nvidia/Qwen3.8-27B-NVFP4 (21.9 GB) and Qwen/Qwen3.8-27B-FP8 (30.9 GB); FP8 working area from the model's configuration file, read on 30 October 2026; the RTX PRO 6000 row applies to every edition.

A request of 128K tokens also takes processing time before the first word of the answer appears. We found no published figure for such long requests on RTX PRO cards, so check the response time with your own documents on the card you plan.

Which workstation for document comparison

The comparison is office work in bursts: a few documents a week in purchasing, more before a contract signing or a specification release. That favours one workstation per department, with a step up when several departments share it.

Our estimate by the users-per-card rule, from the memory table above; RTX PRO 5000 at 300 W from NVIDIA's product page; server as in our guide to contract review in purchasing.

The RTX PRO 5000 Blackwell draws up to 300 W and comes with 48 or 72 GB; the 72 GB card is the one that holds the FP8 build with room for several full-length comparisons. The RTX PRO 6000 Workstation Edition is a 600 W card, and two of them are the realistic maximum in one workstation; three or four RTX PRO 6000 Max-Q belong only in a chassis built for them with strong directed airflow. When comparison runs next to contract review and an assistant for all staff, a server fits better, as our guide to contract review in purchasing shows for a two-card server.

We build these workstations to order with the software you choose; send us the document types, their usual length and the number of comparisons per month, and our team replies with a configuration.

A test before you rely on it

Take ten pairs of real documents where the changes are known, for example negotiation rounds in which your lawyer kept tracked changes. The tracked changes are the answer key.

1. Check that the diff found every change in the key; it should, and a miss points to a conversion problem.
2. Count how many substantive changes the model rated as substantive, and how many editorial changes it rated as substantive by mistake.
3. Check every changed number, unit and date in the list against both versions.
4. Run the cross-reference mode on two changed definitions and check the clauses it names.
5. Repeat with documents in each language you receive, and with thinking mode on and off.

Our article on local LLMs and ChatGPT answer quality explains in plain words why models make such errors. Contracts carry your prices, volumes and the other party's terms; with the model on your own workstation they stay on hardware you control, the point of our article on trade secrets, NDAs and AI tools. The change list is a working document; the legal assessment of a change stays with your lawyer.

Notes for the IT team

1. Diff settings. difflib treats frequent items in long inputs as junk by default; its documentation says the heuristic is asymmetric and suggests "turning this heuristic off" where it hurts, so set autojunk=False for long documents.
2. Structured output. Request the change list as JSON against a fixed schema; vLLM accepts a JSON schema with each request.
3. Verbatim check. Confirm by script that every quoted wording occurs in its source version.
4. Model licences. Docling's code is MIT, and its README asks you to check the licences of the individual models it downloads.
5. Network. vLLM's --api-key protects only some paths (vLLM 0.32.0 security guide), so keep the model server on an internal network.
6. Memory per request. With an FP8 cache the model needs 32 KiB per token in its 16 full-attention layers plus about 0.14 GiB of state per request in its 48 linear-attention layers, by our arithmetic from its config.json.

Our Private AI/ML service deploys open models on-premise with vLLM or Ollama, so the documents do not leave your network.

FAQ