Я правильно понимаю, что по аналогии с проверкой совместимости типа с интерфейсом _ = slice[i] проверяет границы массива на этапе компиляции, а в рантайме эта операция опускается для всех обращений по этому индексу? Объясните, пожалуйста
Задумывался об этом года два назад. LLM ведь пословно формулирует ответ на основании запроса? И таким образом, чтобы ответ "соответствовал" запросу? А это "соответствие" задаётся человеком через публикацию информации в свободном виде. Если результат модели отклоняется от действительного, то нарушается и соответствие. Обучение на x + delta даст x + delta + delta.
Что меня смущает: 1) Объём данных для обучения очень велик. Из-за этого влияние слопа на обучение самой модели должно быть невелико. Или его сложно отследить 2) Даже данные от самих людей не могут быть истиной в 100% случаев 3) Характер отклонений вносимых человек при передаче данных и при генерации сеткой может быть разный 4) У модели может быть механизм "выбора достоверного варианта", который позволяет уменьшить влияние энтропии исходных данных на вывод модели. Подразумеваю выбор наиболее близкого в первоисточнику варианта 5) x + delta может больше нравится пользователям, чем чистый x (продолжая мысль из статьи)
Про третий пункт. Даже изменяя информацию при передаче, человек старается сохранить в ней здравый смысл, а модель его лишена и не может оценивать свой ответ по такому критерию. За счёт первого и четвёртого пункта, который можно назвать сомнительным, вырождаемость информации сложно проверить в реальных условиях за короткий срок. А если в долгий, то в качестве превентивных мер датасеты будут проверяться на наличие слопа (привет курсовые и дипломы). Плюс адаптация моделей к работе с искажёнными данными за счёт историчности.
Но это всё моё бытовое понимание. Буду рад быть неправым
Чем длиннее комбинация инпутов, тем выше соблазн записать её на отдельную клавишу. А если необходимо нажимать в определённом порядке несколько подобных комбинаций, то идея "выселения" на отдельный борд становится разумной. Разобравшись с контроллером, можно настроить разный набор сочетаний для каждого отдельного приложения.
Сценарии: 1. Управление стримом: переключение сцен, отключение и включение микрофона, свет; (StreamDeck дорого, но людям нравится) 2. Приложения для монтажа видео, 3D-моделирования. Любое с широким набором сложных действий; 3. Контроль мультимедиа: пауза, воспроизведение, регулировка громкости (надо добавить крутилку), субтитры, выбор аудиодорожки. 4. Интеграция с другими устройствами: запуск робота-пылесоса, увлажнителя воздуха и другого устройства с небольшим набором режимов работы (стиралка не подойдёт). Была на хабре статья про "ON AIR" знак, который включался при входе в тимспик, но можно и кнопкой.
Экономической целесообразности я тоже не вижу. Скорее тут "я хочу понять, как оно устроено, сделав всё сам". С этой точки зрения статья хорошая. Успешная реализация за короткий промежуток времени с небольшой стоимостью (Забываем про заказ корпуса).
А вот сплит клавы уже гораздо интереснее. Много кастома. На хабре тоже есть. Буду рад увидеть вариант от автора.
У windows не получилось нормально обработать одинарные кавычки. Поэтому POST-запрос надо делать через Git Bash или в двойных кавычках: curl http://localhost:8080/albums --include --header "Content-Type: application/json" --request "POST" --data "{""id"": ""4"",""title"": ""The Modern Sound of Betty Carter"",""artist"": ""Betty Carter"",""price"": 49.99}"
Соревновательная модель получается, если я не ошибаюсь. Чем больше асимметрия, тем больше ходов.
Я думал об устранении асимметричности путём удаления k вхождений результатов с большей вероятностью. Пусть p=2/3, а q=1/3. Кидаем монетку три раза и удаляем одного орла, если он есть. Считаем процентное соотношение. У кого больше, тот и победил.
Я правильно понимаю, что по аналогии с проверкой совместимости типа с интерфейсом _ = slice[i] проверяет границы массива на этапе компиляции, а в рантайме эта операция опускается для всех обращений по этому индексу? Объясните, пожалуйста
Задумывался об этом года два назад. LLM ведь пословно формулирует ответ на основании запроса? И таким образом, чтобы ответ "соответствовал" запросу? А это "соответствие" задаётся человеком через публикацию информации в свободном виде. Если результат модели отклоняется от действительного, то нарушается и соответствие. Обучение на x + delta даст x + delta + delta.
Что меня смущает:
1) Объём данных для обучения очень велик. Из-за этого влияние слопа на обучение самой модели должно быть невелико. Или его сложно отследить
2) Даже данные от самих людей не могут быть истиной в 100% случаев
3) Характер отклонений вносимых человек при передаче данных и при генерации сеткой может быть разный
4) У модели может быть механизм "выбора достоверного варианта", который позволяет уменьшить влияние энтропии исходных данных на вывод модели. Подразумеваю выбор наиболее близкого в первоисточнику варианта
5) x + delta может больше нравится пользователям, чем чистый x (продолжая мысль из статьи)
Про третий пункт. Даже изменяя информацию при передаче, человек старается сохранить в ней здравый смысл, а модель его лишена и не может оценивать свой ответ по такому критерию. За счёт первого и четвёртого пункта, который можно назвать сомнительным, вырождаемость информации сложно проверить в реальных условиях за короткий срок. А если в долгий, то в качестве превентивных мер датасеты будут проверяться на наличие слопа (привет курсовые и дипломы). Плюс адаптация моделей к работе с искажёнными данными за счёт историчности.
Но это всё моё бытовое понимание. Буду рад быть неправым
Чем длиннее комбинация инпутов, тем выше соблазн записать её на отдельную клавишу. А если необходимо нажимать в определённом порядке несколько подобных комбинаций, то идея "выселения" на отдельный борд становится разумной. Разобравшись с контроллером, можно настроить разный набор сочетаний для каждого отдельного приложения.
Сценарии:
1. Управление стримом: переключение сцен, отключение и включение микрофона, свет; (StreamDeck дорого, но людям нравится)
2. Приложения для монтажа видео, 3D-моделирования. Любое с широким набором сложных действий;
3. Контроль мультимедиа: пауза, воспроизведение, регулировка громкости (надо добавить крутилку), субтитры, выбор аудиодорожки.
4. Интеграция с другими устройствами: запуск робота-пылесоса, увлажнителя воздуха и другого устройства с небольшим набором режимов работы (стиралка не подойдёт). Была на хабре статья про "ON AIR" знак, который включался при входе в тимспик, но можно и кнопкой.
Экономической целесообразности я тоже не вижу. Скорее тут "я хочу понять, как оно устроено, сделав всё сам". С этой точки зрения статья хорошая. Успешная реализация за короткий промежуток времени с небольшой стоимостью (Забываем про заказ корпуса).
А вот сплит клавы уже гораздо интереснее. Много кастома. На хабре тоже есть. Буду рад увидеть вариант от автора.
У windows не получилось нормально обработать одинарные кавычки. Поэтому POST-запрос надо делать через Git Bash или в двойных кавычках:
curl http://localhost:8080/albums --include --header "Content-Type: application/json" --request "POST" --data "{""id"": ""4"",""title"": ""The Modern Sound of Betty Carter"",""artist"": ""Betty Carter"",""price"": 49.99}"
Соревновательная модель получается, если я не ошибаюсь. Чем больше асимметрия, тем больше ходов.
Я думал об устранении асимметричности путём удаления k вхождений результатов с большей вероятностью. Пусть p=2/3, а q=1/3. Кидаем монетку три раза и удаляем одного орла, если он есть. Считаем процентное соотношение. У кого больше, тот и победил.
и ложное воспоминание о бабках с 11-го этажа