1) я написал что это компромиссное решение, которое по качеству лучшее. Ого как раз захватывает гармоники через ширину, в то время как в сетки в коде даже этого не делают.
2) LPC делает гораздо, гораздо хуже. Он не приспособлен идеально к речи. Естественно у меня есть код этого через librosa, но там звучание гораздо хуже. Так как librosa больше подходит для неречевых звуков. Что касается pydub, то и с ним у меня была реализация и там тоже что-то было не так. Из всех вариантов, был выбран наиболее лучший по качеству с учётом компромиссов. Остальные давали результат гораздо хуже или ломали что-то ещё.
Вместо того чтобы полагаться на сетки надо проверять, а уже затем утверждать. В этом и заключается проблема, если полагаться на то что утверждает сетка. Я прекрасно знаю, что они отвечают, так как использую их и они в этих моментах очень сильно тупят. И я молчу уже о том, что решая проблему они могут выкинуть что то уже рабочее в коде, какую то деталь, упростить расчет и так далее.
Paart очень известная библиотека. Там же дело не в библиотеке, а к логике реализации. Такие же проблемы возникают и с базами данных. Вот простой пример, который нормально не могут осилить LLM. Нужно перенести SQL с MS SQL на Postgres, это по-моему часть кода одного из отчетов. Ниже два примера MS SQL которые нужно перенести на Postgres. В данном случае есть некоторые участки, где синтаксис будет сильно отличаться или даже может не оказаться аналога. А если еще учесть, что надо динамический запрос, то все усложняется. Вот такие реальные задачи встречаются в жизни.
В первом, LLM постоянно что-то выкидывает, что-то теряет, упускает детали.
Скрытый текст
-- Устанавливаем первый день недели понедельником
SET datestyle = ISO, DMY;
-- Курсор для создания временной таблицы со временем простоя
DO $$
DECLARE
branch_id INT;
work_place_id INT;
wevent INT;
event_time TIMESTAMP;
temp_branch_id INT;
temp_work_place_id INT;
temp_event_time TIMESTAMP;
temp_beg_time TIMESTAMP := NULL;
result_time INTERVAL := INTERVAL '0 seconds';
service_id INT;
service_group_id INT;
BEGIN
DROP TABLE IF EXISTS temp_idle_time_table;
-- Создаем временную таблицу
CREATE TEMP TABLE temp_idle_time_table (
"BRANCH_ID" INT,
"WORK_PLACE_ID" INT,
"EVENT_TIME" DATE,
"IDLE_TIME" INTERVAL
);
-- Цикл для обработки данных
FOR branch_id, work_place_id, wevent, event_time IN
SELECT
ts."BRANCH_ID",
ts."WORK_PLACE_ID",
ts."WEVENT",
ts."EVENT_TIME"
FROM "public"."WP_STATE_STAT" ts
WHERE ts."EVENT_TIME" BETWEEN '2024-09-02'::DATE AND '2024-12-02'::DATE
AND ts."BRANCH_ID" IN (1012)
AND ts."WEVENT" IN (5, 6)
ORDER BY ts."BRANCH_ID", ts."WORK_PLACE_ID", ts."EVENT_TIME", ts."WP_STATE_STAT_ID"
LOOP
-- Проверка смены группы
IF temp_event_time IS NOT NULL AND (
DATE(temp_event_time) <> DATE(event_time) OR
work_place_id <> temp_work_place_id OR
branch_id <> temp_branch_id
) THEN
INSERT INTO temp_idle_time_table ("BRANCH_ID", "WORK_PLACE_ID", "EVENT_TIME", "IDLE_TIME")
VALUES (temp_branch_id, temp_work_place_id, DATE(temp_event_time), result_time);
temp_branch_id := branch_id;
temp_work_place_id := work_place_id;
temp_event_time := event_time;
temp_beg_time := NULL;
result_time := INTERVAL '0 seconds';
END IF;
-- Обработка события WEVENT = 5 или 6
IF wevent = 5 THEN
temp_beg_time := event_time;
ELSE
IF temp_beg_time IS NOT NULL THEN
result_time := result_time + (event_time - temp_beg_time);
temp_beg_time := NULL;
END IF;
END IF;
-- Сохранение текущих данных
temp_branch_id := branch_id;
temp_work_place_id := work_place_id;
temp_event_time := event_time;
END LOOP;
-- Финальная вставка последнего блока
IF temp_event_time IS NOT NULL THEN
INSERT INTO temp_idle_time_table ("BRANCH_ID", "WORK_PLACE_ID", "EVENT_TIME", "IDLE_TIME")
VALUES (temp_branch_id, temp_work_place_id, DATE(temp_event_time), result_time);
END IF;
-- Создаем временную таблицу
DROP TABLE IF EXISTS temp_level_table;
CREATE TEMP TABLE temp_level_table AS
SELECT *
FROM public.FUNC_SRV_PARENT_LEVEL(NULL, NULL, NULL);
-- Добавляем услуги, у которых нет группы
INSERT INTO temp_level_table ("SERVICE_ID")
SELECT s."SERVICE_ID"
FROM "public"."SERVICES" s
WHERE s."BRANCH_ID" = 0
AND s."SERVICE_GROUP_ID" IS NULL;
-- Обрабатываем услуги с группами
FOR service_id, service_group_id IN
SELECT s."SERVICE_ID", s."SERVICE_GROUP_ID"
FROM "public"."SERVICES" s
WHERE s."SERVICE_GROUP_ID" IS NOT NULL
AND s."BRANCH_ID" = 0
LOOP
-- Для каждой услуги добавляем уровни вложенности
INSERT INTO temp_level_table
SELECT *
FROM public.FUNC_SRV_PARENT_LEVEL(0, service_id, service_group_id);
END LOOP;
WITH weekly_periods AS (
SELECT
TS."REG_TIME",
'№' || EXTRACT(WEEK FROM TS."REG_TIME") || ' (' ||
TO_CHAR(DATE_TRUNC('week', TS."REG_TIME") - INTERVAL '1 day', 'DD.MM.YYYY') || ' - ' ||
TO_CHAR(DATE_TRUNC('week', TS."REG_TIME") + INTERVAL '5 day', 'DD.MM.YYYY') || ')'
AS "PERIOD_WEEK"
FROM "TICKETS" AS TS
),
hourly_periods AS (
SELECT
ts."REG_TIME",
TO_CHAR(ts."REG_TIME", 'HH24:00') || ' - ' || TO_CHAR(ts."REG_TIME", 'HH24:59') AS "PERIOD_HOUR"
FROM "TICKETS" ts
)
SELECT
-- Группы отделений и отделения
brgr."BRANCHES_GROUP_NAME" AS BGROUP_NAME,
br."BRANCH_NAME" AS BRANCH_NAME,
-- Уровни вложенности услуги по группам
t."SERVICE_GROUP_NAME_LEV1",
t."SERVICE_GROUP_NAME_LEV2",
t."SERVICE_GROUP_NAME_LEV3",
t."SERVICE_GROUP_NAME_LEV4",
t."SERVICE_GROUP_NAME_LEV5",
t."SERVICE_GROUP_NAME_LEV6",
-- Услуга
sr."SERVICE_NAME" AS SERV_NAME,
-- Приоритет
pr."PRIORITY_NAME",
-- Год
EXTRACT(YEAR FROM ts."REG_TIME") AS PERIOD_YEAR,
-- Месяц (прописью)
TO_CHAR(ts."REG_TIME", 'Month') AS PERIOD_MONTH,
-- Неделя (формат: №Недели (дата первого дня недели - дата последнего дня недели))
wp_week."PERIOD_WEEK",
-- День
TO_CHAR(ts."REG_TIME", 'DD.MM.YYYY') AS PERIOD_DAY,
-- Час (часовой период)
hp."PERIOD_HOUR",
-- ФИО сотрудника
CASE
WHEN ts."WORK_USER_ID" IS NULL THEN ' '
ELSE COALESCE(wu."LAST_NAME", '') || ' ' || COALESCE(wu."FIRST_NAME", '') || ' ' || COALESCE(wu."PATRONYMIC", '')
END AS WU_NAME,
-- Рабочее место
wp."WORK_PLACE_NAME" AS WORK_PLACE_NAME,
-- Время включения/выключения рабочего места
(
SELECT TO_CHAR(wps."EVENT_TIME", 'HH24:MI')
FROM public."WP_STATE_STAT" wps
WHERE wps."BRANCH_ID" = ts."BRANCH_ID"
AND wps."WORK_PLACE_ID" = ts."WORK_PLACE_ID"
AND wps."WEVENT" = 1
AND wps."EVENT_TIME" BETWEEN DATE_TRUNC('day', ts."REG_TIME") AND DATE_TRUNC('day', ts."REG_TIME") + INTERVAL '1 day'
ORDER BY wps."EVENT_TIME"
LIMIT 1
) AS switch_on,
(
SELECT TO_CHAR(wps."EVENT_TIME", 'HH24:MI')
FROM public."WP_STATE_STAT" wps
WHERE wps."BRANCH_ID" = ts."BRANCH_ID"
AND wps."WORK_PLACE_ID" = ts."WORK_PLACE_ID"
AND wps."WEVENT" = 2
AND wps."EVENT_TIME" BETWEEN DATE_TRUNC('day', ts."REG_TIME") AND DATE_TRUNC('day', ts."REG_TIME") + INTERVAL '1 day'
ORDER BY wps."EVENT_TIME" DESC
LIMIT 1
) AS switch_off,
-- Всего по услуге
COUNT(*) AS RECS_COUNT,
-- Обслужено
SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS SERVICED,
-- Не обслужено
COUNT(*) - SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS NOT_SERVICED,
-- Не вызваны
SUM(CASE WHEN ts."SERVE_UP" IN (0, 5, 6) THEN 1 ELSE 0 END) AS NOT_CALLED,
-- Неявка
SUM(CASE WHEN ts."SERVE_UP" = 3 THEN 1 ELSE 0 END) AS ABSENT,
-- Отложены
SUM(CASE WHEN ts."SERVE_UP" = 4 THEN 1 ELSE 0 END) AS DELAYED,
-- Среднее время обслуживания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0
THEN TO_CHAR(SUM(EXTRACT(EPOCH FROM ts."SERV_TIME" - ts."CALL_TIME")) / SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END), 'HH24:MI:SS')
ELSE ''
END AS AVG_SERVE_TIME,
-- Максимальное время обслуживания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0
THEN TO_CHAR(MAX(ts."SERV_TIME" - ts."CALL_TIME"), 'HH24:MI:SS')
ELSE ''
END AS MAX_SERVE_TIME
-- Дополнительно добавить другие вычисления аналогично
FROM "TICKETS" ts
LEFT JOIN "BRANCHES" br ON br."BRANCH_ID" = ts."BRANCH_ID"
LEFT OUTER JOIN "BRANCHES_GROUPS" brgr ON brgr."BRANCHES_GROUP_ID" = br."BRANCHES_GROUP_ID"
LEFT JOIN "WORK_USERS" wu ON wu."WORK_USER_ID" = ts."WORK_USER_ID" AND wu."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "SERVICES" sr ON sr."SERVICE_ID" = ts."SERVICE_ID" AND sr."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN temp_level_table t ON t."SERVICE_ID" = ts."SERVICE_ID"
LEFT JOIN "WORK_PLACES" wp ON wp."WORK_PLACE_ID" = ts."WORK_PLACE_ID" AND wp."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "PRIORITIES" pr ON pr."PRIORITY_ID" = ts."PRIORITY_ID" AND pr."BRANCH_ID" = 0
LEFT JOIN temp_idle_time_table tmp ON tmp."BRANCH_ID" = ts."BRANCH_ID"
AND tmp."WORK_PLACE_ID" = ts."WORK_PLACE_ID"
AND tmp."EVENT_TIME" = CAST(ts."REG_TIME" AS DATE)
LEFT JOIN weekly_periods wp_week ON wp_week."REG_TIME" = ts."REG_TIME"
LEFT JOIN hourly_periods hp ON hp."REG_TIME" = ts."REG_TIME"
WHERE
ts."QMS_DELETED" = FALSE
AND ts."SERVICE_ID" > 0
AND ts."REG_TIME" BETWEEN '2024-09-02' AND DATE '2024-12-01' + INTERVAL '1 day'
AND EXTRACT(HOUR FROM ts."REG_TIME") BETWEEN 0 AND 23
AND ts."BRANCH_ID" IN (1012)
--AND ts."SOURCE_RECORD_KIND" IN (1, 2, 3, 5, 6)
AND EXISTS (
SELECT 1
FROM "WORK_USERS" u
WHERE ts."BRANCH_ID" = u."BRANCH_ID"
)
GROUP BY
brgr."BRANCHES_GROUP_NAME",
br."BRANCH_NAME", ts."BRANCH_ID",
sr."SERVICE_NAME", ts."SERVICE_ID",
t."SERVICE_GROUP_NAME_LEV1", t."SERVICE_GROUP_NAME_LEV2", t."SERVICE_GROUP_NAME_LEV3",
t."SERVICE_GROUP_NAME_LEV4", t."SERVICE_GROUP_NAME_LEV5", t."SERVICE_GROUP_NAME_LEV6",
pr."PRIORITY_NAME",
EXTRACT(YEAR FROM TS."REG_TIME"),
TO_CHAR(TS."REG_TIME", 'Month'),
wp_week."PERIOD_WEEK",
TO_CHAR(TS."REG_TIME", 'DD.MM.YYYY'),
ts."REG_TIME",
hp."PERIOD_HOUR",
ts."WORK_USER_ID", wu."LAST_NAME", wu."FIRST_NAME", wu."PATRONYMIC",
"WORK_PLACE_NAME", ts."WORK_PLACE_ID"
ORDER BY
BGROUP_NAME,
BRANCH_NAME,
"SERVICE_GROUP_NAME_LEV1", "SERVICE_GROUP_NAME_LEV2", "SERVICE_GROUP_NAME_LEV3",
"SERVICE_GROUP_NAME_LEV4", "SERVICE_GROUP_NAME_LEV5", "SERVICE_GROUP_NAME_LEV6",
SERV_NAME,
PERIOD_YEAR,
PERIOD_MONTH,
"PERIOD_WEEK",
CAST(ts."REG_TIME" AS DATE),
"PERIOD_HOUR",
ts."WORK_USER_ID", wu."LAST_NAME", wu."FIRST_NAME", wu."PATRONYMIC",
pr."PRIORITY_NAME",
WORK_PLACE_NAME;
/*Удаляем за собой временную таблицу*/
drop table temp_level_table;
drop table temp_idle_time_table;
END $$;
Во втором, просто тупо допускает ошибки не понимания в чем дело. LLM использует string_agg при конвертировании, и упускает некоторые моменты особенности Postgres при работе с string_agg. Из за этого код она пишет, код при выполнении иногда выдаст ошибку, LLM пытается ее исправить, но зациклено по кругу исправляет одно и тоже, не понимая некоторых нюансов работы string_agg.
Скрытый текст
-- Устанавливаем язык вывода дат
SET datestyle = 'ISO, DMY';
WITH weekly_periods AS (
SELECT
ts."REG_TIME",
'№' || EXTRACT(WEEK FROM ts."REG_TIME") ||
' (' || TO_CHAR(ts."REG_TIME" - INTERVAL '1 day' * (EXTRACT(DOW FROM ts."REG_TIME") - 1), 'DD.MM.YYYY') ||
' - ' || TO_CHAR(ts."REG_TIME" + INTERVAL '1 day' * (7 - EXTRACT(DOW FROM ts."REG_TIME")), 'DD.MM.YYYY') || ')' AS "PERIOD_WEEK"
FROM "TICKETS" ts
),
hourly_periods AS (
SELECT
ts."REG_TIME",
TO_CHAR(ts."REG_TIME", 'HH24:00') || ' - ' || TO_CHAR(ts."REG_TIME", 'HH24:59') AS "PERIOD_HOUR"
FROM "TICKETS" ts
)
SELECT
-- Группы отделений и отделения
brgr."BRANCHES_GROUP_NAME" AS "BGROUP_NAME",
br."BRANCH_NAME" AS "BRANCH_NAME",
-- Роль
COALESCE(wp."WP_ROLE_NAME", ' ') AS "ROLE_NAME",
-- Услуга
sr."SERVICE_NAME" AS "SERV_NAME",
-- Год
EXTRACT(YEAR FROM ts."REG_TIME") AS "PERIOD_YEAR",
-- Месяц (прописью)
TO_CHAR(ts."REG_TIME", 'Month') AS "PERIOD_MONTH",
-- Неделя
wp_week."PERIOD_WEEK",
-- День
TO_CHAR(ts."REG_TIME", 'DD.MM.YYYY') AS "PERIOD_DAY",
-- Час (часовой период)
hp."PERIOD_HOUR",
-- Всего по услуге
COUNT(*) AS "RECS_COUNT",
-- Обслужено
SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS "SERVICED",
-- Не обслужено
COUNT(*) - SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS "NOT_SERVICED",
-- Среднее время обслуживания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0 THEN
TO_CHAR(AVG(ts."SERV_TIME" - ts."CALL_TIME")::interval, 'HH24:MI:SS')
ELSE '00:00:00'
END AS "AVG_SERVE_TIME",
-- Среднее время ожидания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0 THEN
TO_CHAR(AVG(ts."CALL_TIME" - ts."REG_TIME")::interval, 'HH24:MI:SS')
ELSE '00:00:00'
END AS "AVG_WAITING_TIME",
-- Ожидающие менее
SUM(CASE
WHEN ts."CALL_TIME" IS NOT NULL AND (EXTRACT(EPOCH FROM ts."CALL_TIME" - ts."REG_TIME") / 60) < 0 THEN 1 ELSE 0
END) AS "WAITING_LESS",
-- Обслуживающиеся менее
SUM(CASE
WHEN ts."CALL_TIME" IS NOT NULL AND ts."SERVE_UP" = 2 AND (EXTRACT(EPOCH FROM ts."SERV_TIME" - ts."CALL_TIME") / 60) < 0 THEN 1 ELSE 0
END) AS "SERVING_LESS"
FROM "TICKETS" ts
LEFT JOIN "BRANCHES" br ON br."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "BRANCHES_GROUPS" brgr ON brgr."BRANCHES_GROUP_ID" = br."BRANCHES_GROUP_ID"
LEFT JOIN "WP_ROLES" wp ON wp."WP_ROLE_ID" = ts."WP_ROLE_ID" AND wp."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "SERVICES" sr ON sr."SERVICE_ID" = ts."SERVICE_ID" AND sr."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN weekly_periods wp_week ON wp_week."REG_TIME" = ts."REG_TIME"
LEFT JOIN hourly_periods hp ON hp."REG_TIME" = ts."REG_TIME"
WHERE
ts."QMS_DELETED" = false
AND ts."SERVICE_ID" > 0
AND ts."REG_TIME" BETWEEN :PDATE_FROM AND :PDATE_TO
AND EXTRACT(HOUR FROM ts."REG_TIME") BETWEEN :HOUR_FROM AND :HOUR_TO
AND ts."BRANCH_ID" IN (14)
AND ts."SOURCE_RECORD_KIND" IN (1, 2, 3, 5, 6)
AND EXISTS (
SELECT 1
FROM "WP_ROLES" r
INNER JOIN "WP_ROLES_ITEMS" ri ON ri."BRANCH_ID" = r."BRANCH_ID" AND ri."WP_ROLE_ID" = r."WP_ROLE_ID"
WHERE ts."BRANCH_ID" = r."BRANCH_ID" AND r."IS_USED" = true AND ri."SERVICE_ID" = ts."SERVICE_ID"
)
GROUP BY
brgr."BRANCHES_GROUP_NAME",
br."BRANCH_NAME",
sr."SERVICE_NAME",
wp."WP_ROLE_NAME",
wp_week."PERIOD_WEEK",
hp."PERIOD_HOUR",
EXTRACT(YEAR FROM ts."REG_TIME"),
TO_CHAR(ts."REG_TIME", 'Month'),
TO_CHAR(ts."REG_TIME", 'DD.MM.YYYY')
ORDER BY
"BGROUP_NAME",
"BRANCH_NAME",
"ROLE_NAME",
"SERV_NAME",
"PERIOD_YEAR",
"PERIOD_MONTH",
"PERIOD_WEEK",
"PERIOD_DAY",
"PERIOD_HOUR";
Praat это самая популярная и эффективная библиотека при работе с голосом. Все LLM ее знают и все равно галлюцинируют на ней часто обращаясь к тому чего нет. Как уже было сказано выше, да она правильная, так как использовал ее при изменении голоса.
Ниже пример, где также используется эта функция. Я прекрасно знаю что на все это пишут LLM, проблема в том, что они не могут не писать, даже там где имеют проблемные места.
Давайте так, если вы предлагаете решение, то не нужно просто брать и генерировать его и просить модель объяснить это решение. Стоит сначала взять и проверить его и затем уже предлагать. Если кратко то нет, в вашем случае на выходе вы услышите на фоне звука так же потрескивание или наоборот звуки скрежета.
В предложенном коде все кишит проблемами. 1) форманты содержат ширину, и ее надо учитывать. В коде выше, она считается примитивным образом как bw = -np.log(magnitudes[idx]) * sample_rate / np.pi и дальше просто идет проверка. 2) LPC очень плохо справляет на самом деле с голосом. 3) resample в описанном мной примере делается как компромисс, чтобы не потерять сильно в качестве звука. Это важное отличие, которое агенты просто не могут сделать. Нет такого понятие как компромисс, не могут они это оценить. 4) там еще не мало других проблем, вроде if 90 < f < 5000 and bw < 500 и множества других.
Синтетические тесты тут ни как не помогут. Что вы хотите в них анализировать? Как выстроите их, по какому критерию? Просто частоты сдвинулись или нет? В голосе форманты имеют обертоны, и если вы просто сдвинули какую то частоту то это не будет согласовываться например с ними.
Каким образом, работа с агентами может улучшить написание следующего кода: у нас есть аудио с речью, речь как мы знаем можно разделить на форманты F0-F5 (для примера ограничимся F5)? Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту. Вот правильный код на основе praat, который ни одна LLM не смогла написать:
Скрытый текст
def change_formants_shifts(signal, sr, formant_shifts, formants=None):
"""
Изменяет частоты формант в аудиофайле на фиксированное значение для каждой форманты.
"""
if formants:
frequencies = formants["frequencies"]
times = formants["voiced_times"]
else:
frequencies, times, _, _ = formant_frequencies(signal, sr)
# Определение функции для получения новой частоты форманты
def get_new_formant_freq(original_freq, formant_num):
if original_freq <= 0:
return original_freq
return original_freq + formant_shifts[formant_num]
# Создание нового объекта звука для изменённого звука
modified_signal = np.copy(signal)
# Итерация по каждому временно́му шагу и изменение частот формант
for t_idx, t in enumerate(times):
for i in range(5): # Форманты F1 до F5
original_freq = frequencies[i][t_idx]
if original_freq > 0: # Убедиться, что частота форманты действительна
new_freq = get_new_formant_freq(original_freq, i)
# Расчёт коэффициента ресэмплинга
resample_ratio = new_freq / original_freq
# Регулировка значений звука вокруг частоты форманты
segment_start = max(0, int(t * sr) - int(sr / 50))
segment_end = min(len(signal), int(t * sr) + int(sr / 50))
segment = signal[segment_start:segment_end]
# Ресэмплинг сегмента для изменения частоты форманты
resampled_segment = resample(segment, int(len(segment) * resample_ratio))
# Регулировка длины для соответствия оригинальному сегменту
if len(resampled_segment) > (segment_end - segment_start):
resampled_segment = resampled_segment[:segment_end - segment_start]
elif len(resampled_segment) < (segment_end - segment_start):
pad_width = (segment_end - segment_start) - len(resampled_segment)
resampled_segment = np.pad(resampled_segment, (0, pad_width), mode='constant')
# Добавление ресэмплированного сегмента к изменённым значениям
modified_signal[segment_start:segment_end] = resampled_segment
modified_signal = np.clip(modified_signal, -1, 1)
return modified_signal, sr
Вы хоть обложитесь сотней агентов, они не сделают.
Напишут они код? Да напишут. Будет он делать то что нужно? Нет. Могут в этом помочь отладчики или консоль или что-то еще? Нет. Знают ли модели о проблемах, если начать разбирать их код? Конкретно о каждой проблеме они всегда что-то напишут. Могут ли они сразу перечислить все возможно проблемы, чтобы учесть их? Нет.
То есть на выходе вы получите выполняющийся без ошибок код, который будет делать что угодно, только не то что нужно.
Данный пример с аудио, просто один из таких примеров. В реальной работе их множество, когда мы не можете простым выполнением кода, проверить правильный результат или нет. И как уже написал, даже если ваш агент будет заранее рассуждать о возможных проблемах, задачу это не решит и вероятней всего на выходе вы получите "фарш".
У нее многие статьи это скорее рассуждающие, то есть теоретические (чем она и занимается по своей специальности). Сложно назвать их научными в плане исследований, а скорее научными в плане рассуждений. Это как если бы был специальный habr для физиков-математиков.
Насчет цитируемости, то она еще в 2019 году писала статью:
"В данной работе мы описываем и представляем результаты работы простой нейронной сети, которая прогнозирует будущие показатели цитирования отдельных исследователей на основе различных данных из их прошлой деятельности."
Они делали простую нейросеть и прогнозировали цитируемость. На научную работу это не тянет. На хабре многие пишут статью, как что-то спрогнозировали. На GitHub такого много тоже, но для исследования это как-то мелко сегодня. Но тема цитируемости, явно "близка" ей.
Но в остальном, у нее много интересных работ "A derivation of Born’s rule from symmetry", где есть предположение, что вероятности должны быть согласованы с юнитарной структурой гильберта. И из этого ее объяснение показывает, что правило Борна не является случайной догадкой, а математически единственный возможный вариант, совместимый с симметрией квантовой механики. И таких статей у нее много. Они о построении различных гипотез, связях и так далее.
Если обобщить это, то тема цитируемости ей очень близка + большинство ее это гипотезы и рассуждения, но безусловно очень интересные. Так что понятно почему ее лично волнуют LLM статьи:
1) написание большего кол-ва статей, приведет к тому, что ей будет сложнее конкурировать с ними
2) ее статьи как раз рассуждающие, с различными гипотезами, теоретические но под разным углом и разными предположениями. Такое очень удобно делать с помощью LLM.
Другое дело, что LLM сами ничего не сделают. Для этого надо понимать, что они пишут, что попросить проанализировать, разобрать что они написали и отсеять бред. Так что автор либо боится что будет завалено мусором (но мусорных научных статей и так большинство), либо что упростит порог входа и написание теоретически рассуждающих статей другими физиками либо это просто страх неопределенности.
При этом данное добавление обосновано, но должно быть сделано правильно. Оно нужно для связи разных уровней иерархии. Когда какое то слово, может усилить например сигнал на уровне целой главы, а не только следующего уровня иерархии как сейчас (например слово - параграфа).
Следующим шагом следует связать все блоки и выходной сигнал:
Смысл данного подхода в том, что текст это многоуровневая иерархическая цепь условных вероятностей. Сейчас современные LLM используют выход только последнего уровня иерархии. Но это не правильно. Представим себе предложение:
Привет, как дела?
В нем нет дальних зависимостей и длинных связей. Но из-за текущей архитектуры LLM, только последний выход даёт основной вклад в генерацию цепочки. Это можно условно представить как: слоги, слова, синтагмы, предложения, абзацы.. В предложении выше, сложность ограничена связями внутри предложения, все что выше, даёт шум, так как для этого просто нет информации (для глав, параграфов и так далее). То есть верхние уровни связей дадут вклад, но он будет избыточным и слабым. Но в текущих LLM именно самый верхний уровень и даст максимальный вклад, так как остальные уровни не имеют прямого выхода и не могут напрямую вносить свой вклад, усиливая сигнал. Как итог, LLM выдает нам тонны избыточного текста, словно связь была на уровне целой главы и объем текста растет и растет. Если только искусственно через регуляризацию не обучали сокращать текст, но тогда там где нужен длинный текст, она тоже сократит его.
Вот эти два подхода, позволяют LLM правильно согласовывать сигналы разных уровней. И это реально даёт видимый эффект и имеет математическое обоснование. А вот подход усложнения residual как выше, приводит к нестабильности, так как не несёт смысла в усложнении.
В лучшем случае, мы можем добавить в residual линейный слой, чтобы увеличить его размерность в том случае, если мы решили повысить размерность следующего блока. В мозге именно так и происходит. Например, слуховая зона a1-a2-a3. Каждая последующая область содержит больше нейронов где то ~1,5 раза (условно). Это аналогично, как если бы мы напрямую связывали a1 (например 400 тыс нейронов) с a3 (например 800 тыс нейронов). В этом случаев residual играл бы роль пирамидальных нейронов, которые напрямую связывают a1 и a3 и для согласования размерности, мы должны расширить размерность сигнала a1 в a3 с 200 тыс до 800 тыс, через linear. Но никаких избыточных решений как предложено в статье, там нет. Есть прямые связи, которые расширяются.
Какой пост, я не автор поста или вы про комментарий? Вы реально считаете, что нейронная сеть сможем сгенерировать подобный комментарий, да еще и провести сама исследование и показать это наглядно как выше? Нет, LLM бы вам на это сгенерировала тонну правдоподобного мусора, так как это тот случай, когда в обучающих ее данных нет данного ответа. Я видел опечатку про "смелые яблоки", но не стал править, так дальше было прекрасно понятно о чем речь. В том моем комментарии опечаток гораздо больше.
Странное улучшение, если рассматривать это как "выразительность" описывающая более сложные функции, то выглядит это очень натянуто. Мы можем хоть SSM добавить в residual, чтобы придать больше "выразительности", вопрос в том, а надо ли? В исследовании я не увидел аргументов, зачем авторы это делают. кроме как чтобы "улучшить".
Аргумент авторов: n потоков внутри блока → больше "параллельных путей", которые комбинируются через обучаемую матрицу H_res. Но они не приводят доказательств, что именно эта выразительность нужна.
Можно было бы просто увеличить линейные слои внутри residual и теоретически любая функция X→Y записывалась бы.
Увеличение потоков ≈ увеличение числа параметров, без явного анализа, зачем каждый поток нужен.
Пока это спорное не доказанное преимущество, скорее гипотеза что "несколько путей = более выразительно".
Сами же авторы пишут "каждый поток может специализироваться". На каких подзадачах? Никаких формальных разложений задачи внутри блока не приводят. Residual не решает несколько задач явно, это просто функция слоя. Если и существует какая-то декомпозиция задачи, то она не формализована в исследовании.
Можно было просто увеличить линейные слои внутри residual с размером, равным n раз больше → то же количество "параллельных путей" без сложной матрицы H_res.
Далее, авторы пишут, что H_res позволяет решать, какой поток важнее.
На самом деле: x(k+1) = H1(x(k)) + H2(x(k)) + … + H_n(x(k)) + F(x(k)) → это просто линейное сложение N функций.
Нет softmax или gating, чтобы явно выбрать поток → каждый поток всегда участвует одинаково (по весам H_res, которые ограничены многообразием).
Чтобы была реальная маршрутизация → нужно MoE‑подобный routing.
Поэтому все это не доказано, а скорее является интуитивными формулировками.
Ну и как итог, в статье авторы приводят эксперименты на крупных моделях (~27B параметров), где mHC стабилизирует обучение и немного улучшает loss/accuracy по сравнению с HC и baseline. Но нет прямого сравнения с альтернативой "увеличение ширины linear внутри residual", которая теоретически даёт тот же результат. Преимущество скорее в стабильности, чем в "выразительности" или "специализации потоков". Улучшения есть, но не настолько сильные, чтобы однозначно утверждать, что n потоков внутри блока принципиально нужны.
Я вижу, что фактически: это скорее маркетинговая подача, чем проверенная теория.
Все сложнее. Текст является цепями Маркова. Но, это не просто непрерывная цепь Маркова, а иерархическая цепь Маркова, где иерархии верхнего уровня, связывают разрыв цепей нижнего уровня.
Если мы посмотрим распределение вероятностей у логитов в LLM, то увидим:
Вероятности выбранных токенов на выходе из LLM
Здесь модель еще не обучена полностью, но суть передает. Мы видим условные вероятности перехода между токенами с учетом всей иерархии.
Рассмотрим слово «жильцов», представленное последовательностью токенов:
Проблема в том, что стандартные методы top-k / top-p не способны правильно оставлять возможные вероятности для следующего выбора токена.
Как уже было сказано, мы имеем дело с иерархическими цепями Маркова, которые имеют точки разрыва. Поэтому на каждом следующем шаге, мы не можем выбрать все вероятности в ни по интервалу K (top-k) ни по суммарной вероятности P (top-p).
Пусть после двух первых токенов:
P1 ⋅ P2 ≳ θ, где θ— порог разрыва цепи Маркова.
Тогда при выборе следующего токена допустимы только такие условные вероятности P3, для которых:
P1 ⋅ P2 ⋅ P3 ≥ θ
Это резко сужает пространство допустимых токенов и приводит к тому, что:
в конце слова выбор возможен только среди токенов с высокой условной вероятностью;
именно поэтому мы наблюдаем пики вероятности на окончаниях слов.
Если мы выбираем argmax (нулевая температура), то все нормально. Цепь Маркова разрывается и начинается новая. Но argmax в рамках существующих архитектур LLM это статика. Он не способен динамически учитывать контекст. Это приводит к застреванию в локальных максимумах и мы получаем усредненный текст. Это не значит, что он оптимальный, это значит, что при использовании dropout в процессе обучения, в случае неопределенности мы случайно добавляем смещение. Это приводит к статичным локальным маршрутам, которые и отражает генерация текста при температуре 0.
Если же мы используем температуру от личную от 0, то это нормально. Но, тут у нас возникает другая проблема. Если при выборе следующего токена, мы выбираем токен который уменьшить вероятность цепи Маркова ниже допустимого порога, то по сути добавляем шум. Поэтому на каждом шаге мы должны выбирать только такие токены, чья условная вероятность P(v) не уменьшит PMarkov ⋅ P(v) < θ.
Маркер М означает, начало новой цепи Маркова. p - условная вероятность, P вероятность всей цепи Маркова.
При правильном подходе, мы получаем то, что цепь не нарушается и не добавляет шум. Это хорошо видно при начальном обучении модели.
Для примера, при начальном обучении модели LLM (1000 примеров обучения):
Цепи Маркова с порогом разрыва цепи: всего слов: 187, сломанных слов: 22, коэффициент F: 22/187 = 0.1176
Чем меньше F, тем меньше ошибок в словах в целом. Цепь Маркова немного выигрывает Top-K (аналогично Top-pP). На самом деле, если мы посмотрим на сломанные слова у Top-K и Цепи Маркова, что увидим разницу. Top-K - ломает слова полностью "обгваласько"/"беззвольте", а цепь Маркова "гулятьвающиеся"/"покосившимский"/"горизонтело" ("гулять" и шум "вающиеся" на конце, "покосившим" и шум "ский", "горизонт" и шум "ело") из-за маленькой статистики собранной при обучении на 1000 примера. Причина у них разная, в первом случае мы работаем с шумом и пытаемся его продолжить, а во втором случае мы получаем на конце шум, так как еще не собрали достаточно статистики.
Несмотря на маленькую разницу, данный подход показывает, что при использовании цепи Маркова в качестве критерия отсечения logits, мы смещаем шум в конец. В этом случае все упирается в качество обучения. В то время как при использовании Top-K, даже при качественном обучении мы можем получить шум в середине или начале слова, что приведет галлюцинациям и при продолжении, что можем вызвать цепную реакцию галлюцинаций при продолжении генерации.
Поэтому использование top-k/top-p эта одна из причин галлюцинаций современных LLM. Если мы используем только top-p, это может привести к тому, что цепь Маркова выберет недопустимый элемент, который является шумом (при его выборе) для продолжения цепи. Высокая вероятность элемента, не может гарантировать, что он не является шумом. Например: "яблоко кра...". Продолжением может быть красное и красивое. Оба варианта имеют высокую вероятность такого продолжения. Но возможно что вероятность одного из них приведет вероятность цепи Маркова ниже порога. Это значит будет являться шумом. Например, контекст в начале указывает, что мы выбираем смелые яблоки на рынке и красный цвет важен. В то время как выбор красивый, приведет к продолжению галлюцинаций и генерацией текста связанного с красотой, а не выбором по цвету спелые яблоки или нет.
Это одна из форм галлюцинаций, которая возникают как накопление таких отклонений. Каждое, может сильнее отклонить генерацию текста от контекста. Галлюцинации в LLM возникают не как результат одного ошибочного токена, а как следствие накопления локально допустимых, но глобально несогласованных выборов, которые экспоненциально сужают пространство согласованных продолжений.
Снёс gigacode в прошлом месяце, ставил год назад по-моему или больше. Пользы 0, ресурсы жрет прилично. Но не нашел, как нормально сделать его деинсталляцию. Пришлось просто удалять всю папку.
Пока Сбер не начнет серьезно вкладывать в нормальные R&D, так и будет всегда как АвтоВАЗ , брать готовое и улучшать. То что вижу на Хабре и в их списке исследований за год - к серьезному R&D не имеет отношения, скорее оптимизации и выводы из своих ошибок и результата обучения. При таком подходе они не отличаются от стартапа AAA из любой страны, где есть нормальный доступ к недорогому дообучению моделей на видеокартах.
Можно было бы сказать, что Сбер адаптирует по русский текст и поэтому лучше. Но и это не так. Ниже простой пример разницы между фундаментальным R&D и косметическим подходом Сбера. На примере токенизатора.
Это пример начала обучения на токенизаторе Сбера (Яндекс токенизатор даёт такой же результат) классической LLM на 1000 примерах. На выходе высокочастотный шум.
А это результат обучения LLM на тех же 1000 примерах, но специально разработанном токенизаторе.
Разница огромная. А все дело в R&D, реальных исследованиях, разработке математического аппарата, теории, поверка ее и так далее. И как результат получения нового вида токенизатора. То есть Сбер просто взял обычный BPE, вместо того, чтобы проводить реальные R&D. И для этого не нужно миллиарды $ или множество видеокарт.
Поэтому какой смысл от gigacode, если он не способен дать качественный скачек и проигрывает всем. Это аналог АвтоВАЗ, где взяли чужую доступную модель, немного украсили и выдали. Завтра крупные компании закроют opensource архитектуры, и Сбер будет 10 лет выпускать "ваз 2106" (на базе архитектуры deepseek или qwen).
В свое время разрабатывал под грант оборудование для производства тянущихся электронных плат. Там одно из исследований было связано с теплопроводностью. При добавлении нанотрубок в нужных пропорциях теплопроводность улучшалась в ~20 раз.
Из минусов:
Нельзя наносить на алюминий
Стоимость, так как нанотрубки не дешёвые
Но если понятие элитная термопаста существовала бы, то ее состав был бы такой. Термопаста на основе сплавов галлия не новое, но с нанотрубками не видел ни разу. На сегодня это лучший состав, который я только могу себе представить, так как проводили исследования на эту тему. А разработали составов и провели их замеры и исследования не мало. Там можно регулировать и уровень вязкости и критической температуры. В описанном составе, термопроводность высокая при температуре от -20 градусах. Целью было как раз добиться высоких показателей при минусовой температуре, а с плюсовой там проблем совсем нет.
Я правильно понимаю, что профессора математики и физики, который прекрасно умеет абстрагировать, при большой выборке покажут ниже IQ, чем депутаты? При условии, что мы возьмём большую выборку. Так как жизненный успех первых будет гораздо ниже, чем у вторых.
Но по IQ тестам уже миллион раз делали разборы и тесты. Более того, забросим вас в Африку, где племя Массаев покажет больше жизненного успеха и решения проблем в Африке, чем вы. Значит ли это, что IQ при смене территории перетекает между людьми? Или нам нужен тогда новый тест IQ? И какой считать правильным?
Чушь полная. Прекрасно можно менять эмоциональный стиль, получая очень агрессивные ответы, или наоборот, копируя стиль от гопника до сдержанного психолога и даже психа с множеством личностей.
Когда нужно было настраивать характер персонажа, чтобы он не терялся спустя тонны диалогов. И при этом на выходе были и маньяки агрессивные, и нервозные официанты и так далее.
Это только касалось текстовой части, для голосовой было более сложная модель, через баланс распознавания базовых признаков в голосе, историей, внутренним состоянием и так далее. Но для текста выше отлично работает, хотя это только для задания характера. Для того, чтобы внутреннее эмоциональное состояние модели (через тексты) менялось, там тоже немного сложнее было.
Ни какого смысла модели не теряют. Запихивать такое в системный промпт бесполезно.
Легко. У меня этот шлак постоянно выдает. Все дело в сложности вопрос. Пока он на уровне - "какого цвета неба?", все классно. Как только он сложнее - это полнейшая чушь и бред.
Буквально вчера, решил посмотреть что мне предложить LLM (было несколько попыток новых чатов с нуля):
Сейчас при обучении нейронных сетей в llm мы используем предсказание следующего токена через loss кросс энтропии.
Допустим, мы знаем что текущий токен A, и знаем все вероятности перехода токена A в другие токены, так как собрали статистику. Это значит, что мы можем для каждого значения логита, учесть его вероятность. То есть, не один loss на все значения логита, а для вектор loss для всех значений логита. Где мы оцениваем, насколько точно предсказана вероятность этого значения логита. Или это не будет работать лучше?
Тут она выдала сносный ответ, хотя частично не верный. И затем я задал уточняющий вопрос.
Проблема в том, что логиты имеют распределение вероятности токенов. Особенно сырые логиты, хотя они и не являются вероятностями. Проблема в том, что не все из этих значений логитов являются допустимыми для продолжения. Некоторые являются шумом. Top-k и top-p не позволяют отличить допустимые токены от шума. Текст это марковские цепи. И даже если следующий токен имеет высокую вероятность, это не значит, что он допустимый. Вероятность цепи Маркова это умножение всех вероятностей перехода ее элементов. И есть порог разрыва цепи Маркова. Если сейчас вероятность цепи Маркова 0.1, а порог разрыва 0.05, то не каждая вероятность подойдёт как следующий токен. Если вероятность следующего токена 0.2, то он приведет к тому, что цепь Маркова будет меньше 0.05, поэтому этот токен не допустим и является шумов на данном шаге. Но top-k и top-p ничего не знают об этом. В их диапазон легко могут попасть такие токены.
Поэтому я пытаюсь понять, как этого можно избежать. Тут три варианта:
как то обучить llm, чтобы она выдавала сырые логиты в таком виде, что все значения следующих которые приведут к шуму, должны быть ниже какой-то границы.
какая-то дополнительная архитектура после LLM, возможно со скрытым состоянием, которая сможет отследить и выдать только допустимые значения логитов. Но не понятно, как ее обучать и какой должна быть архитектура.
самостоятельно отслеживать текущую вероятность цепочки на выходе. И брать только допустимые значения логитов для выбора следующего токена. Предварительно собрав статистику по переходу всех токенов. Но тут мы можем отслеживать только цепь Маркова первого уровня. Это лучше чем argmax, но не идеально.
Что ты об этом думаешь? Какие есть предложения? Возможно кто-то уже решил эту проблему?
И тут Остапа понесло. Отборный бред помноженный на размышления и на сжатие ответа (анг. вставки не к месту, укороченные слова и бред).
В ответе много такого, как ниже:
N (candidates): 50–200 — хороший компромисс.
H (horizon) для меток: старт 1–3, для production 3–10 при ресурсах.
K (rollouts per candidate): 4–16 — tradeoff bias/variance.
s_min (acceptor threshold): 0.5–0.8 по ROC/PR.
α (power for s): если acceptor достаточно надёжен, α=2..4; иначе α≈1.
Calibrate p_i: temperature scaling на dev set, особенно если используешь raw logits.
Fallback: если фильтр убрал всё, выбирать argmax из original p (или ослабить threshold).
Monitoring: следи за diversity (тип токенов), average chain logprob, human eval.
Пока разберешься, что она имела ввиду, что сократила, проверишь все это и увидишь бред, требует нормально времени и мозг работающий на всю катушку. Я уже молчу про код, который она предложила без каких-то доказательств, без явной логике. Просто по принципу тут соединим и отлично. Произвольный код и я могу написать, только какой мне прок в этом.
И главное, если человек не понимает тему, он ее ответ проглотит, решив, что тут очень умное и правильное. И пойдет хвалить, как сетка написал код.
beta это температура. здесь обучение на 1000 примерах, с разным подходом обучения температуре. В одном она задалась жестко и постепенно увеличивалась, а на другом система сама во время обучения LLM обучалась температуре (постепенно увеличивая ее).
Недавно как раз делал подстройку температуры, где модель для нее обучается отдельно.
Но там температура при этом в связке влияет на токенизатор, механизм внимания и FFN и отсутствует на выходе из модели. Модель сама регулирует и на каждом шаге подстраивает ее.
Как итог на 1000 примерах обучения с нуля, модель выдает не высокочастотный шум, а начинает формировать связи. https://t.me/greenruff/2499 так что регулирование важно, а то что относят к top_k и случайный выбор это немного другая проблема, связанная не с температурой.
Триллион параметров — но благодаря MoE активируется только 32B на токен
Когда пишут про огромное кол-во параметров с использованием MoE, на самом деле это не совсем реальные размеры модели.
Чтобы это понять, представьте, что у вас есть функция F(X) которая аппроксимирует несколько максимумом. Но для этого нужен большой размер FFN. Тогда в место одной F(X) делаете N функций аппроксимации F1(X), F2(X)... Fn(X), каждая из которых аппроксимирует только один максимум. Эти функции по сути схожи, но отличаются немного в параметрах.
Таким образом вы раздули размерность, потому что большая FFN для F(X) у вас не влезает в память. Поэтому вы вынуждены сделать N разных FFN для F1(X), F2(X)... Fn(X), где их размер меньше, для достаточной точности. При этом вы загружаете в память только какую-то одну. Например, только F1(X). То есть мы в N раз увеличили кол-во параметров, из за наших ограничений. Фактически F1(X), F2(X)... Fn(X) эта одна и та функция, только с разными настройками параметров.
В этом легко убедиться, если сначала в MoE включить только один FFN, обучить его. Затем скопировать его веса в остальных экспертов и дальше дообучать деталям.
Поэтому триллионы, секстилионы параметров MoE мало что значат, если у нас там изначально меньше максимумов, которые можно интерпретировать. Я приводил пример, и сейчас использую этот подход для ускорения обучения MoE https://t.me/greenruff/2509
Текущая архитектура LLM это просто архиватор последовательности данных, только в отличии от Zip архиватора, LLM сжимает с учётом иерархии.
Выше простой пример, слово да встречается часто. Какой следующий токен будет оптимален для сжатия цепочки? В данном случае тот, который часто встречается, так как кодирование его в токен увеличивает сжатие.
Вы можете хоть 100 раз регенерировать ответ моделью и она в данном случае будет выдавать вам слово Да. Если только вы не добавите в системный промпт много предложений , где будет встречаться слово нет.
Тогда и zip архиватор следует признать зачатками сознания. А архив сжатый через фрактальное сжатие проявлением сознания.
У них же нет обучения с нуля. В свое время на заборе была статья от Сбера, где была ссылка на их репозиторий с моделью. Как раз после того как deepseek выложил в opensource. Они по-моему писали что взяли ее и дообучали. Я смотрел код их модели на том гмтхабе, там косметические изменения были. Так что, эти крупные модели Сбера не обучены с нуля, а используют в своей основе Deepseek.
Проблема галлюцинаций моделей за последние годы так и не была решена. Однако практический опыт (включение поиска в ChatGPT) показывает, что проблема почти полностью исчезает и взаимодействие с моделью выходит на принципиально иной уровень надежности.
Проблема ни куда не исчезает, она ещё и множится и усугубляется. Возможно для простых вещей, вроде рецепт приготовления супа все нормально, но более сложных - полнейшее фиаско и галлюцинации.
Это отлично видно на математике, где важна точность и логика. Через поиск она находит какую-то работу, берет из нее фрагмент, который косвенно связан. Переформулирует на свое усмотрение и выдает, что "согласно исследованиям/теореме, мы получаем". Смотришь, а там другое, да слова совпадают и даже есть аналогия, но формулы другие, речь о другом. И такое постоянно.
А режим исследования в ChatGPT, вы пробовали смотреть на что он опирается? Там можно посмотреть весь список материалов. Так вот там легко вам может попасться срач на форуме мамочки.ру (условно), где они обсуждали мозги. А ты попросил исследований конкретной темы по неокортексу. Так как модель не может отличить значимость мамочки.ру и сайт с публикацией исследований, особенно когда они рядом в выводе.
Нейронки в текущей архитектуре как были подвержены галлюцинациям, так и будут. Так как проблема не в доступе к информации, не в рассуждениях. Это проблема самой архитектуры, ее ограничений.
Он написал чушь.
1) я написал что это компромиссное решение, которое по качеству лучшее. Ого как раз захватывает гармоники через ширину, в то время как в сетки в коде даже этого не делают.
2) LPC делает гораздо, гораздо хуже. Он не приспособлен идеально к речи. Естественно у меня есть код этого через librosa, но там звучание гораздо хуже. Так как librosa больше подходит для неречевых звуков. Что касается pydub, то и с ним у меня была реализация и там тоже что-то было не так. Из всех вариантов, был выбран наиболее лучший по качеству с учётом компромиссов. Остальные давали результат гораздо хуже или ломали что-то ещё.
Вместо того чтобы полагаться на сетки надо проверять, а уже затем утверждать. В этом и заключается проблема, если полагаться на то что утверждает сетка. Я прекрасно знаю, что они отвечают, так как использую их и они в этих моментах очень сильно тупят. И я молчу уже о том, что решая проблему они могут выкинуть что то уже рабочее в коде, какую то деталь, упростить расчет и так далее.
Paart очень известная библиотека. Там же дело не в библиотеке, а к логике реализации. Такие же проблемы возникают и с базами данных. Вот простой пример, который нормально не могут осилить LLM. Нужно перенести SQL с MS SQL на Postgres, это по-моему часть кода одного из отчетов. Ниже два примера MS SQL которые нужно перенести на Postgres. В данном случае есть некоторые участки, где синтаксис будет сильно отличаться или даже может не оказаться аналога. А если еще учесть, что надо динамический запрос, то все усложняется. Вот такие реальные задачи встречаются в жизни.
В первом, LLM постоянно что-то выкидывает, что-то теряет, упускает детали.
Скрытый текст
Во втором, просто тупо допускает ошибки не понимания в чем дело. LLM использует string_agg при конвертировании, и упускает некоторые моменты особенности Postgres при работе с string_agg. Из за этого код она пишет, код при выполнении иногда выдаст ошибку, LLM пытается ее исправить, но зациклено по кругу исправляет одно и тоже, не понимая некоторых нюансов работы string_agg.
Скрытый текст
Подобные вещи встречаются сплошь и рядом.
Praat это самая популярная и эффективная библиотека при работе с голосом. Все LLM ее знают и все равно галлюцинируют на ней часто обращаясь к тому чего нет. Как уже было сказано выше, да она правильная, так как использовал ее при изменении голоса.
Ниже пример, где также используется эта функция. Я прекрасно знаю что на все это пишут LLM, проблема в том, что они не могут не писать, даже там где имеют проблемные места.
Скрытый текст
https://t.me/greenruff/1895
https://t.me/greenruff/1947
https://t.me/greenruff/1868
Я использую LLM, просто у них есть границы применимости.
Давайте так, если вы предлагаете решение, то не нужно просто брать и генерировать его и просить модель объяснить это решение. Стоит сначала взять и проверить его и затем уже предлагать. Если кратко то нет, в вашем случае на выходе вы услышите на фоне звука так же потрескивание или наоборот звуки скрежета.
В предложенном коде все кишит проблемами.
1) форманты содержат ширину, и ее надо учитывать. В коде выше, она считается примитивным образом как bw = -np.log(magnitudes[idx]) * sample_rate / np.pi и дальше просто идет проверка.
2) LPC очень плохо справляет на самом деле с голосом.
3) resample в описанном мной примере делается как компромисс, чтобы не потерять сильно в качестве звука. Это важное отличие, которое агенты просто не могут сделать. Нет такого понятие как компромисс, не могут они это оценить.
4) там еще не мало других проблем, вроде if 90 < f < 5000 and bw < 500 и множества других.
Синтетические тесты тут ни как не помогут. Что вы хотите в них анализировать? Как выстроите их, по какому критерию? Просто частоты сдвинулись или нет? В голосе форманты имеют обертоны, и если вы просто сдвинули какую то частоту то это не будет согласовываться например с ними.
Каким образом, работа с агентами может улучшить написание следующего кода: у нас есть аудио с речью, речь как мы знаем можно разделить на форманты F0-F5 (для примера ограничимся F5)? Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту. Вот правильный код на основе praat, который ни одна LLM не смогла написать:
Скрытый текст
Вы хоть обложитесь сотней агентов, они не сделают.
То есть на выходе вы получите выполняющийся без ошибок код, который будет делать что угодно, только не то что нужно.
Данный пример с аудио, просто один из таких примеров. В реальной работе их множество, когда мы не можете простым выполнением кода, проверить правильный результат или нет. И как уже написал, даже если ваш агент будет заранее рассуждать о возможных проблемах, задачу это не решит и вероятней всего на выходе вы получите "фарш".
У нее многие статьи это скорее рассуждающие, то есть теоретические (чем она и занимается по своей специальности). Сложно назвать их научными в плане исследований, а скорее научными в плане рассуждений. Это как если бы был специальный habr для физиков-математиков.
Насчет цитируемости, то она еще в 2019 году писала статью:
https://www.researchgate.net/publication/332884179_Predicting_authors'_citation_counts_and_h-indices_with_a_neural_network
"В данной работе мы описываем и представляем результаты работы простой нейронной сети, которая прогнозирует будущие показатели цитирования отдельных исследователей на основе различных данных из их прошлой деятельности."
Они делали простую нейросеть и прогнозировали цитируемость. На научную работу это не тянет. На хабре многие пишут статью, как что-то спрогнозировали. На GitHub такого много тоже, но для исследования это как-то мелко сегодня. Но тема цитируемости, явно "близка" ей.
Но в остальном, у нее много интересных работ "A derivation of Born’s rule from symmetry", где есть предположение, что вероятности должны быть согласованы с юнитарной структурой гильберта. И из этого ее объяснение показывает, что правило Борна не является случайной догадкой, а математически единственный возможный вариант, совместимый с симметрией квантовой механики. И таких статей у нее много. Они о построении различных гипотез, связях и так далее.
Если обобщить это, то тема цитируемости ей очень близка + большинство ее это гипотезы и рассуждения, но безусловно очень интересные. Так что понятно почему ее лично волнуют LLM статьи:
1) написание большего кол-ва статей, приведет к тому, что ей будет сложнее конкурировать с ними
2) ее статьи как раз рассуждающие, с различными гипотезами, теоретические но под разным углом и разными предположениями. Такое очень удобно делать с помощью LLM.
Другое дело, что LLM сами ничего не сделают. Для этого надо понимать, что они пишут, что попросить проанализировать, разобрать что они написали и отсеять бред. Так что автор либо боится что будет завалено мусором (но мусорных научных статей и так большинство), либо что упростит порог входа и написание теоретически рассуждающих статей другими физиками либо это просто страх неопределенности.
Реальное заметное улучшение даёт связь всех блоков и embedding слоя со всеми блоками.
Я делал это и показал, что данный подход более качественно улучшает обучение: https://t.me/greenruff/2497
При этом данное добавление обосновано, но должно быть сделано правильно. Оно нужно для связи разных уровней иерархии. Когда какое то слово, может усилить например сигнал на уровне целой главы, а не только следующего уровня иерархии как сейчас (например слово - параграфа).
Следующим шагом следует связать все блоки и выходной сигнал:
Тоже проводил это: https://t.me/greenruff/2543
Смысл данного подхода в том, что текст это многоуровневая иерархическая цепь условных вероятностей. Сейчас современные LLM используют выход только последнего уровня иерархии. Но это не правильно. Представим себе предложение:
Привет, как дела?
В нем нет дальних зависимостей и длинных связей. Но из-за текущей архитектуры LLM, только последний выход даёт основной вклад в генерацию цепочки. Это можно условно представить как: слоги, слова, синтагмы, предложения, абзацы.. В предложении выше, сложность ограничена связями внутри предложения, все что выше, даёт шум, так как для этого просто нет информации (для глав, параграфов и так далее). То есть верхние уровни связей дадут вклад, но он будет избыточным и слабым. Но в текущих LLM именно самый верхний уровень и даст максимальный вклад, так как остальные уровни не имеют прямого выхода и не могут напрямую вносить свой вклад, усиливая сигнал. Как итог, LLM выдает нам тонны избыточного текста, словно связь была на уровне целой главы и объем текста растет и растет. Если только искусственно через регуляризацию не обучали сокращать текст, но тогда там где нужен длинный текст, она тоже сократит его.
Вот эти два подхода, позволяют LLM правильно согласовывать сигналы разных уровней. И это реально даёт видимый эффект и имеет математическое обоснование. А вот подход усложнения residual как выше, приводит к нестабильности, так как не несёт смысла в усложнении.
В лучшем случае, мы можем добавить в residual линейный слой, чтобы увеличить его размерность в том случае, если мы решили повысить размерность следующего блока. В мозге именно так и происходит. Например, слуховая зона a1-a2-a3. Каждая последующая область содержит больше нейронов где то ~1,5 раза (условно). Это аналогично, как если бы мы напрямую связывали a1 (например 400 тыс нейронов) с a3 (например 800 тыс нейронов). В этом случаев residual играл бы роль пирамидальных нейронов, которые напрямую связывают a1 и a3 и для согласования размерности, мы должны расширить размерность сигнала a1 в a3 с 200 тыс до 800 тыс, через linear. Но никаких избыточных решений как предложено в статье, там нет. Есть прямые связи, которые расширяются.
Какой пост, я не автор поста или вы про комментарий? Вы реально считаете, что нейронная сеть сможем сгенерировать подобный комментарий, да еще и провести сама исследование и показать это наглядно как выше? Нет, LLM бы вам на это сгенерировала тонну правдоподобного мусора, так как это тот случай, когда в обучающих ее данных нет данного ответа. Я видел опечатку про "смелые яблоки", но не стал править, так дальше было прекрасно понятно о чем речь. В том моем комментарии опечаток гораздо больше.
Странное улучшение, если рассматривать это как "выразительность" описывающая более сложные функции, то выглядит это очень натянуто. Мы можем хоть SSM добавить в residual, чтобы придать больше "выразительности", вопрос в том, а надо ли? В исследовании я не увидел аргументов, зачем авторы это делают. кроме как чтобы "улучшить".
Аргумент авторов: n потоков внутри блока → больше "параллельных путей", которые комбинируются через обучаемую матрицу H_res. Но они не приводят доказательств, что именно эта выразительность нужна.
Можно было бы просто увеличить линейные слои внутри residual и теоретически любая функция X→Y записывалась бы.
Увеличение потоков ≈ увеличение числа параметров, без явного анализа, зачем каждый поток нужен.
Пока это спорное не доказанное преимущество, скорее гипотеза что "несколько путей = более выразительно".
Сами же авторы пишут "каждый поток может специализироваться". На каких подзадачах? Никаких формальных разложений задачи внутри блока не приводят. Residual не решает несколько задач явно, это просто функция слоя. Если и существует какая-то декомпозиция задачи, то она не формализована в исследовании.
Можно было просто увеличить линейные слои внутри residual с размером, равным n раз больше → то же количество "параллельных путей" без сложной матрицы H_res.
Далее, авторы пишут, что H_res позволяет решать, какой поток важнее.
На самом деле: x(k+1) = H1(x(k)) + H2(x(k)) + … + H_n(x(k)) + F(x(k)) → это просто линейное сложение N функций.
Нет softmax или gating, чтобы явно выбрать поток → каждый поток всегда участвует одинаково (по весам H_res, которые ограничены многообразием).
Чтобы была реальная маршрутизация → нужно MoE‑подобный routing.
Поэтому все это не доказано, а скорее является интуитивными формулировками.
Ну и как итог, в статье авторы приводят эксперименты на крупных моделях (~27B параметров), где mHC стабилизирует обучение и немного улучшает loss/accuracy по сравнению с HC и baseline. Но нет прямого сравнения с альтернативой "увеличение ширины linear внутри residual", которая теоретически даёт тот же результат. Преимущество скорее в стабильности, чем в "выразительности" или "специализации потоков". Улучшения есть, но не настолько сильные, чтобы однозначно утверждать, что n потоков внутри блока принципиально нужны.
Я вижу, что фактически: это скорее маркетинговая подача, чем проверенная теория.
Все сложнее. Текст является цепями Маркова. Но, это не просто непрерывная цепь Маркова, а иерархическая цепь Маркова, где иерархии верхнего уровня, связывают разрыв цепей нижнего уровня.
Если мы посмотрим распределение вероятностей у логитов в LLM, то увидим:
Здесь модель еще не обучена полностью, но суть передает. Мы видим условные вероятности перехода между токенами с учетом всей иерархии.
Рассмотрим слово «жильцов», представленное последовательностью токенов:
« ж»→«ильц»→«ов».
Вероятность соответствующей марковской цепи равна:
PMarkov = P1(« ж») ⋅ P2(«ильц»∣« ж») ⋅ P3(«ов»∣«ильц»)
Проблема в том, что стандартные методы top-k / top-p не способны правильно оставлять возможные вероятности для следующего выбора токена.
Как уже было сказано, мы имеем дело с иерархическими цепями Маркова, которые имеют точки разрыва. Поэтому на каждом следующем шаге, мы не можем выбрать все вероятности в ни по интервалу K (top-k) ни по суммарной вероятности P (top-p).
Пусть после двух первых токенов:
P1 ⋅ P2 ≳ θ, где θ— порог разрыва цепи Маркова.
Тогда при выборе следующего токена допустимы только такие условные вероятности P3, для которых:
P1 ⋅ P2 ⋅ P3 ≥ θ
Это резко сужает пространство допустимых токенов и приводит к тому, что:
в конце слова выбор возможен только среди токенов с высокой условной вероятностью;
именно поэтому мы наблюдаем пики вероятности на окончаниях слов.
Если мы выбираем argmax (нулевая температура), то все нормально. Цепь Маркова разрывается и начинается новая. Но argmax в рамках существующих архитектур LLM это статика. Он не способен динамически учитывать контекст. Это приводит к застреванию в локальных максимумах и мы получаем усредненный текст. Это не значит, что он оптимальный, это значит, что при использовании dropout в процессе обучения, в случае неопределенности мы случайно добавляем смещение. Это приводит к статичным локальным маршрутам, которые и отражает генерация текста при температуре 0.
Если же мы используем температуру от личную от 0, то это нормально. Но, тут у нас возникает другая проблема. Если при выборе следующего токена, мы выбираем токен который уменьшить вероятность цепи Маркова ниже допустимого порога, то по сути добавляем шум. Поэтому на каждом шаге мы должны выбирать только такие токены, чья условная вероятность P(v) не уменьшит PMarkov ⋅ P(v) < θ.
При правильном подходе, мы получаем то, что цепь не нарушается и не добавляет шум. Это хорошо видно при начальном обучении модели.
Для примера, при начальном обучении модели LLM (1000 примеров обучения):
Top-K: всего слов: 130, сломанных слов: 17, коэффициент F: 17/130 = 0.1307
Цепи Маркова с порогом разрыва цепи: всего слов: 187, сломанных слов: 22, коэффициент F: 22/187 = 0.1176
Чем меньше F, тем меньше ошибок в словах в целом. Цепь Маркова немного выигрывает Top-K (аналогично Top-pP). На самом деле, если мы посмотрим на сломанные слова у Top-K и Цепи Маркова, что увидим разницу. Top-K - ломает слова полностью "обгваласько"/"беззвольте", а цепь Маркова "гулятьвающиеся"/"покосившимский"/"горизонтело" ("гулять" и шум "вающиеся" на конце, "покосившим" и шум "ский", "горизонт" и шум "ело") из-за маленькой статистики собранной при обучении на 1000 примера. Причина у них разная, в первом случае мы работаем с шумом и пытаемся его продолжить, а во втором случае мы получаем на конце шум, так как еще не собрали достаточно статистики.
Несмотря на маленькую разницу, данный подход показывает, что при использовании цепи Маркова в качестве критерия отсечения logits, мы смещаем шум в конец. В этом случае все упирается в качество обучения. В то время как при использовании Top-K, даже при качественном обучении мы можем получить шум в середине или начале слова, что приведет галлюцинациям и при продолжении, что можем вызвать цепную реакцию галлюцинаций при продолжении генерации.
Поэтому использование top-k/top-p эта одна из причин галлюцинаций современных LLM. Если мы используем только top-p, это может привести к тому, что цепь Маркова выберет недопустимый элемент, который является шумом (при его выборе) для продолжения цепи. Высокая вероятность элемента, не может гарантировать, что он не является шумом. Например: "яблоко кра...". Продолжением может быть красное и красивое. Оба варианта имеют высокую вероятность такого продолжения. Но возможно что вероятность одного из них приведет вероятность цепи Маркова ниже порога. Это значит будет являться шумом. Например, контекст в начале указывает, что мы выбираем смелые яблоки на рынке и красный цвет важен. В то время как выбор красивый, приведет к продолжению галлюцинаций и генерацией текста связанного с красотой, а не выбором по цвету спелые яблоки или нет.
Это одна из форм галлюцинаций, которая возникают как накопление таких отклонений. Каждое, может сильнее отклонить генерацию текста от контекста. Галлюцинации в LLM возникают не как результат одного ошибочного токена, а как следствие накопления локально допустимых, но глобально несогласованных выборов, которые экспоненциально сужают пространство согласованных продолжений.
Снёс gigacode в прошлом месяце, ставил год назад по-моему или больше. Пользы 0, ресурсы жрет прилично. Но не нашел, как нормально сделать его деинсталляцию. Пришлось просто удалять всю папку.
Пока Сбер не начнет серьезно вкладывать в нормальные R&D, так и будет всегда как АвтоВАЗ , брать готовое и улучшать. То что вижу на Хабре и в их списке исследований за год - к серьезному R&D не имеет отношения, скорее оптимизации и выводы из своих ошибок и результата обучения. При таком подходе они не отличаются от стартапа AAA из любой страны, где есть нормальный доступ к недорогому дообучению моделей на видеокартах.
Можно было бы сказать, что Сбер адаптирует по русский текст и поэтому лучше. Но и это не так. Ниже простой пример разницы между фундаментальным R&D и косметическим подходом Сбера. На примере токенизатора.
Это пример начала обучения на токенизаторе Сбера (Яндекс токенизатор даёт такой же результат) классической LLM на 1000 примерах. На выходе высокочастотный шум.
А это результат обучения LLM на тех же 1000 примерах, но специально разработанном токенизаторе.
Разница огромная. А все дело в R&D, реальных исследованиях, разработке математического аппарата, теории, поверка ее и так далее. И как результат получения нового вида токенизатора. То есть Сбер просто взял обычный BPE, вместо того, чтобы проводить реальные R&D. И для этого не нужно миллиарды $ или множество видеокарт.
Поэтому какой смысл от gigacode, если он не способен дать качественный скачек и проигрывает всем. Это аналог АвтоВАЗ, где взяли чужую доступную модель, немного украсили и выдали. Завтра крупные компании закроют opensource архитектуры, и Сбер будет 10 лет выпускать "ваз 2106" (на базе архитектуры deepseek или qwen).
Самую лучшую термопасту можно сделать следующим образом:
Правильно подобрать сплав галлия - индий - олово - висмут
Добавляем нанотрубки в нужных пропорциях
https://vc.ru/tribuna/466947-stoit-li-sozdavat-v-rossii-novye-tehnologii-nash-opyt-razrabotki-tyanusheisya-elektroniki-gflex
В свое время разрабатывал под грант оборудование для производства тянущихся электронных плат. Там одно из исследований было связано с теплопроводностью. При добавлении нанотрубок в нужных пропорциях теплопроводность улучшалась в ~20 раз.
Из минусов:
Нельзя наносить на алюминий
Стоимость, так как нанотрубки не дешёвые
Но если понятие элитная термопаста существовала бы, то ее состав был бы такой. Термопаста на основе сплавов галлия не новое, но с нанотрубками не видел ни разу. На сегодня это лучший состав, который я только могу себе представить, так как проводили исследования на эту тему. А разработали составов и провели их замеры и исследования не мало. Там можно регулировать и уровень вязкости и критической температуры. В описанном составе, термопроводность высокая при температуре от -20 градусах. Целью было как раз добиться высоких показателей при минусовой температуре, а с плюсовой там проблем совсем нет.
Я правильно понимаю, что профессора математики и физики, который прекрасно умеет абстрагировать, при большой выборке покажут ниже IQ, чем депутаты? При условии, что мы возьмём большую выборку. Так как жизненный успех первых будет гораздо ниже, чем у вторых.
Но по IQ тестам уже миллион раз делали разборы и тесты. Более того, забросим вас в Африку, где племя Массаев покажет больше жизненного успеха и решения проблем в Африке, чем вы. Значит ли это, что IQ при смене территории перетекает между людьми? Или нам нужен тогда новый тест IQ? И какой считать правильным?
Чушь полная. Прекрасно можно менять эмоциональный стиль, получая очень агрессивные ответы, или наоборот, копируя стиль от гопника до сдержанного психолога и даже психа с множеством личностей.
Ранее приводил пример как это делается через скрытые микродиалоги: https://t.me/greenruff/2240
Когда нужно было настраивать характер персонажа, чтобы он не терялся спустя тонны диалогов. И при этом на выходе были и маньяки агрессивные, и нервозные официанты и так далее.
Это только касалось текстовой части, для голосовой было более сложная модель, через баланс распознавания базовых признаков в голосе, историей, внутренним состоянием и так далее. Но для текста выше отлично работает, хотя это только для задания характера. Для того, чтобы внутреннее эмоциональное состояние модели (через тексты) менялось, там тоже немного сложнее было.
Ни какого смысла модели не теряют. Запихивать такое в системный промпт бесполезно.
Легко. У меня этот шлак постоянно выдает. Все дело в сложности вопрос. Пока он на уровне - "какого цвета неба?", все классно. Как только он сложнее - это полнейшая чушь и бред.
Буквально вчера, решил посмотреть что мне предложить LLM (было несколько попыток новых чатов с нуля):
Сейчас при обучении нейронных сетей в llm мы используем предсказание следующего токена через loss кросс энтропии.
Допустим, мы знаем что текущий токен A, и знаем все вероятности перехода токена A в другие токены, так как собрали статистику. Это значит, что мы можем для каждого значения логита, учесть его вероятность. То есть, не один loss на все значения логита, а для вектор loss для всех значений логита. Где мы оцениваем, насколько точно предсказана вероятность этого значения логита.Или это не будет работать лучше?
Тут она выдала сносный ответ, хотя частично не верный. И затем я задал уточняющий вопрос.
Проблема в том, что логиты имеют распределение вероятности токенов. Особенно сырые логиты, хотя они и не являются вероятностями.Проблема в том, что не все из этих значений логитов являются допустимыми для продолжения. Некоторые являются шумом.
Top-k и top-p не позволяют отличить допустимые токены от шума.
Текст это марковские цепи. И даже если следующий токен имеет высокую вероятность, это не значит, что он допустимый.
Вероятность цепи Маркова это умножение всех вероятностей перехода ее элементов. И есть порог разрыва цепи Маркова. Если сейчас вероятность цепи Маркова 0.1, а порог разрыва 0.05, то не каждая вероятность подойдёт как следующий токен. Если вероятность следующего токена 0.2, то он приведет к тому, что цепь Маркова будет меньше 0.05, поэтому этот токен не допустим и является шумов на данном шаге.
Но top-k и top-p ничего не знают об этом. В их диапазон легко могут попасть такие токены.
Поэтому я пытаюсь понять, как этого можно избежать.Тут три варианта:
как то обучить llm, чтобы она выдавала сырые логиты в таком виде, что все значения следующих которые приведут к шуму, должны быть ниже какой-то границы.какая-то дополнительная архитектура после LLM, возможно со скрытым состоянием, которая сможет отследить и выдать только допустимые значения логитов. Но не понятно, как ее обучать и какой должна быть архитектура.самостоятельно отслеживать текущую вероятность цепочки на выходе. И брать только допустимые значения логитов для выбора следующего токена. Предварительно собрав статистику по переходу всех токенов. Но тут мы можем отслеживать только цепь Маркова первого уровня. Это лучше чем argmax, но не идеально.Что ты об этом думаешь? Какие есть предложения? Возможно кто-то уже решил эту проблему?И тут Остапа понесло. Отборный бред помноженный на размышления и на сжатие ответа (анг. вставки не к месту, укороченные слова и бред).
В ответе много такого, как ниже:
N (candidates): 50–200 — хороший компромисс.H (horizon)для меток: старт 1–3, для production 3–10 при ресурсах.K (rollouts per candidate): 4–16 — tradeoff bias/variance.s_min (acceptor threshold): 0.5–0.8 по ROC/PR.α (power for s): если acceptor достаточно надёжен, α=2..4; иначе α≈1.Calibrate p_i: temperature scaling на dev set, особенно если используешь raw logits.Fallback: если фильтр убрал всё, выбирать argmax из original p (или ослабить threshold).Monitoring: следи за diversity (тип токенов), average chain logprob, human eval.Пока разберешься, что она имела ввиду, что сократила, проверишь все это и увидишь бред, требует нормально времени и мозг работающий на всю катушку. Я уже молчу про код, который она предложила без каких-то доказательств, без явной логике. Просто по принципу тут соединим и отлично. Произвольный код и я могу написать, только какой мне прок в этом.
И главное, если человек не понимает тему, он ее ответ проглотит, решив, что тут очень умное и правильное. И пойдет хвалить, как сетка написал код.
Недавно как раз делал подстройку температуры, где модель для нее обучается отдельно.
Но там температура при этом в связке влияет на токенизатор, механизм внимания и FFN и отсутствует на выходе из модели. Модель сама регулирует и на каждом шаге подстраивает ее.
Как итог на 1000 примерах обучения с нуля, модель выдает не высокочастотный шум, а начинает формировать связи. https://t.me/greenruff/2499 так что регулирование важно, а то что относят к top_k и случайный выбор это немного другая проблема, связанная не с температурой.
Триллион параметров— но благодаря MoE активируется только 32B на токенКогда пишут про огромное кол-во параметров с использованием MoE, на самом деле это не совсем реальные размеры модели.
Чтобы это понять, представьте, что у вас есть функция F(X) которая аппроксимирует несколько максимумом. Но для этого нужен большой размер FFN. Тогда в место одной F(X) делаете N функций аппроксимации F1(X), F2(X)... Fn(X), каждая из которых аппроксимирует только один максимум. Эти функции по сути схожи, но отличаются немного в параметрах.
Таким образом вы раздули размерность, потому что большая FFN для F(X) у вас не влезает в память. Поэтому вы вынуждены сделать N разных FFN для F1(X), F2(X)... Fn(X), где их размер меньше, для достаточной точности. При этом вы загружаете в память только какую-то одну. Например, только F1(X). То есть мы в N раз увеличили кол-во параметров, из за наших ограничений. Фактически F1(X), F2(X)... Fn(X) эта одна и та функция, только с разными настройками параметров.
В этом легко убедиться, если сначала в MoE включить только один FFN, обучить его. Затем скопировать его веса в остальных экспертов и дальше дообучать деталям.
Поэтому триллионы, секстилионы параметров MoE мало что значат, если у нас там изначально меньше максимумов, которые можно интерпретировать. Я приводил пример, и сейчас использую этот подход для ускорения обучения MoE https://t.me/greenruff/2509
Текущая архитектура LLM это просто архиватор последовательности данных, только в отличии от Zip архиватора, LLM сжимает с учётом иерархии.
Выше простой пример, слово да встречается часто. Какой следующий токен будет оптимален для сжатия цепочки? В данном случае тот, который часто встречается, так как кодирование его в токен увеличивает сжатие.
Вы можете хоть 100 раз регенерировать ответ моделью и она в данном случае будет выдавать вам слово Да. Если только вы не добавите в системный промпт много предложений , где будет встречаться слово нет.
Тогда и zip архиватор следует признать зачатками сознания. А архив сжатый через фрактальное сжатие проявлением сознания.
У них же нет обучения с нуля. В свое время на заборе была статья от Сбера, где была ссылка на их репозиторий с моделью. Как раз после того как deepseek выложил в opensource. Они по-моему писали что взяли ее и дообучали. Я смотрел код их модели на том гмтхабе, там косметические изменения были. Так что, эти крупные модели Сбера не обучены с нуля, а используют в своей основе Deepseek.
Проблема ни куда не исчезает, она ещё и множится и усугубляется. Возможно для простых вещей, вроде рецепт приготовления супа все нормально, но более сложных - полнейшее фиаско и галлюцинации.
Это отлично видно на математике, где важна точность и логика. Через поиск она находит какую-то работу, берет из нее фрагмент, который косвенно связан. Переформулирует на свое усмотрение и выдает, что "согласно исследованиям/теореме, мы получаем". Смотришь, а там другое, да слова совпадают и даже есть аналогия, но формулы другие, речь о другом. И такое постоянно.
А режим исследования в ChatGPT, вы пробовали смотреть на что он опирается? Там можно посмотреть весь список материалов. Так вот там легко вам может попасться срач на форуме мамочки.ру (условно), где они обсуждали мозги. А ты попросил исследований конкретной темы по неокортексу. Так как модель не может отличить значимость мамочки.ру и сайт с публикацией исследований, особенно когда они рядом в выводе.
Нейронки в текущей архитектуре как были подвержены галлюцинациям, так и будут. Так как проблема не в доступе к информации, не в рассуждениях. Это проблема самой архитектуры, ее ограничений.