Идея с формальными грамматиками будто бы не про решение проблемы некорректных ответов ИИ, а про ее сужение. Т.е. из исходного множества возможных неправильных ответов мы убираем те, что не верны по форме, и оставляем только те, которые верны по форме, но не верны по сути. Для полного решения проблемы у нас по идее должен быть еще один механизм, который как-то отберет из множества верных по форме ответов те, которые верны еще и по сути, но это уже следующий шаг.
Интересно, как Маск так хорошо знает русский, хотя и не удивительно, он же строил ракеты по русским учебникам. Но вот что он на хабре находит время сидеть— шокирует.
Да, есть некоторые обобщения, которые не сбылись (то, что они на кратно больших масштабах, неважно). Почему делается вывод, что любые экстраполяции не имеют смысла?
По сути принятие жизненных решений основывается на алгоритмах поиска пути. С наивными индивидуальными алгоритмами такого рода есть одна проблема: они не учитывают поведение других акторов.
Если мы посчитали оптимальный маршрут через город для одного автомобилиста, он скорее всего проедет через город быстрее, чем если бы ориентировался сам. Но если мы прогнали тот же алгоритм для всех участников движения, они попадают в пробку, т.к. кратчайший путь имеет ограниченную пропускную способность и не вмещает всех желающих.
Для решения проблемы есть отдельный класс алгоритмов — алгоритмы поиска максимального потока, а не кратчайших путей. В переложении на образование, потоко-подобные алгоритмы должны обязательно учитывать такие факторы, как например емкость рынка. Ваш наивный подход с подсчетом разницы между будущими доходами и процентами по кредиту основан на понятии дохода как некоей стабильной величины. Но если завтра на основании вашего алгоритма выдачи кредитов мы начнем продуцировать на миллион человек инженеров в год больше, рынок скорее всего среагирует соответственно: предложение инженеров на рынке выросло — надо снижать цены, то есть доход этих самых инженеров.
Одной только емкости рынка для адекватного анализа тоже будет не вполне достаточно. Как минимум надо учитывать еще пропускную способность самого универа. Может случиться так, что чтобы подготовить больше инженеров, у нас просто недостаточно преподавательского состава. Преподавательский состав тоже нужно готовить, а это уже задача второго рода, и снова мы сталкиваемся с самореференцией, которую достаточно сложно спрогнозировать. На деле таких самореференций намного больше.
Недавно взял Meizu 21 Note, он внезапно оказался отличным, лучшим телефоном из тех, что у меня были. Минуса 2: в РФ не оч стабильная связь, связано с недостатком бендов — гаджет не предназначался для РФ; камера не оч.
С программистами все тоже пугающе плохо. Где-то читал исследование, что средний IQ программиста в России - 108 баллов. Когда я в должной мере осознал этот факт, у меня очень многие вещи встали на свои места. У ПОЛОВИНЫ программистов IQ где-то ниже 108. Многие концепции в программировании просто не доступны большинству программистов.
Довольно часто на стадии "разбираться и фиксить" есть возможность разбить исходную гипотезу на гипотезы поменьше, сформулировать их в новых тестах, и таким образом найти причину проблемы.
А как насчет "дебага тестами"? Лично я при наличии возможности стараюсь прибегать именно к нему.
Его суть сводится к тому, чтобы формулировать гипотезы о правильной работе кода в виде тестов. Когда тест падает — разбираться и фиксить. Киллер-фича этого подхода состоит в том, что после отладки остается куча артефактов в виде тестов, которые повысят надежность разработки в будущем.
Идея с формальными грамматиками будто бы не про решение проблемы некорректных ответов ИИ, а про ее сужение. Т.е. из исходного множества возможных неправильных ответов мы убираем те, что не верны по форме, и оставляем только те, которые верны по форме, но не верны по сути. Для полного решения проблемы у нас по идее должен быть еще один механизм, который как-то отберет из множества верных по форме ответов те, которые верны еще и по сути, но это уже следующий шаг.
Ну как минимум тот же гитхаб умеет показывать статистику по проекту, какой в нем процент каких ЯПов.
А на Python такие тесты можно писать?
Зачем писать зависимости в readme, если для этого есть requirements.txt, lock-файлы etc.?
Интересно, как Маск так хорошо знает русский, хотя и не удивительно, он же строил ракеты по русским учебникам. Но вот что он на хабре находит время сидеть— шокирует.
Мне кажется, или 50 процессоров — как-то мало для суперкомпьютера? В то время суперкомпьютеры были меньше?
По сути принятие жизненных решений основывается на алгоритмах поиска пути. С наивными индивидуальными алгоритмами такого рода есть одна проблема: они не учитывают поведение других акторов.
Если мы посчитали оптимальный маршрут через город для одного автомобилиста, он скорее всего проедет через город быстрее, чем если бы ориентировался сам. Но если мы прогнали тот же алгоритм для всех участников движения, они попадают в пробку, т.к. кратчайший путь имеет ограниченную пропускную способность и не вмещает всех желающих.
Для решения проблемы есть отдельный класс алгоритмов — алгоритмы поиска максимального потока, а не кратчайших путей. В переложении на образование, потоко-подобные алгоритмы должны обязательно учитывать такие факторы, как например емкость рынка. Ваш наивный подход с подсчетом разницы между будущими доходами и процентами по кредиту основан на понятии дохода как некоей стабильной величины. Но если завтра на основании вашего алгоритма выдачи кредитов мы начнем продуцировать на миллион человек инженеров в год больше, рынок скорее всего среагирует соответственно: предложение инженеров на рынке выросло — надо снижать цены, то есть доход этих самых инженеров.
Одной только емкости рынка для адекватного анализа тоже будет не вполне достаточно. Как минимум надо учитывать еще пропускную способность самого универа. Может случиться так, что чтобы подготовить больше инженеров, у нас просто недостаточно преподавательского состава. Преподавательский состав тоже нужно готовить, а это уже задача второго рода, и снова мы сталкиваемся с самореференцией, которую достаточно сложно спрогнозировать. На деле таких самореференций намного больше.
Оффтоп, но можете про речь животных побольше рассказать? Откуда берете сэмплы и их сопоставления со значениями, например.
Серьезно, микро ОГРОМНАЯ лингвистическая модель?
А это по итогу дало какую-то выгоду? Накручено много ложной машинерии — это точно проще, чем иметь несколько варинтов SVG?
Недавно взял Meizu 21 Note, он внезапно оказался отличным, лучшим телефоном из тех, что у меня были. Минуса 2: в РФ не оч стабильная связь, связано с недостатком бендов — гаджет не предназначался для РФ; камера не оч.
По последнему вопросу. Дело тут не в том, что придется начинать заново, а в том, что при этом у вас на диске остается лежать паразитный файл.
Можно ли было метакласс заменить на дескрипторы? И зачем прибивать гвоздями сторонний логгер?
Очень интересно было бы почитать про уход в айтишный менеджмент, минуя позицию тимлида.
А выводы-то какие по итогу? Да, автор познал некоторые базовые идеи под капотом у баз данных, я правда рад за него, но в чем тут ценность для меня?
С программистами все тоже пугающе плохо. Где-то читал исследование, что средний IQ программиста в России - 108 баллов. Когда я в должной мере осознал этот факт, у меня очень многие вещи встали на свои места. У ПОЛОВИНЫ программистов IQ где-то ниже 108. Многие концепции в программировании просто не доступны большинству программистов.
Довольно часто на стадии "разбираться и фиксить" есть возможность разбить исходную гипотезу на гипотезы поменьше, сформулировать их в новых тестах, и таким образом найти причину проблемы.
А как насчет "дебага тестами"? Лично я при наличии возможности стараюсь прибегать именно к нему.
Его суть сводится к тому, чтобы формулировать гипотезы о правильной работе кода в виде тестов. Когда тест падает — разбираться и фиксить. Киллер-фича этого подхода состоит в том, что после отладки остается куча артефактов в виде тестов, которые повысят надежность разработки в будущем.
Cut the prose, please.
Возможно, это так только на силиконовых маках, но лично у меня Inkscape постоянно глючит и вылетает.