Fine-tune, retrieval чи prompt? Рішення — економічне

«Чи варто нам fine-tune?» звучить так, ніби це питання про модель. Насправді це питання про бюджет із формою, на яку не відповідає жоден benchmark: що оплачується один раз, що оплачується за питання і що доведеться платити знову щоразу, коли світ змінюється.

Три маршрути також не є трьома способами зробити одне й те саме, і постачальники говорять про це відвертіше, ніж більшість блогів. Власна таблиця OpenAI про те, для чого supervised fine-tuning найкраще підходить, перелічує чотири застосування: класифікація, нюансований переклад, генерація контенту в конкретному форматі та виправлення збоїв у дотриманні інструкцій.¹ Серед них немає «навчити модель чогось, чого вона не знає». Підсумок користі формулюється так: «ви можете використовувати коротші prompts із меншою кількістю прикладів і context data, що заощаджує token costs у масштабі й може зменшити latency» — аргумент про рахунок від компанії, яка продає цю функцію.

Отже:

• Fine-tuning навчає форми й поведінки. Тон, формат, форму відповіді, межу, яку можна продемонструвати, але важко описати. Найсильніша опублікована версія — Superficial Alignment Hypothesis з LIMA: знання приходить із pretraining, alignment переважно навчає, у якій підмножині форматів говорити — саме тому там вистачило тисячі відібраних прикладів.²
• Retrieval постачає факти, що змінюються. Це єдиний із трьох підходів, де правка у вашій документації доходить до відповіді без торкання моделі.
• Prompting покриває більшість реальних випадків і є чесною базовою лінією. In-context learning стало стандартом від часів Language Models are Few-Shot Learners: задача демонструється всередині prompt, і жодна вага не рухається.³

Дві вимірювальні статті закривають двері для помилки посередині. Ovadia та колеги порівняли внесення знань через unsupervised fine-tuning із внесенням через retrieval, і retrieval стабільно перемагав, зокрема на фактах, які базова модель уже бачила під час pretraining.⁴ Gekhman та колеги виміряли шкоду: приклади, що вводять нові знання, засвоюються повільно, а коли модель нарешті їх засвоює, її рівень hallucination на інших питаннях зростає.⁵ Навчання фактів через fine-tuning не просто не працює; воно погіршує відповіді, на яких ви не тренувалися.

Ця половина вирішена. Економічна — ні, і їй присвячена решта розділу.

Один кейс, три способи запуску: технічна підтримка по власній документації, яка змінюється щотижня.

Корпус реальний і лежить на цьому диску: 23 Markdown-документи, які один робочий програмний репозиторій тримає як внутрішню документацію — build guide, brand rules, translation brief, десять сервісних інструкцій, нотатки про performance і security. Виміряно через o200k_base, encoding з Розділу 7:

documents                              23
characters                        159,223
words                              22,194
tokens (o200k_base)                42,921
tokens with per-file headers       43,158

Сорок три тисячі token — зручний розмір для цього рішення: він вміщується в будь-яке сучасне context window, тож усі три маршрути справді доступні. На десяти мільйонах рішення приймається за вас, і це retrieval.

Тепер робота, яку виконує слово «щотижня». Зазвичай плинність документації просто стверджують; тут її пораховано з історії версій того репозиторію:

Документи рухаються приблизно через тиждень. Користувацькі тексти — а саме про них насправді питають службу підтримки — змінювалися щотижня відтоді, як існують, приблизно по двадцять commits на тиждень. Який би маршрут ми не вибрали, він має це витримати, і «як часто змінюється те, на чому ви тренувалися?» виявляється числом у вашому власному репозиторії, а не думкою.

До цього корпусу написали двадцять реалістичних питань підтримки, по одному на тему, і кожна цифра нижче обчислена на цих двадцяти.

Найпростіше, що працює: покласти весь корпус у system prompt, питання в кінець і дати моделі знайти відповідь.

system instructions                       140 tokens
the 23 documents                       43,158 tokens
the question (median of 20 measured)       13 tokens
the answer (the one assumption)           150 tokens

Усі числа там пораховано, крім останнього: 150 output tokens — це припущення, вибране в межах assistant turns, які тарифікував Розділ 16. Це єдина цифра тут, яку не виконували; її однаково застосовано до всіх трьох маршрутів, а розділ про break-even показує, наскільки саме рухається висновок, якщо її змінити.

За ставками, прочитаними на сторінці постачальника 7 вересня 2026 року — $1.50 за мільйон input tokens, $9.00 за мільйон output⁶ — це $0.066317 за питання. Ви платите за повторне читання сорока трьох тисяч token, щоб відповісти на тринадцять.

Виправлення з Розділу 16 застосовується напряму: корпус стабільний і стоїть на початку, тому це ідеальний cache prefix, а повторне читання коштує одну десяту — $0.007864 за питання, мінус 88 %. Застереження Розділу 16 також застосовується — у формі, яку той розділ позначив, але не оцінив. Цей постачальник не бере премії за запис; він бере оренду. Явний cache коштує $0.000001 за збережений token на годину,⁶ тож підтримувати 43,298 token теплими коштує

незалежно від того, чи хтось щось питає. Це $189.78 за шість місяців, за порожню кімнату. Поділіть оренду на економію за питання — і умова виходить в один рядок: caching цього корпусу окупається вище 0.74 питання на годину — 546 на місяць, якщо врахувати ще й щотижневу перебудову cache. Нижче цього функція, яку ви ввімкнули для економії, втрачає гроші.

Той самий маршрут, той самий код, один прапорець — і рахунок у п’ять разів більший. Розділ 16 знайшов версію цього, спричинену timestamp не в тому місці; тут нічого не зламано, крім трафіку. Cache — це ставка на обсяг, і в цього постачальника ви робите її погодинно.

Retriever з Розділу 19, без змін: різати по межах секцій із контекстним заголовком, індексувати, класти в prompt чотири найкращі фрагменти. Виміряно на двадцяти питаннях:

chunks produced from the corpus              330
mean tokens of a chunk's own text          124.9
mean tokens of the four retrieved extracts   884
prompt per question (140 + 884 + 13)       1,037
one-off embedding of every chunk        46,823 tokens

У сорок два рази менше prompt tokens, ніж у першому маршруті, за $0.002906 за питання. Індекс коштує $0.0070 побудувати за $0.15 за мільйон embedding tokens⁶ — менше, ніж три питання, — і ті самі $0.0070, щоб перебудувати його з нуля щоразу, коли документація змінюється. Перебудова всього індексу щотижня протягом шести місяців коштує вісімнадцять центів.

На одному варто зупинитися. Retrieval знищує prompt caching. Стабільний prefix тепер — 140-token system instruction; із token 141 prompt відрізняється в кожному виклику, бо фрагменти обираються під питання. А 140 token нижче за всі cache minimum, які цитував Розділ 16. Тож другий маршрут узагалі не можна кешувати, що звучить погано, але поганим не є: не кешувати 1,037 token дешевше, ніж кешувати 43,298.

Це загальне правило, яке варто забрати із собою: дві великі техніки економії token взаємовиключні на тому самому контенті, і перемагає та, що прибирає більше token. Retrieval прибирає 97.6 %.

Навчити на двохстах прикладах у фірмовому стилі, а потім ставити питання без жодної документації поруч.

training examples                            200
training tokens                           24,389
epochs                                         3
prompt per question (15 + 13)                 28

Training costs 24,389 × 3 × $10.00 за мільйон = $0.7317. Це вся вартість побудови, менше за чашку кави, і саме тому так багато команд платить її ще до перевірки, чи це допомагає.

Тепер пастка — причина існування цього розділу. Fine-tuned модель не коштує в запуску стільки ж, скільки її base model. Сторінка цін каже це одним реченням: «for model inference starting from Gemini 3, tuned model endpoint prediction price will be 1.5 times of the base model.»⁶ Не training. Inference — на кожному token, доки модель живе.

Тож запишімо формулу. Нехай $p_i$ і $p_o$ — базові input і output prices, $m$ — tuned multiplier, $L_R$ — prompt length маршруту, який ви замінюєте, $L_F$ — prompt length після fine-tuning, а $O$ — answer length. Fine-tuning дешевший за питання лише коли

Перший доданок очевидний: ваш новий короткий prompt із націнкою. Другий — ні, і саме туди йдуть гроші: надбавка на відповідь, яка не має нічого спільного з вашим prompt і яку training не може скоротити. З виміряними числами — $m = 1.5$, $L_F = 28$, $O = 150$, $p_o/p_i = 6$ — поріг такий:

answer   50 tokens -> the prompt it replaces must exceed   192 tokens
answer  150 tokens -> the prompt it replaces must exceed   492 tokens
answer  400 tokens -> the prompt it replaces must exceed 1,242 tokens
answer 1000 tokens -> the prompt it replaces must exceed 3,042 tokens

За виміряної довжини відповіді — 492 token, з яких 450 припадають на надбавку за відповідь, а не на prompt. Заміна коротшого prompt за це дорожча за питання, назавжди, за будь-якого обсягу; і поріг лінійно зростає з тим, скільки говорить ваш assistant, тож той, хто пише довгі відповіді, ніколи не зможе fine-tune собі дешевший token, хоч би скільки prompt видалив.

Та сама істина з іншого боку — речення, яке варто запам’ятати. Із $0.002088 за питання у fine-tuned маршруті 97.0 % — це відповідь. Fine-tuning оптимізує решту трьох відсотків.

Чотири числа описують будь-який із цих маршрутів: що ви платите один раз, що платите, коли документація змінюється, що платите погодинно незалежно ні від чого, і що платите за питання. Це розширює computeCost з Розділу 16 без змін у ній.

import { computeCost, type Pricing, type Usage } from "./cost";   // Chapter 16

export interface Route {
  name: string;
  setupUSD: number;            // paid once, before the first question
  perRefreshUSD: number;       // paid every time the documentation changes
  standingUSDPerHour: number;  // paid per hour whatever the traffic
  pricing: Pricing;
  usage: Usage;                // one question and its answer
}

export const perQueryUSD = (r: Route) => computeCost(r.pricing, r.usage);

const HOURS_PER_MONTH = (24 * 365.25) / 12;

export function totalUSD(
  r: Route, months: number, queriesPerMonth: number, refreshesPerMonth: number,
) {
  return r.setupUSD
       + months * refreshesPerMonth * r.perRefreshUSD
       + months * HOURS_PER_MONTH * r.standingUSDPerHour
       + months * queriesPerMonth * perQueryUSD(r);
}

/** Monthly volume at which `b` overtakes `a`. null = it never does. */
export function crossover(
  a: Route, b: Route, months: number, refreshesPerMonth: number,
): number | null {
  const fixed = (r: Route) =>
      r.setupUSD
    + months * refreshesPerMonth * r.perRefreshUSD
    + months * HOURS_PER_MONTH * r.standingUSDPerHour;
  const dFixed = fixed(b) - fixed(a);                     // b's extra fixed cost
  const dVar = perQueryUSD(a) - perQueryUSD(b);           // b's per-question saving
  if (dVar <= 0) return null;                             // b is never cheaper
  return Math.max(0, dFixed / dVar / months);
}

Tuned model — це не інший прайс-лист, а той самий, помножений:

const TUNED_MULTIPLIER = 1.5;   // read from the provider's pricing page, 2026-09-07

const scale = (p: Pricing, k: number): Pricing => ({
  input: p.input.map(t => ({ ...t, price: t.price * k })),
  cachedInput: p.cachedInput!.map(t => ({ ...t, price: t.price * k })),
  output: p.output.map(t => ({ ...t, price: t.price * k })),   
});

Один виділений рядок — це весь аргумент попередньої секції, записаний кодом: multiplier падає і на output теж.

Шість місяців, із щотижневим оновленням документації:

І crossovers — чотири числа, яких насправді потребує бюджет:

retrieval -> fine-tune, documentation never changes:     148 questions / month
retrieval -> fine-tune, documentation refreshed weekly: 3,989 questions / month
prompt (no cache) -> retrieval:                            1 question / month
prompt (no cache) -> prompt (cached):                    546 questions / month

Читайте перші два разом, бо це суть розділу. Стаціонарний корпус робить fine-tuning окупним за сто п’ятдесят питань; корпус, що змінюється щотижня, зсуває той самий crossover у двадцять сім разів, і в моделі нічого не змінилося — змінилося лише те, як часто ви платите за неї знову. Вартість побудови — примітка на полях; вартість підтримки — це рішення.

Якщо тепер ви робите висновок, що завантажена служба підтримки має fine-tune, арифметика з вами погоджується. Це все одно неправильно, і наступна секція пояснює чому.

У таблиці витрат є один стовпець, який вона не може обчислити, тож ця секція запускає fine-tune: локально, на невеликій відкритій моделі, з adapter, написаним вручну, а не взятим із бібліотеки. Розділ 11 побудував LoRA; ось вона на q_proj і v_proj усіх 24 шарів Qwen2.5-0.5B-Instruct з rank 8:

class LoRALinear(nn.Module):
    def __init__(self, base: nn.Linear, r=8, alpha=16):
        super().__init__(); self.base = base
        for p in self.base.parameters():
            p.requires_grad = False              # the model is frozen  
        self.A = nn.Parameter(torch.zeros(r, base.in_features))
        nn.init.normal_(self.A, std=1 / r)
        self.B = nn.Parameter(torch.zeros(base.out_features, r))
        self.s = alpha / r
        self.on = True                           # so the same run can compare both

    def forward(self, x):
        y = self.base(x)
        return y + (x @ self.A.T @ self.B.T) * self.s if self.on else y

Двісті training examples механічно походять із корпусу, тож їх можна відтворити: question — це заголовок секції, перетворений на питання, answer — власний текст цієї секції в жорсткому фірмовому стилі: один рядок починається з Short answer:, один рядок починається з Source: із шляхом до файлу. Формат — це форма, якої навчають; шлях — це факт. Далі два числа на двадцяти відкладених питаннях: чи виходить відповідь у фірмовому стилі, і чи називає вона файл, який справді відповідає на питання?

Дві базові лінії роблять таблицю читабельною, і обидві — це наполягання Розділу 4, а не пізня думка. Десять із двадцяти правильних відповідей — той самий файл, тож модель, яка ігнорує питання й завжди відповідає CLAUDE.md, набирає 10/20. І retriever має власну стелю: у цих двадцяти питаннях його чотири фрагменти містять правильний файл 14 разів і ставлять його першим 7 разів, тож 14/20 — максимум, який міг би набрати будь-який reader, що ним користується.

LoRA modules 48   trainable parameters 540,672 (0.109 % of the model)
400 steps, 2 epochs, 0.76 s/step on 16 CPU threads, 304 s in total
mean loss over the first 50 steps 3.7363 -> over the last 50 steps 2.4197

                                        house style   correct source
always answer the most common file             --          10 / 20
the retriever's own ceiling                    --          14 / 20
base model, closed book                    0 / 20           0 / 20
fine-tuned, closed book                   19 / 20           8 / 20
base model, four retrieved extracts       13 / 20           2 / 20
fine-tuned, four retrieved extracts        1 / 20           1 / 20

Форму було вивчено повністю й швидко. Від нуля до дев’ятнадцяти з двадцяти — за допомогою adapter на 540,672 параметри, 0.109 % моделі, за п’ять хвилин training на процесорі без жодної відеокарти поруч.

Факти — ні. Вісім із двадцяти не відрізняється від десяти, які ви отримуєте, якщо повністю ігноруєте питання, і interval з Розділу 4 на двадцяти samples каже це вголос. Ті file paths були в training data по три рази; назовні вийшла звичка завершувати правдоподібним рядком Source:. На питання з початку цього розділу fine-tuned модель відповіла Short answer: 10.x . . . і процитувала CLAUDE.md. Правильна відповідь, яка є в CLAUDE.md, — 18.17.0.

А потім форма зламалася — і саме цей рядок виправдовує експеримент. Дайте fine-tuned моделі тисячу token витягнутих фрагментів — prompt shape, якого вона ніколи не бачила, бо кожен training prompt мав двадцять вісім token — і фірмовий стиль падає з 19/20 до 1/20. На питання з початку розділу вона відповідає 18.17.0 — правильно і без жодного формату, для якого її тренували. Отже, fine-tuning не навчив формату; він навчив формату, умовного на prompts із training set, і перший prompt, який виглядав інакше, забрав формат із собою. Те, на чому ви fine-tune, стає єдиним input distribution, у якому ваша модель сильна, і ніхто не кладе це в spreadsheet.

Остання нотатка про metric, прямо до Розділу 29: «correct source» оцінює форму й факт разом, саме тому обидва рядки retrieval виглядають жахливо, хоча обидві моделі правильно відповіли на факт цього питання. Одне end-to-end число ховало три речі — retriever із 14/20 recall, 0.5B reader і citation format — а вибрати, що лагодити, означає розділити їх до вимірювання, а не після.

Тепер стовпець, який постачальники заповнюють за вас. Fine-tuned модель — не актив, яким ви володієте; це оренда чужої base model із надрукованою датою завершення. 7 вересня 2026 року в секції fine-tuning на сторінці цін OpenAI було таке повідомлення повністю:

OpenAI is winding down the fine-tuning platform. The platform is no longer accessible to new users, but existing users of the fine-tuning platform will be able to create training jobs for the coming months. All fine-tuned models will remain available for inference until their base models are deprecated.⁷

Timeline має дати до дня: 7 травня 2026 — закрито для організацій, які ніколи не робили fine-tune; 2 липня 2026 — закрито для тих, хто не запускав inference на fine-tuned моделі протягом шістдесяти днів; 6 січня 2027 — взагалі жодних нових jobs.⁸ Та сама сторінка планує вимкнення самих fine-tuned моделей — ft-gpt-3.5-turbo, ft-gpt-4, ft-gpt-4.1-nano, ft-babbage-002, ft-davinci-002 — на 23 жовтня 2026 року, кожна з рекомендованою replacement base model, що є ввічливим способом сказати: навчіть це знову.

Інший frontier-постачальник ніколи не продавав вам цю оренду. Індекс документації Anthropic містить 699 сторінок, і жодна не про fine-tuning; секції model customisation на сторінці цін Bedrock охоплюють Amazon Nova, Amazon Titan, Cohere, Meta та OpenAI open-weight models, але не Claude.⁹¹⁰ Якщо ваша архітектура залежить від fine-tune, одна з трьох frontier families для вас просто недоступна за будь-якого бюджету.

Self-hosting замінює оренду моделі орендою машини, і AWS рахує цю арифметику на власній сторінці: одна model unit provisioned throughput для custom model, зобов’язання на один місяць, — «1 model unit × $21.18 × 24 hours × 31 days = $15,757.92» на місяць.¹⁰ Орендувати залізо напряму дешевше, але не безкоштовно — $3.99 за GPU-hour on demand для H100, $1.99 preemptible¹¹ — приблизно $2,900 на місяць за одну карту, яка має бути ввімкнена незалежно від того, чи хтось питає. Увесь retrieval route на десяти тисячах питань на місяць коштує $174.52 за шість місяців.

Саме тут LoRA заслуговує на своє місце — як бюджетний аргумент, а не технічний. Виміряний на тій самій моделі rank-16 adapter поверх attention і feed-forward layers має 8,798,208 параметрів — 1.781 % моделі, 17.6 MB у bfloat16 — проти 0.988 GB базових weights, а його optimiser і gradient state займають 140.77 MB там, де повний fine-tuning потребує 7.90 GB, тобто у 56 разів більше. Наслідок — не дешевший training, а те, що одна завантажена base model може обслуговувати багато adapters, і лише так фіксована вартість GPU ділиться хоч на щось. Managed training це відображає: $0.48 за мільйон token для low-rank до 16B проти $0.54 full, із мінімумом $4.00 за job.¹¹ Поріг — важлива деталь. За 24,389 token на три epochs кожне retraining на цьому корпусі виставляється на $4.00, а не на $0.04, які виходять в арифметиці — $104 мінімальних оплат за двадцять шість щотижневих запусків за дев’яносто один цент арифметики.

Ще два стовпці, які з’являються лише в рахунку.

Data residency коштує близько десяти відсотків, і два постачальники сходяться на цій цифрі. OpenAI бере «10 % uplift» на data-residency endpoints для моделей, випущених 5 березня 2026 року або пізніше;⁷ Vertex оцінює свої non-global endpoints у $1.65 проти $1.50 — ті самі десять відсотків.⁶ Поставте це поруч із п’ятдесятьма відсотками, які коштує tuned endpoint, і фольклор перевертається: residency дешева, fine-tuning — ні; і fine-tuning усе одно не є приватним варіантом, бо корпус доходить до постачальника в будь-якому разі — один раз під час training замість одного разу на виклик.

Найпряміша ціна, яку будь-коли поставили на ваші дані, — на тій самій сторінці: одна fine-tuned модель наведена двічі; з увімкненим data sharing inference рівно вдвічі дешевший — $2.00 проти $4.00 input, $8.00 проти $16.00 output.⁷ Дозволити постачальнику зберігати те, що ви надіслали, варте 50 % знижки, і це показує, скільки воно варте для них.

Distillation — навчання власної малої моделі на відповідях великої — зазвичай пропонують як вихід із обох проблем. Порахуйте ціну, і це не вихід, бо teacher — це система, яку ви намагалися замінити: створити двісті training examples, поставивши retrieval route двісті питань, коштує 200 × $0.002906 = $0.58, додатково до $0.73 за training на них. Distillation — це те, що ви робите після того, як retrieval pipeline працює, щоб зробити її дешевшою, і вона успадковує кожен факт, який retriever отримав неправильно.

Гроші — видима половина. Інша приходить як очікування з тієї самої причини, що й рахунок: модель читає весь prompt, перш ніж сказати слово. Розділ 13 вимірював prefill проти decode на моделі, яку можна було помацати; ось те саме вимірювання, один запуск, одна машина, залежно від prompt length:

Абсолютні числа належать 0.5B моделі на шістнадцяти CPU threads і нічого не кажуть про hosted frontier model. Форма переноситься точно: prefill росте з prompt length, а cost per token повзе вгору, коли починає проявлятися квадратичний член із Розділу 9 — 4.79 ms на тисячі token проти 6.04 ms на восьми тисячах, штраф 26 % просто за довжину.

Наслідок для трьох маршрутів прямий. Перший маршрут prefills сорок три тисячі token на питання, і cache hit робить це терпимим — Розділ 16 пояснив чому: cache read замінює роботу prefill, тож купує latency і гроші однією транзакцією. Другий маршрут prefills тисячу й додає спершу round trip до індексу. Третій prefills двадцять вісім і нічого не додає, тому вимірювано найшвидше відповідає з трьох. Просто відповідає не на те.

Три збої, які виглядають як проблеми моделі, але ними не є — десять хвилин тут економлять місяць потім:

І вимога над усім цим: це рішення неможливо прийняти без evaluation set, і постачальник, який продає fine-tune, сам це каже. Гайд OpenAI починається з «Only invest in fine-tuning after setting up evals. You need a reliable way to determine whether your fine-tuned model is performing better than a base model» і додає: якщо п’ятдесят хороших прикладів нічого не змінюють, проблема в задачі або prompt, а не в обсязі даних.¹ Двадцять питань, як у цьому розділі, показують механізм і не можуть вибрати постачальника — Розділ 4 виміряв чому, а що робити, коли двадцять cases — це все, що у вас є, — повторювати їх, парувати їх і вимірювати розкид між запусками — це Розділ 29.

Чотири стовпці, і вирішує лише останній:

Правило, яке з цього випливає, досить коротке, щоб його запам’ятати: починайте з prompt; додавайте retrieval, коли факти рухаються; fine-tune лише тоді, коли ви виміряли, що вам досі бракує форми, а не факту — і перед цим рахуйте відповідь, а не prompt.

Незручна версія для тих, хто прийшов із готовим рішенням: у виміряному кейсі цього розділу fine-tuning є найдешевшим маршрутом вище чотирьох тисяч питань на місяць, але за фактами все одно не може перемогти відповідь CLAUDE.md на все.

Усі ціни тут були за token, і кожен маршрут був іншим способом розкласти token. Зараз це перестане бути правдою.

Розділ 21 залишає текст. Зображення, що входить у модель, — не рядок, а сітка patches із кількістю token, яку ви не обирали; хвилина мовлення в одного постачальника тарифікується по секундах, в іншого — по audio token; synthetic speech продають за character, transcription — за minute, raw compute — за GPU-second. Питання, на яке цей розділ відповів однією cost function — що дешевше? — навіть не можна поставити, доки одиниці не збігаються, і жоден калькулятор в інтернеті їх не нормалізує.

Там же знову з’являється training: image adapter із trigger word і voice, cloned зі sample. Це підводить до питання, з якого починається наступний розділ, і воно не риторичне: якщо fine-tuning мовної моделі майже завжди неправильна покупка, чому fine-tuning image model майже завжди правильна?

Кожну ціну, поріг і multiplier у цьому розділі прочитано на власній сторінці постачальника 7 вересня 2026 року і процитовано з цією датою, бо всі вони зміняться. Виміряні величини — token counts, chunk sizes, retrieval sizes, training loss, scores, latencies і version-history counts — були отримані на одній машині того самого дня й відтворюються з описаного вище корпусу.

Локальні експерименти використовували Qwen/Qwen2.5-0.5B-Instruct із greedy decoding, тож відтворюються точно; adapter — дванадцятирядковий class, надрукований вище, із rank 8 поверх q_proj і v_proj. Корпус — відстежувана Markdown-документація одного робочого програмного репозиторію, без двох append-only logs; частоту змін пораховано з історії версій цього репозиторію.