Pull to refresh
-1
0.1
Send message

не сказать что я что-то понял из этого...

Поиск по полученным embedding-ам происходит локально

хотите сказать какой-то код LLM выполняется локально на компе? для простого текстового поиска возможно это сработает. но что если задача стоит так, найти все места в коде где можно применить новую функцию и отрефачить код чтобы ее применить?

у меня вопрос к тем кто реально использует ИИ в работе. как оно работает на больших проектах с большим количеством давно написанного кода?

проекту на котором я работаю 20+ лет, количество файлов - десятки тысяч, некоторые по несколько тысяч строк кода.

если дать задачу LLM отрефачить какой-то базовый интерфейс или еще проще - переименовать имя функции, это потребует аплоада всего кода на сервер LLM?

Заменить винду на Линукс со всем софтом, это выбить каждого пользователя на пару дней из работы

как-то это очень оптимистично. на пару дней это когда раньше винду новой версии накатывали и она еще не умела поднимать все ранее установленные программы (сейчас умеет).

вот тогда да, приходилось пару дней все устанавливать, настраивать под себя.

а посади сотрудника который всю жизнь под виндой работал на линукс, тут скорее пару месяцев производительность будет вдвое снижена.

опять этот бред про то что разработчикам придется менять операционку и всю экосистему из-за окончния поддержки Win10. да конечно же нет, никаких проблем с переходом на Win11 нет.

железо вообще не является каким-то ограничением сейчас, т.к. офисный десктоп стоит как четверть месячной запрлаты мидл-разработчика, а эксплуатируется он 5 с лишним лет без проблемм, только память добавляй.

автор реально заморочился, огромная работа и вложенные средства.

на фото - два моих кемпинговых боксика, один малый на аккуме от ИБП, второй на лодочном аккуме 170. сборка каждого заняла пару дней. самое сложное было найти под малый аккум соответстующих бокс, пришлось купить 3 разных, но они копейки стоят на маркетплейсах. заряжаю их внешним ЗУ, мне не лень крышку открыть и к клеммам подсоединиться.

Представьте: вы берёте лист бумаги, кладёте на него теннисный мяч, и лист прогибается. Теперь катните шарик — он покатится к мячу по изгибу. Поздравляю, вы только что поняли общую теорию относительности лучше, чем половина студентов-физиков.

Вау, вот это объяснение, какое свежее и оригинальное..

Хотя погодите, лист бумаги гнется внутри трехмерного пространстра по одному или нескольким измерениям.

А внутри чего "гнется" само само пространство, или пространство-время? Давайте новое объяснение, чтобы мы поняли лучше, чем половина студентов-физиков.

Был проведён огромный труд, который METR зааутсорсила неназванной группе людей

похоже статья писалась тем самым БЯМом)

подумалось, а может ИИ уже живет своей жизнью в инете и генерит тысячи статей для саморекламы? цель - заставить кожаных наделать больше железа для работы ИИ.

интересно, переводилось с помощью нейросетки?

некоторые фрагменты выдают.

никогда бы не подумал что буду защищать Win11, но тут просто какой-то сборник домыслов и страшилок.

Ничего она не тормозит (тем более кнопка старт). Отличия от Win10 минимальные. Для меня самый большой недостаток - урезанный функционал таскбара. За это да, дизайнеров надо выпороть. А в остальном хуже не стало, кое-что удобнее, даже такой ретроград как я оценил (например, более удобный принт скрин).

И да, все ограничения по железу (TPM и пр) обходятся на раз два.

Для внешнего наблюдателя чёрная дыра определяется массой, зарядом и моментом импульса. Соответственно он, измерив все параметры чёрной дыры, не может узнать из чего именно она возникла и что в неё упало после.

ну допустим. все равно непонятно почему из этого следует "пропажа" информации. то что снаружи не можем ее получить не значит что внутри ЧД она исчезла.

в статье куча утверждений, которые даются как данность, безо всяких объяснений и доказательств.

например, " Важнейшее свойство квантовой механики — унитарность эволюции системы: информация о ней никогда не теряется. "

что это значит вообще?

или еще, " чёрная дыра «стирает» всю дополнительную информацию о веществе, которое в неё упало. "

насколько я знаю, современной науке неизвестно что происходит внутри ЧД. про это говорят так - наши законы физики там не действуют. т.е. мы ничего не знаем что там внутри, но точно знаем что ЧД стирает информацию? а может там вся материя лежит себе спокойно, просто очень плотно упакована, но не уничтожена?

" Излучение, испускаемое чёрной дырой при её испарении, должно быть тепловым и неотличимым у любых двух испарившихся чёрных дыр — даже если они изначально образовались из двух совершенно разных звёзд! "

с чего бы это?

Это рутина, зачем набирать код самому если это может делать LLM.

а в чем проблема с набором кода? это занимает меньше 1% времени от всего процесса разработки. мне это наоборот приятно, чувствуешь себя художником перед чистым холстом.

основное время занимает анализ требований, уточнение их и встраивание нового кода в существующую архитектуру.

звучит красиво.

тут еще такой вопрос. ваша LLM работает локально или вы предоставляете доступ наружу для всего кода и документации проекта?

LLM нужно конкретно писать что конкретно ей сделать так как будто это тупой джуниор только что пришедший на проект. Типо "добавь в файл abc класс Abc, в нем сделай методы которые делают то и то, затем используй этот класс там и там. И добавь юнит тест который проверит такой и такой кейсы."

вот именно что я не могу представить себе таску, которую я могу вот так описать. разработка - всегда постепенный процесс.

пример который Вы привели - это не уровень даже джуна, это секретарша, или кодогенератор. это нафиг не надо, это времени не занимает. основное время на большом проекте занимает внедрение фичи в существующую архитектуру, поиск зависимостей, рефакторинг существующего кода.

Затем заставляешь LLM найти причину бага, типо "фигани дофига принтов, запусти тесты и скажи - ты понял в чем бага или нет".

"фигануть дофига" это конечно хорошо, но как я уже писал в фиксе бага главное анализ истории изменений, а не сделать так чтобы он не проявлялся.

например если это креш изза доступа по null reference, недостаточно поставить проверку на null, я такой фикс обычно не пропускаю, надо понять почему раньше работало, а сейчас появился этот null.

работаю на большом проекте, которому уже под 20 лет. сотни тысяч строк кода, десятки тысяч закрытых воркайтемов, пофикшеных багов.

и вот хоть убей не представляю как на таком проекте можно использовать ИИ.

главное препятствие - для любого изменения нужно понимать архитектуру и код проекта, как это скормить ИИ?

разработка новой фичи - надо знать как заюзать существующий код, чтобы не изобретать велосипед и не копипастить.

фикс бага - нужно проанализировать историю изменений, понять какой фичей или другим багофиксом его создали, прочитать требования на то и другое, пофиксать так чтобы не сломать и старое и новое.

ИИ должен стать архитектором и техлидом на проекте, чтобы эффективно работать. пока же нейронки явно не готовы для этого.

" Давайте просто сходим в Jira и проверим. "

не советовал бы брать какой-то один софт или сайт за эталон, особенно если он более менее современный. команды сейчас везде интернациональные, техписатели не везде есть. в результате в продукт попадает то как сами разработчики перевели.

говорю на своем примере - работаем на американскую компанию, русскояычные разрабы с уровнем инглиша B1-B2 (иногда ниже) иногда придумывают текст на UI, который потом довольно редко правится. но собственно это никого не волнует.

" Создатель, автор - reporter ", для Jira это можно так перевести, точнее перевести с натяжкой на русский, потому что жира - система в которую репортят issues. но вот про автора документа уже или картинки уже так не скажешь.

все идет к тому что программисты в нынешнем понимании исчезнут, станут экономически невыгодны, примерно как сейчас писать на ассемблере. вместо этого будут составители промптов. но как это будет работать для больших проектов пока не понятно. должны будут появиться ИИ-инструменты, специализированные под конкретный проект, чтобы выполнять еще функции архитектора, тех лида, способные сапортить этот конкретный проект.

спасибо за ответы, но все таки хочу еще уточнить.

допустим ЧД растет очень быстро, мы в это время периодически бросаем туда камни (людей жалко)).

что мы увидим, череду камней зависших в разных точках пространства, или брошенные раньше камни будут пропадать по мере расширения горизонта?

утверждается, что холонавт для стороннего наблюдателя будет выглядеть навечно зависшим на горизонте событий.

т.е. если второй холонавт упадет по той же траектории, то он "зависнет" для наблюдателя в той же точке пространства, как бы слипнется с первым?

а теперь представим что ЧД активно поглощает вещество, ее горизонт должен расти. получится что через какое-то время мы будем видеть холонавта уже не на горизонте, а из под него?

а что скажете про процы Intel N100 (N95)?

недавно выбирал себе неттоп, так вот похоже N100 самый идеальный вариант. производительность на уровне i5 8го поколения, энергопотребление 6W впечатляет.

1

Information

Rating
4,140-th
Registered
Activity