Вправи з DeepSeek — аналіз SQL-запитів

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

Хайп сьогоднішнього допису – DeepSeek, розроблена в Китаї велика мовна модель, що глибоко вразила багатьох, передовсім швидкістю своєї роботи та здатністю пояснювати свої висновки. "Міркуючи" над вашим запитом, вона показує хід своїх "думок" в окремій секції інтерфейсу – і з якоїсь причини ця здатність отримала високу оцінку користувачів, ніби всі вони мають проводити технічну співбесіду з цією моделлю, і мають потребу зрозуміти, наскільки вона здатна розбиратися в питаннях. Як на мене, витрачати час на те, аби, зрештою, модель спромоглася видати свої проміжні "думки" на екран, є чимось нерозумним, оскільки все, що мені потрібно – це просто якнайшвидше отримати відповідь. Якщо відповідь неправильна, я не вбачаю сенсу в аналізі ходу міркувань моделі; якщо відповідь правильна, то це, власне, те, заради чого я цю модель використовую – я не є спеціалістом з мовних моделей, мені байдуже, як саме вона "міркувала". Я отримав правильну відповідь, на цьому – все, дякую :)

В різних відео люди просять DeepSeek написати гру в Пітоні, дати пораду щодо дитячого свята або порахувати 'r' в слові 'strawberry'. Це круто, але все це лежить трохи осторонь моїх повсякденних потреб. Я – кодер, тож мені потрібна підмога в кодуванні. Тож я вчинив просто – взяв шматчоок SQL-коду й попрохав DeepSeek пояснити, що в ньому відбувається.

Я взяв три моделі DeepSeek: DeepSeek-Coder-V2-Lite-Instruct-Q8_0.gguf (15.56 GB), DeepSeek-R1-Distill-Llama-8B-Q8_0.gguf (7.95 GB) та Qwen2.5-14B-DeepSeek-R1-1M-Uncensored.Q8_0.gguf (15.7 GB).

Також я взяв дві інші моделі: qwen2.5-coder-14b-instruct-q4_0.gguf (8.52 GB) та qwen2.5-coder-32b-instruct-q4_0.gguf (18.64 GB).

Для звірення я брав відповідь ChatGPT 4 в засадничому режимі "Вдалий для повсякденних завдань".

Всім моделям було поставлене те саме питання, буква в букву, і лише одна з них, а саме qwen2.5-coder-32b-instruct-q4_0, надала правильну відповідь.

Отже, питання було таке:

I have 2 t-sql queries which logically are the same but provide different results:

select id,
       case
           when p_id is null then 'Root'
           when id in (select distinct p_id from Tree) then 'Inner'
           else 'Leaf'
           end as type
from Tree;

select id,
       case
           when p_id is null then 'Root'
           when id not in (select distinct p_id from Tree) then 'Leaf'
           else 'Inner'
           end as type
from Tree

Query 1 provides correct output whereas query 2 not. Why is that?

Якщо ви, як і я, ще не є SQL-гуру, можете зараз спробувати розібратися з цим самостійно.

І от шо відбулося далі.

1. DeepSeek-Coder-V2-Lite-Instruct-Q8_0.gguf – ця модель вважає, що обидва SQL-запити є тотожніми за логікою і поведінкою, і дає такий висновок:

Both queries should theoretically produce the same output. However, if there are any inconsistencies in your database or a mistake in data insertion, it might lead to different results. Given that both queries are logically equivalent in this context, you should check for potential issues with your data (e.g., missing values, incorrect insertions) and ensure that the schema is correctly defined.

2. DeepSeek-R1-Distill-Llama-8B-Q8_0.gguf – я припинив роботу цієї моделі після 4+ годин очікування заради цікавості. Я не мав достатньо терпіння :) і в останніх параграфах видачі модель стрибала між "Отже...", "Зачекай-но.." та "Хоча, можливо.." (тут адаптивний переклад), згенерувавши 33008 марних токенів.

Якщо цікаво, тут повна видача цієї моделі.

3. Qwen2.5-14B-DeepSeek-R1-1M-Uncensored.Q8_0.gguf – цього разу модель відпрацювала набагато швидше, втім, з так само неправильним висновком.

The two queries are logically equivalent and should produce the same result. If they differ, it might be due to an oversight in the data or conditions.

4.Qwen2.5-coder-14b-instruct-q4_0.gguf – працювало недовго, висновок неправильний, відхилилось в якісь хащі, де намагалося розрізнити різні типи вузлів.

Query 1 correctly implements the logic to distinguish between root, inner, and leaf nodes based on their relationship with other nodes.

Query 2, due to its conditional logic, fails to properly classify nodes that are both parents and have children as 'Inner' nodes, leading to incorrect results.

5. Qwen2.5-coder-32b-instruct-q4_0.gguf – переможець цих змагань. Затребувавши 32 ГБ пам'яті, просуваючись так повільно, як я ледь можу дозволити собі на своєму комп'ютері, все ж таки модель закінчила з коректним поясненням того, що ж саме є неправильним в тих двох SQL-запитах:

The difference in the results of your two queries stems from how the CASE statement handles the conditions, particularly when it comes to the presence of NULL values in the subquery.

Why Query 2 Provides Incorrect Results:
The issue with Query 2 arises when there are NULL values in the subquery result (select distinct p_id from Tree). In SQL, comparisons involving NULL return UNKNOWN, not TRUE or FALSE. Therefore:

Solution:

To ensure that Query 2 works correctly, you should explicitly handle NULL values in the subquery:

select id,
    case
        when p_id is null then 'Root'
        when id not in (select distinct p_id from Tree where p_id is not null) then 'Leaf'
        else 'Inner'
    end as type
from Tree;

This modified version of Query 2 excludes NULL values from the subquery, ensuring that the NOT IN condition behaves as expected.

If your table contains any rows where p_id is NULL, those NULL values will cause the id NOT IN (subquery) condition to evaluate to UNKNOWN for all rows. As a result, no row will be classified as 'Leaf' based on this condition.

---
Як я згадував, відповідь ChatGPT, яку я брав за дороговказ, була викладена майже тими самими словами, а запропонований фікс коду на 100% співпадав з тим, що я отримав від локальної моделі.

Отже, не все то істина, що від моделі :)