Сьогодні text-to-SQL має на меті полегшити роботу з базами даних, дозволяючи користувачам ставити запитання про складні дані, використовуючи звичайну мову. Однак багато сучасних методів не працюють належним чином, оскільки надто зосереджуються лише на створенні SQL-коду.

У цьому пості я не буду заглиблюватися в оптимізацію генерації SQL. Замість цього хочу поділитися технікою, яку я знайшов корисною для покращення підходу до багатьох проблем з підготовкою запитів, використовуючи text-to-SQL як тестову базу: використання синтетичних резюме для покращення навчання на малих вибірках.

Навчання на малих вибірках — це метод, коли ми надаємо системі невелику кількість прикладів для допомоги в розумінні та виконанні завдання. У нашому випадку ми використовуємо це для того, щоб допомогти зіставити запитання користувача з відповідними SQL-запитами. Основна ідея, яку ми будемо досліджувати, — це використання синтетичних резюме SQL-запитів для покращення цього процесу.

Ось основна ідея:

1. Ми беремо наявні SQL-запити і створюємо детальні резюме того, що вони роблять.
2. Ми використовуємо ці резюме, а не сам SQL, при намаганні зіставити запитання користувача з відповідними запитами.
3. Ми можемо генерувати більше таких резюме за потребою, що дозволяє нам постійно покращувати нашу систему.

За результатами моїх тестів, цей підхід показав багатообіцяючі результати:

• Він покращив точність пошуку правильної інформації з 81 % до 90 %.
• Він зберігав гарну ефективність, навіть коли ми додавали неактуальні дані.
• Він виявився кращим у захопленні бізнес-логіки порівняно з традиційними методами.

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

У решті цього посту я розповім, як я розробив цей підхід, з якими проблемами стикнувся та які рішення знайшов. Сподіваюся, що поділившись цим досвідом, я зможу надати корисні поради для інших, хто працює над подібними проблемами, навіть якщо вони не зосереджені безпосередньо на генерації SQL.

Не забувайте, що основний висновок тут не про сам SQL, а про те, як ми можемо використовувати синтетичні дані та резюме для розробки систем на базі LLM (Language Model). Цей підхід потенційно можна застосувати в багатьох інших сферах, де ми намагаємося зіставити запити на природній мові зі специфічною технічною інформацією.

Виходячи за межі простого SQL: захоплення складної бізнес-логіки

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

Приклад: Місячне зростання

Молодший інженер може підходити до цього завдання з на перший погляд розумним запитом:

SELECT  
 DATE_TRUNC('month', order_date) AS month,  
 SUM(total_amount) AS monthly_revenue,  
 LAG(SUM(total_amount)) OVER (ORDER BY DATE_TRUNC('month', order_date)) AS previous_month_revenue,  
 (SUM(total_amount) - LAG(SUM(total_amount)) OVER (ORDER BY DATE_TRUNC('month', order_date))) /  
 LAG(SUM(total_amount)) OVER (ORDER BY DATE_TRUNC('month', order_date)) * 100 AS month_over_month_growth  
FROM  
 orders  
GROUP BY  
 DATE_TRUNC('month', order_date)  
ORDER BY  
 month;

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

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

WITH daily_revenue AS (  
 SELECT  
 DATE(order_date) AS date,  
 SUM(CASE  
 WHEN order_status IN ('completed', 'shipped')  
 AND payment_status = 'paid'  
 AND return_date IS NULL  
 THEN total_amount  
 ELSE 0  
 END) AS revenue  
 FROM  
 orders  
 LEFT JOIN returns ON orders.order_id = returns.order_id  
 GROUP BY  
 DATE(order_date)  
),  
rolling_28_day AS (  
 SELECT  
 date,  
 SUM(revenue) OVER (  
 ORDER BY date  
 ROWS BETWEEN 27 PRECEDING AND CURRENT ROW  
 ) AS revenue_28_day,  
 LAG(SUM(revenue) OVER (  
 ORDER BY date  
 ROWS BETWEEN 27 PRECEDING AND CURRENT ROW  
 ), 28) OVER (ORDER BY date) AS prev_revenue_28_day  
 FROM  
 daily_revenue  
),  
fiscal_periods AS (  
 SELECT  
 date,  
 revenue_28_day,  
 prev_revenue_28_day,  
 FLOOR((EXTRACT(DOY FROM date) - 1) / 28) + 1 AS fiscal_period  
 FROM  
 rolling_28_day  
)  
SELECT  
 fiscal_period,  
 MAX(date) AS period_end_date,  
 SUM(revenue_28_day) AS period_revenue,  
 SUM(prev_revenue_28_day) AS prev_period_revenue,  
 CASE  
 WHEN SUM(prev_revenue_28_day) > 0 THEN  
 (SUM(revenue_28_day) - SUM(prev_revenue_28_day)) / SUM(prev_revenue_28_day) * 100  
 ELSE  
 NULL  
 END AS growth_rate  
FROM  
 fiscal_periods  
GROUP BY  
 fiscal_period  
ORDER BY  
 fiscal_period DESC;

Ця версія враховує кілька важливих аспектів:

1. Визнання доходу: Доходом враховуються лише завершені або відправлені замовлення, які були сплачені і не повернуті.
2. Фінансові періоди: Замість календарних місяців використовуються 28-денні фінансові періоди, що гарантує однакову кількість кожного дня тижня в кожному періоді.
3. Рухоме вікно: Використовується рухоме вікно на 28 днів в межах цих фінансових періодів.
4. Агрегація періоду: Агрегується дохід за весь період і порівнюється з попереднім періодом.
5. Гнучке визначення кінця періоду: Кінець кожного фінансового періоду визначається динамічно.
6. Обчислення темпу зростання: Темп зростання обчислюється за допомогою загального доходу для кожного фінансового періоду.

Чому бізнес-логіка важлива

Цей приклад з “місячним зростанням” — лише верхівка айсберга. Ледь не кожен на перший погляд простий бізнес-показник може мати приховані складнощі:

1. Фінансові роки: Фінансовий рік компанії може не збігатися з календарним, що впливає на всі розрахунки за рік.
2. Сегментація клієнтів: Визначення “клієнта з високою цінністю” може сильно відрізнятися між бізнесами та навіть між відділами в одній компанії.
3. Обіг товарів: Цей розрахунок може змінюватися залежно від галузі або навіть продуктових ліній в одній компанії.
4. Атрибуція продажів: У бізнесах з комплексними продажами атрибуція продажу до конкретного каналу маркетингу або продавця часто вимагає складної логіки.

Потужність репозиторію SQL-запитів

Зважаючи на ці складнощі, важливо мати репозиторій добре визначених SQL-запитів. Такий репозиторій виконує кілька ключових функцій:

1. Послідовність: Він гарантує, що всі в організації використовують однакові визначення і розрахунки для ключових показників.
2. Передача знань: Нові члени команди можуть швидко зрозуміти, як компанія обчислює різні показники.
3. Основи автоматизації: Ці запити можуть служити основою для автоматизованих звітних систем.
4. Відповідність вимогам: У регульованих галузях наявність централізованого репозиторію затверджених розрахунків може допомогти в аудиторських процесах.

Коли цей репозиторій застосовують до системи text-to-SQL, його потенціал стає ще більшим.
Замість того, щоб генерувати загальний SQL, система може використовувати бібліотеку запитів, які вже вбудовують специфічну бізнес-логіку компанії та переважні методи розрахунків.

Маючи таку бібліотеку запитів у репозиторії прикладів, ми виходимо за межі типового SQL. Ви можете уявити, як можна використовувати такі приклади для складання електронних листів, написання коду, вилучення даних та багато іншого.

Ключовим моментом у цьому застосуванні є те, що, хоча наявність репозиторію SQL-коду є потужною, використання синтетичних резюме може покращити відновлення цих даних через систему пошуку.

Наше рішення: Кращий спосіб комбінувати різні методи

Щоб наша система працювала краще, ми використовуємо комбінацію різних інструментів. Ось як це працює:

1. Синтетичні резюме: Ми використовуємо штучний інтелект (AI), щоб створити детальні резюме таблиць та SQL-коду. Ці резюме допомагають краще розуміти інформацію, ніж просто перегляд ключових слів.
2. Пошук із доповненням контекстного навчання: Наша система використовує двоступеневий процес для покращення генерації SQL:

• Спочатку ми ідентифікуємо відповідні таблиці та фрагменти коду.
• Отримані таблиці та приклади коду використовуються для надання контекстних інструкцій нашій великій мовній моделі (LLM), що дозволяє їй краще розуміти та застосовувати специфічні бізнес-правила при генерації SQL-запитів.

def create_sql_answer(question):  
 tables = BASIC_TABLES + find_related_tables(question)  
 code_examples = BASIC_EXAMPLES + find_related_examples(question)  
 final_answer = ai.generate_answer(tables, code_examples, question)  
 return final_answer

Ось спрощений приклад того, як ми надаємо запит для генерації SQL нашій LLM:

You are an SQL analyst tasked with writing SQL queries to answer specific questions about data stored in a database. Your goal is to create an accurate and efficient SQL query that answers the given question.  

Here is the question you need to answer:  

{{QUESTION}}  


To help you write the SQL query, here are some relevant tables you can use:  

{{TABLES}}  


Additionally, here are some relevant example snippets that may be helpful:  

{{EXAMPLES}}  


Follow these steps to create your SQL query:  

1. Carefully analyze the question to understand what data is being requested.  
2. Identify the relevant tables and columns needed to answer the question.  
3. Determine any necessary joins, filters, aggregations, or other SQL operations required to produce the desired result.  
4. Write a clear and efficient SQL query that answers the question.  
5. After writing the query, briefly explain your approach and any key decisions you made in constructing the query.  

Please provide your response in the following format:  

[Your SQL query here]  



[Your explanation of the query and approach here]  


Remember to use proper SQL syntax and best practices when writing your query. If you need any clarification or additional information to answer the question, please state so in your explanation.

Тестування наших ідей з використанням синтетичних даних

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

Щоб оцінити наш підхід з використанням синтетичних резюме для навчання на малих вибірках (few-shot learning) у задачах text-to-SQL, нам знадобилася тестова система.
Ось як ми розробляли та вдосконалювали процес тестування:

Початкові спроби з простими синтетичними даними

Ми почали з створення власних простих запитів і відповідних запитань.

SELECT product_id, COUNT(impression_id) as impression_count  
FROM impressions  
WHERE product_id = $1 AND deleted_at IS NULL  
GROUP BY product_id;

Запитання: “Як дізнатися, скільки вражень отримав конкретний продукт, не враховуючи ті, що були видалені?”

Однак цей підхід виявився занадто спрощеним. Наша система досягла підозріло високих результатів (recall@5 = 0.95), що вказує на те, що наш тестовий набір був недостатньо складним.

Використання складних відкритих даних

Для створення більш реалістичного тестового середовища ми звернулися до набору даних BirdSQL, який містить понад 1 500 запитів, що працюють з 95 окремими таблицями. Це надало необхідну складність для відтворення реальних сценаріїв.

Приклад запиту з BirdSQL:

SELECT  
 (CAST(SUM(T1.id) AS REAL) / COUNT(T1.id)) / 4,  
 T2.language  
FROM  
 sets AS T1  
INNER JOIN  
 set_translations AS T2 ON T1.id = T2.id  
WHERE  
 T1.releaseDate BETWEEN '2012-01-01' AND '2015-12-31'  
GROUP BY  
 T1.releaseDate  
ORDER BY  
 COUNT(T2.language) DESC  
LIMIT 1

Оригінальне запитання: “Яка середня річна кількість наборів, що були випущені в період з 1.01.2012 по 31.12.2015? Вкажіть загальну мову картки.”

Врахування надмірно специфічних запитань

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

Використання LLM для узагальнення запитів

Щоб вирішити цю проблему, ми використовували великі мовні моделі (LLM), щоб переписати запитання, створюючи більш узагальнені версії, які відображали суть без витоку специфічних деталей.

Переписане запитання: “Яка середня популярність наборів, випущених з 2012 по 2015 рік, за мовою?”

Цей процес значно змінив наші показники продуктивності (що було бажаним, ми не хотіли мати занадто легкий тест):

• Recall@5 для фрагментів: 0.84 → 0.68 (зниження на 20%)
• Recall@5 для резюме: 0.9 → 0.81 (зниження на 10%)
• Recall@10 для фрагментів: 0.92 → 0.82 (зниження на 11%)
• Recall@10 для резюме: 0.95 → 0.92 (зниження на 4%)

Генерація міток таблиць за допомогою LLM

Оскільки в BirdSQL не було міток релевантності для пар "запитання - SQL", ми використовували GPT для автоматичної генерації цих міток. Ми надавали моделі доступні таблиці та SQL-фрагмент, а потім просили її визначити, які з них є релевантними.

Приклад підказки:

Given a set of tables and a SQL snippet, describe if the tables or snippets are relevant to the question.  

Here are the relevant tables:  

[insert tables in database here]  


Here is the snippet:  

[insert snippet here]  


Here is the question:  

[insert question]  


Determine if the snippet is relevant

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

Ітерації над генерацією резюме

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

1. Виділити основну мету запиту.
2. Згадати важливі джерела даних (таблиці), які використовуються.
3. Описати основні SQL-операції.
4. Пояснити основні метрики або розрахунки.
5. Деталізувати важливі фільтри або умови.
6. Описати очікуваний результат і його бізнес-значення.
7. Запропонувати 2–3 конкретні способи, якими запит можна змінити або розширити.
8. Запропонувати потенційні запитання, які цей запит може допомогти відповісти.

Цей ітеративний процес призвів до значного покращення. Наша фінальна підказка досягла recall@5 на рівні 0.91, що на 54% краще, ніж безпосереднє вбудовування самого прикладу коду.

Оцінка стійкості до шуму

Для тестування стійкості нашого підходу ми навмисно вводили нерелевантні дані в наш тестовий набір.
Ми виявили, що наш метод на основі резюме зберігав recall@5 понад 90 %, навіть коли ми збільшували кількість нерелевантних даних. Натомість, метод на основі фрагментів показав зниження recall@5 до менш ніж 70 % за подібних умов.

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

Ось що ми виявили:

Наш метод на основі резюме продовжував працювати добре, зберігаючи точність на рівні близько 90 % у знаходженні правильної інформації (recall@5), навіть коли половина даних була нерелевантною. Це схоже на те, як наша система могла все одно знайти голку, навіть після того, як ми додали набагато більше сіна в купу.

З іншого боку, метод на основі фрагментів мав більші труднощі, коли ми додавали нерелевантні дані. Його точність впала з 85 % до 68 %, коли ми збільшили кількість нерелевантних даних з 10 % до 50 %.

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

Основні висновки з нашого процесу тестування

1. Починати з простого: Початок з простих запитів допоміг налаштувати наш початковий фреймворк, але складніші запити були необхідні для належного тестування.
2. Використовувати реалістичні дані: Використання існуючих наборів даних надало рівень складності і реалістичності, який ми не могли б досягти вручну. Якщо ваші базові показники високі, це може означати, що ваше завдання занадто легке. Це просто дивно.
3. Обережно з витоками даних: Запитання, надто специфічні до запитів, призводили до штучно високих показників продуктивності.
4. Креативно використовувати LLM: Ми використовували мовні моделі для генерації резюме, переписування запитів і генерування міток.
5. Ітерації над підказками: Постійне вдосконалення підказок було ключем до покращення продуктивності системи.
6. Об'єктивно вимірювати: Використання таких метрик, як recall@5 і recall@10, дало нам конкретні способи вимірювання покращень.
7. Тестування на стійкість: Введення шуму допомогло нам оцінити, як наша система працює в менш ідеальних умовах.

Цей процес тестування не тільки допоміг нам вдосконалити наш підхід, але й продемонстрував потенціал використання синтетичних резюме для навчання з кількома прикладами в завданнях text-to-SQL та потенційно в інших завданнях обробки природної мови.

Основні знахідки та аналіз

Наші тести виявили кілька важливих інсайтів:

1. Покращення точності пошуку: Наш підхід з індексом на основі резюме покращив recall@5 з 81 % до 90 %, що є значним підвищенням ефективності пошуку інформації.

2. Стійкість до шуму: Резюме зберігали recall@5 понад 90 % навіть при додаванні нерелевантних даних. Це контрастує з фрагментами, де recall@5 впав до менше ніж 70 %, коли ми додавали більше нерелевантних фрагментів.

3. Ключова роль інженерії підказок: Якість наших резюме та, відповідно, продуктивність усієї системи, була дуже залежною від підказок, які використовувалися для генерації цих резюме.

Покращення Recall за допомогою кращих підказок

В наших експериментах ми виявили, що спосіб, у який ми просимо нашу AI-модель створити резюме SQL-запитів, має велике значення. Ми спробували три різні способи запитування, або "підказки", і кожен з них дав нам кращі результати. Давайте подивимось, що ми зробили і що ми дізналися:

1. Проста підказка: Ми просто попросили створити коротке резюме.

Generate a concise, keyword-rich summary of the given SQL query without starting with phrases like "This SQL" or "The query". Avoid adjectives and focus on technical details.   

<snippet>  
{{ query }}  
</snippet>

**Підказка на основі ролі**: Ми сказали AI діяти як досвідчений аналітик даних і надали йому деякі правила.

Ви досвідчений аналітик даних з великим досвідом роботи з SQL, який каталогізує SQL-запит для майбутнього використання.

Згенеруйте коротке, багате на ключові слова резюме заданого SQL-запиту, уникаючи початків типу "Цей SQL" або "Запит". Уникайте прикметників і зосередьтеся на технічних деталях.

Включіть:
1. Основні операції та техніки SQL
2. Типи даних та контекст бізнес-аналізу
3. Ключові обчислення та метрики
4. Назви таблиць та важливі стовпці (будьте конкретними та всеохопними)
5. Критерії фільтрації та часові рамки
6. Специфічні функції SQL та клаузи
7. Елементи структури запиту
8. Опис виводу та його бізнесова цінність

{{ query }}

```

3. Детальна підказка з прикладами: Ми надали AI конкретну роль, чіткі інструкції та приклади хороших резюме.

<role>  
Ви досвідчений аналітик даних з великим досвідом роботи з SQL, який каталогізує SQL-запит для майбутнього використання.  
</role>  

<task>  
Ваше завдання — переглянути заданий SQL-запит і створити коротке, інформативне резюме, яке охоплює основні аспекти запиту. Ваше резюме має бути структурованим в одному абзаці і надавати достатньо деталей, щоб інші аналітики швидко зрозуміли мету запиту та можливі модифікації для їхніх випадків використання.  

Зосередьтеся на висвітленні:  
1. Основна мета запиту  
2. Важливі джерела даних (таблиці), що використовуються  
3. Основні операції SQL, що застосовуються  
4. Основні метрики або обчислення, що виконуються  
5. Значущі фільтри або умови, що застосовуються  
6. Очікуваний вивід та його бізнесова значущість  
7. 2-3 конкретні способи, якими можна модифікувати або розширити запит для суміжних аналітичних завдань  
8. Потенційні питання, на які інші аналітики можуть шукати відповіді за допомогою цього запиту  

Переконайтесь, що ви виводите дійсний JSON у вашій відповіді без можливих зайвих символів наприкінці.  
</task>  

<rules>  
1. Тримайте ваше резюме сфокусованим і коротким, уникаючи зайвих пояснень або загальних тверджень про SQL-техніки.  
2. Не пояснюйте базові концепції SQL або цінність структури запиту, якщо це не безпосередньо стосується його унікальних особливостей.  
3. Уникайте переліку всіх можливих значень для полів або пояснення кожного значення, якщо це не безпосередньо стосується мети запиту.  
4. Коли пропонуєте модифікації, будьте конкретними і пов’язаними з потенційними бізнес-запитами, на які цей запит може дати відповідь з незначними змінами.  
5. Використовуйте технічну SQL-термінологію належним чином, але не переобтяжуйте її поясненнями загальних операцій.  
6. Виділяйте будь-які незвичайні або особливо хитрі аспекти запиту, які можуть не бути очевидними на перший погляд.  
</rules>  

<query>  
{{SNIPPET}}  
</query>  

<examples>  
[Приклади опущені для стислості]  
</examples>

Що ми отримали

1. Резюме за допомогою простої підказки:

Обчисліть загальну середню вартість подій для Елайджи Аллена за вересень та жовтень.

2. Резюме за допомогою підказки на основі ролі:

Агрегований розрахунок середньої вартості витрат Елайджи Аллена на події у вересні та жовтні. Фільтрується за користувачем і двомісячним періодом часу за допомогою SQL-клауз і BETWEEN. Орієнтується на таблицю подій і стовпець витрат для обчислення ключової метрики — середньої вартості, висвітлюючи фінансові аспекти витрат особи на події.

3. Резюме за допомогою детальної підказки:

Цей SQL-запит обчислює середні витрати для члена ‘Елайджа Аллен’ у вересні та жовтні. Він об’єднує таблиці ‘member’ та ‘expense’ за допомогою ‘memberid’, фільтрує за ‘Елайджа Аллен’ через ім’я та прізвище і ізолює витрати з вересня та жовтня за допомогою порівняння підрядків у полі ‘expensedate’. Результат — це середні витрати, понесені Елайджою Алленом у ці місяці.
Цей запит можна легко модифікувати для аналізу витрат за різні періоди, для різних членів або груп членів, змінюючи умови в клаузі WHERE. Подальші розширення можуть включати агрегацію витрат за категоріями або порівняння індивідуальних витрат з середніми витратами департаментів для виявлення аномалій.

Як працювала кожна підказка

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

Як видно, наша детальна підказка працювала найкраще, знаходячи правильну інформацію в 91 % випадків серед перших п'яти результатів.

Що ми дізналися

1. Починайте з простого, потім додавайте деталі: Початок з базової підказки створив основу для покращення.
2. Призначте AI роль: Інструктування AI про прийняття ролі експерта підвищило якість резюме.
3. Надавайте чіткі інструкції: Чітке викладення наших вимог до резюме призвело до кращих результатів.
4. Використовуйте приклади: Демонстрація того, що є хорошим резюме, значно покращила результати AI.
5. Застосовуйте оцінки: На диво, довші резюме давали кращий recall. Оцінки дозволили нам перейти від інтуїтивних рішень до рішень, заснованих на даних.
6. Використовуйте оцінки для оптимізації: Завдяки метрикам оцінок ми могли приймати обґрунтовані компроміси між складністю підказки та її ефективністю.

Економія часу та грошей

Використовуючи ці підказки, ми можемо застосувати два трюки для економії часу та грошей:

1. Кешування підказок: Це означає, що ми зберігаємо частини підказки, які не змінюються, такі як інструкції та приклади, які тепер доступні в OpenAI та Anthropic API. Ми відправляємо тільки нові частини (як-от SQL-запит) кожного разу. Це може зробити процес швидшим і дешевшим.
2. Пакетування: Замість того, щоб надсилати один запит за раз, ми можемо відправити пакет запитів. Це особливо корисно, коли нам не потрібно отримувати відповіді негайно. Це може заощадити гроші, оскільки відправка одного великого пакету часто коштує на 50 % менше.

Що це означає для інших завдань

Спосіб, яким ми покращили SQL-резюме, може бути корисним і для інших завдань з пошуку:

• Підсумовування вмісту таблиць баз даних
• Опис зображень
• Підсумовування довгих документів
• Написання пояснень до комп'ютерного коду
• Доповнення текстових блоків

Завдяки тестовому набору ми можемо доповнити його синтетичними даними та експериментувати з техніками підказок для покращення recall.

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

Якщо ви шукаєте базу даних для створення продуктів на основі AI, зверніться до pgai та Timescale Cloud. За допомогою Timescale Cloud розробники можуть отримати доступ до pgvector та pgai — розширень, які перетворюють PostgreSQL на просту у використанні та високо продуктивну векторну базу даних, а також повністю кероване хмарне середовище для баз даних. Створіть ваш AI-додаток за допомогою Timescale Cloud сьогодні (це безкоштовно на 30 днів, без необхідності надавати дані картки).

Цю статтю написали Джейсон Ліу та Іван Лео і вона була опублікована тут на офіційному блозі Timescale 2 січня 2025 року.

Перекладено з: Enhancing Text-to-SQL With Synthetic Summaries: A Few-Shot Learning Approach