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

[rockclimber]

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

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

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

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

В общем да, примерно так и работает. Задачу можно немного по-разному сформулировать, в том числе так, чтобы было решать не очень удобно. Я специально выбрал максимально удобный вариант, чтобы у ИИ было меньше возможностей отвертеться. Суть в том, что аналитическая функция в SQL рассчитывается для плавающего окна, задавать границы окна можно самыми разными способами, и вся соль этой задачи в том, чтобы описать это окно.

diletto в сообщении #1703000 писал(а):

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;

Это уже намного лучше! (а если бы вы еще и форматировали код нормально, было бы вообще замечательно)
Не уверен, правда, что этот код заработает, а если заработает - вернет хотя бы приблизительно правильный результат. Но это точно шаг в правильном направлении. Хотя не исключено, что случайный

Проблема запроса в том, что он использует LAG, а эта функция берет данные со следующей строки. Но ниоткуда не следует (при моей постановке задачи), что если процесс тормозит, то он будет тормозить только до начала следующего. Он может и дольше тормозить. Я даже на это намекнул - "для каждого log_id вывести количество новых процессов". То есть оно может быть разным.
То есть, нам надо:
отсортировать по полю start_date
начало окна - текущая строка
конец окна - строка, где start_date больше чем end_date текущей
функция - count (ищем количество строк), и вычесть 1, потому что посчитается текущий процесс
Ответ в спойлере.

(Оффтоп)

select *
  from (select log_id, count(*) over (order by start_date range between current row and end_date - start_date following) - 1 cnt
          from log_table)
 where cnt > 0

-- 25.09.2025, 20:42 --

Alexandr_A в сообщении #1703173 писал(а):

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

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

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

Это все неважно. Детали, почему именно он не справляется, пусть его разработчики анализируют. А я человек простой: слышу заявление разработчиков, что их ИИ достиг уровня PhD - иду проверять
Ну, пока не достиг.
Мне пока приходит такая аналогия в голову: стереотипный гений-вундеркинд из художественной литературы и кино, который уже слышал много чего с переднего края всех наук сразу, но с трудом завязывает себе шнурки и не может приготовить завтрак.

[ozheredov]

rockclimber
Гений-вундеркинд сожрал пару сотен миллиардов папиных денег. При этом не завязал ни одних шнурков и не приготовил ни одного завтрака. Значит, дело не в шнурках.