Зміст
Коротко
Велика мовна модель (LLM) може впевнено назвати суму або середнє значення, навіть не опрацювавши всі вихідні рядки. Автор розбору на Habr пропонує не змушувати ШІ рахувати «в голові»: обчислення має виконувати DuckDB, а модель — керувати інструментами.
Підхід поєднує перегляд структури даних до першого запиту, доступ лише для читання та окрему пісочницю для складнішої аналітики. Він не усуває помилки повністю, проте звужує простір, у якому ШІ здатен замінити відсутній факт правдоподібним припущенням.
Що сталося
Автор починає з поширеної проблеми: передавати CSV-файл безпосередньо в контекст моделі ненадійно для аналізу таблиць. Для LLM таблиця лишається текстом. Якщо рядків забагато, назва стовпця неочікувана або запит сформульований неточно, модель може добудувати схожу на правду відповідь замість чесного повідомлення про нестачу даних.
Claude Desktop краще працює з великими наборами, однак один і той самий запит усе ще може привести до різних шляхів аналізу. Автор не намагається відтворити внутрішню будову продукту, а переносить корисний принцип у власний сервер інструментів: модель складає запит, а контрольоване середовище отримує та обчислює дані.
За арифметику відповідає DuckDB. ШІ пише SQL, але середнє, суму, групування та з’єднання таблиць виконує рушій. Якщо для статистики, прогнозу чи перетворень SQL замало, код запускається в окремій ізольованій пісочниці Python.
Чому це важливо
Помилка в числі небезпечніша за неточне формулювання: вона звучить переконливо, може потрапити до звіту й вплинути на бюджетне або клієнтське рішення. Навіть правильний рушій не врятує, якщо модель вибрала не той стовпець або підсумувала лише скорочену вибірку.
Тому критична послідовність дій. Спочатку ШІ має побачити перелік доступних наборів і їхню структуру: назви полів, типи, частку пропусків, одиниці виміру та валюти. Лише після цього варто складати запит. Так менше шансів вигадати таблицю, поле або поєднати несумісні величини.
Інструменти мають чесно описувати й результат. Якщо запит не повернув рядків, вони можуть показати фактичні значення у стовпці фільтра. Якщо відповідь скорочено, про це слід повідомити явно. Замість потреби здогадуватися модель отримує дані, щоб виправити запит.
На практиці
Основні обмеження можна додати без побудови великої аналітичної платформи:
- Виконуйте арифметику та підсумкові операції в базі даних або аналітичному рушії, а не у відповіді LLM.
- Надайте інструмент перегляду схеми до виконання запиту, щоб модель не вигадувала таблиці та поля.
- Дозволяйте лише читання даних і перевіряйте SQL перед запуском. Забороняйте зміну даних, довільний доступ до файлів і завантаження розширень.
- Запускайте написаний моделлю Python-код у відокремленому середовищі з відомим набором бібліотек та обмеженим доступом до мережі.
- Повертайте кількість рядків, ознаку скорочення та зрозумілі помилки. Коли фільтр нічого не знайшов, допоможіть порівняти його з реальними значеннями.
Межі такого підходу теж варто враховувати. Проста перевірка SQL може не помітити з’єднання, що дублює рядки, а збережена схема може застаріти. Попередження про змішані валюти корисне, але слабше за правило, яке система виконує примусово.
Підсумок
Мета не в тому, щоб пообіцяти безпомилковість ШІ. Надійність зростає, коли код контролює обчислення, доступ до файлів і стан даних, а модель не може тихо підмінити відсутній доказ переконливим текстом.
Для команд, які під’єднують LLM до таблиць, корисний орієнтир — простежуваність: кожне число у відповіді має вести до виконаного запиту й конкретного набору даних. Межі, закріплені в інструментах, полегшують перевірку та повторення результату.