Немного не в тему обсуждения, но приведите, пожалуйста, пример девайса, сопоставимого с MacBook Pro по совокупности характеристик, но без "лживых понтов" и на 90% дешевле. Мне искренне интересно.
По теме безусловной полезности ИИ — да, для части бизнеса вполне выгодно в моменте заменить часть персонала (например, людей в первой линии поддержки) на API-вызовы. Выгодно ли это клиентам — вопрос риторический. Выгодно ли бизнесу в более отдалённой перспективе — неясно, и я не о лояльности клиентов такого бизнеса. Зависимость от стороннего сервиса — это дополнительный риск: никто не застрахован от того, что условная OpenAI в какой-то момент перестанет работать на капитализацию и начнёт агрессивно выдаивать монетизировать своих клиентов, повышая цены и ограничивая функционал.
Сразу скажу - я ни в коем случае не отрицаю прогресс в LLMках, наблюдаемый при их масштабировании, и с удовольствием их использую в работе и не только. Но сходства нейронки с нервной системой заканчиваются на слове "нейрон", используемом в разных контекстах при описании.
Да, грубой эмуляции текстового общения достаточно для решения многих практических задач. Но причём тут интеллект?
Человек способен научиться новым способам рассуждения и делать выводы на основе единичных взаимодействий со средой. Попытка повторить этот трюк в нейронке во-первых не ложится на нынешние архитектуры (одного примера недостаточно для адекватного обновления весов), во-вторых - ставит крест на масштабировании. Человек способен сомневаться, перепроверять, убеждаться/признавать некомпетентность; статистическая модель - нет.
Веса в нейронке - статичная, застывшая в моменте обучения конструкция, которая не меняется при взаимодействии со средой. Мы можем прикрутить к нейронке костыли в виде Tool Calling, RAG, etc. для того, чтобы дать ей доступ к данным, которые не присутствовали в обучающем датасете, но эти данные не способны повлиять на сам "процесс рассуждений" (инференс).
Даже насекомые адаптируются к среде, а LLM - нет. Разница в способности к обучению принципиальна и не устраняется простым увеличением вычислительных мощностей на текущих архитектурах сетей.
Совершенно не факт, что корень проблемы в том, что "нейрон" в сетке - слишком грубая модель; возможно, на других архитектурах получится воспроизвести процесс рассуждений не хуже, чем это получается у кожаных. Но этих других архитектур, которые хорошо переносятся на имеющееся железо и параллелятся/масштабируются, пока нет. Возможно, они появятся завтра; возможно, через 5/50/500 лет; возможно, никогда.
Классический IT-стартап — это история про рост капитализации (масштабирование на деньги инвесторов с ожиданиями когда-то в будущем выйти на прибыль). Даже вне кризиса никто не инвестирует в код; нужна бизнес-модель.
Без инвестиций вам придётся как можно раньше выходить на прибыль. Либо нужно будет найти нишу с относительно небольшой конкуренцией, уже существующим платёжеспособным спросом и организовать околобесплатную маркетинговую кампанию (крайне маловероятное сочетание), либо с нуля создать платёжеспособный спрос на несуществующем ранее рынке (это совсем фантастика).
Разве это всё входит в компетенции программиста? Опытный маркетолог и то больше шансов имеет попасть в рынок.
Эволюция случайна только на уровне отдельных мутаций; она направляется отбором. Этот отбор, кстати, не дал нам какого-то большого разнообразия в принципах работы нервных систем у животных; биохимия там плюс-минус похожая.
Нам известен ровно один тип носителя — нервная система. Да, ничего не мешает предположить, что возможны альтернативы, но какие обоснованные выводы из этого можно сделать? Как вы оцениваете вероятности?
Здесь возможна та же самая ситуация, что и с возникновением жизни: мы можем предполагать, в каких условиях она могла бы возникнуть, эстраполировать наши выводы на оценку числа планет, но оценить вероятности по одному примеру не получается (см. уравнение Дрейка + парадокс Ферми).
Безосновательный оптимизм скорее про веру, чем про вероятности.
Очередной GPT-перевод бессмысленной пресной статьи ради наполнения корпоративного блога. Сколько таких уже было, 50?
Оригинальная статья тоже старательно обходит все возможные грабли, коих в Go миллион.
Ни слова не сказано про select, про channel axioms (дедлоки на nil-каналах, грабли с дефолтными значениями, возвращаемыми из закрытых каналов), про утечки горутин, про чудесную "особенность" с копированием мьютекса в структуре при вызове метода с value receiver на ней и о многом другом.
Реальный продакшн-код на Go выглядит совершенно по-другому, с куда большим количеством приседаний и проверок.
Неприятная история, конечно, но это именно баг в реализации, а не "дыра в системе типов".
Ничего не мешает доказать корректность абстрактной модели, в которой бага нет. Если мы в ходе доказательства найдём противоречия в этой модели — можно будет говорить о дырах в ней.
Как привести реальный компилятор в соответствие с теоретической моделью — уже отдельный вопрос.
Исходя из презумпции адекватности, я бы не предполагал, что на общий вопрос ожидается конкретный ответ (но ответ может помочь оценить кругозор соискателя).
Признаюсь, не в курсе, как собеседуют джунов/миддлов (сам в профессию попал, когда были просто программисты/разработчики), но сеньорские собеседования обычно проходят в виде диалога, в котором контекст дополняется уточняющими вопросами, и не возбраняется задавать встречные.
Применительно к этой ситуации, ничего не мешает обозначить всю вариативность технологий хранения — schemafull/schemaless, механизмы обеспечения связности, транзакционность, отказоустойчивость, гарантии, уместность SQL/NoSQL-хранилищ в разных кейсах, etc. Пока я пробегаюсь по верхам, интервьюер с большой вероятностью сузит контекст, опираясь на что-то сказанное мной — попросит развернуть, уточнить, приведёт пример/задачку.
В реальности настолько общие вопросы задают нечасто, т.к. банально нет времени на подобные обсуждения. Самый общий вопрос, который я встречал — "в чём особенности написания многопоточных программ": за ним последовало 40-минутное обсуждение, в рамках которого и о мьютексах/атомиках поговорили, и о сисколлах/сменах контекста, и о высокоуровневых примитивах, и о тулинге).
В 2023 пора бы уже забыть про Rocket и сразу брать Axum — он поддерживается (командой Tokio, благодаря чему хорошо интегрируется с остальной экосистемой; например, позволяет использовать готовые middleware для Tower/Hyper), быстрее, эргономичней.
Немного не в тему обсуждения, но приведите, пожалуйста, пример девайса, сопоставимого с MacBook Pro по совокупности характеристик, но без "лживых понтов" и на 90% дешевле. Мне искренне интересно.
По теме безусловной полезности ИИ — да, для части бизнеса вполне выгодно в моменте заменить часть персонала (например, людей в первой линии поддержки) на API-вызовы. Выгодно ли это клиентам — вопрос риторический. Выгодно ли бизнесу в более отдалённой перспективе — неясно, и я не о лояльности клиентов такого бизнеса. Зависимость от стороннего сервиса — это дополнительный риск: никто не застрахован от того, что условная OpenAI в какой-то момент перестанет работать на капитализацию и начнёт
агрессивно выдаиватьмонетизировать своих клиентов, повышая цены и ограничивая функционал.Так что вопрос крайне неоднозначный.
Сразу скажу - я ни в коем случае не отрицаю прогресс в LLMках, наблюдаемый при их масштабировании, и с удовольствием их использую в работе и не только. Но сходства нейронки с нервной системой заканчиваются на слове "нейрон", используемом в разных контекстах при описании.
Да, грубой эмуляции текстового общения достаточно для решения многих практических задач. Но причём тут интеллект?
Человек способен научиться новым способам рассуждения и делать выводы на основе единичных взаимодействий со средой. Попытка повторить этот трюк в нейронке во-первых не ложится на нынешние архитектуры (одного примера недостаточно для адекватного обновления весов), во-вторых - ставит крест на масштабировании. Человек способен сомневаться, перепроверять, убеждаться/признавать некомпетентность; статистическая модель - нет.
Веса в нейронке - статичная, застывшая в моменте обучения конструкция, которая не меняется при взаимодействии со средой. Мы можем прикрутить к нейронке костыли в виде Tool Calling, RAG, etc. для того, чтобы дать ей доступ к данным, которые не присутствовали в обучающем датасете, но эти данные не способны повлиять на сам "процесс рассуждений" (инференс).
Даже насекомые адаптируются к среде, а LLM - нет. Разница в способности к обучению принципиальна и не устраняется простым увеличением вычислительных мощностей на текущих архитектурах сетей.
Совершенно не факт, что корень проблемы в том, что "нейрон" в сетке - слишком грубая модель; возможно, на других архитектурах получится воспроизвести процесс рассуждений не хуже, чем это получается у кожаных. Но этих других архитектур, которые хорошо переносятся на имеющееся железо и параллелятся/масштабируются, пока нет. Возможно, они появятся завтра; возможно, через 5/50/500 лет; возможно, никогда.
Классический IT-стартап — это история про рост капитализации (масштабирование на деньги инвесторов с ожиданиями когда-то в будущем выйти на прибыль). Даже вне кризиса никто не инвестирует в код; нужна бизнес-модель.
Без инвестиций вам придётся как можно раньше выходить на прибыль. Либо нужно будет найти нишу с относительно небольшой конкуренцией, уже существующим платёжеспособным спросом и организовать околобесплатную маркетинговую кампанию (крайне маловероятное сочетание), либо с нуля создать платёжеспособный спрос на несуществующем ранее рынке (это совсем фантастика).
Разве это всё входит в компетенции программиста? Опытный маркетолог и то больше шансов имеет попасть в рынок.
Эволюция случайна только на уровне отдельных мутаций; она направляется отбором. Этот отбор, кстати, не дал нам какого-то большого разнообразия в принципах работы нервных систем у животных; биохимия там плюс-минус похожая.
Нам известен ровно один тип носителя — нервная система. Да, ничего не мешает предположить, что возможны альтернативы, но какие обоснованные выводы из этого можно сделать? Как вы оцениваете вероятности?
Здесь возможна та же самая ситуация, что и с возникновением жизни: мы можем предполагать, в каких условиях она могла бы возникнуть, эстраполировать наши выводы на оценку числа планет, но оценить вероятности по одному примеру не получается (см. уравнение Дрейка + парадокс Ферми).
Безосновательный оптимизм скорее про веру, чем про вероятности.
Очередной GPT-перевод бессмысленной пресной статьи ради наполнения корпоративного блога. Сколько таких уже было, 50?
Оригинальная статья тоже старательно обходит все возможные грабли, коих в Go миллион.
Ни слова не сказано про select, про channel axioms (дедлоки на nil-каналах, грабли с дефолтными значениями, возвращаемыми из закрытых каналов), про утечки горутин, про чудесную "особенность" с копированием мьютекса в структуре при вызове метода с value receiver на ней и о многом другом.
Реальный продакшн-код на Go выглядит совершенно по-другому, с куда большим количеством приседаний и проверок.
Вы про баги в компиляторе?
Вот, например, issue с 2015-го года висит. Пока не исправили. Обещают починить с новым trait solver'ом.
https://github.com/rust-lang/rust/issues/25860
Неприятная история, конечно, но это именно баг в реализации, а не "дыра в системе типов".
Ничего не мешает доказать корректность абстрактной модели, в которой бага нет. Если мы в ходе доказательства найдём противоречия в этой модели — можно будет говорить о дырах в ней.
Как привести реальный компилятор в соответствие с теоретической моделью — уже отдельный вопрос.
Исходя из презумпции адекватности, я бы не предполагал, что на общий вопрос ожидается конкретный ответ (но ответ может помочь оценить кругозор соискателя).
Признаюсь, не в курсе, как собеседуют джунов/миддлов (сам в профессию попал, когда были просто программисты/разработчики), но сеньорские собеседования обычно проходят в виде диалога, в котором контекст дополняется уточняющими вопросами, и не возбраняется задавать встречные.
Применительно к этой ситуации, ничего не мешает обозначить всю вариативность технологий хранения — schemafull/schemaless, механизмы обеспечения связности, транзакционность, отказоустойчивость, гарантии, уместность SQL/NoSQL-хранилищ в разных кейсах, etc. Пока я пробегаюсь по верхам, интервьюер с большой вероятностью сузит контекст, опираясь на что-то сказанное мной — попросит развернуть, уточнить, приведёт пример/задачку.
В реальности настолько общие вопросы задают нечасто, т.к. банально нет времени на подобные обсуждения. Самый общий вопрос, который я встречал — "в чём особенности написания многопоточных программ": за ним последовало 40-минутное обсуждение, в рамках которого и о мьютексах/атомиках поговорили, и о сисколлах/сменах контекста, и о высокоуровневых примитивах, и о тулинге).
В 2023 пора бы уже забыть про Rocket и сразу брать Axum — он поддерживается (командой Tokio, благодаря чему хорошо интегрируется с остальной экосистемой; например, позволяет использовать готовые middleware для Tower/Hyper), быстрее, эргономичней.