В коментариях часто встречаются мнения, что LLM (Large Language Model) надо за ручку водить, что она не понимает ни того, как, к примеру, в корпоративных БД инф искать, ни того, как правильно интенетом пользоваться, чтобы найти факты, а не "генерировать" их. Посмотрите пакет langchain. Он помогает с интеграцией LLM со многими системами. Если, к примеру, при ответе на вопрос надо провести вычисления, или запрос к БД, или семантический поиск в базе документов, то langchain сначала попросит LLM сделать python программу для вычисления, или сделать SQL query к БД (предварительно запросив схему этой БД), или загрузит документы, конвертирует их в embedding vectors, а потом отловит нужные документы по similarity. Есть там модули для запросов к куче API (конечно и к Google Search), и т.п. Я к тому, что проблема интеграции LLM с другими системами активно решается.
Посмотрите пакет langchain. Он помогает с интеграцией LLM со многими системами. Если, к примеру, при ответе на вопрос надо провести вычисления, или запрос к БД, или семантический поиск в базе документов, то langchain сначала попросит LLM сделать python программу для вычисления, или сделать SQL query к БД (предварительно запросив схему этой БД), или загрузит документы, конвертирует их в embedding vectors, а потом отловит нужные документы по similarity. Есть там модули для запросов к куче API (конечно и к Google Search), и т.п. Я к тому, что проблема интеграции LLM с другими системами активно решается.
Что интересно, Sam Altman в недавнем интерью Alex Fridman указал на то, что GPT-4 отвечает на вопросы очень корректно, вежливо и по существу. Что это можно использовать для создания в социальных сетях благожелательной и творческой атмосферы. Знания и ум избавляют от многих недостатков, это давно подмечено.
По поводу "ада" - не понял. Даже если надо было переписать все на другом языке, то создание прототипа должно было сократить суммарные издержки. Если такого не происходило, то надо смотреть, почему этап "перевод прототипа в продакшн код" выполнялся неэффективно. Даже если продакшн код пишется на том же языке, что и прототип, приходится добавлять и менять очень большие части кода. Естественный процесс. Требования к прототипу и к продакшн коду все же сильно отличаются. Часто прототипы прямиком идут в продакшн. Такое случается в стартапах. Бывает. И тут надо быть готовым к неизбежным проблемам.
Прежде, чем создавать/оценивать систему найма, можно склассифицировать позицию.
Например,
дженерик JS для разработки сайта. Позиция в нетехнологической компании. Jr. в команде 4 человек.
дженерик JS для разработки сайта. Позиция в Amazon. Весь сайт делают 300 человек. Вас нанимают в одну команду, кот.делает маленькую часть сайта.
Скорее всего на позицию 1 требоваться будут общие скилзы плюс какой-нибудь основной стек.
На позицию 2 будут требоваться все, что на 1ую, плюс 3-4 специализированных пакета, на которых работает данная команда.
На позицию 1 будет 10 кандидатов со средним уровнем ниже среднего.
На позицию 2 будет 200 кандидатов со средним уровнем сильно выше среднего.
В результате системы найма придется настраивать по-разному.
На позицию 1 не надо делать много фильтров, на 2 — фильтров придется делать больше.
Порог фильтров тоже н.б.настраивать по-разному.
Скорее всего и в одну компанию надо делать разные системы, если компания достаточно большая.
Для меня было откровением, что Kubernetes по умолчанию устанавливает кластеры без всякой защиты. Весь трафик внутри кластера открытый. Весь…
Наверное, это и помогло им так быстро распространиться среди девов. Прототип слепить можно очень быстро, если не париться с security.
Получается, что Calico полностью заменяет (ну, или, может заменить) kube сети на свою реализацию. Довольно радикально.
Meжду прочим, моя компания занимается защищенными сетями в том числе с использованием eBPF. Я сам ML занимаюсь, но постоянно слышу про eBPF. Если интересно, то есть несколько блог постов про это: Announcing eBPF Mode GA; A Look at the New Calico eBPF Dataplane; Introducing the Calico eBPF Dataplane. Еще недавно наш CTO написал e-book на эту тему (бесплатную). Если интересно, могу ссылку поискать.
Требования немножко противоречивые. 1+2 против 6. Т.е.или низкоуровневый, для системных работ — против UI. Я бы не смешивал.
Если брать первые требования, то Go на ум приходит.
Я тоже по этому пути прошел.
Занимался одним интеграционным продуктом одной известной комании (неважно какой продукт, какая компания). Тоже добрался до топа.
А в конце получилась похожая история, несочетание меня и этой софтвари.
И да, было горестно бростать все нажитое, выученное.
Сейчас получаю давно забытое удовольствие от программирования. python, я ж его просто люблю. Я так соскучился по забытому чувству, когда что-то пишешь-пишешь, а оно бац, и сразу работает. И это с моим-то счастьем (счастье мое в том, что я вылавливаю больше ошибок, чем вся команда. Хотя иногда кажется, что ошибки вылавливают меня.)
Получаю сейчас раза в 3 меньше. И совсем не жалею. Может когда и дорасту до прежних рейтов, может нет, совсем неважно. Убитых лет жалко.
Уверен, что у тебя тоже все получится. Нажитый опыт, он не весь по языку. В этом опыте еще много чего полезного и уникального. Не надо себя недооценивать.
Есть куча свежих, веселых, умных языков, которые решают С++шные задачи.
:)
Постараюсь с другой стороны. Если бы работали с тэгом, то были бы просто значение null или class1+class2. A c двумя классами будут null и другой null. Что совсем не один тэг null. С двумя классами все бохааче. М.б. class1_null+class2, class1+class2_null, class1_null+class2_null. А если null окрасим "разными причинами пропуска", то еще богаче, информативнее :)
Кстати,
есть интересное дополнение.
Часто случается, когда мы классикацию по нескольким классам заменяем на тэги. Т.е.несколько фич заменяем на фичу-list, в которой м.б. сколько угодно значений (тех же классов, к примеру). При использовании тэга может потеряться сематника пропущенных классов.
Лучше на примере: есть значение Должность (Electrical Engineer, Mechanical Engineer). Мы работаем с фичами Индустрия и Роль, либо с тэгом. С двумя инженерами понятно. Что делать со названием работы "нужен помощник со знанием математики"? Т.е. Индустрия — "не хватает данных", Роль — "многозначная" или "другие". А с тэгом пролет, потому что натурально мы бы просто не задали никакого тэга. И тогда мы теряем семантику пропущенных двух классов одновременно. А если пытаться в тэги засунуть семантику нескльких NA значений, то будет проще опять заменить тэг на те же пару классов. (заранее извиняюсь за скомканное объяснение)
Спасибо за поддержку,
Именно! Получаются доп.фичи.
Разные источники/причины NA могут быть определены в виде дополнительных фичь. Т.е. не просто заменой NA значения на что-то еще, а в виде доп.колонки с признаком. Из примера сверху это может быть — "не хватает текста".
Статья отражает многие современные исследования. На ум приходит компания Numenta, Jeff Howkins with Hierarchical Temporal Memory. У них много есть чего на youtube в том числе очень интересные курсы по HTM. Так вот они тоже все строят на бинарной идее.
Далеко ходить не надо. Наш могз построен на бинарной основе и пока что никакие супер-сложные и быстрые процессоры его не переплюнули. Numenta как раз идет от работы мозга.
Так что, я тоже думаю, что бинарные сети будут рулить.
Похоже, что самая большая проблема на этом пути — в создании "правильного" двоичного железа. Не того, что моделирует плавающую арифметику на двоичной элементной базе, а железа, похожего на HTM.
… и вдогонку. Дискуссии о проблемах имплементирования бинарных сетей на существующих процессорах понятны, но, по большому счету, мало что значат. Как в свое время быстренько выдумали GPU для каких-то там игра, так и сейчас, быстренько сварганят двоичные процессоры для бинарных сетей. С современными компьютерами — это небольшая работа :)
Пару дополнений к этой статье про MVP из России.
Да, продление статуса делается проще, чем получение его в первый раз. Лидеры по стране (служащие МС) часто не перерабатывают, а процедура продления намного проще для них, чем нахождение нового кандидата. У нас, в Канаде, в принципе то же самое.
Про критику МС… Наверное это специфика Российской программы. У нас ни разу за критику ни слова не говорили. И не слышал такого от других МVP. Хотя, это м.б.специфика Канады. У нас "наезд" — это всегда доброжелательный и конструктивный диалог, с улыбками, и часто с беспрерывными извинениями :) Ну, такая уж специфика. Мне лично она нравится. И результат такого общения мне тоже нравится :) Кстати, именно на MVP Summit часто этот стиль отбрасывался и пару раз была просто ругань (у SQL Server MVP есть пяток ребят :) ). В русском стиле… потом на парти они же с майкрософтовскими ребятами, на которых ругались, в обнимку ходили.
Метод доставки сообщения ("ручной", интернетом,..) мало влияет не формат сообщения. Но если у вас действительно используются используются поля EDI сообщений для роуминга и авторизации, то это будет первый случай в моей практике :) Не рассказывайте только это знакомым хакерам, хотя вряд ли они будут это хакать. Слишком просто и примитивно все это взломать. Все равно, что у младеньца леденец отобрать.
Основная идея статьи похожа на правду. Но сами рассуждения как бу уводят от нее от конкретного разбора ситуации в эмоциональную сферу, которой здесь не место.
Действительно, IBM смотрится очень слабо на нынешнем ландшафте ИИ. Масса статей и прорывных технологий от Google, Microsoft, Yandex, университетов. А IBM двигает Ватсон, не раскрывая, что там у него внутри. Если зайти на их сайт и попробовать понять это, ничего не получится. Увидим сплошной sales-треп ни о чем. Что обидно, т.к.известно, что внутри IBM есть (были?) очень хорошие группы ученых и инженеров.
Похоже, что Ватсон базируется на массивном инвестировании в классические ML методы, в Deep-Learning, NN что-то о них не слышно. Т.е.у них, похоже, хороший инжиниринг в feature preparation. Ничего в этом плохого нет. Плохо, когда мало понимающие сейлзмэны строят свой мир, далекий от реальности.
Это уже у них неоднократно наблюдалось, например с продвижением EDI, с реинкарнацией мэйнфреймов. Корпоративный мир, однако.
В коментариях часто встречаются мнения, что LLM (Large Language Model) надо за ручку водить, что она не понимает ни того, как, к примеру, в корпоративных БД инф искать, ни того, как правильно интенетом пользоваться, чтобы найти факты, а не "генерировать" их.
Посмотрите пакет langchain. Он помогает с интеграцией LLM со многими системами. Если, к примеру, при ответе на вопрос надо провести вычисления, или запрос к БД, или семантический поиск в базе документов, то langchain сначала попросит LLM сделать python программу для вычисления, или сделать SQL query к БД (предварительно запросив схему этой БД), или загрузит документы, конвертирует их в embedding vectors, а потом отловит нужные документы по similarity.
Есть там модули для запросов к куче API (конечно и к Google Search), и т.п.
Я к тому, что проблема интеграции LLM с другими системами активно решается.
Посмотрите пакет langchain. Он помогает с интеграцией LLM со многими системами. Если, к примеру, при ответе на вопрос надо провести вычисления, или запрос к БД, или семантический поиск в базе документов, то langchain сначала попросит LLM сделать python программу для вычисления, или сделать SQL query к БД (предварительно запросив схему этой БД), или загрузит документы, конвертирует их в embedding vectors, а потом отловит нужные документы по similarity.
Есть там модули для запросов к куче API (конечно и к Google Search), и т.п.
Я к тому, что проблема интеграции LLM с другими системами активно решается.
Что интересно, Sam Altman в недавнем интерью Alex Fridman указал на то, что GPT-4 отвечает на вопросы очень корректно, вежливо и по существу. Что это можно использовать для создания в социальных сетях благожелательной и творческой атмосферы. Знания и ум избавляют от многих недостатков, это давно подмечено.
По поводу "ада" - не понял. Даже если надо было переписать все на другом языке, то создание прототипа должно было сократить суммарные издержки. Если такого не происходило, то надо смотреть, почему этап "перевод прототипа в продакшн код" выполнялся неэффективно.
Даже если продакшн код пишется на том же языке, что и прототип, приходится добавлять и менять очень большие части кода. Естественный процесс. Требования к прототипу и к продакшн коду все же сильно отличаются.
Часто прототипы прямиком идут в продакшн. Такое случается в стартапах. Бывает. И тут надо быть готовым к неизбежным проблемам.
Нет специализации по Machine Learning, Artifical Intelligency (ML, AI)?
Прежде, чем создавать/оценивать систему найма, можно склассифицировать позицию.
Например,
Скорее всего на позицию 1 требоваться будут общие скилзы плюс какой-нибудь основной стек.
На позицию 2 будут требоваться все, что на 1ую, плюс 3-4 специализированных пакета, на которых работает данная команда.
На позицию 1 будет 10 кандидатов со средним уровнем ниже среднего.
На позицию 2 будет 200 кандидатов со средним уровнем сильно выше среднего.
В результате системы найма придется настраивать по-разному.
На позицию 1 не надо делать много фильтров, на 2 — фильтров придется делать больше.
Порог фильтров тоже н.б.настраивать по-разному.
Скорее всего и в одну компанию надо делать разные системы, если компания достаточно большая.
Согласен.
Я сам пару раз менял стек и на первом проекте работал "за еду". :)
Для меня было откровением, что Kubernetes по умолчанию устанавливает кластеры без всякой защиты. Весь трафик внутри кластера открытый. Весь…
Наверное, это и помогло им так быстро распространиться среди девов. Прототип слепить можно очень быстро, если не париться с security.
Получается, что Calico полностью заменяет (ну, или, может заменить) kube сети на свою реализацию. Довольно радикально.
Meжду прочим, моя компания занимается защищенными сетями в том числе с использованием eBPF. Я сам ML занимаюсь, но постоянно слышу про eBPF. Если интересно, то есть несколько блог постов про это:
Announcing eBPF Mode GA; A Look at the New Calico eBPF Dataplane; Introducing the Calico eBPF Dataplane. Еще недавно наш CTO написал e-book на эту тему (бесплатную). Если интересно, могу ссылку поискать.
Мы рабоаем на MS DevOps, Teams, Slack. Для software development сейчас DevOps очень хороша.
Требования немножко противоречивые. 1+2 против 6. Т.е.или низкоуровневый, для системных работ — против UI. Я бы не смешивал.
Если брать первые требования, то Go на ум приходит.
Кстати, зачем С++ выдумали поверх С? Для ООП. А ООП какие проблемы решает? DRY проблемы. Не хочется много раз что-то повторять.
В UI подобные проблемы везде. А в системном программировании поменьше. Linux © — тому хороший пример.
Я тоже по этому пути прошел.
Занимался одним интеграционным продуктом одной известной комании (неважно какой продукт, какая компания). Тоже добрался до топа.
А в конце получилась похожая история, несочетание меня и этой софтвари.
И да, было горестно бростать все нажитое, выученное.
Сейчас получаю давно забытое удовольствие от программирования. python, я ж его просто люблю. Я так соскучился по забытому чувству, когда что-то пишешь-пишешь, а оно бац, и сразу работает. И это с моим-то счастьем (счастье мое в том, что я вылавливаю больше ошибок, чем вся команда. Хотя иногда кажется, что ошибки вылавливают меня.)
Получаю сейчас раза в 3 меньше. И совсем не жалею. Может когда и дорасту до прежних рейтов, может нет, совсем неважно. Убитых лет жалко.
Уверен, что у тебя тоже все получится. Нажитый опыт, он не весь по языку. В этом опыте еще много чего полезного и уникального. Не надо себя недооценивать.
Есть куча свежих, веселых, умных языков, которые решают С++шные задачи.
:)
Постараюсь с другой стороны. Если бы работали с тэгом, то были бы просто значение null или class1+class2. A c двумя классами будут null и другой null. Что совсем не один тэг null. С двумя классами все бохааче. М.б. class1_null+class2, class1+class2_null, class1_null+class2_null. А если null окрасим "разными причинами пропуска", то еще богаче, информативнее :)
Кстати,
есть интересное дополнение.
Часто случается, когда мы классикацию по нескольким классам заменяем на тэги. Т.е.несколько фич заменяем на фичу-list, в которой м.б. сколько угодно значений (тех же классов, к примеру). При использовании тэга может потеряться сематника пропущенных классов.
Лучше на примере: есть значение Должность (Electrical Engineer, Mechanical Engineer). Мы работаем с фичами Индустрия и Роль, либо с тэгом. С двумя инженерами понятно. Что делать со названием работы "нужен помощник со знанием математики"? Т.е. Индустрия — "не хватает данных", Роль — "многозначная" или "другие". А с тэгом пролет, потому что натурально мы бы просто не задали никакого тэга. И тогда мы теряем семантику пропущенных двух классов одновременно. А если пытаться в тэги засунуть семантику нескльких NA значений, то будет проще опять заменить тэг на те же пару классов. (заранее извиняюсь за скомканное объяснение)
Спасибо за поддержку,
Именно! Получаются доп.фичи.
Разные источники/причины NA могут быть определены в виде дополнительных фичь. Т.е. не просто заменой NA значения на что-то еще, а в виде доп.колонки с признаком. Из примера сверху это может быть — "не хватает текста".
Ага, отличное дополнение! Добавлю ссылку на этот МAR.
Статья отражает многие современные исследования. На ум приходит компания Numenta, Jeff Howkins with Hierarchical Temporal Memory. У них много есть чего на youtube в том числе очень интересные курсы по HTM. Так вот они тоже все строят на бинарной идее.
Далеко ходить не надо. Наш могз построен на бинарной основе и пока что никакие супер-сложные и быстрые процессоры его не переплюнули. Numenta как раз идет от работы мозга.
Так что, я тоже думаю, что бинарные сети будут рулить.
Похоже, что самая большая проблема на этом пути — в создании "правильного" двоичного железа. Не того, что моделирует плавающую арифметику на двоичной элементной базе, а железа, похожего на HTM.
… и вдогонку. Дискуссии о проблемах имплементирования бинарных сетей на существующих процессорах понятны, но, по большому счету, мало что значат. Как в свое время быстренько выдумали GPU для каких-то там игра, так и сейчас, быстренько сварганят двоичные процессоры для бинарных сетей. С современными компьютерами — это небольшая работа :)
Пару дополнений к этой статье про MVP из России.
Да, продление статуса делается проще, чем получение его в первый раз. Лидеры по стране (служащие МС) часто не перерабатывают, а процедура продления намного проще для них, чем нахождение нового кандидата. У нас, в Канаде, в принципе то же самое.
Про критику МС… Наверное это специфика Российской программы. У нас ни разу за критику ни слова не говорили. И не слышал такого от других МVP. Хотя, это м.б.специфика Канады. У нас "наезд" — это всегда доброжелательный и конструктивный диалог, с улыбками, и часто с беспрерывными извинениями :) Ну, такая уж специфика. Мне лично она нравится. И результат такого общения мне тоже нравится :) Кстати, именно на MVP Summit часто этот стиль отбрасывался и пару раз была просто ругань (у SQL Server MVP есть пяток ребят :) ). В русском стиле… потом на парти они же с майкрософтовскими ребятами, на которых ругались, в обнимку ходили.
Метод доставки сообщения ("ручной", интернетом,..) мало влияет не формат сообщения. Но если у вас действительно используются используются поля EDI сообщений для роуминга и авторизации, то это будет первый случай в моей практике :) Не рассказывайте только это знакомым хакерам, хотя вряд ли они будут это хакать. Слишком просто и примитивно все это взломать. Все равно, что у младеньца леденец отобрать.
Действительно, IBM смотрится очень слабо на нынешнем ландшафте ИИ. Масса статей и прорывных технологий от Google, Microsoft, Yandex, университетов. А IBM двигает Ватсон, не раскрывая, что там у него внутри. Если зайти на их сайт и попробовать понять это, ничего не получится. Увидим сплошной sales-треп ни о чем. Что обидно, т.к.известно, что внутри IBM есть (были?) очень хорошие группы ученых и инженеров.
Похоже, что Ватсон базируется на массивном инвестировании в классические ML методы, в Deep-Learning, NN что-то о них не слышно. Т.е.у них, похоже, хороший инжиниринг в feature preparation. Ничего в этом плохого нет. Плохо, когда мало понимающие сейлзмэны строят свой мир, далекий от реальности.
Это уже у них неоднократно наблюдалось, например с продвижением EDI, с реинкарнацией мэйнфреймов. Корпоративный мир, однако.