Таблиці, яких не існувало

Розділ 2 — Таблиці, яких не існувало

Технік з машинобудівної компанії на Півночі-Сході розповів нам про це за еспресо, з тією спокійністю, притаманною венеційцям, яка передує катастрофі: "Наш чат-бот знав все про двигун. Крім даних про двигун." Потім він пояснив. Їхній внутрішній AI-асистент міг описувати лінійки продуктів, контексти використання, історію бренду, конкурентні переваги. Чудово, з точки зору наративу. Але коли клієнт запитував номінальний крутний момент моделі CMP50L — тобто технічні дані, заради яких люди відкривають каталог, номер, за який купують двигун — чат-бот відповідав розпливчасто, іноді правдоподібно, іноді ні. П’ять місяців розробки, все більш спантеличений операційний директор, і ніхто не знав, чому.

Діагноз прийшов випадково, майже від нудьги, під час ручної перевірки бази даних після чергових безрезультатних зборів. PDF-каталог містив 342 технічні таблиці. У базі даних надійшло нуль. Не жменька: нуль. Жодної. Код, який витягував таблиці з PDF, зберігав дані в полях під назвою columns та data, тоді як код, який потім їх індексував, очікував поля під назвою headers та rows. Недотриманий "синонім". Внутрішня домовленість, яка зірвалася під час забутого рефакторингу. Результат, протягом п’яти тихих місяців: вся числова інтелектуальність каталогу — пари, потужності, діаметри, ваги, коди замовлення, напруги живлення — витікала з крана, не будучи налитою в склянку. Триста сорок дві таблиці, втрачені одна за одною в літургійній тиші.

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

Урок полягає не в тому, щоб "стежити за назвами полів". Він більш складний: у серйозному RAG кожен тип контенту — таблиці, зображення, буквено-цифрові коди, заголовки параграфів, виноски — потребує спеціальної обробки, проєктування та тестування. І тест на працездатність — це не "чат-бот відповідає на тривіальні запитання" — на них відповідають навіть несправні системи, оскільки є достатньо плаваючих даних для побудови чогось правдоподібного. Справжній тест — це "чат-бот відповідає на запитання, які змушують його торкатися кожної частини конвеєра". Конкретні, числові, перевіряємі запитання. Запитання, для яких існує одна правильна відповідь, і якщо система помиляється, ви одразу це знаєте.

Якщо ви не проводите цей тест, ви не знаєте, чи працює ваш RAG. Ви знаєте лише, що він не скаржиться. А "не скаржиться" — це дуже низький критерій якості для системи, яку люди використовуватимуть для прийняття рішень.