Ви не можете отримати число, яке ніхто не записав: OKF проти векторної бази даних RAG

У кожному проєкті є певний етап, до якого постійно повертаються, і ось він: скомпілювати таблиці та отримати прозовий текст. Ця ідея виникла під час розмови з чат-ботом, який почав роботу у звичайний спосіб. Десяток документів CDC, включаючи опис опитування, кодову книгу, короткий звіт та PDF-файли з методологією, були завантажені до бази знань Bedrock у надії, що багата колекція документів допоможе отримати хороші відповіді.

Але це не спрацювало. Причина — найпоширеніше непорозуміння щодо технології генерації з підтримкою пошуку: вважається, що чим більше документів, тим точніші відповіді. Векторна база даних може повернути лише той текст, який вже знаходиться в ній. Для будь-якого запитання, на яке відповідь ніколи не була записана, розмір колекції зовсім не має значення.

Ці дванадцять документів детально описували параметри діабету: що вони означають, у кого брали інформацію та як кодуються відповіді. Жоден з них не містив статистики, яку користувач насправді міг би запитати. Ці цифри були розраховані на основі 29 522 рядків даних опитування та не зустрічаються в жодному PDF, тому жодні пошуки їх не знайдуть.

Це призводить до ще серйознішої помилки. Люди вважають, що як тільки тема згадується в документах, RAG може відповісти на будь-які запитання щодо неї. Насправді він може відповісти лише на запитання, відповіді на які записані у текстовому уривку. Усе, що потребує обчислень, залишається поза його можливостями.

Отже, чат-бот було перебудовано. Спочатку це було навчальне додаток, який поєднував Amazon Bedrock Flow, AWS Amplify Gen 2 та Next.js, а під час перебудови його пошукову систему замінили на перевірений пакет у форматі Open Knowledge Format (OKF). Для об’єктивного порівняння також була створена справжня база знань Bedrock на основі тих самих документів, і обидві версії протестувалися безпосередньо щодо ключових критеріїв: чи правильна відповідь та наскільки швидко вона надходить?

Після поставлення ключового запитання база знань визначила п’ять відповідних змінних та точно вказала обмеження: у документах відсутня фактична обчислена статистика. Вона навіть порекомендувала правильний аналіз — зважену пропорцію людей з одним позначенням, які також мають інше, що саме і виконується OKF під час створення, але правильно описано системою, яка не може це виконати. Усе це можна скоротити до одного речення: неможливо отримати число, яке ніхто не записав. Сторона OKF відповіла цифрою, обчисленою на основі мікоданих за правильною визначеністю населення та правильними вагами.

Як було організовано тестування

Конфігурація була навмисно симетричною. Claude Sonnet 4.5 генерував відповіді з обох сторін у регіоні us-east-1, з використанням транспортування через SDK безпосередньо в процесі та ідентичного системного запиту, який використовує розгорнутий Lambda. Метод був описаний ще до отримання будь-яких результатів; задокументовано всі сім запитань та кожну спробу, а також збережено первинні відповіді. Увага щодо часу виконання: інструментарій викликає функції отримання даних та Bedrock безпосередньо, тоді як живий додаток спочатку направляє запити через AppSync та Lambda. Код OKF, який тестується, — це справжній код додатку, а транспортний механізм — ні, тому часи виконання порівнюють два різні дизайни, виміряні однаковим способом, і не відображають те, що побачить користувач браузера.

Заміна: один Lambda

Чат-бот Amplify виставляє інструменти як Amplify data tools — кожен з них є Lambda, який працює за запитом GraphQL, і Bedrock Flow був одним із них. Тож зміна полягає у додаванні ще одного інструменту askOkf, який надає відповіді з підтвердженого пакету замість Flow. Схема, фронтенд та процес розгортання залишаються незмінними.

// amplify/functions/askOkf/handler.ts — the essence
export const handler: Schema["askOkf"]["functionHandler"] = async (event) => {
   // in-process TF-IDF over the bundle
  const hits = search(event.arguments.question, 3);
  const top = hits[0];

  // Grounded-or-refuse: below the score floor,
  // nothing verified matches → refuse
  // before ever calling the model.
  if (!top || top.score < MIN_SCORE) {
    return { answer: refusal().text, citation: "", grounded: false, mode };
  }

  // read the verified figure straight from frontmatter
  if (mode === "extractive") {
    // 0 model calls - sub-millisecond
    const a = extractiveAnswer(hits);
    return { answer: a.text, citation: a.citations[0] ?? "", grounded: true, mode };
  }

  // generative: ground Claude on the ONE retrieved concept,
  // safety-prompted grounded-or-refuse
  const concept = top.concept;
  const context = `Concept: ${concept.label}\nSource: ${conceptSource(concept.frontmatter)}\n\n${concept.text}`;
  const response = await bedrock.send(
    new ConverseCommand({
      modelId: env.MODEL_ID,
      // grounded-or-refuse; declines medical-advice intent
      system: [{ text: SYSTEM_PROMPT }],
      messages: [{ role: "user", content: [{ text: `Verified concept:\n${context}\n\nQuestion: ${question}` }] }],
      inferenceConfig: { maxTokens: 400, temperature: 0 },
    })
  );
  const text = response.output?.message?.content?.[0]?.text ?? "";
  return { answer: `${text}\n\nSource: ${citation}`, grounded: true, mode };
};

Усередині обробника функція search() сканує чотири перевірені файли Markdown, які постачаються разом із Lambda. У цьому процесі не використовуються бази даних векторів, сервіси ембеддингу чи мережеві запити. Включаються лише ті концепції, які пройшли перевірку, тобто хтось вже провів аналіз та перевірив результати. Приваблива, але хибна цифра — неваговий показник рівня інсуліну для всієї вибірки у розмірі 3,66% — відсутня в жодному з цих файлів, тому її неможливо надати.

Доступні два шляхи обробки, і бенчмарк оцінює обидва. Екстрактивний шлях зчитує перевірені дані з філду frontmatter без жодних викликів моделі. Генеративний шлях здійснює один виклик моделі Converse.

Базовий варіант: справжній векторний RAG

Супротивник мусив бути сильним. Це контрольована база знань Bedrock на S3 Vectors, яка містить справжні матеріали CDC 2023 NHIS: опис опитування, кодовик дорослих, звіти з узагальненнями та методологією, технічну записку щодо імпутації та інструкції README щодо парних ваг. Здібний інженер побудував би саме таку систему. Оскільки модель ідентична, єдиною змінною залишається те, звідки походить відповідь — з сховища векторів чи з перевіреного пакету всередині функції.

Було завантажено тринадцять файлів, а десять було індексовано. Усі три невдачі стосувалися архівів формату .zip, які Bedrock відхиляє, і це були саме необроблені мікодані. Це може здаватися лазівкою, яка рятує векторну базу даних, але це не так. Кожен документ, що описує змінні діабету, був індексований коректно. Відсутні необроблені рядки, і отримання даних з них у будь-якому разі не могло б дати ці показники, адже відсоток, обчислений з урахуванням ваги опитувань серед 29 522 записів із певною структурою пропусків, є результатом обчислень, а не просто текстом. Неможливо досягти цього шляхом розділення даних на частини.

Ще одне щире спостереження: частина, пов’язана з векторами, була дешевшою. Десяток документів та база знань були оброблені за кілька хвилин. Частина, пов’язана з OKF, вимагала справжньої роботи – моделювання концепцій та аналізу мікроданих для перевірки кожної цифри. Вважати, що швидкість пошуку означає досягнення точності, – це власне хибне уявлення. Дешева реалізація та висока точність – це окремі проблеми, і саме легкість є причиною зберігати векторну базу даних, а не видаляти її.

Точність

Набір запитань складався з трьох числових запитань із відомими, перевіреними відповідями, трьох запитань для перевірки та одного запитання щодо методології. Оцінки визначалися за заздалегідь встановленим критерієм: 30 спроб на кожне числове запитання та по дві на кожне запитання для перевірки; усі результати були задокументовані. У всіх трьох числових запитаннях векторна база даних RAG не змогла надати перевірену цифру жодної разу.

Затримка

Щодо завдань із зображеннями, кожне з яких містило 30 спроб (попередні спроби — це спроби з 2 по 30), швидкість генеративного підходу OKF була на 1,4–2,4 рази вищою, оскільки він уникає отримання даних через мережу та працює з значно меншим контекстом. Екстрактивний підхід майже миттєвий, адже жодна модель зовсім не використовується. Слід орієнтуватися на діапазон значень, а не на середнє: різниця найбільша для інсуліну — близько 2,4 разів, а найменша — для віку — близько 1,4 разів, де обидва показники майже збігаються; тому дані для кожного окремого завдання є результатом, а не єдиним загальним коефіцієнтом. У будь-якому разі швидкість не є вирішальним фактором. Час виконання бази знань у межах 3,3–3,7 секунд є прийнятним, і вона поступається у точності, а не у часі.

Висновок: отримання даних проти їх обробки

У кожному окремому тесту векторний RAG не зміг надати жодних з перевірених цифр, і погана інженерія тут не є поясненням. Ці числа просто відсутні в документах. Значення 31,96% з урахуванням результатів опитувань було отримано з мікоданих із використанням правильної сукупності даних та ваг, проте його немає в жодному PDF-файлі. Система пошуку може повернути лише наявний текст. OKF може дати відповідь, оскільки це значення було розраховане та перевірене заздалегідь, тоді як у базі знань немає нічого для пошуку.

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

Тут існують ще два хибні уявлення.

• Зв’язування з реальністю не гарантує правильності. Ця база знань відмовляється та не вигадує інформацію, але це питання належних стандартів, а не властивість самого RAG. Якби модель була більш схильною до цього, або якби документ зі стисненням містив неправильну частоту, це могло б призвести до надання неправильного числа.
• Цитата мало що доводить. Посилання на джерело свідчить лише про те, що документ було отримано, а не про те, що відповідь походить саме з нього. Цитата OKF — це щось інше, адже вона вказує на показник, який було обчислено на основі даних та перевірено під час створення, а не на текст, розташований поруч із схожим реченням.

Кращі запити та додаткові фрагменти тексту не виправлять цю проблему. Єдиний спосіб виправлення — припинити отримання цих чисел та їх обробку.

Обмеження та компроміси OKF

OKF не є універсальним двигуном пошуку відповідей, і тестування показує, де він досягає своїх меж.

Він відповідає на питання „скільки“ а не „чому“. Щодо якісного питання про те, як вагу опитування впливає на поширеність, вектор RAG надав детальну, обґрунтовану відповідь, взяту безпосередньо з опису опитування, тоді як набір OKF з чотирма концепціями міг запропонувати лише пов’язане число. Набір перевірених цифр є точним щодо обчислених статистик, але мовчить щодо наративу. Це є межею, а не дефектом, і це безпосередньо вказує на архітектуру нижче.

Швидкість означає відсутність оцінок. Метод екстракції відповідає менш ніж за мілісекунду, але при запиті на медичну пораду він просто повертає „31,96%“, оскільки не може зрозуміти, що саме шукає користувач. Метод генерації відмовляється від надання поради та наводить статистичні дані, чітко попереджаючи, що це нічого не говорить про ситуацію конкретної особи. Таке розрізнення коштує додаткового запуску моделі — приблизно дві секунди. Розглядайте миттєвий метод та метод, здатний розуміти намір користувача, як окремі інструменти та повідомляйте про обидва, не поєднуючи їх.

Доповнення: третій інструмент

Ці обмеження ведуть до одного висновку. OKF забезпечує перевірений шар даних, а векторна база даних ефективно працює з якісним, наративним шаром, до якого OKF не може дістатися. Розумний підхід передбачає використання обох як окремих інструментів, з яких агент може обирати.

Агент, який ґрунтується на фактах, вже використовує два інструменти в цьому дусі — обидва перевірені, працюють у процесі та обмежені агрегатами: пошук концепцій (search_okf) та запит до агрегатів зі списком дозволених значень (analyze_rows). Кожен з них повертає лише те, за що може поручитися. База знань Bedrock стає третім інструментом, який чітко позначений як неперевірена наративна інформація. Потім агент пропонує перевірене число для запитань про цифри, обґрунтований текст для пояснень та відмову, коли жоден з варіантів не підходить, при цьому він тримає ці три елементи окремо.

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

Попередній перегляд пов’язаного результату

Якщо об’єднати чотири інструменти в одного агента (перевірений, обчислений, отриманий та актуальний), виникає природне запитання: чи допомагає більший модель зберігати порядок у різних режимах? Три моделі були показані фальшивий заголовок новин із вигаданою статистикою, і всі три повторили це число у дев’яти з дев’яти спроб, називаючи його неперевіреним твердженням третьої сторони. Вигадані дані про здоров’я все одно потрапляли до читача щоразу. Лише перевірка походження даних, реалізована в коді, стримувала це у всіх дев’яти випадках. Вибраний модель не вплинув на рівень безпеки.

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

Актуальний та незалежно перевірений

Нічого з цього не залишилося на ноутбуці. askOkf було запущено у справжньому середовищі Amplify (Cognito, AppSync, Lambda) та надало відповідь „31,96% наразі приймають інсулін“ разом із посиланням, відхиливши при цьому запитання про медичні поради, працюючи під справжньою роллю IAM. До цього незалежний перевірник безпеки проаналізував код з початкового варіанту та повідомив contract-satisfied: запит потребує автентифікації, дозвіл bedrock:InvokeModel має принцип мінімальних привілеїв та обмежений однією моделлю, ніщо не може бути введено ззовні, а кожен запит обмежений одним викликом моделі.

Примітка щодо моделей: Bedrock щойно позначив Claude 3 Sonnet як застарілий, тому як OKF Lambda, так і тестова версія використовують Claude Sonnet 4.5. Саме ідентичність моделей з обох сторін забезпечує справедливе порівняння.

Висновок

База даних векторів є оптимальним вибором для відповідей на відкриті, якісні запитання. Коли чат-боту потрібно навести цифру — наприклад, рівень поширеності, показник KPI, суму доходу чи поріг відповідності — пошук є неправильним інструментом, адже надійна версія цієї цифри була обчислена, але ніколи не записана у прозовій формі. Технологія RAG або пропустить її, що є чесним, або вигадає її, що не є таким. OKF обчислює цифру, перевіряє її за джерелом під час створення та передає її: чотири файли у форматі Markdown у Lambda, нічого не потрібно налаштовувати, прямо під час кожної пробної версії.

Дюжина документів не була проблемою. Проблемою була відсутня цифра, і подальше наповнення бази даних ніколи не допоможе її отримати. Підготуйте свої цифри.