Как владелец сначла 3, а потом 4 rtx 3090 (2 ti, 2 обычные) полностью подтверждаю, при условии что 130 тыс токенов контекста хватает. Если возьмете 3 rtx 3090, то можно и не квантованную версию модели использовать с полным контекстом по умолчанию (262 тыс. токенов). Это лучшее что может быть сегодня за адекватные деньги. Скорость генерации высокая, скорость чтения супер высокая
Я добавил 4-ю gpu и получил возможность крутить qwen 122b-a10b q5_K_s на скорости генерации 9-11 ток/с (4000 тыс токенов контекста и ответ тоже около 4000 тыс токенов) и скорости чтения около 1600-1800 ток/сек.
Когда была только 1 видюха, то крутил эту же модель но в Q6_M с частичной выгрузкой в RAM с той же скоростью генерации, но со скоростью чтения 35-50 ток./сек. Для кодинга не было применимо, но в чате вполне хорошо.
В общем, сегодня 2 rtx 3090 - это реальный оптимум.
Кол-во видюх дает возможность запускать более крупные модели, но скорость работы не увеличивается, а только уменьшается (скорость генерации утыкается в скорость памяти а не производительность чипа,)
Rtx 3090, на авито можно ухватить за 60 тыс и это не самый дешевый вариант.
Блок питания помощнее нужен (хотябы 1 квт), либо отдельный на 500 вт взять и видюху к нему подключить.
Проц не вилияет сильно. Оперативка вадна, если будете запускать гибридный инференс, выгружая часть слоев на оперативку. У меня 3600 МТ/с - не быстрая, но гибридный инференс qwen 122b-a10b идет в 9-15 ток/сек - для чата комфортно, для агентов минимально приемлемо
На реддите писали, что получали максимальный буст от NVlink на двух rtx 3090 c 9 ток/сек до 14 ток/сек. Но вот деталей я уже не помню (что за модель, какой движок для инференса). Но большинство писало, что эффект от NVlink в пределах 10-20%
Я добираю 4-ю rtx 3090 в свой сетап и на этом успокоюсь 122b-a10b в Q5 должна влезть, бюджет на хобби выбран и больше видюх не поместится в корпус.
Дальше только переход на HEDT или серверные железки. Если смогу преобразовать это дорогое хобби в доход, то думаю над сборкой на основе threadripper 7965wx, там 128 линий и материнка есть с 6 шт. pci-e 5.0x16 + один pci-e 5.0x8. Но даже в этой сборке переходить к профессиональным картам не думал ибо бюджет улетает в космос.
Blackwell 6000 на 96 гб выходит дороже четырех rtx 3090 и даже двух 4090 48gb.
Годная статья, саи недавно начал крутить локальные LLM для кодинга в OpenCode, очень не хватало этой информации, спасал забугорный реддит.
Последние qwen 3.5 - 3.6 справляются с кодингов вполне хорошо, запускал на своем железе (192 гб RAM + rtx 3090 ti) как плотные 27b, так и MoE 122b-A10B, 31b-a3. Удалось в q6 запустить модель на 122b с частичной выгрузкой в RAM, было 9-15 токенов - небыстро, но приемлемо.
Проникся как качественно работает, решил добавить в систему еще 2 rtx 3090, думая что смогу меньше слоев выгружать в RAM и будет быстрее работать. Это была ошибка: либо я не смог понять как правильно загрузить несколько GPU при использовании n-cpu-moe, либо узкое горлышко в виде pci-e 4.0x4 делает частичную выгрузку в RAM бессмысленным
Но зато 27b модель с контекстом в 262 тыс. токенов помещается на 3х3090 идеально и это без использования какого-либо квантования
В тексте такое определение ИИ, что если я в Экселе сделал линейную регрессию по данным в столбце, а данные в этом столбце обновляются, то я - разработчик ИИ.
Подход с BERT topic показал плохие результаты с хорошей метрикой silhouette по довольно тривиальной причине: silhouette, как и остальные метрики кластеризации без разметки из Sklearn по своей природе оценивают качество кластеризации для кластеров сферической формы. HDBSCAN (как и DBSCAN и агломеративная кластеризация) порождают кластеры произвольной формы. То есть, используемая метрика не способна оценить кластеризацию HDBSCAN в общем случае.
Какой тут выход?
Использовать метрики сходства кластеризации и имеющейся у вас классификации. То есть что-то, что умеет оценивать похожесть двух категориальных переменных, можно тестом хи-квадрат. Я в подобных случаях использую взаимную информацию, нормированную на энтропию целевой категориальной переменной - очень полезная метрика когда переменные только категориальные, а особенно если в каждой много категорий.
Спасибо за качественную статью, было интересно увидеть сравнение методов на реальных данных.
В статье показаны некоторые методы обработки текстов, чтобы вытянуть некоторые показатели - хорошо для новичка в текстовом анализе. Однако не хватает цели: анализ же никогда не делается для того чтобы что-то посчитать, показатели нужны для выводов.
Сам сталкивался с разведочным анализом текстов, но в моем случае было 2 цели:
1) облегчить работу data scientist, чтобы они на EDA время не тратили
2) ускорить понимание корпуса документов любому члену команды, кому резко потребовалось поработать с теми текстами, что уже попали мне в руки.
Исходя из вышеописанного я бы в набор тех методов, которые описаны в статье, добавил:
1) Расчет TF-IDF и оценку того какая доля уникальных слов покрывает объем всех слов по частоте и по TF-IDF. То есть на выходе получить значения вида: 20% уникальных слов покрывает 50% вхождений всех слов и 35% суммарного TF-IDF.
Так мы поймем насколько уникальны документы и насколько большой должен быть словарь для векторизации через BoW или TF-IDF
2) добавить ключевые слова для тем. Не только расчетом наиболее частотных, но и с помощью, либо легких алгоритмов YAKE, RAKE, либо путем поиска ближайших слов к центроиду тем.
Так мы поймем о чем наши тематики более точно
3) рассчитать все показатели не только для отдельных слов, но и для 2, 3 - грамм. Зачастую n-граммы помогают лучше понять о чем текст.
Так мы улучшим понимание текстов для тех, кто читает наш анализ. В случае, если тексты не сильно уникальные (например отзывы на парикмахерскую), то уже на 3-граммах можно будет отловить основные паттерны и более глублокий анализ может даже не потребоваться.
4) оценка изменения тем во времени. Например, через подсчет кол-ва документов тематик в каждый месяц. Изменение распределения документов в темах от месяца к месяцу даст нам информацию о том, как быстро сменяются (читай, дрифтуют) основные темы в корпусе документов. В случае отзывовов мы поймем ушли ли старые проблемы и добавились ли новые.
5) если есть категориальные переменные, то добавить оценку взаимной информации между темами и категориями. Так мы поймем что у нас есть реальная связь между темой текста и его категорией. Отсюда поймем надо ли тюнить наш алгоритм поиска тем или может действительно связи нет.
6) К LDA я бы добавил LSA (TF-IDF + SVD) и кластеризацию для поиска тематик, так как гадать над количеством тем не очень интересно. В свою очередь такой ручной поиск тематик через кластеризацию дает больше управления и позволяет сделать выводы о том насколько документы однородны. Например, если нас устраивает кластерищация через k-means, значит темы в корпусе документов более-менее четкие. Если же через k-means получается ерунда, но нас устроила клстеризация через (H)DBSCAN, значит темы в документах "расплывчатые" могут перетекать из одной в другую, приводя к тому, что есть множества документов, где каждый похож друг на друга, но все они либо без четкой границы, либо перетекают из темы в тему в рамках макротемы.
Читал в студенчестве, очень полезная была для мышления. Хотя и мусолит одно и то же под разными соусами, здорово что именно такой подход позволяет лучше детектировать жтих самых лебедей в жизни.
Еще классная идея у него это - стратегия штанги
Согласно такой стратегии заводил несколько YouTube каналов и прочувствовал положительного "черного лебедя" в виде выстрелившего ролика.
Для этого достаточно книжки с андроидом, на который установлен obsidian. Прописывается директория со всеми документами в obsidian и все, поиск работает
Я мехматов не заканчивал, по первому пункту сказать ничего не могу, но по оставшимся интересно было бы уточнить:
Ложные/локальные минимумы существующая проблема, с которой пытаются бороться разными методами (запуск гралиентного спуска с разными точками инициализации, например). То есть ML работает со сложными поверхностями целевой функции, а не только с выпуклыми. Не факт что делает это хорошо, но работает.
Связь может быть слабой/сильной: влияет ли факт наличия пьяного бомжа по средам вечером у входа в Пятёрочку на продажи хлеба? - влияет, кто-то передумает заходить в магазин за хлебом. Но каков вес влияния этого фактора на выручку хлебопроизводителя за месяц? Скорее всего очень низкий, настолько, что может затеряться в шуме. Вот в этом случае я бы и сказал, что связь слабая и на данных я бы вообще посчитал ее шумом. А если мы задумается что такое "шум" в данных, то поймем, что это как раз такие очень слабо влиющие факторы, которых просто много и выявить точную связь с ними мы не можем.
Мои мысли описал, если укажите, где я не прав, то буду рад просветиться: больше знаний - лучше
Уточните, что имеется в виду под "требуется анализировать информацию в БД"?
Есть некая БД, SQL запросом вытягивается информация и ваш сервис должен проанализировать (выдать саммари, исходя из контекста) получаемую таблицу?
В этом сценарии подсказть о подходах не могу, так как мы сфокусированы на обработке текстов из баз знаний. Таблицы там тоже есть и мы пока еще выбираем подход к их обработке.
А так, чтобы целенаправленно обрабатывать таблицу из БД - такой варинт есть в планах, но сейчас поделится нечем.
Хорошая обзорная статья, полностью согласен с выводами. Я бы еще добавил, что специалисту по DS полезно было бы еще освоить операции линала в numpy - порой помогает писать значительно более быстрый код
Сложно понять, что вам не понравилось в "такой алгебре". Я не против складывать 1.5 + 0.5 землекопа. В общем-то и теплое с мягким, когда это два вектора, превращенные линейной комбинацией в главную компоненту с интерпретацией 'комфорт".
Приведите пример другой алгебры полезной в прикладном смысле, относительно data science (это ведь тема статьи)
Автор не врет, когда говорит что специалисту в Data science без знания таких концепций не стать настоящими профессионалом.
Сам как аналитик данных подтверждаю, что даже базовое понимание линейной алгебры очень хорошо прокачивает спеца.
А если говорить про инетпретируемый анализ данных, то более сложная математика зачастую противопоказана
Статья интересная, как человеку с экономическим образованием, почитать про реальные проблемы нахождения кривой спроса - очень интересно.
Но как аналитик данных, хочу сказать, что на протяжении всей статитьи в голове мысль: "если строили модель и она не дала хороших результатов, то как-то не так ее строили".
Если вы утверждаете, что "черные лебеди" прилетают и ломают модели, то очень хочется увидеть что были за события и насколько поломались модели.
Более того, уверен, что предсказать заранее влияние ковида или СВО на продажи за адекватное время невозможно. Однако, как вы и делаете сейчас, можно же поделить время на срезы до и после событий такого рода и также рассчитывать прогнозы отдельнотдля каждого периода.
На фоне того как ствтья погружает в проблему поиска решения, результат в виде линейной регрессии на коротких промежутках времени выглядит как Ока на фоне Lamborghini.
Очевидно, что любая функция аппроксимируется линейной и чем меньше промежуток, тем лучше будет работать линейное приближение.
Как заинтересованный читатель я бы очень хотел увидеть в следующих статьях показатели мер связи между предикатами, которые вы использовали и таргетом и ответ на вопрос почему линейная регрессия на коротких промежутках лучше, чем все остальное. И хотелось бы увидеть как подбирали регрессию для сушествующего решения
Нейронки все же учитывают словоформы и синонимы. Так как не все синонимы на 100% схожи по смыслу. Более того они учитывают контекст, то есть несколько смыслов для одного слова.
Смысл в том, что с вектор отражает смысл текста и можно из вектора получить обратно текст. Текст будет похож на исходный.
Очевидно, что с sha256 такое не сделать.
Можно текст вообще в одно число закодировать, только коллизий много будет. Смысл не только в сжатии, а в возможности работать с этой сжатой информацией.
Я бы сказал, что исследователи изучали наименьшую возможную размерность пространства смыслов в которое можно вложить текст
Как владелец сначла 3, а потом 4 rtx 3090 (2 ti, 2 обычные) полностью подтверждаю, при условии что 130 тыс токенов контекста хватает. Если возьмете 3 rtx 3090, то можно и не квантованную версию модели использовать с полным контекстом по умолчанию (262 тыс. токенов). Это лучшее что может быть сегодня за адекватные деньги. Скорость генерации высокая, скорость чтения супер высокая
Я добавил 4-ю gpu и получил возможность крутить qwen 122b-a10b q5_K_s на скорости генерации 9-11 ток/с (4000 тыс токенов контекста и ответ тоже около 4000 тыс токенов) и скорости чтения около 1600-1800 ток/сек.
Когда была только 1 видюха, то крутил эту же модель но в Q6_M с частичной выгрузкой в RAM с той же скоростью генерации, но со скоростью чтения 35-50 ток./сек. Для кодинга не было применимо, но в чате вполне хорошо.
В общем, сегодня 2 rtx 3090 - это реальный оптимум.
Кол-во видюх дает возможность запускать более крупные модели, но скорость работы не увеличивается, а только уменьшается (скорость генерации утыкается в скорость памяти а не производительность чипа,)
Rtx 3090, на авито можно ухватить за 60 тыс и это не самый дешевый вариант.
Блок питания помощнее нужен (хотябы 1 квт), либо отдельный на 500 вт взять и видюху к нему подключить.
Проц не вилияет сильно. Оперативка вадна, если будете запускать гибридный инференс, выгружая часть слоев на оперативку. У меня 3600 МТ/с - не быстрая, но гибридный инференс qwen 122b-a10b идет в 9-15 ток/сек - для чата комфортно, для агентов минимально приемлемо
На реддите писали, что получали максимальный буст от NVlink на двух rtx 3090 c 9 ток/сек до 14 ток/сек. Но вот деталей я уже не помню (что за модель, какой движок для инференса). Но большинство писало, что эффект от NVlink в пределах 10-20%
Я добираю 4-ю rtx 3090 в свой сетап и на этом успокоюсь 122b-a10b в Q5 должна влезть, бюджет на хобби выбран и больше видюх не поместится в корпус.
Дальше только переход на HEDT или серверные железки. Если смогу преобразовать это дорогое хобби в доход, то думаю над сборкой на основе threadripper 7965wx, там 128 линий и материнка есть с 6 шт. pci-e 5.0x16 + один pci-e 5.0x8. Но даже в этой сборке переходить к профессиональным картам не думал ибо бюджет улетает в космос.
Blackwell 6000 на 96 гб выходит дороже четырех rtx 3090 и даже двух 4090 48gb.
А скорость и на потребителском железе приемлемая
Годная статья, саи недавно начал крутить локальные LLM для кодинга в OpenCode, очень не хватало этой информации, спасал забугорный реддит.
Последние qwen 3.5 - 3.6 справляются с кодингов вполне хорошо, запускал на своем железе (192 гб RAM + rtx 3090 ti) как плотные 27b, так и MoE 122b-A10B, 31b-a3. Удалось в q6 запустить модель на 122b с частичной выгрузкой в RAM, было 9-15 токенов - небыстро, но приемлемо.
Проникся как качественно работает, решил добавить в систему еще 2 rtx 3090, думая что смогу меньше слоев выгружать в RAM и будет быстрее работать. Это была ошибка: либо я не смог понять как правильно загрузить несколько GPU при использовании n-cpu-moe, либо узкое горлышко в виде pci-e 4.0x4 делает частичную выгрузку в RAM бессмысленным
Но зато 27b модель с контекстом в 262 тыс. токенов помещается на 3х3090 идеально и это без использования какого-либо квантования
Посмотреть на перплексию токенов ответа, сравнить с понятной для модели ситуацией.
Понятная модели ситуация - это такая, которой модель точно обучалась.
В рамках эксперимента чем ближе по длине промпт и ответ, тем более справедливое сравнение.
Замерить перплексию ответов закрытой модели, наверное никак, с открытыми проще, но не просто.
В тексте такое определение ИИ, что если я в Экселе сделал линейную регрессию по данным в столбце, а данные в этом столбце обновляются, то я - разработчик ИИ.
Задача решается интерактивным дашбордом. LLM тут не нужна. Странный кейс
Я что-то не понял а чем плохо, что Яндекс взял веса Квена и начал обучение с них, а не инициализировал их случайно?
Какие тут компетенции и опыт теряются?
Просто экономия компьюта за счет старта обучения из локального минимума из другого, но похожего пространства весов.
Самое сложное и требующее компетенций людей как раз остается и никуда не уходит
Подход с BERT topic показал плохие результаты с хорошей метрикой silhouette по довольно тривиальной причине: silhouette, как и остальные метрики кластеризации без разметки из Sklearn по своей природе оценивают качество кластеризации для кластеров сферической формы. HDBSCAN (как и DBSCAN и агломеративная кластеризация) порождают кластеры произвольной формы. То есть, используемая метрика не способна оценить кластеризацию HDBSCAN в общем случае.
Какой тут выход?
Использовать метрики сходства кластеризации и имеющейся у вас классификации. То есть что-то, что умеет оценивать похожесть двух категориальных переменных, можно тестом хи-квадрат. Я в подобных случаях использую взаимную информацию, нормированную на энтропию целевой категориальной переменной - очень полезная метрика когда переменные только категориальные, а особенно если в каждой много категорий.
Спасибо за качественную статью, было интересно увидеть сравнение методов на реальных данных.
В статье показаны некоторые методы обработки текстов, чтобы вытянуть некоторые показатели - хорошо для новичка в текстовом анализе. Однако не хватает цели: анализ же никогда не делается для того чтобы что-то посчитать, показатели нужны для выводов.
Сам сталкивался с разведочным анализом текстов, но в моем случае было 2 цели:
1) облегчить работу data scientist, чтобы они на EDA время не тратили
2) ускорить понимание корпуса документов любому члену команды, кому резко потребовалось поработать с теми текстами, что уже попали мне в руки.
Исходя из вышеописанного я бы в набор тех методов, которые описаны в статье, добавил:
1) Расчет TF-IDF и оценку того какая доля уникальных слов покрывает объем всех слов по частоте и по TF-IDF. То есть на выходе получить значения вида: 20% уникальных слов покрывает 50% вхождений всех слов и 35% суммарного TF-IDF.
Так мы поймем насколько уникальны документы и насколько большой должен быть словарь для векторизации через BoW или TF-IDF
2) добавить ключевые слова для тем. Не только расчетом наиболее частотных, но и с помощью, либо легких алгоритмов YAKE, RAKE, либо путем поиска ближайших слов к центроиду тем.
Так мы поймем о чем наши тематики более точно
3) рассчитать все показатели не только для отдельных слов, но и для 2, 3 - грамм. Зачастую n-граммы помогают лучше понять о чем текст.
Так мы улучшим понимание текстов для тех, кто читает наш анализ. В случае, если тексты не сильно уникальные (например отзывы на парикмахерскую), то уже на 3-граммах можно будет отловить основные паттерны и более глублокий анализ может даже не потребоваться.
4) оценка изменения тем во времени. Например, через подсчет кол-ва документов тематик в каждый месяц. Изменение распределения документов в темах от месяца к месяцу даст нам информацию о том, как быстро сменяются (читай, дрифтуют) основные темы в корпусе документов. В случае отзывовов мы поймем ушли ли старые проблемы и добавились ли новые.
5) если есть категориальные переменные, то добавить оценку взаимной информации между темами и категориями. Так мы поймем что у нас есть реальная связь между темой текста и его категорией. Отсюда поймем надо ли тюнить наш алгоритм поиска тем или может действительно связи нет.
6) К LDA я бы добавил LSA (TF-IDF + SVD) и кластеризацию для поиска тематик, так как гадать над количеством тем не очень интересно. В свою очередь такой ручной поиск тематик через кластеризацию дает больше управления и позволяет сделать выводы о том насколько документы однородны. Например, если нас устраивает кластерищация через k-means, значит темы в корпусе документов более-менее четкие. Если же через k-means получается ерунда, но нас устроила клстеризация через (H)DBSCAN, значит темы в документах "расплывчатые" могут перетекать из одной в другую, приводя к тому, что есть множества документов, где каждый похож друг на друга, но все они либо без четкой границы, либо перетекают из темы в тему в рамках макротемы.
Читал в студенчестве, очень полезная была для мышления. Хотя и мусолит одно и то же под разными соусами, здорово что именно такой подход позволяет лучше детектировать жтих самых лебедей в жизни.
Еще классная идея у него это - стратегия штанги
Согласно такой стратегии заводил несколько YouTube каналов и прочувствовал положительного "черного лебедя" в виде выстрелившего ролика.
Полезное чтиво.
Для этого достаточно книжки с андроидом, на который установлен obsidian. Прописывается директория со всеми документами в obsidian и все, поиск работает
Как владелец такого же аппарата, на который перешел с samsung galaxy tab s7 plus, подтверждаю, что лучше бы оставил планшет.
Tab ultra C во владении порядка полутора лет. Думаю взять galaxy tab s9 ultra в ближайшее время.
Заметок от руки сделано много и на Самсунге, и на tab ultra C.
Я мехматов не заканчивал, по первому пункту сказать ничего не могу, но по оставшимся интересно было бы уточнить:
Ложные/локальные минимумы существующая проблема, с которой пытаются бороться разными методами (запуск гралиентного спуска с разными точками инициализации, например). То есть ML работает со сложными поверхностями целевой функции, а не только с выпуклыми. Не факт что делает это хорошо, но работает.
Связь может быть слабой/сильной: влияет ли факт наличия пьяного бомжа по средам вечером у входа в Пятёрочку на продажи хлеба? - влияет, кто-то передумает заходить в магазин за хлебом. Но каков вес влияния этого фактора на выручку хлебопроизводителя за месяц? Скорее всего очень низкий, настолько, что может затеряться в шуме. Вот в этом случае я бы и сказал, что связь слабая и на данных я бы вообще посчитал ее шумом. А если мы задумается что такое "шум" в данных, то поймем, что это как раз такие очень слабо влиющие факторы, которых просто много и выявить точную связь с ними мы не можем.
Мои мысли описал, если укажите, где я не прав, то буду рад просветиться: больше знаний - лучше
Спасибо за такую оценку!
Уточните, что имеется в виду под "требуется анализировать информацию в БД"?
Есть некая БД, SQL запросом вытягивается информация и ваш сервис должен проанализировать (выдать саммари, исходя из контекста) получаемую таблицу?
В этом сценарии подсказть о подходах не могу, так как мы сфокусированы на обработке текстов из баз знаний. Таблицы там тоже есть и мы пока еще выбираем подход к их обработке.
А так, чтобы целенаправленно обрабатывать таблицу из БД - такой варинт есть в планах, но сейчас поделится нечем.
Если я не правильно понял вопрос, то уточните.
Хорошая обзорная статья, полностью согласен с выводами. Я бы еще добавил, что специалисту по DS полезно было бы еще освоить операции линала в numpy - порой помогает писать значительно более быстрый код
Сложно понять, что вам не понравилось в "такой алгебре". Я не против складывать 1.5 + 0.5 землекопа. В общем-то и теплое с мягким, когда это два вектора, превращенные линейной комбинацией в главную компоненту с интерпретацией 'комфорт".
Приведите пример другой алгебры полезной в прикладном смысле, относительно data science (это ведь тема статьи)
Автор не врет, когда говорит что специалисту в Data science без знания таких концепций не стать настоящими профессионалом.
Сам как аналитик данных подтверждаю, что даже базовое понимание линейной алгебры очень хорошо прокачивает спеца.
А если говорить про инетпретируемый анализ данных, то более сложная математика зачастую противопоказана
Статья интересная, как человеку с экономическим образованием, почитать про реальные проблемы нахождения кривой спроса - очень интересно.
Но как аналитик данных, хочу сказать, что на протяжении всей статитьи в голове мысль: "если строили модель и она не дала хороших результатов, то как-то не так ее строили".
Если вы утверждаете, что "черные лебеди" прилетают и ломают модели, то очень хочется увидеть что были за события и насколько поломались модели.
Более того, уверен, что предсказать заранее влияние ковида или СВО на продажи за адекватное время невозможно. Однако, как вы и делаете сейчас, можно же поделить время на срезы до и после событий такого рода и также рассчитывать прогнозы отдельнотдля каждого периода.
На фоне того как ствтья погружает в проблему поиска решения, результат в виде линейной регрессии на коротких промежутках времени выглядит как Ока на фоне Lamborghini.
Очевидно, что любая функция аппроксимируется линейной и чем меньше промежуток, тем лучше будет работать линейное приближение.
Как заинтересованный читатель я бы очень хотел увидеть в следующих статьях показатели мер связи между предикатами, которые вы использовали и таргетом и ответ на вопрос почему линейная регрессия на коротких промежутках лучше, чем все остальное. И хотелось бы увидеть как подбирали регрессию для сушествующего решения
Нейронки все же учитывают словоформы и синонимы. Так как не все синонимы на 100% схожи по смыслу. Более того они учитывают контекст, то есть несколько смыслов для одного слова.
Смысл в том, что с вектор отражает смысл текста и можно из вектора получить обратно текст. Текст будет похож на исходный.
Очевидно, что с sha256 такое не сделать.
Можно текст вообще в одно число закодировать, только коллизий много будет. Смысл не только в сжатии, а в возможности работать с этой сжатой информацией.
Я бы сказал, что исследователи изучали наименьшую возможную размерность пространства смыслов в которое можно вложить текст