RAG у production: chunking, retrieval і чесні цитування

Усе нижче вимірюється на одному корпусі: перших тринадцяти розділах цього курсу — 13 документів, 359 067 символів, 127 секцій, без front matter і бібліографій. Це реальний технічний корпус із прозою, таблицями, формулами й code blocks, і це саме той тип матеріалу, який люди завантажують у knowledge base, а потім скаржаться.

Ground truth — це 32 запитання, кожне в парі з needle: коротким дослівним реченням із корпусу, яке на нього відповідає. Кожен needle трапляється рівно один раз у 359 067 символах, і жоден не є заголовком секції — ця перевірка важлива, бо chunker, який копіює заголовки в кожен chunk, інакше сам себе переоцінив би. Кожне запитання ставиться двічі: один раз мовою курсу, інший — так, як його формулює support ticket: 64 queries на 32 ground truths.

Retrieval правильний, коли повернений chunk містить needle цілком. Це єдине визначення, яке відповідає потребам generator: половина речення в prompt — не відповідь, а небезпека.

Embedding model — all-MiniLM-L6-v2: 384 виміри, mean-pooled і normalized, контрастивно навчена model, яку вимірював Розділ 8. Індексація корпусу займає 20,8 секунди на CPU, 22 ms на chunk; embedding одного query займає 13 ms.

Шість стратегій із трьох незалежних інгредієнтів. Blind ріже кожні 512 символів, не дивлячись на текст. Boundaries ніколи не ріже всередині абзацу, відступаючи до межі речення лише тоді, коли один абзац перевищує бюджет. Header додає перед кожним chunk назву документа й шлях секції. Overlap копіює останні 64 символи попереднього chunk у наступний.

Для 64 queries 95 % інтервал Вілсона на R@20 становить [0.471, 0.705] для A і [0.718, 0.901] для E — вони не перекриваються, але більшість інших колонок перекривається, і непарна таблиця не може їх розділити. Кожна стратегія відповідає на ті самі queries, тож чесний тест — парний: порахувати wins і losses кожної стратегії проти іншої та запустити sign test на discordant pairs. Три результати його переживають.

Blind chunking знищує чотири з тридцяти двох відповідей напряму. Не погано їх ранжує — знищує. Needle перетинає межу в 512 символів, тож жоден chunk в індексі не містить його, і recall ceiling для цих queries дорівнює нулю. Жоден reranker їх не відновить, жоден threshold не допоможе, жодна більша model не допоможе. Ви не можете retrieve текст, якого ніде в індексі немає одним шматком. Це найбільш недоговорений збій у RAG, бо він виглядає точнісінько як поганий retriever.

Overlap виправляє це і нічого більше. Кожна стратегія з overlap втрачає нуль відповідей — саме для цього overlap і потрібен. Він не покращує ranking: B проти A на R@8 — +8/−6, p = 0.79; на R@20 — +9/−7, p = 0.80. Гірше: додавання overlap поверх header активно шкодить — F проти E дає +2/−6 на R@20 — і причина механічна. Вектор chunk — це середнє за його tokens, тож 64 символи попереднього chunk тягнуть це середнє до теми сусіда. Overlap — це страховка від розрізаної відповіді, оплачена precision.

Contextual header — ось що купує retrieval. E проти A — +18/−3 на R@20, p = 0.0015. А ablation каже, що справа не в boundaries: E проти C — ті самі розрізи, єдина різниця header — +12/−2, p = 0.0129. Префікс "Classification, Cross-Entropy, and How Not to Fool Yourself > How many test examples do I need?" перед абзацом підказує embedding model, про що цей абзац, бо сам абзац часто цього не каже. Це pronoun resolver для документів.

Звідси форма chunker і одне правило, яке легко зрозуміти неправильно:

export interface Chunked {
  /** What gets EMBEDDED: contextual header + this chunk's own content. */
  text: string;              
  /** ONLY this chunk's own content: what is quoted back to the user. */
  content: string;           
  section: string;
  /** Character range in the document's canonical text. Sliceable. */
  from: number;
  to: number;
}

export function chunkDocument(doc: string, docTitle: string, target = 512): Chunked[] {
  const out: Chunked[] = [];
  const heads = [...doc.matchAll(/^## (.+)$/gm)].map((m) => ({ at: m.index!, title: m[1].trim() }));
  const spans = heads.length
    ? heads.map((h, i) => ({ ...h, end: i + 1 < heads.length ? heads[i + 1].at : doc.length }))
    : [{ at: 0, title: "", end: doc.length }];

  for (const s of spans) {
    const header = s.title ? `${docTitle} > ${s.title}` : docTitle;     
    const skip = /^## .+\n/.exec(doc.slice(s.at, s.end))?.[0].length ?? 0;
    const body = doc.slice(s.at + skip, s.end);
    const origin = s.at + skip;

    // The offset is FOUND in the document, never accumulated: adding up
    // lengths drifts by a character wherever a separator was normalised,
    // and a citation anchor off by one points at the wrong line.
    const emit = (from: number, to: number) => {
      const raw = body.slice(from, to);
      const lead = raw.length - raw.trimStart().length;
      const content = raw.trim();
      if (!content) return;
      out.push({ text: `[${header}]\n${content}`, content, section: s.title,
                 from: origin + from + lead, to: origin + from + lead + content.length });
    };

    let open: [number, number] | null = null;
    for (const m of body.matchAll(/[^\n]([^\n]|\n(?!\n))*/g)) {          // paragraphs
      const [pf, pt] = [m.index!, m.index! + m[0].length];
      if (pt - pf > target) {                                            // one huge paragraph
        if (open) { emit(open[0], open[1]); open = null; }
        let cur: [number, number] | null = null;
        for (const sm of body.slice(pf, pt).matchAll(/[^.!?]*[.!?]*\s*/g)) {
          if (!sm[0]) continue;
          const [sf, st] = [pf + sm.index!, pf + sm.index! + sm[0].length];
          if (cur && st - cur[0] > target) { emit(cur[0], cur[1]); cur = null; }
          cur = cur ? [cur[0], st] : [sf, st];
        }
        if (cur) emit(cur[0], cur[1]);
        continue;
      }
      if (open && pt - open[0] > target) { emit(open[0], open[1]); open = null; }
      open = open ? [open[0], pt] : [pf, pt];
    }
    if (open) emit(open[0], open[1]);
  }
  return out;
}

Два тексти, не один. text — це те, що отримує embedding, разом із header і всім іншим. content — лише власні слова цього chunk, і саме вони цитуються користувачу. Процитуйте text — і citation покаже header, якого в документі в цьому місці немає, а з overlap ще й повторений хвіст попереднього фрагмента. Тоді він показує текст не там, де стверджує, а це гірше, ніж не показувати нічого.

Header не безкоштовний. На 940 chunks він коштує 24 213 із 114 275 embedded tokens індексу: 21,2 % того, за що ви платите під час embedding, — це header, який ви написали самі. Він також притискає chunks до window encoder. all-MiniLM-L6-v2 приймає 256 word-pieces; у стратегії E 17 chunks за цією межею, у F — 28, і кожен тихо truncated без жодного попередження. Ваш ефективний розмір chunk — не число у config, а менше між ним і window вашого encoder.

Dense retrieval має одну системну слабкість, і вона зовсім не тонка: він зіставляє значення, тому байдужий до того, який саме рядок ви ввели. Номер деталі, код помилки, acronym, прізвище — нічого з цього не має корисного значення для embedding, а найближчий сусід коду помилки — кожен інший код помилки у вашому корпусі.

Класична відповідь старіша за все це й займає двадцять рядків. BM25 оцінює документ за тим, як часто terms query трапляються в ньому, приглушуючи кожен term зі зростанням частоти й караючи довгі документи, які накопичують збіги просто завдяки довжині.¹ Term $t$ додає

де $f_{t,d}$ — кількість term у документі, $|d|$ — його довжина, $\overline{|d|}$ — середня довжина, а $k_1 = 1.2$ і $b = 0.75$ — дві conventional constants: $k_1$ задає, як швидко повторення перестає допомагати, $b$ — наскільки сильно карається довжина.

const toks = (s: string) => s.toLowerCase().match(/[a-z0-9]+/g) ?? [];

export class BM25 {
  private tf: Map<string, number>[] = [];
  private len: number[] = [];
  private idf = new Map<string, number>();
  private avg = 0;
  private k1: number; private b: number;
  constructor(docs: string[], k1 = 1.2, b = 0.75) {
    this.k1 = k1; this.b = b;
    const df = new Map<string, number>();
    for (const d of docs) {
      const t = new Map<string, number>(); const ws = toks(d);
      for (const w of ws) t.set(w, (t.get(w) ?? 0) + 1);
      for (const w of t.keys()) df.set(w, (df.get(w) ?? 0) + 1);
      this.tf.push(t); this.len.push(ws.length);
    }
    this.avg = this.len.reduce((a, b) => a + b, 0) / this.len.length;
    const N = docs.length;
    for (const [w, n] of df) this.idf.set(w, Math.log(1 + (N - n + 0.5) / (n + 0.5)));
  }
  scores(query: string): number[] {
    const q = toks(query);
    return this.tf.map((tf, i) => {
      const L = this.len[i]; let s = 0;
      for (const w of q) {
        const f = tf.get(w); if (!f) continue;
        s += (this.idf.get(w) ?? 0) * (f * (this.k1 + 1)) /
             (f + this.k1 * (1 - this.b + (this.b * L) / this.avg));
      }
      return s;
    });
  }
}

На 940 chunks це оцінює query за 1,14 ms без жодного індексу, окрім двох hash maps. І це не музейний експонат:

BM25 більш ніж удвічі піднімає top-1 accuracy dense retriever на цьому корпусі й сильно програє йому до rank 8. Вони падають на різних queries — і це весь аргумент за те, щоб запускати обидва.

Поєднання їх — одне з місць, де очевидний підхід неправильний. Cosine distances і BM25 scores не в одній шкалі, не обмежені однаково, а нормалізація per query змушує weight залежати від того, наскільки добрим випадково був найкращий hit. Reciprocal rank fusion викидає scores і залишає лише ranks:²

/** Reciprocal rank fusion: ranks, not scores. Nothing to calibrate. */
export function rrf(lists: number[][], k = 60): number[] {
  const acc = new Map<number, number>();
  for (const list of lists)
    list.forEach((id, r) => acc.set(id, (acc.get(id) ?? 0) + 1 / (k + r + 1)));
  return [...acc.entries()].sort((a, b) => b[1] - a[1]).map(([id]) => id);
}

І тут чесне читання таблиці важливіше за саму таблицю. Hybrid перемагає BM25 на R@4 на +10/−3, p = 0.09. Він перемагає dense на +10/−6, p = 0.45. На цьому корпусі, з 64 queries, hybrid retrieval не відрізняється від dense retrieval статистично. Він кращий у point estimates і в кожній колонці recall, але доказ не досягає significance. Майже кожен blog post про hybrid search в інтернеті показує таблицю на кшталт наведеної й жодного інтервалу; ось що каже інтервал.

Усе досі — це bi-encoder: query проходить через model сам, кожен chunk пройшов через неї сам місяці тому, і вони ніколи не зустрічаються, окрім dot product. Саме це робить індекс можливим — embed один раз, reuse forever — і це ж є стелею. Model ніколи не дивиться на query і chunk разом.

Cross-encoder робить саме це: бере пару як один input і повертає relevance score. Нічого не можна precompute, тому він не може rank індекс — але може rerank shortlist. Reranking hybrid top 25 за допомогою ms-marco-MiniLM-L-6-v2 рухає R@1 з 0.094 (dense) до 0.312, а MRR з 0.280 до 0.447: найбільше одиничне покращення в цьому розділі й єдине, яке торкається верхівки списку, а не хвоста.

Це коштує 569 ms на query на CPU, проти 1,14 ms для BM25 і 0,3 ms для vector scan. Приблизно у дві тисячі разів дорожче за retrieval cost для двадцяти п’яти документів. Уся trade-off bi-encoder/cross-encoder в одному числі, і саме тому architecture завжди має одну форму: дешевий retriever із широким recall, потім дорогий scorer на shortlist, який ви можете собі дозволити. ColBERT стоїть між ними: precomputing per-token vectors і late interaction, дешевший за cross-encoder і гостріший за dot product.³

Vector databases повідомляють distances, а яка саме distance — це option у config. На normalised vectors вибір косметичний, і identity варто зробити один раз, бо все далі залежить від того, що vectors справді unit. Для $\lVert a \rVert = \lVert b \rVert = 1$:

тож cosine distance $1 - \cos\theta$ — це точно $d^2/2$. Це dot product і norm з Розділу 1, переведені в готівку. Перевірено на двох реальних chunk vectors з індексу вище, а потім на 40 000 парах:

||a|| = 1.000000   ||b|| = 1.000000
L2 = 0.795183   L2^2/2 = 0.316158   1 - cos = 0.316158   diff = 7.66e-08
max |L2^2/2 - (1 - cos)| over 200 x 200 pairs = 8.3e-07

Точно до floating-point noise — і лише тому, що vectors normalised. Пропустіть normalisation — і identity хибна, ваш threshold нічого не означає, а distance, яку повідомляє документ, залежить від довжини його тексту.

Тепер число, яке ніхто не виводить. Retriever завжди щось повертає: він сортує весь індекс і дає вам верх списку, незалежно від того, чи відповідь взагалі є в корпусі. Threshold — єдина частина системи, яка може сказати ні; а щоб його встановити, потрібні queries, які мають нічого не повернути. Ось тридцять: двадцять одне про речі, яких цей корпус справді не покриває — streaming, rate limits, prompt caching, JSON schemas, agent loops, vector databases, prompt injection, image generation — і дев’ять про паелью, паспорти й refund policies. Проти того самого індексу:

Розподіли розділяються — і перекриваються. Найгірший in-domain query далі від своєї відповіді (0.721), ніж найкращий out-of-domain query від нерелевантного абзацу (0.497), тож жоден threshold не робить правильними обидва. Sweep через реальний gate — залишити максимум чотири chunks і лише ті, що нижче cut:

Читайте останню колонку як блеф. Без threshold assistant тридцять разів із тридцяти дає впевнену, добре процитовану відповідь на "how do I renew my Spanish passport" з корпусу про backpropagation. На 0.675 він робить це десять разів із тридцяти. На 0.525 — двічі, і здається на дванадцяти запитаннях, на які міг відповісти.

Цей trade-off — product decision, і правильний його край залежить від того, скільки вам коштує неправильна відповідь. Що не підлягає переговорам — це існування останньої колонки. Якщо ви ніколи не вимірювали retriever на запитаннях, від яких він має відмовитися, у вас немає threshold — у вас є число.

Два з десяти блефів на 0.675 показують два способи, як це ламається.

query: "how much does prompt caching save on a long conversation"
  [1] d=0.497  13-inference-optimization > Prefill and decode are two different machines
  [2] d=0.532  13-inference-optimization > The cache is also the bill

query: "what is the capital of france"
  [1] d=0.671  12-reasoning > The model does not think. It computes for longer.
      "…it is why 'think step by step' does nothing for what is the capital of France."

Перший — near miss: корпус докладно пояснює KV cache, query про prompt cache, слова ті самі, і 0.497 ближче, ніж більшість правильних in-domain retrievals у всьому експерименті. Embedding не знає, що два caches з однаковою назвою — різні машини. Другий — literal match без відповіді: корпус містить точну фразу "what is the capital of France", використану як приклад запитання, що не потребує reasoning. Retriever має рацію; відповіді там немає. Будь-яка система, яка читає "I found something similar" як "I found the answer", на цій підставі заявить Paris — або, що гірше, не заявить.

Model не має окремої здатності для фактів. Створити істинне речення й створити правдоподібне — це та сама операція: next-token prediction з Розділу 8, і ніщо в цій операції не позначає, що є чим. Аналіз 2025 року, який переформулював це, стверджує, що training and evaluation pipeline активно винагороджує вгадування: benchmarks оцінюють binary accuracy і не дають credit for abstention, тож model, яка завжди відповідає, випереджає ідентичну model, що каже "I don't know", коли не знає, а post-training оптимізує саме це.⁶ Hallucination у такому читанні — не загадковий дефект. Це те, що ви отримуєте, коли оцінюєте multiple-choice exam без штрафу за неправильну відповідь.

Подивіться на форму. На прохання назвати вісім papers про contrastive sentence embeddings, з identifiers, Qwen2.5-0.5B-Instruct створив вісім рядків у ідеальному форматі. Усі вісім identifiers well-formed. Усі вісім ведуть до реальних papers на arXiv. Нуль із восьми — це заявлена paper.

claimed  arXiv:1907.06432 - Contrastive Sentence Embeddings for Text Retrieval
actual   A Neural Turing~Machine for Conditional Transition Graph Modeling

claimed  arXiv:1809.08669 - Contrastive Learning of Sentence Representations…
actual   Collapsing Superstring Conjecture

claimed  arXiv:1807.08669 - Contrastive Learning of Sentence Representations…
actual   Automatic Speech Recognition for Humanitarian Applications in Somali

Це мала model, і її rate — її власний; frontier model вигадує значно менше. Mechanism узагальнюється, і це причина правила нижче. Validator, який перевіряє "does this identifier exist", пропускає всі вісім, а користувач, натиснувши один, потрапляє на реальну сторінку реального архіву без способу зрозуміти, що mapping вигаданий. Збій не в identifier і не у format. Він в association — саме тій речі, яку language model створює через plausibility.

Отже: model пише [1] і [2], але ніколи не пише link. Числа посилаються на фрагменти, які retrieved сервер, а сервер — який точно знає, з якого документа й яких offsets походить кожне число, — потім додає document, label і URL. Model немає чого вигадувати, бо її ніколи не просять про єдину річ, яку вона вигадала б.

export function buildContext(question: string, hits: Scored[]) {
  const citations: Citation[] = hits.map((h, i) => ({
    index: i + 1,
    documentId: h.chunk.documentId,
    documentName: h.chunk.documentName,
    locatorLabel: label(h.chunk),
    fragment: `#char=${h.chunk.locator.flow.from},${h.chunk.locator.flow.to}`,  
    quote: h.chunk.content,          // the OWN content, never `text`
    cosineDistance: h.cosineDistance,
  }));
  const blocks = citations
    .map((c) => `[${c.index}] ${c.documentName} - ${c.locatorLabel}\n${c.quote}`)
    .join("\n\n");
  const prompt =
    `Answer using ONLY the numbered sources below. Cite every claim as [n].\n` +
    `If the sources do not contain the answer, say so and stop.\n\n` +
    `SOURCES\n${blocks}\n\nQUESTION\n${question}`;
  return { prompt, citations };
}

Запустіть це на початковому запитанні — і чотири chunks стануть 591-token prompt і таблицею, яку model ніколи не бачить:

[1] 04-classification  How many test examples do I need?      #char=28215,28701  d=0.594
[2] 04-classification  Three splits, and the leak…            #char=20329,20839  d=0.598
[3] 04-classification  How many test examples do I need?      #char=25873,26272  d=0.600
[4] 04-classification  How many test examples do I need?      #char=25554,25871  d=0.605

Locator — це частина, яку люди пропускають, а потім не можуть додати пізніше. #char=25873,26272 — це range у canonical text документа; для PDF еквівалент — #page=12, для audio або video — #t=132.4,158.9, для spreadsheet — sheet і A1 range. Ці дві речі не вигадки: #page= — це PDF Open Parameters, а #t= — W3C Media Fragments, які браузери нативно підтримують для video й audio elements. Citation без locator — це назва документа, а назва документа не є citation; це пропозиція користувачу піти й пошукати.

І коли нічого не проходить threshold, pipeline взагалі не доходить до model:

NO ANSWER: nothing under cosine distance 0.675 for "what is the offside rule in football"
NO ANSWER: nothing under cosine distance 0.675 for "how do i renew my spanish passport"
NO ANSWER: nothing under cosine distance 0.675 for "how do i build an agent loop with tools"

Це дешевша й надійніша відмова, ніж будь-яка інструкція в system prompt, бо це порівняння двох чисел, а не прохання до probabilistic system.

Кожне вимірювання в цьому розділі оцінює retriever і жодного разу не просить model написати відповідь. Це навмисно, і саме цей шматок більшість команд пропускає.

RAG system має два failure modes, які зовні виглядають однаково. Retriever не знайшов passage; або знайшов, але generator його проігнорував, суперечив йому чи змішав із тим, у що вже вірив. Оцінюйте лише final answer — і ці два випадки нерозрізненні, тож ви tuning prompts проти проблеми, яка живе у вашому chunker. Recall@k, MRR і answer-destroyed count не потребують generation call, вони достатньо дешеві, щоб запускати їх на кожному deploy, і це harness із Розділу 15 з іншою scoring function — той самий request, deadline, concurrency і tally, на фіксованому question set замість live conversation.

Публікуйте їх з інтервалами. Арифметика Розділу 4 застосовується без змін: для 64 queries recall 0.5 має 95 % інтервал Вілсона приблизно ±0.12, тож стратегія, яка випереджає іншу на чотири пункти, ще нічого вам не сказала. Використовуйте paired test щоразу, коли обидві стратегії відповідають на ті самі запитання, а тут це завжди так — саме він перетворив "E виглядає кращою за A" на p = 0.0015.

І остання чесність: RAG зменшує hallucination, але не прибирає її. Покласти правильний passage у prompt не змушує model ним користуватися, і literature говорить це ще з original paper.⁷ Дві речі погіршують це в production. Long contexts degrade — model надійніше знаходить інформацію на початку й наприкінці довгого prompt, ніж у середині, тож двадцять chunks замість чотирьох можуть знизити accuracy й підняти рахунок; цей ефект виміряно в Розділі 24. А retrieval може бути правильним і все одно недостатнім, як показали два caches вище. SelfCheckGPT позначає claims, які не переживають resampling;⁸ Self-RAG навчає model emit власні retrieve-and-critique tokens;⁹ TruthfulQA зробив failure mode зрозумілим із самого початку.¹⁰ Жоден не закриває gap, а система, яка подає retrieved text як proof, переплутала sourced із true.

Retriever — видима частина pipeline, чиї збої всі стаються раніше, у темряві. Три з них повторюються.

Extraction — місце, де content помирає. PDF — це не текст; це drawing instructions. Two-column layouts перемішуються, tables стають word soup, page headers повторюються в кожному chunk, а scanned page не має тексту взагалі, доки OCR не дасть його, з confidence. Усе виміряне вище припускало, що extractor виконав свою роботу; у production він часто цього не робить, і симптом виглядає як поганий retrieval на три шари далі.

Index stamped із model, яка його створила. Embeddings із двох models не порівнювані — не "менш точні", а саме непорівнювані, бо це points у різних spaces. Змініть embedding model — і кожен vector у store стає сміттям, доки його не перебудують. Тому model name, dimension count, pipeline version і extractor version записуються поруч із кожним документом під час indexing. Без них у день upgrade ви не можете сказати, які документи stale, а які current, і напівмігрований index повертає впевнену нісенітницю без жодної помилки.

Один зламаний документ не має ламати folder, а counters мають рахувати те, що сталося. Документ, у якого впав extraction, завершується в state failed із причиною, видимою й retryable, тоді як інші дев’яносто дев’ять лишаються searchable; а кількість indexed chunks записує сервер, коли завершує роботу, а не client, коли uploads. Folder, який reports 400 fragments, а має 40, — брехня, що проявляється лише як unanswerable question.

Система в цьому розділі відповідає на запитання, відповіді на які записані. Вона retrieves їх, ranks їх, відмовляє, коли не може, і cites, де шукала. Це більшість того, чого люди хочуть від assistant над власними документами, і це обмежено одним конкретним способом: retrieval може повернути лише те, що хтось написав.

Залишається інша половина. Частина того, що ви хочете, аби model робила, взагалі не є фактом у документі — format, який вона має тримати, tone, taxonomy з чотирма сотнями labels, спосіб вирішувати, що живе в десяти тисячах минулих прикладів і в жодному абзаці. Retrieval не може це доставити, бо retrieve нічого; довший prompt лише платить рахунок Розділу 16 за опис skill замість самого skill.

Розділ 20 — про це рішення: fine-tune, retrieve чи prompt — і його висновок у тому, що рішення економічне раніше, ніж технічне: усі три оцінюються end to end на одному запитанні, а crossover — це token count. Запитання, з якого він починається, — те, на яке цей розділ не може відповісти. Не де записана відповідь, а що робити, коли її ніколи не було.

Усе виміряне в цьому розділі використовувало один корпус і один інструмент, і обидва reproducible. Корпус — розділи 1–13 цього курсу станом на 7 вересня 2026 року: 13 документів, 359 067 символів, 127 секцій, front matter і bibliographies removed. Ці розділи продовжують редагуватися, тож застосування того самого правила сьогодні дає на кілька тисяч символів більше: section count не змінився, як і кожен висновок нижче, але total characters — snapshot і позначений як такий. Ground truth — 32 запитання, кожне в парі з дослівним реченням, яке трапляється рівно один раз у корпусі й ніколи не є section heading, поставлені у двох phrasing для 64 queries. Retrieval embeddings — sentence-transformers/all-MiniLM-L6-v2 (384 dimensions, mean-pooled, L2-normalised, 256-token window); reranking — cross-encoder/ms-marco-MiniLM-L-6-v2 over the top 25; generation example — Qwen/Qwen2.5-0.5B-Instruct with greedy decoding. Усі timings — single-threaded CPU. Жоден paid API не викликався для створення цього розділу, тому кожна latency тут локальна й позначена як така.

Chunker, показаний у TypeScript, — той самий chunker, який вимірювався: Python instrument, що реалізує те саме правило, і ts/chunk.ts були порівняні chunk за chunk на всьому корпусі й збігаються на всіх 940 chunks, texts і offsets. Intervals — Wilson at 95 %; paired comparisons — two-sided exact sign tests on the discordant pairs.

Усі чотирнадцять identifiers, процитовані вище, були resolved через arXiv API і перевірені title by title 7 вересня 2026 року — що, з огляду на ті вісім, які такими не були, здається найменшим, що міг зробити саме цей розділ.