Lite Life ($LITE): long text, light serving

Package leaflet: information for the user

litefit 0.1.0: fitting long text to small model budgets by keeping the sentences a question needs

Read all of this leaflet before you rely on the numbers. It says what was measured, how, and what was not.

What is in this leaflet: 1. What litefit is and what it is used for · 2. What you need to know before you use it · 3. How it chooses · 4. How it was tested · 5. Possible side effects · 6. Contents of the pack and other information

1What litefit is and what it is used for

litefit is an extractive fitter: given a long text, a question and a budget in words or characters, it returns the sentences of the text that the question most likely needs, in their original order, and the reason each one was kept. It uses no language model: sentence splitting, a light stemmer, BM25 scoring and two readable rules. On a held-out set of 1,702 questions, each asked against its whole article (about 3,800 words), the answer is still in the fitted text for 88.8% of questions at 75 words, 95.5% at 150 and 97.9% at 300. BM25 alone keeps 86.5%, 94.2% and 96.5%.

2What you need to know before you use it

Background. On 6 October 2026 Engadget reported that from 9 October free accounts of Google's Gemini app would lose the Flash and Pro models and keep only Flash-Lite, described as Google's most cost-effective model; the $5-a-month AI Plus plan loses Gemini 3.1 Pro, Pro stays on the $20 plan, and new low, medium and high effort settings draw more of a user's limit as they rise [1]. Smaller models and tighter limits make the same request: send less, and send what matters.

Not connected. litefit, this site and $LITE have no connection with Google, Engadget, the authors of SQuAD or any maker of AI models, and none of them has seen this leaflet.

Words, not tokens. Budgets are counted in words (or characters). Tokenizers differ from model to model; in English a word is usually one or two tokens.

3How it chooses

Sentences. The text is split paragraph by paragraph; abbreviations (Dr., Sept., e.g.), initials and decimals do not end a sentence.

Score. Each sentence s gets BM25 against the question's content words q (stop words and question words removed; plurals, -ing, -ed and -ly folded; accents folded): Σ_t∈q idf(t) · f(t,s)(k₁+1) / (f(t,s) + k₁(1 − b + b·|s|/avg)), with k₁ = 1.2, b = 0.75 and idf counted over the sentences of the same text.

What the question wants. "When" and "what year" want a date, "how many" a number, "how much … cost" money, "who" a name, "where" a place; a sentence that already scores and holds that kind of thing gains 0.35 of the best score.

Next to a match. A sentence next to a higher-scoring one in the same paragraph moves half of the way towards it: answers often sit one sentence after the words of the question.

Fill. Sentences enter best first; one that would overflow is skipped and the next tried; the result is put back in document order, with "…" where text was cut. Pinned sentences enter first.

4How it was tested

Data. The development set of SQuAD v1.1 [2]: 48 Wikipedia articles and 10,570 questions whose answers people marked in the text. Each question is asked against its whole article, which always contains the answer; the article is cut to the budget; we count the questions whose answer (any of the marked versions, ignoring case, punctuation and articles) is still in the cut text.

Held out first. Before any rule was written, the 11 articles whose title's SHA-256 starts with 0–3 were set aside and their titles recorded. The rules were written and tuned on the other 37 (8,868 questions); the held-out 11 (1,702 questions) were scored once, after the rules were frozen. Lead (the opening), random sentences (seeded) and BM25 alone are the baselines.

Table 1. Answer kept, held-out set (11 articles, 1,702 questions).
Method	75 words	150 words	300 words

Table 2. Development set (37 articles, 8,868 questions; the rules were written on these).
Method	75 words	150 words	300 words

Table 3. Held out, question by question: kept by one and lost by the other.
Serving	litefit only	BM25 only

Table 4. Held out at 150 words, by what the question wants.
The question wants	Questions	BM25	litefit

Fetches the held-out file (455 KB), checks its SHA-256, and scores every question again, here.

5Possible side effects

Easy questions. SQuAD questions were written by people looking at the paragraph, so they share many words with it. Word-matching methods look better here than on questions written without the text in front of you: "arrival" does not find "we land".
Kept is not answered. The answer being in the serving is necessary, not sufficient. No language model was run.
A modest gain. Over BM25 alone the rules add 1.3 to 2.3 points on the held-out set; at 150 words litefit still misses 77 questions.
English, and a light stemmer. "buses" and "bus" do not meet; irregular verbs never do.
Greedy filling. A long, relevant sentence that does not fit is skipped in favour of shorter, weaker ones.

6Contents of the pack and other information

One file, src/litefit.js, with a command line, 11 tests, three examples, the held-out data and the script that rebuilds the split from the original file. MIT licence for the code; the data keeps SQuAD's CC BY-SA 4.0.

M. Moon, Engadget, 6 October 2026: Google removes free access to Gemini Flash and Pro starting October 9. engadget.com
P. Rajpurkar, J. Zhang, K. Lopyrev, P. Liang. SQuAD: 100,000+ Questions for Machine Comprehension of Text. EMNLP 2016. rajpurkar.github.io/SQuAD-explorer
S. Robertson, H. Zaragoza. The Probabilistic Relevance Framework: BM25 and Beyond. Foundations and Trends in Information Retrieval 3(4), 2009.
litefit 0.1.0, the library on this page (MIT), and its eval/ folder.

This leaflet was last revised in October 2026.

Lite Life

Prepare it yourself

On the shelf: $LITE

Taste test

Serving sizes

Package leaflet