После того, как всякие такие навайбкодят, когда всё начнёт ломаться и трещать по швам, а починить они не смогут сами, настоящие нормальные программисты станут на порядки ценнее. Просто подождём.
Пик численных методов и математики тоже близок? В ИИ важнее не фреймворки и архитектура, а как просто матрицы множить численно устойчиво и быстро. Не надо называть численную оптимизацию сознанием просто. Её пика не предвидится, а пик хайпа на нейронках случится, как придёт новое, как нейро- заменило нано-.
Я и удивился перечислению numpy. А blas и lapack даже скорее фортрановские, больше f77. Но там не прям всё распараллелено, например, стандартный gemm нет. Можете убедиться в исходниках))
Расскажите, как это можно непосредственно применить для ускорения numpy, раз он стал потокобезопасен? И коснулся ли threading используемых blas и lapack? С какими сложностями пришлось столкнуться для numpy, scipy, pyarrow?
А с какого момента "чувак, который освоил ИИ" стало значить того, кто генерирует код нейронками, а не того, кто понимает ML, матан, линейную алгебру, численные методы и в состоянии реализовать многое с нуля, потому что понимает? Кажется, произошла подмена программиста пользователем.
Мне кажется, многое на деле проще. Под конкретную задачу выбор инструмента обычно легче сделать из логики проекта, а популярность инструментов тут неважна.
Если проект учебный, чтобы научиться чем-то пользователься, то выбор уже сделан. Если чтобы научиться что-то сделать (а не чем-то), то выбор сделан и состоит в том, чтобы попробовать разное и сравнить (в том числе под что способы ищутся легче).
Если речь о выборе чего-то для самого начала обучения, величина проблемы тоже преувеличена. Во-первых, необязательно выбирать что-то, что точно пригодится. У меня в школе был BASIC, но я не сокрушаюсь о "бесцельно потраченных годах". Если тревожно искать вариант, который явно пригодится, то (как мне кажется) ещё долго будет надёжно как скриптовый выбирать Python, как более мощный чистый C (с учётом C API как универсальной связки разных инструментов между собой). Хотя надеяться изучить всё за минимум времени и не потратить лишней минуты зря уже ошибка, без готовности тратить много времени хорошо программирование не учится. Для изучения самых основ конкретный язык не так важен. После основ C и Python понимать стоит ну большинству. А дальше выбор более конкретных инструментов и выбор языка очень связаны. Тодга лучше выбирать, что хочется делать [новичку] на будущем месте работы, а не при помощи чего.
Общие рейтинги ЯП вообще штука заранее сомнительная, предвзятая и неоднозначная. А если делать их менее общими и специализировать под интересующую область, то рейтинги становятся неинтересными и рассыпаются, всё становится нередко "и так понятно", и рейтинг на практике бесполезен, вещь в себе.
Сначала и во-первых это красиво, учит правильным привычкам и любопытная головоломка. Но потом и во-вторых продолжать конкретные инструменты именно под Haskell оказывается надо очень редко, вакансии довольно редки, а также проблематично прототипировать, дебажить и оптимизировать, связь исходного кода и ассемблера тут ну очень непрозрачна. А делать производительные части условно на C/C++/Fortran, чтобы использовать Haskell как фронтенд вместо питона ну как-то overkill (и претит любителым чистых функций без unsafe, что часто среди ярых хаскелистов), тем более что потенциальных пользователей окажется тогда очень мало (а если делать под питон, то его условно "знают все" или по крайней мере, смогут воспользоваться), встречал такой пример, как hasktorch, который вроде забросили. Так что для любознательности и кругозора Haskell — это прекрасно и полезно, но чаще для души, чем для работы. А поскольку язык общего назначения, задач, под которые Haskell был бы идеально заточен, чтобы где-то сказать, что вот тут точно надо делать именно на нём, я не встречал.
Если апатия приводит в python, а безысходность в js, то конструктивный поиск приводит к Rust или порой к Go. Ещё бывает, что долг возвращает к C++ или Fortran.
А удаётся ли генерировать годные задачи? С решениями понятно, а вот для составления красивых задач это может быть любопытнее даже, чем с их же решением.
У специалистов слово "понимание" размывается, а у неспециалистов неверно используется. Про мелкие паттерны и свёрточные слои внутри слышали не все, но все слышат, что оно "понимает смысл", потому что это озвучивают на каждом углу так громко, что даже часть специалистов уже сомневается. Слова в естественном понимании и термины путать не стоит. Если с обучением ок, обязательное добавление слова "машинное" позволяет избежать проблем, то уже со словом "интеллект" всё очень спорно. А "машинного понимания" и "искусственного схватывания смысла" как терминов не существует, и вводить это не надо. Просто говорить тут про понимание вообще неуместно, это не термин.
Я бы больше боялся не появления злой воли у нейронок, а как раз приписывания нейронкам понимания, осознания, воли и прочего человеческого, к тому же, на широкую аудиторию. В итоге широкая аудитория верит и очеловечивает алгоритмы численной оптимизации, постепенно начнёт передавать ответственность за решения нейронкам. А в случае катастрофических последствий говорить, что интеллект стал слишком умный и вышел из-под контроля, хотя это просто функция с параметрами. Опасны не продвинутые алгоритмы, а такие упрощения для массовой аудитории.
"Это был первый переводчик, который действительно понимал контекст и схватывал смысл целиком"? Вы сами в это верите? О "понимании смысла" и у современных нейронок речь не идёт вообще. Вы путаете численную оптимизацию (что реально есть) и искусственное сознание (что не просто не сделано, а даже не определено чётко).
Простейший нетривиальный вариант, как всегда, LeNet на MNIST. Или пусть даже полносвязную нейронку в несколько слоёв на том же датасете (или тогда уж на чём попало), потому что известно, что MLP на MNIST тоже учится, пусть и не очень хорошо.
Можно при выводе массивов смотреть на массив xf64array (неточное будет помечено вопросиками), а также на вывод отдельно значений (поле values массива типа xf64array) и количества точных битов (поле exact_bits). Единственное, что это всё-таки расширение numpy, а не torch, так что исходную модель надо брать, где вычисление градиентов дополнительно реализуется, но такое в открытом доступе найти несложно, особенно, для чего-то простейшего типа MLP. Только надо поменять импорты numpy на xnumpy, и в большинстве случаев этого будет достаточно. И входные данные при конвертации в xf64array неплохо бы снабдить их естественной погрешностью. Например, если значения пикселей целые от 0 до 255, мы делим это на 256 для получения float, то логично предположить, что там вряд ли более 8 точных битов, а то и меньше, потому что это относительная погрешность.
Если выводить только values, то вывод будет, как если бы считалось на numpy, значения могут только чуть-чуть отличаться, если зависимые версии glibc, blas и прочие чуть-чуть поменялись, но это несущественные и крайне редкие изменения. Разница не в величине ошибки numpy и xnumpy, а в том, что в xnumpy величину ошибки мы знаем, а в numpy не имеем инструмента измерения ошибки вычислений, принимаем их как есть. Ошибки и какая-то мера их накопления неизбежны, а так можно эту величину увидеть без больших усилий заменой импорта. Поиграв с реализацией алгоритма, можно посмотреть, какие варианты надёжнее. И хотя выбор всё равно за лучшей целевой метрикой, из вариантов выбора важно исключить те, которым нельзя верить, зная величину их численной ошибки.
Это очень сильно замедлило бы. Да, есть boost/intervals, но для начала память увеличивается вдвое (а в xnumpy плюс байт на значение с плавающей точкой). И сами алгоритмы от классической теории погрешностей утяжеляют сильно. Здесь вместо этого используется число обусловленности для дифференцируемых функций, overhead получается вообще небольшой вместо минимум удвоения только на памяти и куда более тяжких алгоритмах. А для всяких округлений функции переписываются из glibc, чтобы не проходить два раза те же ветвления. Плюс к тому, особо важные функции типа матричного умножения (из blas/cublas/mkl) очень эффективны, но вроде не реализованы мощно для интервальной арифметики, вручную сделать настолько же эффективно и надёжно огромная проблема, а это нередко самые тяжеловесные операции. А оценки точностей в точных битах сводят всё к тем же матричным операциям с использованием тех же очень сильно оптимизированных библиотек при помощи оценки тропического произведения целочисленных матриц. Подход с точными битами потому и выбран, что иначе либо пользоваться станет невозможно, либо переписывать огромный тяжеловесный код, который десятки лет оптимизировали, это надо использовать, а не отказываться и переделывать с нуля. Матричные умножения с оценкой точных битов могут становиться тяжелее в разы, а если пытаться наивно посчитать точность интервалами, то медленнее станет в тысячи раз, что неприменимо на практике. С тригонометрией интервалы минимум удваивают стоимость вычислений, а в подходе с точными битам через число обусловленность получается overhead в процентах (например, на exp +21%, на log10 +9% по последнему бенчмарку, тогда как для intervals подсчёт для концов интервала и дополнительные проверки дадут сходу >100% overhead). Плюс к тому, для оценки точности мантиссы в битах часто вместо дополнительных операций с плавающей точкой используется целочисленная арифметика и работа с битовыми масками согласно представлению floating point в памяти, что тоже позволяет сделать ряд оптимизаций (как для арифметики, округлений). Но если добавить к увеличению времени ещё требование сокращать батч вдвое, то для нейронок на трансфере данных до gpu и обратно станет тратиться ещё большее время, так что выгоднее пользоваться оценкой точных битов вместо классических погрешностей очень сильно, а насколько именно, сильно зависит от железа и конкретных нейронок.
Тема предиктивной криминалистики начала появляться сильно до нынешней эры недетерминированных blackbox-алгоритмов. Даже во время классического ML была масса вопросов, правда, атрибутированных больше правовой системе США с её нюансами, чем нашей. Примеры сложностей (что-то из то ли книги, то ли статьи про PredPol, что-то добавил):
Если не балансировать данные, то одни этнические или прочие группы будут подозреваться ИИ чаще других.
Если балансировать, это делает целенаправленно одних более виноватыми, чем других.
Если делать централизованную систему, то правоприменительная практика будет отличаться от средней в отдельном штате, проблема.
Если учитывать особенности и законы отдельных штатов, то система сможет считать одного и того же человека виноватым или нет в зависимости от места преступления, тоже так себе.
Если системе не давать данные условно о расе и этнической принадлежности преступника, тем самым обосновав её якобы непредвзятость, то внутренние корреляции могут неявно "вычислить" этническую принадлежность через proxy-параметры (например, уровень дохода, образования и проживание в "чёрном" районе) и тем самым могут оказаться якобы очищенным от предвзятости обоснованием расизма со стороны правоохранительных органов, а подозрений в обоснованном скрытом проявлении расизма стремились избежать больше всего.
Если пытаться лишить алгоритм аугментацией данных возможности учитывать любые внутренние скрытые корреляции с этническими и расовыми группами (и прочими, чтобы осталась только социальная группа преступников), то алгоритм остаётся при минимуме параметров и практически теряет смысл и предсказательную силу. Вообще преступники не так сильно отличаются какими-то неочевидными признаками, иначе бы работа криминалистов не была такой сложной.
Наконец, если в прецедентном праве что-то изменится от очередного прецедента, как алгоритм начнёт это применять и когда? Алгоритмы машинного обучения с учителем не очень приспособлены для "прецедентного обучения", ну я такого по крайней мере не встречал, и существующие модели на базе нейронок подружить с этим может быть очень непросто, вопросов становится больше, чем ответов.
И плюс вопрос, кто несёт ответственность за признанное ошибочкным решение на основе ИИ? Разработчики, разметчики, обучатели ИИ? Ну странно. Вроде как всё равно только полицейский или судья, но алгоритмы и софт будут на места спускать свыше, так что всё равно будут винить систему и адресовывать пересмотр несправедливого решения выше. А если человека, например, задержали из-за ложного срабатывания системы распознавания лиц, каковы его возможности это оспорить на практике? И будет ли кому-то что-то за ложное срабатывание и ложное осуждение? Это очень сложно регулировать, при этом ответственность максимально размывается, а система может давать простые готовые решения с хорошим процентом по базам данных, то есть как бы обнадёживающе хорошо, но на деле надёжность может очень неочевидно быть устроена и проверяться.
У нас тема расовых претеснений не является настолько острой, к счастью, хотя наверняка найдётся масса возражений к этой фразе, я не против, но не об этом. Пока проблема касалась в основном более-менее явных whitebox-алгоритмов, уже возникала масса вопросов. Сейчас везде чёрные ящики, предвзятость которых сложно оценить в принципе.
Вообще немалая часть проблемы в том, что к алгоритмам ИИ всё чаще относят понятия "разобраться", "понять", "распознать", "принять взвешенное разумное решение", хотя стоит применять только слово "вычислить", и то с погрешностью, которую игнорируют. Даже "распознать" имеет весьма условное применение, потому что мы давно слышали про one-pixel-attack и про многое другое потом. А с большими языковыми моделями сложности получают сразу несколько дополнительных уровней косвенности и становятся ещё менее проверяемыми.
Но сейчас везде и всем пихают ИИ как магию, которая "делает любой текст лучше" или "напишет текст за вас", и человеческая лень в итоге придёт к написанию в том числе юридических документов генеративными нейронками, последствия будут катастрофическими. Причина просто в том, что этого практически невозможно избежать. Суровая наказуемость этого может несколько отсрочить, но не более того. Главное на этом пути не идти впереди всех и не пройтись по куче грабель первыми.
После того, как всякие такие навайбкодят, когда всё начнёт ломаться и трещать по швам, а починить они не смогут сами, настоящие нормальные программисты станут на порядки ценнее. Просто подождём.
все такие умные стали, проверяют наличие сознания у функции, которая даже вычисляется неточно...
Пик численных методов и математики тоже близок? В ИИ важнее не фреймворки и архитектура, а как просто матрицы множить численно устойчиво и быстро. Не надо называть численную оптимизацию сознанием просто. Её пика не предвидится, а пик хайпа на нейронках случится, как придёт новое, как нейро- заменило нано-.
Потому что она предобучалась на примерно миллионе партий про до того, как играла сама с собой.
Я и удивился перечислению numpy. А blas и lapack даже скорее фортрановские, больше f77. Но там не прям всё распараллелено, например, стандартный gemm нет. Можете убедиться в исходниках))
Расскажите, как это можно непосредственно применить для ускорения numpy, раз он стал потокобезопасен? И коснулся ли threading используемых blas и lapack? С какими сложностями пришлось столкнуться для numpy, scipy, pyarrow?
Есть обратная сторона вопроса: новость получается сгенерированной и может быть иногда не совсем правдой, а отсылки к первоисточнику для проверки нет.
А с какого момента "чувак, который освоил ИИ" стало значить того, кто генерирует код нейронками, а не того, кто понимает ML, матан, линейную алгебру, численные методы и в состоянии реализовать многое с нуля, потому что понимает? Кажется, произошла подмена программиста пользователем.
Да на код свой гляньте. Если вам реально нужны vtables, ну ок. Иначе ооп только compile time приблуда. Вы задачи решаете или тексты пишете?
Мне кажется, многое на деле проще. Под конкретную задачу выбор инструмента обычно легче сделать из логики проекта, а популярность инструментов тут неважна.
Если проект учебный, чтобы научиться чем-то пользователься, то выбор уже сделан. Если чтобы научиться что-то сделать (а не чем-то), то выбор сделан и состоит в том, чтобы попробовать разное и сравнить (в том числе под что способы ищутся легче).
Если речь о выборе чего-то для самого начала обучения, величина проблемы тоже преувеличена. Во-первых, необязательно выбирать что-то, что точно пригодится. У меня в школе был BASIC, но я не сокрушаюсь о "бесцельно потраченных годах". Если тревожно искать вариант, который явно пригодится, то (как мне кажется) ещё долго будет надёжно как скриптовый выбирать Python, как более мощный чистый C (с учётом C API как универсальной связки разных инструментов между собой). Хотя надеяться изучить всё за минимум времени и не потратить лишней минуты зря уже ошибка, без готовности тратить много времени хорошо программирование не учится. Для изучения самых основ конкретный язык не так важен. После основ C и Python понимать стоит ну большинству. А дальше выбор более конкретных инструментов и выбор языка очень связаны. Тодга лучше выбирать, что хочется делать [новичку] на будущем месте работы, а не при помощи чего.
Общие рейтинги ЯП вообще штука заранее сомнительная, предвзятая и неоднозначная. А если делать их менее общими и специализировать под интересующую область, то рейтинги становятся неинтересными и рассыпаются, всё становится нередко "и так понятно", и рейтинг на практике бесполезен, вещь в себе.
Сначала и во-первых это красиво, учит правильным привычкам и любопытная головоломка. Но потом и во-вторых продолжать конкретные инструменты именно под Haskell оказывается надо очень редко, вакансии довольно редки, а также проблематично прототипировать, дебажить и оптимизировать, связь исходного кода и ассемблера тут ну очень непрозрачна. А делать производительные части условно на C/C++/Fortran, чтобы использовать Haskell как фронтенд вместо питона ну как-то overkill (и претит любителым чистых функций без unsafe, что часто среди ярых хаскелистов), тем более что потенциальных пользователей окажется тогда очень мало (а если делать под питон, то его условно "знают все" или по крайней мере, смогут воспользоваться), встречал такой пример, как hasktorch, который вроде забросили. Так что для любознательности и кругозора Haskell — это прекрасно и полезно, но чаще для души, чем для работы. А поскольку язык общего назначения, задач, под которые Haskell был бы идеально заточен, чтобы где-то сказать, что вот тут точно надо делать именно на нём, я не встречал.
Если апатия приводит в python, а безысходность в js, то конструктивный поиск приводит к Rust или порой к Go. Ещё бывает, что долг возвращает к C++ или Fortran.
А удаётся ли генерировать годные задачи? С решениями понятно, а вот для составления красивых задач это может быть любопытнее даже, чем с их же решением.
У специалистов слово "понимание" размывается, а у неспециалистов неверно используется. Про мелкие паттерны и свёрточные слои внутри слышали не все, но все слышат, что оно "понимает смысл", потому что это озвучивают на каждом углу так громко, что даже часть специалистов уже сомневается. Слова в естественном понимании и термины путать не стоит. Если с обучением ок, обязательное добавление слова "машинное" позволяет избежать проблем, то уже со словом "интеллект" всё очень спорно. А "машинного понимания" и "искусственного схватывания смысла" как терминов не существует, и вводить это не надо. Просто говорить тут про понимание вообще неуместно, это не термин.
Я бы больше боялся не появления злой воли у нейронок, а как раз приписывания нейронкам понимания, осознания, воли и прочего человеческого, к тому же, на широкую аудиторию. В итоге широкая аудитория верит и очеловечивает алгоритмы численной оптимизации, постепенно начнёт передавать ответственность за решения нейронкам. А в случае катастрофических последствий говорить, что интеллект стал слишком умный и вышел из-под контроля, хотя это просто функция с параметрами. Опасны не продвинутые алгоритмы, а такие упрощения для массовой аудитории.
"Это был первый переводчик, который действительно понимал контекст и схватывал смысл целиком"? Вы сами в это верите? О "понимании смысла" и у современных нейронок речь не идёт вообще. Вы путаете численную оптимизацию (что реально есть) и искусственное сознание (что не просто не сделано, а даже не определено чётко).
Простейший нетривиальный вариант, как всегда, LeNet на MNIST. Или пусть даже полносвязную нейронку в несколько слоёв на том же датасете (или тогда уж на чём попало), потому что известно, что MLP на MNIST тоже учится, пусть и не очень хорошо.
Можно при выводе массивов смотреть на массив xf64array (неточное будет помечено вопросиками), а также на вывод отдельно значений (поле values массива типа xf64array) и количества точных битов (поле exact_bits). Единственное, что это всё-таки расширение numpy, а не torch, так что исходную модель надо брать, где вычисление градиентов дополнительно реализуется, но такое в открытом доступе найти несложно, особенно, для чего-то простейшего типа MLP. Только надо поменять импорты numpy на xnumpy, и в большинстве случаев этого будет достаточно. И входные данные при конвертации в xf64array неплохо бы снабдить их естественной погрешностью. Например, если значения пикселей целые от 0 до 255, мы делим это на 256 для получения float, то логично предположить, что там вряд ли более 8 точных битов, а то и меньше, потому что это относительная погрешность.
Если выводить только values, то вывод будет, как если бы считалось на numpy, значения могут только чуть-чуть отличаться, если зависимые версии glibc, blas и прочие чуть-чуть поменялись, но это несущественные и крайне редкие изменения. Разница не в величине ошибки numpy и xnumpy, а в том, что в xnumpy величину ошибки мы знаем, а в numpy не имеем инструмента измерения ошибки вычислений, принимаем их как есть. Ошибки и какая-то мера их накопления неизбежны, а так можно эту величину увидеть без больших усилий заменой импорта. Поиграв с реализацией алгоритма, можно посмотреть, какие варианты надёжнее. И хотя выбор всё равно за лучшей целевой метрикой, из вариантов выбора важно исключить те, которым нельзя верить, зная величину их численной ошибки.
Это очень сильно замедлило бы. Да, есть boost/intervals, но для начала память увеличивается вдвое (а в xnumpy плюс байт на значение с плавающей точкой). И сами алгоритмы от классической теории погрешностей утяжеляют сильно. Здесь вместо этого используется число обусловленности для дифференцируемых функций, overhead получается вообще небольшой вместо минимум удвоения только на памяти и куда более тяжких алгоритмах. А для всяких округлений функции переписываются из glibc, чтобы не проходить два раза те же ветвления. Плюс к тому, особо важные функции типа матричного умножения (из blas/cublas/mkl) очень эффективны, но вроде не реализованы мощно для интервальной арифметики, вручную сделать настолько же эффективно и надёжно огромная проблема, а это нередко самые тяжеловесные операции. А оценки точностей в точных битах сводят всё к тем же матричным операциям с использованием тех же очень сильно оптимизированных библиотек при помощи оценки тропического произведения целочисленных матриц. Подход с точными битами потому и выбран, что иначе либо пользоваться станет невозможно, либо переписывать огромный тяжеловесный код, который десятки лет оптимизировали, это надо использовать, а не отказываться и переделывать с нуля. Матричные умножения с оценкой точных битов могут становиться тяжелее в разы, а если пытаться наивно посчитать точность интервалами, то медленнее станет в тысячи раз, что неприменимо на практике. С тригонометрией интервалы минимум удваивают стоимость вычислений, а в подходе с точными битам через число обусловленность получается overhead в процентах (например, на exp +21%, на log10 +9% по последнему бенчмарку, тогда как для intervals подсчёт для концов интервала и дополнительные проверки дадут сходу >100% overhead). Плюс к тому, для оценки точности мантиссы в битах часто вместо дополнительных операций с плавающей точкой используется целочисленная арифметика и работа с битовыми масками согласно представлению floating point в памяти, что тоже позволяет сделать ряд оптимизаций (как для арифметики, округлений). Но если добавить к увеличению времени ещё требование сокращать батч вдвое, то для нейронок на трансфере данных до gpu и обратно станет тратиться ещё большее время, так что выгоднее пользоваться оценкой точных битов вместо классических погрешностей очень сильно, а насколько именно, сильно зависит от железа и конкретных нейронок.
С целыми числами не получится, потому что градиентный спуск работать не будет. Избавиться от IEEE754 разом невозможно, на него завязано слишком много.
Тема предиктивной криминалистики начала появляться сильно до нынешней эры недетерминированных blackbox-алгоритмов. Даже во время классического ML была масса вопросов, правда, атрибутированных больше правовой системе США с её нюансами, чем нашей. Примеры сложностей (что-то из то ли книги, то ли статьи про PredPol, что-то добавил):
Если не балансировать данные, то одни этнические или прочие группы будут подозреваться ИИ чаще других.
Если балансировать, это делает целенаправленно одних более виноватыми, чем других.
Если делать централизованную систему, то правоприменительная практика будет отличаться от средней в отдельном штате, проблема.
Если учитывать особенности и законы отдельных штатов, то система сможет считать одного и того же человека виноватым или нет в зависимости от места преступления, тоже так себе.
Если системе не давать данные условно о расе и этнической принадлежности преступника, тем самым обосновав её якобы непредвзятость, то внутренние корреляции могут неявно "вычислить" этническую принадлежность через proxy-параметры (например, уровень дохода, образования и проживание в "чёрном" районе) и тем самым могут оказаться якобы очищенным от предвзятости обоснованием расизма со стороны правоохранительных органов, а подозрений в обоснованном скрытом проявлении расизма стремились избежать больше всего.
Если пытаться лишить алгоритм аугментацией данных возможности учитывать любые внутренние скрытые корреляции с этническими и расовыми группами (и прочими, чтобы осталась только социальная группа преступников), то алгоритм остаётся при минимуме параметров и практически теряет смысл и предсказательную силу. Вообще преступники не так сильно отличаются какими-то неочевидными признаками, иначе бы работа криминалистов не была такой сложной.
Наконец, если в прецедентном праве что-то изменится от очередного прецедента, как алгоритм начнёт это применять и когда? Алгоритмы машинного обучения с учителем не очень приспособлены для "прецедентного обучения", ну я такого по крайней мере не встречал, и существующие модели на базе нейронок подружить с этим может быть очень непросто, вопросов становится больше, чем ответов.
И плюс вопрос, кто несёт ответственность за признанное ошибочкным решение на основе ИИ? Разработчики, разметчики, обучатели ИИ? Ну странно. Вроде как всё равно только полицейский или судья, но алгоритмы и софт будут на места спускать свыше, так что всё равно будут винить систему и адресовывать пересмотр несправедливого решения выше. А если человека, например, задержали из-за ложного срабатывания системы распознавания лиц, каковы его возможности это оспорить на практике? И будет ли кому-то что-то за ложное срабатывание и ложное осуждение? Это очень сложно регулировать, при этом ответственность максимально размывается, а система может давать простые готовые решения с хорошим процентом по базам данных, то есть как бы обнадёживающе хорошо, но на деле надёжность может очень неочевидно быть устроена и проверяться.
У нас тема расовых претеснений не является настолько острой, к счастью, хотя наверняка найдётся масса возражений к этой фразе, я не против, но не об этом. Пока проблема касалась в основном более-менее явных whitebox-алгоритмов, уже возникала масса вопросов. Сейчас везде чёрные ящики, предвзятость которых сложно оценить в принципе.
Вообще немалая часть проблемы в том, что к алгоритмам ИИ всё чаще относят понятия "разобраться", "понять", "распознать", "принять взвешенное разумное решение", хотя стоит применять только слово "вычислить", и то с погрешностью, которую игнорируют. Даже "распознать" имеет весьма условное применение, потому что мы давно слышали про one-pixel-attack и про многое другое потом. А с большими языковыми моделями сложности получают сразу несколько дополнительных уровней косвенности и становятся ещё менее проверяемыми.
Но сейчас везде и всем пихают ИИ как магию, которая "делает любой текст лучше" или "напишет текст за вас", и человеческая лень в итоге придёт к написанию в том числе юридических документов генеративными нейронками, последствия будут катастрофическими. Причина просто в том, что этого практически невозможно избежать. Суровая наказуемость этого может несколько отсрочить, но не более того. Главное на этом пути не идти впереди всех и не пройтись по куче грабель первыми.