Connect with us

Статьи

Ошибки команд в акселераторе: как привлечь следующий раунд инвестиций

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

QIWI Universe

Опубликовано

/

     
     

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

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

Так что же пошло не так?

Ошибка 1. Предприниматель по расписанию

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

Да и в целом, в какой-то момент нужно сделать для себя выбор – работать на основной работе или заниматься проектом и сфокусироваться на нем. Невозможно быть предпринимателем по расписанию, с 9 до 5 работая на работе, а с 6 до 9 занимаясь проектом.

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

Мораль

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

Ошибка 2. Уход в продукт

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

Часто вторая ошибка связана с первой: основателям кажется, что достаточно найти классных разработчиков и написать хорошее ТЗ, а самим можно спокойно заниматься другими проектами или работой. Но продукт не равен коду. Посмотрите вокруг себя – ни одни проект не провалился, потому что у них был плохой код, а вот проблемы с потребителями, конкурентами, логистикой и ценностями продукта были и будут всегда. Именно их и придется решать в режиме нон-стоп каждый день.

Мораль

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

Ошибка 3. «Я все знаю!»

Часто команды проектов решают «забить» на образовательные мастер-классы и встречи с экспертами, потому что «а мы уже это знаем/читали, лучше попилим продукт». (Например, в начале программы QIWI Universe команды проектов часто жаловались нам, что из-за интенсивного обучения у них нет времени поработать над проектом).

При этом команды упускают важные особенности образовательного процесса именно в акселераторе.

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

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

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

Мораль

Если вы идете в акселератор за кратным ростом своего бизнеса, то нужно ходить на все мастер-классы и встречи с экспертами, а не просто сидеть и пилить продукт (это можно с успехом делать дома, не отдавая долю в проекте). Мы заметили, что в России, в целом, довольно высокомерное отношение к образованию, как к чему-то оторванному от реальности, и часто этот шлейф идет еще от институтских лет. Однако практика показывает обратное – лучшие результаты показывают те предприниматели, которые пытаются впитать максимальное количество полезных знаний и навыков из образовательной программы.

Ошибка 4. «Пните меня!»

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

С одной стороны, это действительно так – на специальных traction meeting, которые происходят каждую неделю, команда акселератора обсуждает все планы и достижения каждой из команд. Для многих команд это повод собраться и ускориться.

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

Мораль

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

Ошибка 5. Соседи — это только грязная посуда и бесполезный треп

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

Но, как правило, команды слишком сосредоточены на своем продукте, и не пользуются теми возможностями, которые открывает перед ними экосистема акселератора.

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

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

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

Мораль

Тратьте время на обсуждение своего проекта с другими командами акселератора, не бойтесь попросить у них помощи. В общем, будьте более социальными! :)

Ошибка 6. «Я не услышал будильник»

Акселерационная программа — это марафон для команды проекта и, прежде всего, для основателей. Если ваш проект получил инвестиции, вы попали в акселератор – это не финиш, на котором стоит расслабляться, а только старт, после которого нужно начать работать еще интенсивней и не сбавлять темп.

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

Мораль

Если вы приняли решение идти в акселератор, заранее морально подготовьтесь, что придется много – очень много – работать. Подумайте, в какое время вам комфортно начинать работать (например, с 11 утра) и возьмите за правило не отклониться от него. Этот прием отлично дисциплинирует в условиях свободного графика работы.

QIWI Universe
Комментарии Facebook
Продолжить чтение
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Статьи

Применение инженерного подхода к собеседованиям

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

Анна Гуляева

Опубликовано

/

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

  1. Какова ваша цель при проведении собеседования?
  2. Как вы оцениваете достижение этой цели?

Какова ваша цель при проведении собеседования?

От некоторых рекрутеров я слышал фразу “Хм, я не совсем знаю, кого мы ищем”, но обычно многие делятся на такие категории:

  1. Найти лучшего человека.
  2. Понять, подойдет ли кандидат для компании.
  3. Оценить, как хорошо кандидат сможет справляться с той работой, на которую он хочет попасть (это довольно редкий ответ).

Менее 10% компаний сказали, что их процесс собеседования создан, чтобы оценить, насколько эффективно человек будет справляться с работой, на которую хочет устроиться. Найм “лучших” и “подходящих” людей кажется мне нелепой стратегией, основанной на предрассудках рекрутера, а не на способностях кандидата.

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

Как вы оцениваете достижение цели?

Большинство компаний отвечают, что не производят оценку. Если вы оптимизируете программу, и вашим показателем успеха является “Не знаю, я что-то изменил, и оно стало работать лучше”, то вас высмеют. Но мы применяем эту тактику к процессу собеседования. Хотя люди и говорят, что команда является самой важной частью стартапа, большинство компаний поверхностно относятся к процессу найма и не применяют инженерный подход.

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

Это лучше, чем ничего, но есть и вторая часть уравнения. Что насчет людей, которых вы не нанимаете? Люди часто говорят, что менее рискованно отвергнуть хорошего кандидата, чем нанять плохого, но я думаю, что это бессмысленно. Я постоянно слышу, что лучшие компании жаждут талантливых разработчиков и что на рынке труда их сложно найти, но те же самые компании отвергают множество людей, потому что они не там учились или они не так быстро решили тестовое задание. Даже если вы думаете, что менее рискованно сократить (и так уже маленький) пул людей, которых вы нанимаете, чем нанять неправильного человека, вам стоит быть уверенными, что вы ищете среди правильной группы людей.

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

Проведите ваше собеседование на существующих сотрудниках

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

Составьте “набор для оценки”

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

У этого подхода есть несколько проблем:

  1. Он необъективен к людям, у которых нет GitHub/Twitter/блога или другого присутствия онлайн.
  2. Существует много кандидатов, которые не умеют программировать, поэтому нахождение проблем в процессе собеседования может занять время.

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

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

Заключение

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

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

Анна Гуляева
Комментарии Facebook
Продолжить чтение

Разработка

Почему не надо патентовать идею мобильного приложения

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

AppCraft

Опубликовано

/

Автор:

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

В этой статье мы тезисно перечислим причины этого не делать.

Что такое патент

Патент – это охранный документ, удостоверяющий исключительное право, авторство и приоритет изобретения, полезной модели либо промышленного образца. В случае с разработкой мобильного приложения, являющегося программным обеспечением, получить патент в России и Европе на алгоритмическую часть (непосредственно программу) не удастся: статья 52 европейской патентной конвенции прямо запрещает патентование программ для ЭВМ.

Поэтому в случае с мобильными приложениями, как правило, защищается не сам продукт, а общая идея функционирования сервиса, отражающая некоторую новизну подхода к решению той или иной задачи. Запатентовать код тоже можно, но только в некоторых юрисдикциях, например, в США или Южной Корее.

Это долго и дорого

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

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

Вы потратите минимум 50–100 тысяч рублей (если часть работы будете делать самостоятельно) и не меньше 3–4 месяцев, если делать все очень быстро.

После этого вы можете получить отказ на регистрацию от патентного бюро, потому что описание недостаточно детальное, не содержит инновационности, дублирует уже существующие патенты и т.д. Только 56% патентов регистрируется, соответственно, 44% – отклоняется.

При этом, по статистике, 97% (!) патентов генерируют прибыли меньше, чем стоимость их оформления.

Вы патентуете не то, что нужно

Практически всегда желание защитить бизнес возникает на стадии первой идеи. Как только прошло достаточно времени на обдумывание плана, сразу возникает мысль о защите еще будущего предприятия. Желание понятно, однако идея и ее реализация – всегда разные вещи.

Пол Грэм, один из известнейших предпринимателей в IT и основатель Y Combinator, говорит, что по его опыту от 70 до 100% проектов имеют разные ключевые идеи на старте и через 3 месяца операционной работы.

Так происходит из-за того, что бизнес – это решение реальных проблем. Он развивается и растет в синергии с потребностями людей, которые:

  1. вам досконально неизвестны на стадии идеи;
  2. меняются со временем;
  3. решаются так, как хочется им, а не вам.

Как только вы начнете запускать идею, с вероятностью близкой к 100% вам придется если не полностью изменить вашу задумку, то значительно ее переработать. Зачем в этом случае патентовать в самом начале то, от чего в последствие вы сами откажетесь?

Забывается главное

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

Фокусируясь на защите идеи, вы сразу же отстаете в скорости ее развития и реализации.

Патент – не единственный способ защититься

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

  • Купите домен с именем продукта. Хорошее имя дает сильный эффект, а при решении любых споров покупка вашего домена в более ранний срок, чем оформление торговой марки конкурента, решает многие вопросы.
  • Создайте группы в социальных сетях с названием проекта. Как и в случае с доменом, хорошие названия имеют и хорошие поисковые позиции, и неплохо запоминаются, и становятся недоступны конкурентам.
  • Зарегистрируйте торговую марку. Это не быстро в некоторых юрисдикциях (например, в России), но во многих странах осуществляется в течение нескольких дней и с минимальными затратами.

Итого

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

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

AppCraft
Комментарии Facebook
Продолжить чтение

Разработка

Программное обеспечение 2.0

Руководитель отдела искусственного интеллекта в Tesla Андрей Карпатый рассказал, почему нейронные сети — это не просто новый вид программного обеспечения, а совершенно новый этап в развитии вычислительной техники.

Анна Гуляева

Опубликовано

/

Иногда люди называют нейронные сети просто “ещё одним инструментом в наборе машинного обучения”. У них есть плюсы и минусы, они могут работать здесь или там, и иногда вы можете использовать их в соревнованиях Kaggle. К сожалению, эта интерпретация упускает нечто большее. Нейронные сети — это не просто ещё один классификатор, они представляют  фундаментальный сдвиг в том, как мы создаем программы. Они — Программное Обеспечение 2.0.

“Классический стек” программного обеспечения 1.0 — это то, с чем мы уже давно знакомы, он написан на языках вроде Python, C++ и так далее. Он состоит из четких инструкций для компьютера, написанных программистами. С каждой строкой кода программист указывает определенную точку в программном поле с нужным поведением.

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

Что читать, смотреть и где учиться машинному обучению

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

ПО 2.0 не заменит ПО 1.0 (большое количество инфраструктуры 1.0 необходимо для обучения и “компиляции” кода 2.0), но оно будет выполнять большую часть задач, за которые сегодня отвечает ПО 1.0. Давайте рассмотрим некоторые примеры этого перехода:

Визуальное распознавание ранее состояло из запрограммированных функций с небольшим количеством машинного обучения (метод опорных векторов). С тех пор мы разработали платформы для создания более мощных программ анализа изображений (в семействе архитектур ConvNet – сверточных нейронных сетей), а в последнее время начали поиск по архитектурам.

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

К речевому синтезу традиционно подходили при помощи различных механизмов сшивания, но сегодня современные модели представляют собой большие сверточные сети (например, WaveNet), которые генерируют выходной аудиосигнал.

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

Робототехника имеет давнюю традицию разбивать проблему на блоки восприятия, оценки поз, планирования, управления, моделирования неопределенности, используя явные, а не промежуточные представления и алгоритмы. Мы еще не совсем достигли это, но исследования в UC Berkeley и Google намекают на то, что ПО 2.0 может значительно улучшить работу всего этого кода.

Игры. Игровые программы существовали долгое время, но AlphaGo Zero (сверточная сеть, которая смотрит на состояние доски и делает ход) стала самым сильным игроком в игре. Я ожидаю, что мы увидим очень похожие результаты в других областях, например, в Dota 2 или StarCraft.

Искусственному интеллекту для игры в Го больше не нужны люди

Вы могли заметить, что множество ссылок включают работы Google. Это потому, что сейчас Google переписывает большую часть своей инфраструктуры на Код 2.0. Подход “Одна модель, чтобы править всеми” показывает, как это может выглядеть, когда статистические мощности отдельных областей объединены в одно непрерывное понимание мира.

Преимущества программного обеспечения 2.0

Почему мы предпочитаем переносить сложные программы в Software 2.0? Ясно, что простой ответ заключается в том, что они просто лучше работают. Тем не менее, есть много других причин, чтобы предпочесть этот стек. Давайте рассмотрим некоторые преимущества Software 2.0 (то есть, нейронных сетей) по сравнению с Software 1.0 (то есть, базой кода C++ на уровне продакшена). Программное обеспечение 2.0:

Гомогенно в вычислениях. Типичная нейронная сеть на первом уровне состоит только из двух операций: матричного умножения и приведения к нулю (ReLU). Сравните это с набором операций в классических программах, который является более разнородным и сложным. Поскольку вам нужно обеспечить реализацию Software 1.0 только для небольшого числа основных вычислительно простых элементов (например, умножения матрицы), то в этом случае гораздо проще гарантировать производительность.

Проще реализуется в оборудовании. Так как набор инструкций нейронной сети относительно мал, эти сети гораздо проще воплотить в оборудовании при помощи кастомных ASIC, нейроморфных чипов и так далее. Мир изменится, когда искусственный интеллект, требующий низкой производительности, распространиться вокруг нас. То есть когда небольшие недорогие чипы получат предварительно натренированные нейронные сети, получат речевое распознавание и синтез речи WaveNet – и все это встроится в небольшой протомозг, который вы можете подсоединить к чему угодно.

Постоянная производительность. Каждая итерация типичного прохода нейронной сети занимает одинаковое количество FLOPS. По сравнению с разными путями выполнения C++ кода, у нейронных сетей нулевая изменчивость в производительности. Разумеется, у вас могут быть динамические вычислительные графы, но поток выполнения, как правило, все еще значительно ограничен. Таким образом, мы также почти гарантированно никогда не оказываемся в бесконечных циклах.

Постоянное использование памяти. В ПО 2.0 отсутствует динамически распределенная память, поэтому утечки памяти, которые вы должны выискивать в своем коде, маловероятны.

Высокая портативность. Последовательность матричных вычислений значительно проще запускать на произвольных вычислительных конфигурациях по сравнению с классическими двоичными файлами или скриптами.

Высокая гибкость. Если у вас есть код на C++, и кто-то хочет, чтобы вы сделали его в два раза быстрее (пусть даже в ущерб производительности, если это необходимо), было бы очень нетривиально настроить систему под новые спецификации. Однако для ПО 2.0 мы можем взять нашу сеть, удалить половину каналов, переквалифицировать — и она будет ​​работать ровно в два раза быстрее и немногим хуже. Это магия. И наоборот, если вам нужно получить больше данных или провести больше вычислений, вы можете сразу улучшить свою программу, добавив больше каналов и переквалификацировав ее.

Модули могут объединяться в оптимальное целое. Наше программное обеспечение часто раскладывается на модули, которые взаимодействуют через публичные функции, API-интерфейсы или конечные точки. Однако, если два модуля ПО 2.0, которые были первоначально обучены отдельно, взаимодействуют, мы можем легко объединить их в целое. Подумайте о том, насколько это удивительно, если бы ваш веб-браузер мог автоматически перепроектировать низкоуровневые системные инструкции на десять шагов вглубь, чтобы повысить эффективность загрузки веб-страниц. С 2.0 это поведение доступно по умолчанию.

Его легко изучить. Я люблю шутить, что глубокое обучение не так уж и глубоко. Это не ядерная физика, где вы должны получить PhD до того, как сделать что-то полезное. Основные концепции требуют знаний базовой линейной алгебры, вычислений, Python и некоторых лекций из курса CS231n. Конечно, некоторые интуитивные знания придут с опытом, поэтому точнее будет сказать, что к стеку ПО 2.0 легко подойти, но его непросто освоить.

Оно лучше, чем вы. Наконец, самое важное: нейронная сеть — это лучший код, чем я или вы можем придумать для многих областей, среди которых сейчас любая работа с изображениями, видео, звуком, речью и текстом.

Ограничения ПО 2.0

Стек 2.0 имеет и свои недостатки. По завершении оптимизации у нас есть большие сети, которые хорошо работают, но нам сложно сказать, как они это делают. Во многих случаях у нас есть выбор между моделью с 90% точностью, которую мы понимаем, и моделью с 99% точностью, которую мы не понимаем.

Стек 2.0 может допускать постыдные ошибки, воспринимая предрассудки в данных для обучения, которые очень сложно обнаружить в таких больших объемах.

Наконец, мы все ещё изучаем некоторые специфические свойства этих программ. Например, существование враждебных примеров и атак показывает неинтуитивную природу этого стека.

Финальные мысли

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

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

А программное обеспечение 3.0? Он будет уже полностью зависеть от этого сильного искусственного интеллекта.

 

Анна Гуляева
Комментарии Facebook
Продолжить чтение




Календарь

ноябрь

17ноя - 19Весь деньТИЛТЕХ МЕДХАК

24ноя - 26Весь деньWhat the hack?!

25нояВесь деньSmart Taler 2017

25нояВесь деньLadies Code: время технологий

30нояВесь деньSmart Cars & Roads 2017

декабрь

5дек18:30- 22:00Яндекс изнутри: глазами iOS-разработчика

8дек - 9Весь деньКубок СTF России

9дек - 10Весь деньGames Gathering 2017

9декВесь деньЛекционный день по игровой индустрии

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков веб и мобильных приложений!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Наш Facebook

Популярное

X

Спасибо!

Теперь редакторы в курсе.