Adapt a language model through a versioned corpus table
COUNT introduces a way to adapt a language model by changing corpus-count tables without retraining its weights. Treat the table, tokenizer and mixing settings as a release unit, with their own evidence and rollback route.
Keep development and test groups separate before comparing performance. No measured results are shown.
A language model could become more useful for a specialist domain by changing a table built from that domain’s text. COUNT (Counting Offline Unlocks N-gram Transformers), described in a preprint released on 14 October, explores this adaptation route. Its table can change after pretraining while the model’s learned weights remain fixed. (COUNT paper, section 5)
For a team developing an in-house model, this creates an interesting separation between expensive parameter training and subsequent corpus preparation. The data owner could provide a new domain table for an existing compatible checkpoint, the saved model weights. The architecture owner should treat that combination as a new candidate release, with a defined corpus, configuration and route back to the previous version.
Corpus counts become an input to generation
An n-gram is a short sequence of tokens, the units a model processes. COUNT stores frequent continuations and their scores in the host computer’s main memory. It uses those scores to combine learned token representations from the model’s output matrix and adds the resulting vector to the token input. The method therefore influences generation without inserting retrieved document passages into the prompt. (COUNT paper, section 2)
The authors test domain-table mixtures for mathematics, biomedicine and law on a billion-parameter COUNT backbone. Their reported improvements in prediction loss, a measure of how well the model predicts reference text, are more consistent than improvements in answer accuracy. These are research evaluations, not evidence of reliable specialist advice. The adaptation uses a model pretrained with COUNT, rather than a plug-in for any hosted language model. (COUNT paper, sections 3 and 5)
A hypothetical engineering publisher might investigate this design for terminology-sensitive drafting from an approved technical corpus. A new product family could prompt a candidate table rebuild while the checkpoint stays fixed. That is an opportunity to test whether corpus preparation can support a useful adaptation cycle. It does not establish that the resulting draft follows the latest manual or that a generated instruction has documentary support.
Where an answer must cite a particular approved passage, retain a separate evidence-retrieval path. A frequent continuation is not an approval record. In the publisher example, reviewers would still need the applicable manual and revision when checking a safety instruction. The table could influence language while the document system supplies the evidence for the claim.
Make the adaptation unit explicit
The released implementation exposes a base table, an optional second table and a mixing weight that sets their relative contribution. It also permits changes to the number of retained continuation candidates and n-gram orders used in evaluation. Its table-building pipeline counts token sequences, scores continuations and packs them with a build manifest.
Those settings make “the same model” an incomplete description of a comparison. A proposed release record should identify the checkpoint, tokenizer, corpus snapshot, table-build settings, resulting table and runtime mixture. Give the final combination an immutable identifier and record it with the evaluation and serving configuration. These are proposed operational controls, not features established by the paper.
| Proposed release record |
|---|
| Corpus and rules. The data owner can explain which material influenced the table. |
| Tokenizer and build rules. The engineering owner can check that token identifiers and table construction match the intended checkpoint. |
| Table and mix. The reviewer can distinguish a changed data contribution from a changed model. |
| Live and prior release. The service owner can restore a known combination when a candidate fails. |
A checksum establishes the identity of an artefact. It does not establish that the source corpus was suitable or the outputs were correct. Keep the data owner’s corpus decision and the service owner’s acceptance evidence beside the technical identifiers. Avoid an unversioned path called “latest” for the table used by a running service.
A table swap changes the candidate system
Swipe or scroll for the full diagram →
Treat the corpus table and its mixing settings as part of the released model configuration.
- Observed
- The authors adapt a pretrained COUNT model by changing corpus-count tables without updating its learned weights.
- Inference
- Approve and retain a compatible checkpoint, tokenizer, table and mixing configuration together.
- Evidence boundary
- Whether a particular organisational corpus improves the intended task, preserves other behaviour and fits the serving budget.
An architectural inference from COUNT, not a tested enterprise deployment or a model-performance chart.
Research supports testing adaptation through corpus counts. The proposed release unit combines a checkpoint, tokenizer, count table and mixing configuration. Useful enterprise behaviour and operating cost remain to be demonstrated.
- COUNT preprint · Section 5: inference-time table swapping
Reviewed 2026-10-15
This extends the earlier embedding-migration argument. That article addresses compatibility between query vectors and an index. Here, a corpus-derived table changes the generator’s input representation while the learned checkpoint remains unchanged. The release decision concerns the behaviour of that combined generator, including tasks outside the target domain.
Budget the serving path as well as the table build
The repository’s scope statement says the public implementation contains the core method but is not the optimised runtime used for the paper’s throughput measurements. Its table lookup runs in the trainer’s main process before each forward pass. Do not use a published throughput result as a capacity promise for an installation of that code.
The paper’s largest table occupies about 797 GB of host memory, used with backbone configurations from 370 million to a billion parameters. This is a substantial additional serving resource even though the table adds no learned parameters. (COUNT paper, section 3.2)
For a proposed deployment, measure memory, table-load time and response latency on the intended host. Include cold starts, concurrent requests and the capacity needed to retain the preceding table during a change. If the old and new configurations cannot coexist, the release plan needs an explicit interruption or another serving route. A smaller table may change both the hardware requirement and output behaviour, so preserve it as a separate candidate.
The data boundary also needs review. The paper’s ethics statement cautions that counts of rare, longer token sequences can reveal source fragments. A derived table should not automatically be treated as anonymous or freely shareable. (COUNT ethics statement)
Choose a bounded adaptation experiment
Begin with public or approved non-sensitive material and a task whose outputs a domain reviewer can assess. Keep evaluation documents outside the table-building corpus. Compare the original table with a candidate domain mixture on the same checkpoint and runtime settings, retaining a broader task set to detect losses outside the target domain. Report output quality and operating measurements separately.
The data owner should approve the corpus and its permitted use. The model owner should retain the complete configuration and demonstrate a return to the preceding release. Fund further work only if the domain benefit survives that comparison and fits the serving budget. If the requirement is simply to answer from current documents with citations, test the existing retrieval route first before committing to a different model architecture.