Конкретное хорошее соотношение кода и тестов очень сильно зависит от области, обычно это чет типа интуиции, которая постепенно вырабатывается, и 1 к 5 - это моя личная интуиция, ниже этих цифр по моему опыту код был явно ненадежным и часто стрелял. Возможно, для около-математического кода она была бы немного иной. В этой области вообще нет четких ответов, многое до сих пор опирается на интуитивные суждения.
Метрики типа покрытия (кстати, настоятельно рекомендую помимо обычного покрытия считать также покрытие "по бранчам", т.е. с автоматической проверкой, что обе ветки любого условия были протестированы) хороши только в качестве нижней планки. Лично у меня для библиотек включен трэшхолд в 100% покрытия по строкам и бранчам, на 99% и ниже просто CI не пройдет. Но это именно нижняя планка, 100% легко достичь, ничего на самом деле не протестировав, поэтому приходится иметь дополнительные интуиции, указывающие на возможные проблемы.
Из более интересных метрик могу посоветовать попробовать мутационное тестирование, возможно вам зайдет, раз вы интересуетесь эволюционными алгоритмами :) Возможно, получится разово словить какие-то инсайты от запуска mutmut, хотя готового прям к повседневному исследованию тулинга в этой области для Python пока нет (но я прямо сейчас работаю над этим). В целом это полезная штука, когда покрытие уже 100%, и все очевидные идеи, что можно протестировать, уже исчерпаны.
13 000 строк Python, из которых большая часть — основной функционал, а четверть — тесты
Это ужасное соотношение, библиотеку вряд ли можно назвать протестированной. Обычно хорошее соотношение кода к тестам начинается где-то от 1 к 5, т.е. в данном случае нужно примерно в 20 раз больше тестов.
У нейросетей нет кнопочек. Вы использовали какое-то странное приложение для инференса, прибитое гвоздями, как я понял, к какой-то модели. Используйте другое приложение для выбранной модели.
В начале войны я был более оптимистичен. Я предполагал, что будут проблемы с поставками железа, и думал, что это мотивирует вкладываться в бережливую разработку, спровоцирует интерес к более вычислительно эффективным системам/алгоритмам/языкам, повысит культуру перфоманса и качества ПО, побудит к хитрым оптимизациям вроде той, где дипсик в умудрился в 10 раз удешевить инференс на видеокартах. То есть я думал, что мы закроем дефицит железа интеллектом. По факту кое-где сейчас это и правда так, но, кажется, основной эффект противоположный: компании стали экономить на разработчиках, а продолжающие расти расходы перекладываются на потребителя, разгоняя инфляцию.
А где технические подробности? Что улетает в контекст для LLMки, используются ли RAGи, и если да, то как для них нарезается исходный код? Как подбирались промпты, и какие они сейчас? Есть ли ограничения по языкам программирования?
Локальный запуск LLM для ревью прямо внутри раннера гитхаба — мечта.
А где технические детали решения? Где там какие RAGи под капотом, что подавали в контекст нейронке, какую нейронку выбрали и через какого провайдера подключали (а может на локальной все собрали?), какие промпты использовали? Почему не использовали одно из готовых решений?
Идея с формальными грамматиками будто бы не про решение проблемы некорректных ответов ИИ, а про ее сужение. Т.е. из исходного множества возможных неправильных ответов мы убираем те, что не верны по форме, и оставляем только те, которые верны по форме, но не верны по сути. Для полного решения проблемы у нас по идее должен быть еще один механизм, который как-то отберет из множества верных по форме ответов те, которые верны еще и по сути, но это уже следующий шаг.
Интересно, как Маск так хорошо знает русский, хотя и не удивительно, он же строил ракеты по русским учебникам. Но вот что он на хабре находит время сидеть— шокирует.
Да, есть некоторые обобщения, которые не сбылись (то, что они на кратно больших масштабах, неважно). Почему делается вывод, что любые экстраполяции не имеют смысла?
По сути принятие жизненных решений основывается на алгоритмах поиска пути. С наивными индивидуальными алгоритмами такого рода есть одна проблема: они не учитывают поведение других акторов.
Если мы посчитали оптимальный маршрут через город для одного автомобилиста, он скорее всего проедет через город быстрее, чем если бы ориентировался сам. Но если мы прогнали тот же алгоритм для всех участников движения, они попадают в пробку, т.к. кратчайший путь имеет ограниченную пропускную способность и не вмещает всех желающих.
Для решения проблемы есть отдельный класс алгоритмов — алгоритмы поиска максимального потока, а не кратчайших путей. В переложении на образование, потоко-подобные алгоритмы должны обязательно учитывать такие факторы, как например емкость рынка. Ваш наивный подход с подсчетом разницы между будущими доходами и процентами по кредиту основан на понятии дохода как некоей стабильной величины. Но если завтра на основании вашего алгоритма выдачи кредитов мы начнем продуцировать на миллион человек инженеров в год больше, рынок скорее всего среагирует соответственно: предложение инженеров на рынке выросло — надо снижать цены, то есть доход этих самых инженеров.
Одной только емкости рынка для адекватного анализа тоже будет не вполне достаточно. Как минимум надо учитывать еще пропускную способность самого универа. Может случиться так, что чтобы подготовить больше инженеров, у нас просто недостаточно преподавательского состава. Преподавательский состав тоже нужно готовить, а это уже задача второго рода, и снова мы сталкиваемся с самореференцией, которую достаточно сложно спрогнозировать. На деле таких самореференций намного больше.
Куда уж базированнее то?
По Numba-коду тоже можно считать покрытие.
Конкретное хорошее соотношение кода и тестов очень сильно зависит от области, обычно это чет типа интуиции, которая постепенно вырабатывается, и 1 к 5 - это моя личная интуиция, ниже этих цифр по моему опыту код был явно ненадежным и часто стрелял. Возможно, для около-математического кода она была бы немного иной. В этой области вообще нет четких ответов, многое до сих пор опирается на интуитивные суждения.
Метрики типа покрытия (кстати, настоятельно рекомендую помимо обычного покрытия считать также покрытие "по бранчам", т.е. с автоматической проверкой, что обе ветки любого условия были протестированы) хороши только в качестве нижней планки. Лично у меня для библиотек включен трэшхолд в 100% покрытия по строкам и бранчам, на 99% и ниже просто CI не пройдет. Но это именно нижняя планка, 100% легко достичь, ничего на самом деле не протестировав, поэтому приходится иметь дополнительные интуиции, указывающие на возможные проблемы.
Из более интересных метрик могу посоветовать попробовать мутационное тестирование, возможно вам зайдет, раз вы интересуетесь эволюционными алгоритмами :) Возможно, получится разово словить какие-то инсайты от запуска mutmut, хотя готового прям к повседневному исследованию тулинга в этой области для Python пока нет (но я прямо сейчас работаю над этим). В целом это полезная штука, когда покрытие уже 100%, и все очевидные идеи, что можно протестировать, уже исчерпаны.
Удачи с проектом!
Это ужасное соотношение, библиотеку вряд ли можно назвать протестированной. Обычно хорошее соотношение кода к тестам начинается где-то от 1 к 5, т.е. в данном случае нужно примерно в 20 раз больше тестов.
У нейросетей нет кнопочек. Вы использовали какое-то странное приложение для инференса, прибитое гвоздями, как я понял, к какой-то модели. Используйте другое приложение для выбранной модели.
Большинство сегодня пишет на мультипарадигменных языках, где подобной дихотомии просто нет.
В начале войны я был более оптимистичен. Я предполагал, что будут проблемы с поставками железа, и думал, что это мотивирует вкладываться в бережливую разработку, спровоцирует интерес к более вычислительно эффективным системам/алгоритмам/языкам, повысит культуру перфоманса и качества ПО, побудит к хитрым оптимизациям вроде той, где дипсик в умудрился в 10 раз удешевить инференс на видеокартах. То есть я думал, что мы закроем дефицит железа интеллектом. По факту кое-где сейчас это и правда так, но, кажется, основной эффект противоположный: компании стали экономить на разработчиках, а продолжающие расти расходы перекладываются на потребителя, разгоняя инфляцию.
А где технические подробности? Что улетает в контекст для LLMки, используются ли RAGи, и если да, то как для них нарезается исходный код? Как подбирались промпты, и какие они сейчас? Есть ли ограничения по языкам программирования?
Локальный запуск LLM для ревью прямо внутри раннера гитхаба — мечта.
А где технические детали решения? Где там какие RAGи под капотом, что подавали в контекст нейронке, какую нейронку выбрали и через какого провайдера подключали (а может на локальной все собрали?), какие промпты использовали? Почему не использовали одно из готовых решений?
Будто бы из разработчиков вряд ли кого-то интересуют виндо-проблемы, а сам редактор на сегодня топовый.
А где Zed?
В ЧБ варианте выглядело свежо, раскрасили зря.
Проблема в том, что "мясные" хирурги так и работают, это такая же стохастика.
Идея с формальными грамматиками будто бы не про решение проблемы некорректных ответов ИИ, а про ее сужение. Т.е. из исходного множества возможных неправильных ответов мы убираем те, что не верны по форме, и оставляем только те, которые верны по форме, но не верны по сути. Для полного решения проблемы у нас по идее должен быть еще один механизм, который как-то отберет из множества верных по форме ответов те, которые верны еще и по сути, но это уже следующий шаг.
Ну как минимум тот же гитхаб умеет показывать статистику по проекту, какой в нем процент каких ЯПов.
А на Python такие тесты можно писать?
Зачем писать зависимости в readme, если для этого есть requirements.txt, lock-файлы etc.?
Интересно, как Маск так хорошо знает русский, хотя и не удивительно, он же строил ракеты по русским учебникам. Но вот что он на хабре находит время сидеть— шокирует.
Мне кажется, или 50 процессоров — как-то мало для суперкомпьютера? В то время суперкомпьютеры были меньше?
По сути принятие жизненных решений основывается на алгоритмах поиска пути. С наивными индивидуальными алгоритмами такого рода есть одна проблема: они не учитывают поведение других акторов.
Если мы посчитали оптимальный маршрут через город для одного автомобилиста, он скорее всего проедет через город быстрее, чем если бы ориентировался сам. Но если мы прогнали тот же алгоритм для всех участников движения, они попадают в пробку, т.к. кратчайший путь имеет ограниченную пропускную способность и не вмещает всех желающих.
Для решения проблемы есть отдельный класс алгоритмов — алгоритмы поиска максимального потока, а не кратчайших путей. В переложении на образование, потоко-подобные алгоритмы должны обязательно учитывать такие факторы, как например емкость рынка. Ваш наивный подход с подсчетом разницы между будущими доходами и процентами по кредиту основан на понятии дохода как некоей стабильной величины. Но если завтра на основании вашего алгоритма выдачи кредитов мы начнем продуцировать на миллион человек инженеров в год больше, рынок скорее всего среагирует соответственно: предложение инженеров на рынке выросло — надо снижать цены, то есть доход этих самых инженеров.
Одной только емкости рынка для адекватного анализа тоже будет не вполне достаточно. Как минимум надо учитывать еще пропускную способность самого универа. Может случиться так, что чтобы подготовить больше инженеров, у нас просто недостаточно преподавательского состава. Преподавательский состав тоже нужно готовить, а это уже задача второго рода, и снова мы сталкиваемся с самореференцией, которую достаточно сложно спрогнозировать. На деле таких самореференций намного больше.
Оффтоп, но можете про речь животных побольше рассказать? Откуда берете сэмплы и их сопоставления со значениями, например.