Детекція знань у документах: як код відділяє факти від шуму, а модель дає їм ім’я
Уявіть, що потрібно знайти в тисячах розрізнених документів один конкретний факт: чому ухвалили саме таке рішення, яка вимога насправді обов’язкова, де саме це визначено. Найчастіше єдина відповідь — перечитати купу тексту заново, бо пам’ятати, у якому саме файлі що записано, неможливо.
Це науковий детектив: розслідування однієї підозрюваної тези. Машина здатна самостійно, детерміновано, без жодного суб’єктивного рішення людини чи мовної моделі, виділити з великого корпусу документів компактні, простежувані кандидати в об’єкти знань, розпізнати їхній тип і клас — і це дає практичну користь для пошуку та роботи мовних моделей. Єдиний доказ, який я приймаю, — виміряні числа, а не враження чи інтуїція.
Розслідування перевірило шість гіпотез на корпусі з 9 746 документів RFC (Request for Comments — технічні специфікації інтернет-протоколів, відкриті, стабільні, англомовні, і саме тому зручні як великий та різнорідний тестовий матеріал; вибір матеріалу, а не обмеження методу). Ця стаття зводить усі отримані результати в одне ціле — без покрокового відтворення кожного запуску, лише підсумкові таблиці й те, що виявилося цікавим.
Апаратна база незмінна для більшості експериментів: ноутбук HP EliteBook X360 830 G11, CPU Intel Core Ultra 5 135U (1,60 ГГц), вбудована відеокарта Intel Arc, нейро-прискорювач Intel AI Boost (NPU), 16 ГБ RAM, Windows 11; для окремих експериментів — локальний мережевий хост з відеокартою NVIDIA RTX 3080 (8 ГБ) під Ollama. Увесь код написано на Go 1.26.4.
Ідея і дисципліна: чому рішення ухвалює лише код
Знання в будь-якій організації, що працює довше кількох років, розпорошені по величезній кількості файлів різних форматів; знайти конкретний факт означає або пам’ятати, в якому файлі він записаний, або щоразу перечитувати багато тексту. Ідея дослідження: перетворити цю купу різнорідних документів на набір невеликих типізованих об’єктів знань (Knowledge Object, KO) — атомарних тверджень факту, кожне з яких прив’язане дослівною цитатою-доказом до місця в джерелі.
Головне правило, якого дослідження тримається від першого рядка коду:
Жодне рішення про те, чи існує кандидат у «об’єкт знання», не може залежати від думки людини чи ШІ. Або це вирішує детермінований алгоритм за наперед зафіксованим, перевірюваним правилом, або ж це вирішують лише виміряні надалі числа — а не будь-яка форма «прийняти/відхилити».
Мовну модель дослідження використовує лише у двох ролях: як об’єкт вимірювання (порівнюю її роботу з еталоном, який рахує код) і як класифікатор/іменувач над уже готовими, детерміновано побудованими даними. Вона ніколи не вирішує, чи кандидат існує, і ніколи не пише текст доказу.
Ще одне термінологічне уточнення, важливе для всього подальшого викладу: те, що детермінований код витягує з сирого тексту, я свідомо називаю кандидатом, а не готовим об’єктом знань. Кандидат — фрагмент із побайтовим походженням: доведено існує в джерелі, але сам не каже, що це за знання. Об’єктом знань кандидат стає лише тоді, коли до нього додається шар метаданих — тип (нормативна вимога чи структурне визначення), глибина (поверхневе форматування чи предметний зміст), домен. Це і є маршрут усього розслідування: від кандидата до повноцінного об’єкта знань.
Шість гіпотез і вердикт за числами
| Гіпотеза | Що перевіряє | Вердикт за числами |
|---|---|---|
| HYP-001 — простежуваність | Чи кожен кандидат, відібраний кодом, має дослівний, побайтовий доказ у джерелі | Підтверджено. 100% побайтових доказів і на 100 RFC, і на всіх 9 746 документах. |
| HYP-002 — користь пошуку | Чи пошук по кандидатах не гірший за пошук по сирому тексту | Залежить від масштабу. На 100 RFC гірший Recall@5 (69,8% проти 73,6%), але вдвічі менше слів до влучання. На повному корпусі кандидати виграють за обома критеріями (69,5% проти 50,8%). |
| HYP-003 — самовиникання груп | Чи ≥ 25% кластерів кандидатів міждокументні, без наперед заданих категорій | Не підтверджено на порозі, ні на TF-IDF (17,4%), ні на нейроембедингу (11,0%) — обидва нижче 25%. Але груба доменна карта показує, що структура таки є, лише не в тій формі, яку шукав поріг. |
| HYP-004 — економіка пристрою | Чи CPU / GPU / NPU дають той самий результат, лише різну ціну | Підтверджено. Косинус між векторами з різних пристроїв — 0,99998; NPU у 3,5 раза швидший за CPU. |
| HYP-005 — нейро проти генеративної моделі | Чи потрібна генеративна модель для класифікації типу знання | Для цієї двокласової типізації — ні. Крихітний NPU-класифікатор точніший (93,1% проти 88,1%) і у ~130 разів швидший за |
| HYP-006 — якість генерації | Чи псується відповідь LLM, коли контекст — об’єкти знань замість сирого тексту | Підтверджено і посилено. На 8 RFC якість рівна, на 20 RFC об’єкти знань обганяють сирий текст — і щоразу потребують меншого контексту та швидше дають перший токен. |
Кожна гіпотеза — окреме, заздалегідь заявлене питання; стрілки показують, яке питання природно поставило наступне.
Усі шість гіпотез — початковий стан цього розслідування: вони зафіксовані ще до першого запуску, разом із початковими переконаннями про те, що взагалі варто перевірити. Але хід дослідження не йшов по цьому списку по черзі. Щойно детермінований код упритул підійшов до питання про групування знань (HYP-003) і вперся в межу власних можливостей — код уміє згрупувати схожі фрагменти, але не вміє назвати тему людськими словами, — саме це відкрите питання й повело розслідування далі, ще до того, як дійшла черга до пристрою та моделі: якого типу буває знання і хто дає йому людську назву, яка частка знань — лише форма, а яка справжній зміст, і чи можна за цими метаданими відповісти на практичний запит. Це не окремий, наперед запланований блок, а прямий наслідок результатів групування: кожне наступне питання поставили самі попередні дані. Лише після цього дослідження повернулося до решти гіпотез про пристрій і модель.
Матеріал: один корпус, два представлення
У розслідуванні два набори файлів. Перший — вихідний, сирий текст 9 746 документів RFC, один файл на документ. Другий — похідний корпус компактних кандидатів в об’єкти знань, які детермінований код видобуває з першого. RFC обрано тому, що це великий, історично глибокий набір, у якому знання задокументоване навмисно (вимоги, угоди, означення), відкритий, стабільний і англомовний — зручний тестовий полігон, а не обмеження методу: той самий конвеєр можна застосувати до будь-якого іншого великого набору текстових документів.
HYP-001 — чи лишається доказ дослівним
Якщо існування кандидата в об’єкт знання вирішує лише код, чи не почне цей код десь «спрямляти» чи спотворювати текст? Ця гіпотеза перевіряє найбазовішу річ: чи кожен фрагмент, який код визнав кандидатом, справді слово-в-слово, байт-у-байт існує в оригінальному документі, а не є перефразуванням.
Перевірити таке твердження можна лише одним способом, який не залишає місця для враження чи догадки: узяти реальний вихід коду і звірити кожен його фрагмент із першоджерелом побайтово. А оскільки вдалий результат на невеликій вибірці ще нічого не доводить, я свідомо запускаю один і той самий незмінний код двічі — спершу на невеликій вибірці, а тоді на всьому корпусі — і визнаю гіпотезу підтвердженою лише тоді, коли результат тримається на обох масштабах однаково.
Правило відбору кандидата заморожене до першого запуску й ніколи не підправлялося заднім числом: код розбиває кожен документ на речення (бібліотека prose), а тоді визнає речення кандидатом, лише якщо воно містить один із двох незалежних від теми маркерів — нормативне слово (MUST/SHALL/SHOULD/MAY/REQUIRED) або структурний маркер (визначення поля, ASCII-діаграма, нумерований список). Кожне речення додатково проходить побайтову перевірку: чи є воно дослівно в оригіналі, символ у символ. Якщо ні — кандидатом воно не стає взагалі, а рахується як провал простежуваності.
| Масштаб перевірки | Документів | Речень | Кандидатів | Частка дослівних доказів |
|---|---|---|---|---|
| Вибірка | 100 | 37 422 | 5 766 | 100% (5 766 з 5 766) |
| Увесь корпус | 9 746 | 2 987 170 | 432 858 | 100% (432 858 з 432 858) |
Висновок. Дослівність тримається на обох масштабах без жодного винятку — це та цеглина, на якій стоїть усе інше дослідження: якщо доказ не дослівний, немає сенсу говорити ні про пошук, ні про групування, ні про мовні моделі. Побічна знахідка: те саме структурне правило, що ловить справжні означення полів, так само ловить службові рядки шапки документа («Request for Comments: 458», «NIC: 14378») — формально дослівні, але не знання. Це не провал HYP-001, але вада точності правила, яка згодом озветься в пошуку й групуванні.
HYP-002 — чи виграє пошук по кандидатах
Якщо шукати відповідь не по всьому сирому тексту документів, а лише по компактному набору кандидатів, чи знайдеться та сама правильна відповідь — і чи знайдеться вона швидше, прочитавши менше тексту? Тут порівнюються два способи пошуку по одному й тому самому корпусу: пошук по повних абзацах і пошук по кандидатах.
Пряме порівняння вимагає двох речей одразу: запитань, які не підібрала зручно людина, і однакового алгоритму ранжування для обох індексів — інакше різницю в результатах можна було б списати на вдалий вибір прикладів чи на різні формули пошуку. Тому запитання я не придумую сам, а виводжу їх механічно з того, що документи вже цитують одне одного, а обидва індекси проганяю через один і той самий пошуковий алгоритм. І знову перевіряю результат на двох масштабах: висновок на маленькій вибірці ще не є висновком про весь корпус.
Еталон запитань: якщо один RFC цитує номер іншого RFC із тієї самої вибірки, це речення стає запитанням, а «правильна відповідь» — будь-який фрагмент саме з процитованого документа. Ранжує результати в обох випадках BM25 (Okapi BM25, стандартна формула ранжування в інформаційному пошуку), реалізована у власному Go-пакеті; змінюється лише індекс, по якому він шукає: один раз це сирі абзаци, другий раз — кандидати. Два показники якості: Recall@5 — чи опинився правильний документ серед перших п’яти результатів пошуку, і медіана слів до влучання — скільки тексту в середньому довелося прочитати, щоб до нього дійти.
| Масштаб перевірки | Запитів | Recall@5, сирий текст | Recall@5, кандидати | Медіана слів, сирий текст | Медіана слів, кандидати |
|---|---|---|---|---|---|
| Вибірка зі 100 документів | 53 | 73,58% | 69,81% | 149 | 71 |
| Увесь корпус (пакетами по 100 документів) | 22 187 | 50,82% | 69,54% | 174 | 88 |
Висновок. Те саме питання дає протилежні відповіді залежно від масштабу. На 100 документах кандидати програють за Recall@5, хоч і читають удвічі менше слів до влучання — за наперед зафіксованим правилом гіпотеза відхилена. На повному корпусі кандидати виграють за обома критеріями одразу: сирі абзаци множаться зі зростанням корпусу набагато швидше за кандидатів, тож у великому індексі сирого тексту накопичується більше правдоподібних, але неправильних конкурентів. Інженерна деталь, яка зробила повний масштаб вимірюваним: наївний єдиний BM25-індекс на весь корпус зависав на 12+ годин; рішенням стала пакетна обробка (98 пакетів по 100 документів). Вона не змінювала ані правила відбору кандидатів, ані правила побудови запитань — лише дала змогу довести той самий тест до завершення за 15 хвилин.
HYP-003 — чи групуються кандидати самі, без підказки
Якщо взяти всіх кандидатів і дозволити схожим між собою автоматично об’єднатися в групи — без жодного наперед заданого списку категорій, — чи з’являться групи, які повторюються в різних документах? Якщо так, це означає, що в корпусі є прихована структура тем, яку можна знайти без участі людини.
Довести це можна лише повністю автоматичним групуванням: жодна категорія не задається наперед, і жоден кластер не підганяється під очікуваний результат заднім числом. Тому метод перетворення тексту на числа і поріг схожості я фіксую до першого запуску, а отриману частку міждокументних груп порівнюю з наперед оголошеним порогом 25% — без права присунути цей поріг, побачивши число.
Щоб порівнювати два фрагменти тексту, код спершу перетворює кожен кандидат на вектор — рядок чисел, де кожне число показує, наскільки важливе певне слово саме для цього кандидата (метод TF-IDF). Два кандидати вважаються схожими, якщо кут між їхніми векторами малий — це і є косинусна схожість, число від 0 (нічого спільного) до 1 (майже те саме). Саме групування виконує BSAS (Basic Sequential Algorithmic Scheme) — класичний, повністю детермінований однопрохідний алгоритм розпізнавання образів, реалізований у Go: кожен кандидат приєднується до найбільш схожого вже існуючого кластера (групи) або починає новий, якщо жоден кластер не подолав наперед зафіксований поріг схожості 0,35. Це не найпростіший варіант такого групування: класичний «алгоритм лідера» (Leader Algorithm, Hartigan, 1975) приєднує кандидата до першого кластера, що подолав поріг, а не до найкращого; я свідомо обираю BSAS саме за цю відмінність: «перший, хто підійшов» і «найбільш схожий» — це різні правила, і різниця між ними прямо впливає на те, які саме кластери в підсумку утворяться.
| Метод перевірки | Кластерів | Багаточленних | Міждокументних | Частка міждокументних |
|---|---|---|---|---|
| TF-IDF-вектори, вибірка зі 100 документів | 2 575 | 855 | 149 | 17,43% (поріг 25%) |
Розвідувальна перевірка: а що, як рецептура векторів була заслабка? Я порахував справжні нейроембединги (bge-m3, 1024 виміри, GPU) — вектори, які будує вже навчена нейромережа, а не проста статистика слів, — і прогнав ту саму кластеризацію на всій кривій порогів:
| Поріг косинуса | Кластерів | Міждокументних | Частка міждокументних | Найбільший кластер |
|---|---|---|---|---|
| 0,60 | 71 | 25 | 73,53% | 2 089 (виродження — один велетенський блоб) |
| 0,65 | 402 | 66 | 37,71% | 653 |
| 0,70 | 1 475 | 112 | 21,83% | 192 |
| 0,75 | 2 854 | 82 | 10,96% | 100 |
| 0,80 | 3 965 | 44 | 6,13% | 56 |
| 0,90 | 5 023 | 17 | 4,82% | 44 |
Висновок. Частка міждокументних кластерів повністю визначається порогом, а не «розумом» ембедингу: 25% «пробивається» лише там, де кластеризація вироджена (поріг 0,60, один кластер поглинає 36% усіх кандидатів). При гранулярності, порівнянній із TF-IDF (поріг 0,75 → 2 854 кластери), нейроембединг дає 10,96% — нижче за TF-IDF-результат (17,43%). Справжній нейроембединг на реальному GPU не рятує HYP-003: на цій вибірці просто немає 25% справжнього змістовного міждокументного повторення, бо домінує формат. Навіть уцілілі при найсуворішому порозі міждокументні кластери — це знову «Author’s Address» того самого автора чи шапка «Network Working Group», а не змістовна тема.
Поверхневе проти глибокого знання
Не кожен кандидат, якого впіймало правило коду, — це справжнє знання. Частина з них — це просто форма документа: шапка, підпис редактора, юридичне застереження. Тут перевіряється, скільки саме кандидатів — це форма (поверхневе знання), а скільки — справжня начинка, конкретна вимога чи означення (глибоке знання), і чи можна відділити одне від одного детерміновано, без жодної моделі.
Замість наївного попарного групування на півмільйоні кандидатів повного корпусу (той самий клас складності, що завісив пошук на 12 годин), я поставив інше питання: якого роду ці знання? Поверхневе знання — це форма (шапки, підвали, адреси авторів, юридичні застереження, ASCII-рамки, самі слова-ключі); глибоке — це начинка (конкретна вимога, поле формату, домен). Мета цього окремого прогону — виміряти співвідношення форми й змісту за час, що лишається лінійним, а не квадратичним від кількості кандидатів.
Розпізнавач поверхневого шару написаний у Go як набір із семи детермінованих правил зіставлення підрядків і регулярних виразів, навмисно консервативний (може лише занижувати частку поверхневого, ніколи не завищувати):
| Різновид поверхневого | Кандидатів | Що це |
|---|---|---|
page_furniture | 39 283 | колонтитули, розриви сторінок, номери |
diagram_scaffolding | 21 096 | ASCII-рамки й стрілки діаграм |
author_address | 11 548 | блоки адрес авторів |
masthead | 10 178 | шапки «Network Working Group...» |
rfc2119_keywords | 5 498 | переліки самих слів MUST/SHALL |
editor_footer | 5 154 | підвали «errata... rfc-editor.org» |
ipr_copyright | 3 011 | юридичні застереження про права |
Результат на 432 858 кандидатах повного корпусу: 95 768 (22,1%) — поверхневі, 337 090 (77,9%) — глибокі. Розподіл нерівномірний за правилом, що впіймало кандидата:
| Правило, що спрацювало | Глибоких | Поверхневих | Частка поверхневого |
|---|---|---|---|
| нормативне (MUST/SHALL...) | 202 733 | 15 604 | 7% |
| структурне (поле/діаграма) | 125 658 | 77 104 | 38% |
| обидва | 8 699 | 3 060 | 26% |
Глибокі кандидати розкладаються на два виразні шари домену: наскрізну протокольну лексику, розкидану по сотнях RFC (address 311, length 294, port 279, key 255, version 209), і конкретні технологічні домени, згущені в десятках документів (tls 174 RFC, certificate 192, sip 158, router/route 150/145, eap 62, printer 26).
Висновок. Нормативне знання майже завжди глибоке (93%), а структурний шар — майже наполовину оболонка (38% поверхневого). Саме цей шар у HYP-002 псував Recall@5, коли службовий boilerplate спливав нагору видачі. Практичний рецепт: якщо спершу зняти поверхневий шар, глибоке знання стає і чистішим, і швидше знаходиться. Увесь прохід по 432 858 кандидатах зайняв 6 270 мс на самому CPU — близько 69 035 кандидатів за секунду.
Типи й назви знань: код проти мовної моделі
Групи схожих кандидатів уже є (попередній розділ), але як дізнатися, про що кожна з них? Чи здатен детермінований код сам описати тему групи, чи для людської назви теми обов’язково потрібна мовна модель — і чи можна їй довіряти?
Детермінований код може сам виявити групи спільного словника й підписати кожну сигнатурою теми — набором найхарактерніших слів (наприклад, sip · telephony · devices · req · support). На вибірці зі 100 документів це дало 739 родин-типів, 164 міждокументні. Але сигнатура лишається набором слів, а не людською назвою — цей крок iменування вже судження, а не побайтове обчислення.
Я називаю цей другий, окремий прогін дуеллю не заради ефектного слова. Досі в розслідуванні мовна модель була в ролі глядача: код відбирав, групував і рахував, а модель нічого не вирішувала. Тепер уперше вона отримує право голосу — але це право відразу випробовується за суворими правилами двобою, а не дається як подарунок. Код уже виклав усе, що зумів сказати про кожну групу, — голий список найхарактерніших слів; тепер модель мусить довести, що вона здатна на те, чого код не вміє в принципі: перетворити цей список у людську назву. Помилка тут так само можлива, як і влучна відповідь, — і, як покаже результат, модель повторювано хибить в одних і тих самих типах випадків.
Дуель: локальна модель qwen2.5-coder:7b, яку викликано через Ollama на хості з відеокартою RTX 3080, отримує лише сигнатуру й три дослівні приклади-речення та повертає компактну назву й тип — ніколи не текст доказу. Кожну запропоновану назву код звіряє на заземлення: чи містить вона хоча б одне слово зі справжніх членів кластера — проста, але, як покаже результат нижче, недостатня перевірка.
| Масштаб дуелі | Валідний JSON / заземлення | Змістовно точних (людська оцінка) |
|---|---|---|
| 12 найбільших родин | 12/12 | 8/12 (67%) |
| 30 найбільших родин | 30/30 | 25/30 (83%) |
Висновок. Модель справді додає те, чого код дати не може: eap · radius · attribute стало «EAP Authentication», а найтонше — абзац RFC 2119 модель правильно впізнала за самими словами shall · recommended · words · interpreted, хоч у сигнатурі немає ні «2119», ні слова «keywords». Але на обох масштабах повторюються ті самі два типи помилок: узагальнена родина бітових діаграм звужена до одного документа («RIP Version 2»), а MPLS-родина lsr · lsp · bfd названа неправильним акронімом «LDP» замість Label Switching Router. І найважливіше: хибна назва «LDP» усе одно пройшла формальну перевірку на заземлення (містить спільне слово з членами кластера) — лексичне заземлення необхідне, але недостатнє. Назва від моделі завжди лишається гіпотезою, яку треба звірити з дослівними членами кластера, а не готовою істиною.
Чому не інша Go-бібліотека
Дуель показала, що мовна модель уміє дати назву, але часом вигадує. Тому варто прямо назвати альтернативи, якими я міг би замінити виклик до Ollama на цьому кроці, — і чому жодна з них не покриває завдання цілком. Наше завдання ширше за класичне розпізнавання іменованих сутностей (NER, Named Entity Recognition): потрібні не просто сутності (імена, дати), а типізовані твердження з дослівним доказом, який проходить побайтову перевірку. Тому готові NER-бібліотеки закривають лише частину задачі.
| Бібліотека | Тип | Що вміє | Придатність для цього завдання |
|---|---|---|---|
| jdkato/prose | чистий Go, без CGO | токенізація, частиномовна розмітка, rule-based NER | базовий NER, слабкий для технічних термінів RFC (уже використовується тут для сегментації речень) |
| nlpodyssey/cybertron (на spaGO) | чистий Go | BERT/BART: класифікація токенів, zero-shot класифікація, QA | найближче до потреби: zero-shot типізація без Python |
| knights-analytics/hugot | Go + ONNX Runtime | конвеєри HuggingFace у Go, підтримує GLiNER через ONNX | найгнучкіше: GLiNER-подібні моделі локально |
| MITIE | C++ з Go-біндингами (CGO) | NER, видобуток бінарних відношень | зрілий NER, але вимагає CGO |
| GLiNER (модель, ONNX) | універсальний NER за довільними мітками | малий розмір, працює на CPU | перспективна, запускається з Go через hugot |
Підсумок: нативний Go-стек для цієї задачі існує (cybertron для zero-shot типізації, hugot + GLiNER для гнучкого NER), але жоден варіант «з коробки» не робить рівно те, що потрібно тут: типізоване, переформульоване ім’я разом із дослівним, побайтово перевіреним доказом. NER дає межі сутності; сам крок «дай тип і не чіпай цитату» лишається або за генеративною моделлю (як у цій дуелі), або за зв’язкою «класифікатор типу плюс код, що вирізає цитату». Це список варіантів для вибору за вартістю й точністю, а не єдиний обов’язковий шлях.
HYP-004 — економіка пристрою
Один і той самий розрахунок (перетворення тексту кандидата на вектор) можна виконати на трьох різних пристроях ноутбука: звичайному процесорі, вбудованій відеокарті або спеціальному нейрочіпі. Питання просте: чи змінює вибір пристрою сам результат обчислення, чи лише його швидкість і ціну?
Виміряти тільки швидкість тут недостатньо — потрібно ще й довести, що всі три пристрої рахують те саме. Тому я компілюю один і той самий конвеєр ембедингу під кожен пристрій і проганяю його на однакових вхідних кандидатах, а тоді звіряю не лише час, а й самі отримані вектори між собою: якщо пристрій непомітно змінює результат, це має проявитися саме в розбіжності векторів, а не лише в цифрах швидкості.
Той самий конвеєр ембедингу (all-MiniLM-L6-v2, ONNX) через OpenVINO на трьох пристроях того самого ноутбука, на однакових 400 кандидатах.
| Пристрій | Пропускна здатність | Латентність (медіана) | Старт (компіляція) |
|---|---|---|---|
| CPU | 68,2 ембединга/с | 14,49 мс | 561 мс |
| GPU (Intel Arc iGPU) | 231,1 ембединга/с | 4,31 мс | 4 198 мс |
| NPU (Intel AI Boost) | 239,1 ембединга/с | 3,96 мс | 6 625 мс |
Косинусна схожість тих самих 400 векторів між пристроями: CPU↔GPU 0,999996, CPU↔NPU 0,999996, GPU↔NPU 0,999996 — практично тотожні вектори, розбіжність лише на рівні числового шуму.
Висновок. Пристрій не змінює результат, лише його ціну. NPU — найшвидший і з найнижчою латентністю (у 3,5 раза швидший за CPU), але найдовше «прогрівається»: для одного-двох ембедингів вигідніше лишитися на CPU, для масової фонової обробки — переходити на NPU. Це та цеглина, заради якої в кожному попередньому вимірі я щоразу зазначав «на CPU, без NPU»: тепер видно, що перенесення на прискорювач нічого не ламає.
HYP-005 — нейро проти генеративної моделі
Класифікація («цей кандидат — нормативна вимога чи структурне означення?») — це не те саме, що написання тексту. Чи справді для такої простої класифікації потрібна велика генеративна мовна модель, чи крихітний спеціалізований нейроприскорювач впорається не гірше і з меншою обчислювальною вартістю?
Це вже пряма дуель, а не паралельне тестування: два зовсім різні за природою суперники виходять на те саме поле. З одного боку — крихітний нейроембедер, який важить лічені мегабайти й не вміє сказати жодного слова, лише перетворює речення на вектор чисел. З іншого — семимільярдна генеративна модель, здатна вести діалог і пояснювати власні рішення. На перший погляд це нерівний двобій, як поставити спеціалізований вимірювач проти універсального співрозмовника. Але завдання тут не «напиши текст», а «віднеси до одного з двох відомих класів» — і саме в цьому вужчому двобої вага суперника перестає бути гарантією перемоги.
Щоб порівняння не залежало від різних умов, обом класифікаторам потрібна однакова мітка, яка не залежить від чиєїсь думки, і жоден із них не повинен мати доступу до власної правильної відповіді заздалегідь. Тому обом дістається одна й та сама мітка, яку вже вивело те саме детерміноване правило коду (нормативне чи структурне), а нейрокласифікатор будує кожен еталонний вектор класу без участі кандидата, який у цей момент перевіряється, — щоб він не міг підглянути власну відповідь.
Крихітний нейроембедер all-MiniLM на NPU з класифікацією найближчим центроїдом (кожному класу відповідає усереднений вектор усіх його прикладів, крім поточного), реалізованою прямо в Go, проти тієї самої генеративної qwen2.5-coder:7b через Ollama, якій дозволено відповісти рівно одним словом. Вибірка — 160 кандидатів, порівну нормативних і структурних.
| Класифікатор | Точність | Обчислення | На кандидата |
|---|---|---|---|
NPU-нейро (all-MiniLM + центроїд) | 93,1% (149/160) | 715 мс | 4,5 мс |
Генеративна qwen2.5-coder:7b | 88,1% (141/160) | 92 336 мс + мережа | 583 мс |
Висновок. Крихітний класифікатор на NPU виявився і точнішим (93,1% проти 88,1%), і у ~130 разів швидшим на кандидата, ніж
HYP-006 — чи псує об’єкт знань відповідь LLM
Якщо давати мовній моделі для відповіді не повний сирий текст документа, а лише компактний набір кандидатів (об’єктів знань), чи погіршиться сама відповідь, чи зміниться лише швидкість і кількість прочитаного тексту?
Щоб різницю між двома умовами можна було приписати саме контексту, а не примсі моделі, я фіксую все інше: той самий запит, температуру 0 і той самий початковий стан генератора випадкових чисел (seed), і змінюю лише те, що підставляю в контекст. А оскільки думка людини про «кращу» відповідь — це вже судження, а не вимір, якість рахую тим самим детермінованим способом, яким рахував усе інше дослідження: часткою впізнаваних слів документа у відповіді моделі. І знову перевіряю це на двох вибірках різного розміру, а не на одній, — щоб побачити, чи тримається напрям, коли документів стає більше.
Єдина відмінність між умовами — контекст: повний сирий текст документа чи лише його кандидати, підставлені прямо в запит (підхід, відомий як RAG, retrieval-augmented generation), надісланий через Ollama до qwen2.5-coder:7b. Якість — частка «золотих» термінів документа (найхарактерніші слова самого документа за TF-IDF), які модель згадала у своїй відповіді. TTFT (час до першого токена) — скільки часу минає від запиту до першого символу відповіді: чим менший контекст, тим менше моделі «читати» перед тим, як почати відповідати.
| Вибірка | Умова | Якість (частка золотих термінів) | Контекст (токени) | TTFT |
|---|---|---|---|---|
| 8 RFC | сирий текст | 0,266 | 2 354 | 1 983 мс |
| 8 RFC | об’єкти знань | 0,250 | 1 877 | 1 204 мс |
| 20 RFC | сирий текст | 0,306 | 2 169 | 1 385 мс |
| 20 RFC | об’єкти знань | 0,350 | 1 948 | 1 258 мс |
Висновок. На 8 документах якість практично рівна (різниця в межах шуму), а об’єкти знань уже компактніші як контекст (на третину менше токенів) і швидші (TTFT майже вдвічі менший). На 20 документах — вибірці, більшій і надійнішій, — об’єкти знань не просто не гіршають, вони обганяють сирий текст за якістю (0,350 проти 0,306), лишаючись компактнішими й швидшими. Найправдоподібніше пояснення: обрізаний сирий текст (перші 8000 символів) — це здебільшого титул і вступ, тоді як об’єкти знань — уже відібрані кодом змістовні речення з усього документа. Щільніший контекст менше відволікає модель на службову «воду».
Карта знань на практиці
Усі попередні метадані (поверхневе проти глибокого, типи, домени) — не самоціль, а будівельний матеріал. Останній практичний тест: чи досить цих метаданих, щоб одразу відповісти на конкретний запит людини — наприклад, «електронна пошта» — не перечитуючи корпус заново?
Карта не малюється руками, вона обчислюється: кандидат релевантний, якщо містить термін запиту, оцінка — сума ваг TF-IDF по збігах, а поверхневі влучання відсіюються окремо й ніколи не змішуються зі знанням.
Реальний результат запиту «electronic mail email smtp imap pop mime message mailbox sender recipient» по всьому корпусу: 40 570 релевантних глибоких кандидатів, 22 743 поверхневих (автоматично відсіяних); тип — 27 384 нормативних, 12 056 структурних (регіон пошти на ⅔ складається з вимог); під-теми — message, mime, mailbox, mail, smtp, relay, hello; документи-джерела — саме поштові стандарти: RFC 5321/2821 (SMTP), 9051/3501 (IMAP), 8621 (JMAP), 6531 (SMTPUTF8). Увесь запит по 432 858 кандидатах зайняв 8 074 мс на CPU — 53 608 кандидатів за секунду.
Це саме й означає «онтологічне дерево», обчислене кодом, а не намальоване вручну: кожен рівень — окремий детермінований крок конвеєра, і кожна цифра на ньому — реальне число з того самого прогону.
Чотири рівні дерева: запит → поверхневе/глибоке (з розподілом на нормативне й структурне) → домен-під-тема → побайтовий доказ. Гілка «Поверхневе» обривається на другому рівні навмисно — це і є те, що карта відсіює, а не показує як знання.
Негативний контроль: запит, якого в корпусі нема
Позитивний приклад легко сплутати з рекламою методу, тож я поставив тій самій утиліті, без жодної зміни коду, свідомо абсурдне для цього корпусу запитання: «пончик з абрикосовим джемом». Корпус англомовний, тож і запит я формулюю відповідними словами: donut doughnut apricot jam pastry bakery glaze sugar dessert filling. До специфікацій інтернет-протоколів це змістово не належить — і саме тому працює як контрольний запит.
Реальний результат того самого коду: 47 «глибоких» і 30 «поверхневих» кандидатів — тобто не нуль, хоча запит про випічку до корпусу мережевих стандартів не має жодного змістового зв’язку. Причина видна одразу, щойно подивитися на самі знайдені приклади:
- Термін
jamзібрав кандидатів навколо фрази «paper jam» / «media jam» — це стан помилки принтера (RFC 2566, протокол IPP), а не фруктовий джем. - Термін
sugarзнайшовся в буквальному прикладі значень заголовка: «sugar, tea, rum» — це ілюстративні приклади рядків у специфікації Structured Field Values (RFC 8941/9651), а не про їжу взагалі. - Термін
filling— це майже завжди дієслово «заповнити поле чи шаблон» («filling in the following template»), а не начинка пончика. - Решта «тем» (
floor,hellman,origin,sasl,dictated,abbrev,bills,bits) — випадкові однослівні перетини з геть не пов’язаними протоколами (контроль підлоги для відеоконференцій, обмін ключами Diffie — Hellman, заголовокOrigin, механізм автентифікації SASL): кожна така тема —1–4 кандидати з1–3 RFC, і жодна не повторюється так широко, як реальні домени в прикладі про пошту(34–145 RFC на тему).
Ось і практичний сигнал, який відрізняє справжній збіг від шуму: коли запит справді має відповідник у корпусі («electronic mail»), карта складається з небагатьох тем, і кожна охоплює десятки документів. Коли відповідника немає («donut apricot jam»), та сама карта розсипається на 34 дрібні, не пов’язані між собою уламки по
Висновок. До фрагмента з побайтовим походженням тепер додано метадані — тип, домен, місце в карті — і людину вже не змушують читати тисячі документів, щоб дізнатися, «про що там про пошту». Дослідник дізнається, про що корпус, не читаючи корпус і не питаючи модель. Але негативний контроль одразу показує межу методу: пошук за збігом слів (TF-IDF) не відрізняє «в корпусі є така тема» від «в корпусі випадково трапилося одне спільне слово» — побачити різницю можна лише за ступенем розсипання результату на дрібні теми й за самими дослівними прикладами, а не за самим фактом, що щось знайшлося.
Обмеження
Перш ніж підбити підсумок, варто назвати межі того, що виміряно вище — без цих меж картина виглядала б охайнішою, ніж є насправді.
- Структурне правило ловить не тільки зміст, а й формат — саме воно й стало найбільшим джерелом поверхневого шару: 38% структурних кандидатів виявилися оболонкою, а не змістом.
- Еталон запитань для пошуку грубий: правильною відповіддю рахується будь-яка згадка процитованого документа, а не конкретний його фрагмент. Це грубіше за ручний добір зручних прикладів, зате не залежить від чийогось смаку — і все одно не замінює точного набору питань із точними відповідями.
- Метрики якості відповіді — грубі проксі: частка «золотих» термінів і регулярно-виведена мітка типу добре показують, що один варіант кращий чи гірший за інший, але не вловлюють тонких відмінностей у формулюванні.
- Порівняння NPU і генеративної моделі відбулося на різних «вагах»: нейро-прискорювач рахує прямо в ноутбуці, а генеративна модель — на окремій машині за мережею. Я віднімаю мережевий час від обчислювального окремо, але якби обидва пристрої стояли поруч — або обидва працювали за мережею — різниця в цифрах могла б трохи змінитися.
- Висновки про економіку пристрою — з одного конкретного ноутбука й одного Ollama-хоста, а не з апаратури взагалі: інший чіп чи інша відеокарта можуть дати інші абсолютні числа.
- Корпус один, і він відомий наперед: RFC — технічні специфікації з упізнаваною структурою, обрані саме тому, що результат можна перевірити. Чи так само чітко розділиться поверхневе й глибоке знання на зовсім іншому, незнайомому заздалегідь корпусі документів — це питання для наступного дослідження.
Три висновки дослідження
1. Парсинг сирого тексту програє об’єктам знань — і за швидкістю, і за якістю. На повному корпусі пошук по кандидатах виграє Recall@5 і веде до відповіді вдвічі меншою кількістю прочитаних слів; а як контекст для мовної моделі об’єкти знань дають щонайменше таку саму, а на більшій вибірці й кращу відповідь — за менший контекст і швидший перший токен. Кращий спосіб обробки — не годувати систему сирим текстом, а спершу детерміновано витягти об’єкти знань і працювати вже з ними.
2. Метадані про знання формуються детерміновано — код сам каже, про що корпус. Без жодної моделі детермінований код виводить: яка частка поверхневого (22,1%) і глибокого (77,9%); які класи за правилом (нормативне/структурне); і доменну мапу (sip, tls, certificate, printer...). Дай коду теку документів — і він за лічені секунди скаже, скільки в ній оболонки, а про які домени йдеться в начинці.
3. Частину роботи можна робити без онлайн-LLM — і це не компроміс, а кращий технічний вибір для вузьких задач. Для двокласової типізації крихітний нейрокласифікатор на локальному NPU виявився точнішим і у ~130 разів швидшим за
Відтворення
Кожен експеримент має машинно-читаний маніфест і окремий код запуску; усі числа в статті взяті з реальних прогонів, не з очікувань. Для відтворення потрібні: корпус RFC у вигляді plain-text файлів, локальний Ollama-хост із моделлю qwen2.5-coder:7b та ембедером, і збірка з тегом openvino для дослідів із пристроями. Адреса хоста передається лише як аргумент запуску й ніде не зберігається.
Джерела
— Salton, G., Wong, A., Yang, C. S. (1975). A Vector Space Model for Automatic Indexing. Communications of the ACM, 18(11),
— Robertson, S. E., Walker, S. (1994). Some Simple Effective Approximations to the
— Hartigan, J. A. (1975). Clustering Algorithms. John Wiley & Sons. — класичний «алгоритм лідера» (Leader Algorithm), з яким явно порівняно метод BSAS.
— Theodoridis, S., Koutroumbas, K. (2009). Pattern Recognition (4th ed.). Academic Press. — опис BSAS (Basic Sequential Algorithmic Scheme).
— Bradner, S. (1997). Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF.
— github.com/jdkato/prose/v2, версія 2.0.0 — сегментація тексту на речення.
— nlpodyssey/cybertron і spaGO — Go-стек для трансформерних NLP-задач, згаданий як можлива альтернатива для типізації.
— knights-analytics/hugot — Go-інтерфейс до ONNX Runtime / HuggingFace-подібних конвеєрів.
— MITIE — C++/CGO-бібліотека для NER і видобутку відношень.
— GLiNER — модель універсального NER за довільними мітками, згадана як кандидат для локальної типізації через ONNX.
— The Go Programming Language, версія 1.26.4, go.dev.
— RFC Editor / IETF — корпус документів RFC (rfc-editor.org).
— Ollama (репозиторій) — локальна генеративна модель qwen2.5-coder:7b і ембедери.
— OpenVINO — обчислення на CPU / iGPU / NPU; модель ембедингів all-MiniLM-L6-v2.
— Архітектура Intel Core Ultra (Meteor Lake) і вбудований прискорювач Intel AI Boost — офіційна документація Intel.
11 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівДуже цікаво як працює пошук знань в документах певного формату.
Але дуже шкода, що 100% гарантії досягти не можливо...
Мене зараз більше цікавлять алгоритми повʼязані з «векторизацією» зображень.
Не в тому сенсі, як растрові переводяться в вектор, а як «зрозуміти сенс» та записати його у вигляді векторів
Наскільки я розумію, пане Миколо, в такому напрямку існує зараз багато технологій.
Останнім часом я ще не займався оптичним розпізнаванням і глибоко не занурювався в цей домен.
Можу згадати розробки команди Viewdle (головний програміст Юрій Мусатенко, науковий керівник професор Михайло Іванович Шлезінгер) в напрямку face recognition в растрових зображеннях (і скріншотах відеострімів), де я свого часу мав нагоду працювати інфраструктурним інженером, можливо Вас це чимось надихне.
Компанія Viewdle (український стартап у сфері комп’ютерного зору з 2006 року, придбаний Google у 2012 році) використовувала унікальний науковий підхід для розпізнавання облич та об’єктів на мобільних пристроях. Оскільки в ті часи смартфони мали слабкі процесори та обмежену пам’ять, класичні нейромережі чи хмарні обчислення не підходили.
В основі технології Viewdle лежав підхід низькорангової матричної факторизації (Low-Rank Matrix Factorization), розроблений українськими математиками з Інституту кібернетики імені В. М. Глушкова НАН України (проф. Шлезінгер).
Суть математичного підходу Viewdle
Замість порівняння «піксель у піксель» або побудови «важких» векторних контурів ліній обличчя, алгоритм Viewdle робив наступне:
- Представлення у вигляді матриці: Зображення обличчя чи об’єкта розглядалося як велика цифрова матриця яскравості пікселів.
- Факторизація (розкладання): Велика матриця розкладалася на добуток двох значно менших матриць нижчого рангу. Цей процес схожий на метод головних компонент (PCA — Principal Component Analysis), але адаптований для швидких обчислень.
- Виділення сутнісного вектора: Завдяки розкладанню алгоритм відкидав «шум» (зміни освітлення, легкі повороти голови, тіні). На виході залишався стислий, компактний математичний зліпок (вектор ознак), який містив лише ключові характеристики геометрії обличчя.
- Миттєве порівняння: Отриманий маленький вектор порівнювався з базою даних локально на пристрої за частки секунди.
Чому цей підхід став революційним для свого часу?- Локальні обчислення (On-Device Processing): Алгоритм працював безпосередньо на смартфонах без підключення до Інтернету чи серверів, що було критично важливим на межі
2000-х та 2010-х років. - Екстремальне стиснення даних: Замість зберігання гігабайтів фотографій для навчання системи, Viewdle зберігала кілобайтні текстово-математичні профілі облич.
- Стійкість до перешкод: Завдяки властивостям матричної факторизації, алгоритм успішно ідентифікував людину, навіть якщо вона одягала окуляри, змінювала зачіску або перебувала у погано освітленому приміщенні.
- Обробка у реальному часі: Технологія дозволяла розпізнавати людей безпосередньо у відеопотоці камери на частоті понад
15-20 кадрів на секунду
Звісно ця технологія була патентована.Дякую за відповідь.
Наша задача трохи відрізняється від розпізнання облич, але сам підхід обробки у реальному часі з екстремальним стисненням даних — має сенс.
Цікаві наступні експерименти:
1. Сильніша перевірка якості відповіді LLM
Перейти від простої перевірки наявності термінів до claim-level оцінки: чи модель не змінила сенс, не додала заперечення, не переплутала суб’єкт, дію, умову або модальність MUST / SHOULD / MAY.
2. Масштабування HYP-006 на стратифіковану вибірку
Повторити порівняння raw text vs KO не на випадкових 20 RFC, а на вибірці, яка покриває різні типи документів: старі/нові, normative-heavy, structural-heavy, high-surface, high-deep, з малою і великою кількістю KO.
3. KO як компресор контексту
Перевірити, скільки тексту можна прибрати без втрати якості відповіді: сирий текст, top-N raw fragments, усі KO, top-N KO, deep-only KO, normative-only KO, KO без поверхневого шару, KO з метаданими.
4. Surface/deep як фільтр перед RAG
Перевірити, чи поділ на поверхневе і глибоке знання реально покращує пошук і відповіді LLM: порівняти всі кандидати, тільки deep, deep+normative, deep+structural, deep без boilerplate, сирий текст.
5. BM25 проти embedding retrieval проти hybrid retrieval
Порівняти класичний BM25, embedding-пошук і гібридні схеми на raw text і KO. Окремо виміряти якість пошуку, latency/query і роботу на CPU/GPU/NPU.
6. Багатокласова типізація KO на NPU
Розширити класифікацію з двох класів normative/structural до більш практичних типів: requirement, permission, prohibition, definition, interface/schema, example, security consideration, surface тощо.
7. Квантизація OpenVINO-конвеєра
Перевірити FP32, FP16 і INT8 для embedding pipeline: чи можна прискорити inference на CPU/GPU/NPU без помітної втрати retrieval quality, cosine similarity і класифікації.
8. Локальна дуель моделей для HYP-006
Перевірити, чи KO-контекст допомагає не тільки qwen2.5-coder:7b, а й іншим локальним моделям Ollama. Порівняти якість, hallucination rate, claim correctness, latency і context size.
9. Перший шар експертної системи: пошук невідповідностей
Порівнювати нормативні KO з фактичними твердженнями про систему або проєкт. Наприклад: правило каже MUST use X, факт каже uses Y, система показує potential violation і докази з обох боків.
10. Out-of-domain і негативні корпуси
Запустити той самий конвеєр на іншому типі документів: README/changelog, issue tracker, юридичні тексти, safety manual або інший технічний корпус. Мета: перевірити, що ламається поза RFC і чи KO лишаються корисними.
Микола, чудова стаття! Але якщо я вірно вас зрозумів — під терміном «знання» ви маєте на увазі і правила і факти? Бо в старих класичних експертних системах є окрема база з фактами і окрема база з правилами\фреймами\тощо (в залежності від обраного представлення знань). І саме ця база називається «База знань».
Припустимо в «Базі знань» вказано: за умов А, Б, В — треба використовувати бібліотеку\алгоритм\фреймворк\... X. Або — за таких-то умов навантаження в архітектуру треба додавати балансири.
А в «Базі фактів» є факт що в такому-то проєкті умови А, Б, В виконані — але чомусь замість X використали Y. Тобто порушили правило.
І цимус (один з багатьох цимусів))) експертних систем в тому, що вони можуть знаходити такі невідповідності.
Додайте власні критерії.
Знаходження (не)відповілностей це саме те над чим ми й працюємо, і це складне рішення. Тому ви про це запитуєте, і я запитую теж.
Михайле, дякую за натяк. У статті слово «знання» вжите не в класичному сенсі повної експертної системи з окремою базою фактів, базою правил, фреймами та механізмом виведення. Тут це більш вузький, операційний термін: Knowledge Object, тобто невеликий фрагмент знання з документа, який має тип, походження і дослівний доказ у джерелі.
Дісклеймер: Це ж був окреме дослідження з кількома експериментами, зі своїми цікавими результатами, корисними для побудови експертних систем, але сам по собі бін не є експертною системою, тож відмінності припустимі.
Тому в моєму експерименті KO може бути і фактом, і правилом, і вимогою, і структурним визначенням. Наприклад, для RFC-корпусу дуже багато цінних KO мають саме нормативний характер: MUST, SHOULD, MAY. Це ближче до правила або вимоги, ніж до простого факту на кшталт «у проєкті виконано умови А, Б, В».
Точніше було б сказати так: перший шар системи будує не «базу фактів» і не повну «базу знань» у сенсі експертних систем, а трасований корпус типізованих тверджень. Уже поверх нього можна будувати наступний шар: порівнювати нормативні KO з фактичним станом конкретного проєкту і шукати невідповідності, саме такі, як у вашому прикладі з «за умов А, Б, В треба X, але в проєкті зробили Y».
Реальний приклад одного такого об’єкта з другого корпусу, з регіону «electronic mail»:
{ "id": "C-41328", "source": "RFC 2305", "span": { "start_byte": 6351, "end_byte": 6595 }, "type": "normative", "layer": "deep", "domain": "mailbox / SMTP / POP / IMAP", "evidence": "Mailbox protocols\n\n An offramp gateway that operate as an MTA serving multiple users\n SHOULD use SMTP; a gateway that operates as a UA serving a single\n mail recipient MAY use a mailbox access protocol such as POP or IMAP\n [9, 10]." }Це не просто «факт» у вузькому сенсі. Це нормативне інженерне твердження: за певної ролі gateway рекомендовано SMTP, а за іншої ролі дозволено POP або IMAP. Для експертної системи це вже кандидат у правило. Але в моєму експерименті я поки не дозволяю системі самій робити висновок «тут порушення». Я лише будую перевірений, дослівно прив’язаний шар знань, з якого такий висновок потім можна обчислювати окремим шаром правил.Тобто ваша рамка «факти окремо, правила окремо» правильна для класичних експертних систем. Моє дослідження зараз знаходиться на попередньому рівні: як надійно дістати з документів самі атомарні, типізовані й доказові одиниці, з яких потім уже можна складати базу правил, базу фактів і механізм пошуку невідповідностей.
О, дуже цікава стаття! І підхід гарний.
Хоча на HYP-006 про якість трохи не прозоро написано. Якщо llm буде заперечувати слово ви рахували це як «термін застосовано» чи як помилку? Типу якщо треба сказати «Василь це робив» а модель сказала «Не Василь це робив»? Ну і чи достатьо вам однієї метрики яку ви написали в розділі?
І чи були у вас думки стосовно того, що реальний датасет може бути не таким як «лабораторний»? Навіть якщо домен співпадає, інша структура, повнота контексту, актуальність — можуть впливати на всю систему
Так, в розділі «Обмеження» я зазначив:
Григорію, так, тут ви правильно побачили непрозору межу HYP-006.
Метрика, яку я використав для EXP-014, доволі груба. Якщо модель сказала б «Не Василь це робив», а еталонний термін «Василь» просто присутній у відповіді, така term-recall метрика могла б зарахувати термін як знайдений. Тобто вона не ловить заперечення, інверсію сенсу й причинно-наслідкову помилку. Для production-якості такої однієї метрики, звісно, недостатньо.
У цьому конкретному EXP-014 задача була вужча: не перевірити істинність складної відповіді на рівні логіки, а порівняти два типи контексту для тієї самої LLM: сирий текст RFC проти KO-контексту. Тому я фіксував модель, seed, температуру й запит, а міняв лише контекст. Метрика «частка золотих TF-IDF термінів документа, які з’явилися у відповіді» працює як грубий індикатор: чи не втрачає KO-контекст основний зміст документа. Але вона не є повноцінною оцінкою фактичної правильності відповіді.
І друге важливе уточнення: HYP-006 у статті не був прогнаний на повному корпусі 9 746 RFC. Він був зроблений на 8 RFC, а потім повторений на 20 RFC. На 8 документах KO-контекст був практично на рівні сирого тексту: 0,250 проти 0,266, але з меншим контекстом і швидшим TTFT. На 20 документах KO уже виграв: 0,350 проти 0,306, також залишаючись компактнішим і швидшим.
Тобто коректне формулювання таке: HYP-006 отримав напрямну підтримку на малому та збільшеному зразку, але це ще не «доведено на повному корпусі». Повний корпус тут міг би змінити картину, як це вже сталося в HYP-002, де вибірка 100 RFC і повний корпус дали різні вердикти. Тому для сильнішого висновку потрібен окремий наступний прогін: більша або стратифікована вибірка, claim-level перевірка, яка ловить заперечення, і кілька метрик, а не тільки term recall.
.