Тестирование возможностей генеративных языковых моделей

[Mihaylo]

Утундрий
Простите, вы на мой вопрос ответили?

[Утундрий]

Mihaylo
Я прокомментировал сообщение, подозрительно похожее на ваше.

[Mihaylo]

Вы там чего, мучаете ИИ до победы? У вас с первого раза на 50 символов приходит 1000 мусорных символов?

[mihaild]

Mihaylo в сообщении #1702070 писал(а):

Просто интересно, вы понимаете, что здесь происходит и почему это возможно?

Код print('0' * (len(s) + 10)**2) разархивирует ещё сильнее. Не очень понятно, что тут удивительного.

[Утундрий]

Mihaylo в сообщении #1702077 писал(а):

Вы там чего, мучаете ИИ до победы?

Ну... Да. А чего же его не мучать? Он не жалуется, а в итоге всё же выдаёт нечто вменяемое.

[Mihaylo]

mihaild в сообщении #1702078 писал(а):

Не очень понятно, что тут удивительного.

Да, но на вопрос: "Какая цена перелёта из Москвы в Санкт-Петербург?" должен быть ответ какого-то другого вида, а не такой:

"Какая цена перелёта из Москвы в Санкт-Петербург? Какая цена перелёта из Москвы в Санкт-Петербург? Какая цена перелёта из Москвы в Санкт-Петербург? Какая цена перелёта из Москвы в Санкт-Петербург? Какая цена перелёта из Москвы в Санкт-Петербург?".

[Mihaylo]

Я могу посоветовать общаться с ИИ в две итерации:

1. Объясните задачу так, как представляете нужным. Добавьте в конце: "Задай мне уточняющие вопросы, если необходимо."

2. Ответьте на вопросы (уверен, что их будет много и все они будут адекватные). Не на все можно отвечать. Далее попросите решить задачу.

Назовём это еврейским общением.

[rockclimber]

mihaild в сообщении #1702874 писал(а):

Ну кстати подобрать сейчас задачу на теорему Байеса, которую надежно решит второкурсник-троечник, и надежно не решат LLM, не так-то просто.

Я уже полгода собираюсь запостить одну задачку сюда. Напишу, пожалуй, сейчас, раз к слову пришлась.

Задача на SQL. Чатгпт никакой версии решить не может. Он, собака, все необходимые элементы решения задачи знает, но без наводящих вопросов в лоб я не смог заставить его написать решение.
Если у кого есть доступ к другим ИИ (платным версиям), спросите тоже - решат или нет? Ну и кто знает (или думает, что знает ) SQL, попробуйте решить сами.

Задача навеяна практикой.
У меня есть таблица log_table следующего вида:

create table log_table (
   log_id number, 
  start_date date,
  end_date date); 

Есть также индекс по полю start_date. В эту таблицу записывается лог выполнения некоторого процесса, обрабатывающего данные в БД. В поля start_date и end_date, соответственно, записывается, когда процесс начался и закончился. Обработка данных устроена таким образом, что очередной процесс расчетов должен закончить выполняться до того, как будет запущен новый экземпляр процесса. Иногда он не успевает закончить. Надо написать SQL запрос, который выведет все такие случаи (новый процесс был запущен до того, как завершился старый), и для каждого log_id вывести количество новых процессов, начавшихся до того, как старый завершится. Также он должен работать максимально быстро, так как данных в таблице очень много.

[diletto]

rockclimber в сообщении #1702881 писал(а):

Ну и кто знает (или думает, что знает ) SQL, попробуйте решить сами.

Навскидку так:
select earlyid, count(*)
from
(select early.id as earlyid, late.id as lateid
from log_table early inner join log_table late on early.end>late.start
where early.start<late.start and early.id<>late.id) as joined
group by earlyid

[rockclimber]

diletto
Да, это именно то решение, которое предлагает чатгпт. Но в моей реальной таблице было около 100 миллионов записей, и такой запрос будет работать до второго пришествия. А все из-за джойна. А джойн не нужен (подсказка: достаточно одной аналитической функции)
Причем он же, собака, знает нужный синтаксис и может объяснить, почему правильное решение работает - если ему это решение показать. А если не показывать, можно бесконечно повторять - джойн не нужен, достаточно к таблице один раз обратиться, и т. п., он будет настойчиво пихать разные варианты этого решения.

[diletto]

rockclimber в сообщении #1702928 писал(а):

джойн не нужен

Дипсик без подсказок выдал три варианта, в том числе:

SELECT
log_id,
(SELECT COUNT(*)
FROM log_table l2
WHERE l2.start_date < l1.end_date
AND l2.start_date > l1.start_date) as overlapping_processes
FROM log_table l1
WHERE l1.end_date IS NOT NULL
AND EXISTS (
SELECT 1
FROM log_table l2
WHERE l2.start_date < l1.end_date
AND l2.start_date > l1.start_date
)
ORDER BY log_id;

- и сказал, что самоджойн может быть неоптимален для больших таблиц, поэтому вот. Но добавил, что "в большинстве случаев самоджойн с груп бай будет лучшим вариантом, т.к. эффективно использует индекс".

Я что-то подозреваю, что от оптимизатора сильно зависит, какой вариант выиграет...

[rockclimber]

diletto
Это то же самое… Этот запрос можно по-разному переписывать. Можно написать inner join, можно where exists, можно коррелированный подзапрос (select (select count(*) …) …). В конце концов, суть та же. Если коротко - у вас название исходной таблицы встречается один раз или больше? Больше - не надо.
Была раньше такая шутка на эту тему: компьютер делает то, что вы скажете ему делать, а не то, что вы хотите, чтобы он делал. Так и тут, дело не в оптимизаторе. Если вы пишете "делай джойн", оптимизатор будет колоться, плакать, но делать джойн. (Шучу, конечно, не будет он плакать. Плакать будет юзер.) И дипсик даже правильно сказал - "может медленно работать на больших объемах". Зрит в корень, собака! Но последний шаг сделать не может.

[worm2]

Тут, насколько я понимаю, алгоритм такой: нужно выбрать все записи, отсортированные по возрастанию start_date (индекс этому способствует), а потом из них выбрать те, у которых end_date > следующего start_date, либо start_date < предыдущего end_date.
Но я плохо знаю SQL, в частности, не знаю как в нём оперировать с "предыдущей" и "следующей" записями в выборке. Это мощный язык, наверное, в нём предусмотрено что-нибудь эдакое, но я не в курсе. Ну и ещё можно с хранимой процедурой заморочиться, наверное.

-- Вт сен 23, 2025 16:13:41 --

Сейчас подсмотрел, в SQL есть такие штуки как LAG и LEAD, с помощью которых можно достучаться до предыдущей и следующей записи.
Наверное, если LLM про них подсказать, она выдаст корректное решение.

[diletto]

worm2 в сообщении #1702959 писал(а):

LAG и LEAD

Тьфу ты, я в прошлой реплике не тот кусок из ответа дипсика второпях скопировал.

SELECT log_id, overlapping_processes
FROM (
SELECT
log_id,
start_date,
end_date,
LAG(end_date) OVER (ORDER BY start_date) as prev_end_date,
COUNT(CASE WHEN start_date < LAG(end_date) OVER (ORDER BY start_date)
THEN 1 END)
OVER (PARTITION BY NULL ORDER BY start_date ROWS UNBOUNDED PRECEDING) as overlapping_processes
FROM log_table
WHERE end_date IS NOT NULL
)
WHERE overlapping_processes > 0
ORDER BY log_id;

[Alexandr_A]

rockclimber в сообщении #1702928 писал(а):

Причем он же, собака, знает нужный синтаксис и может объяснить, почему правильное решение работает - если ему это решение показать. А если не показывать, можно бесконечно повторять - джойн не нужен, достаточно к таблице один раз обратиться, и т. п., он будет настойчиво пихать разные варианты этого решения.

Достаточно один раз сказать "не думай о розовом слоне". Для чата эта ситуация куда как безнадежнее чем для людей. Особенно, если это новый чат, то в контекстном окне будут эти слова и от них пойдут семантические связи по наработанным в процессе обучения. Может чаты плохо обучены и надо дообучать на конкретном примере, но придумывать то чему не обучали это немного другой навык. А так же думать о том, о чем не просили, иметь свою цель.