Спасибо за статью, было приятно прочитать!
Для книги будет плохо работать любой — слишком большой объем текста. Но если гипотетически рассматривать, то нужна абстрактная суммаризация, попробуйте SummAE от гугл: github.com/...search/tree/master/summae
У них же недавно вышел PEGASUS, который state-of-the-art, но готового кода пока не видел. Плюс все сильно зависит от того, на чем тренировали — если на новостях, например, то результат будет «желтушным».
Спасибо! Если честно, не совсем понял конечную задачу. Если где-то есть ответ на этот вопрос, то BERT создан как раз с целью нахождения ответа в тексте.
Если задача каким-то образом распарсить сами вопросы, то важно понять какие структуры мы в них ищем. Соответственно, может быть простой NER (как в примере «Лондон или Нью Йорк» — найти географические локации), так и может быть целая цепочка процессинга вроде Spacy для нахождения объекта в предложении (SVO), потом dependency parsing и noun phrases из Berkeley Parser...
Но вообще, если есть неочевидная задача, то я обычно задаю себе вопрос: «а как бы человек сделал вручную? На что ориентировался бы?» — и если есть понятный ответ, то разбиваю ее на подзадачи исходя из потенциальных приоритетов. Часто оказывается, что оптимальным решением оказывается комбинация подходов.
Андрей, спасибо за вопрос. Если коротко, то не сравнивали. Отчасти по той причине, что у них несколько разное назначение.
Вот хороший комментарий, описывающий почему BERT не предназначен для векторизации документов целиком: github.com/...32#issuecomment-462762704
Вот еще есть статья, которая описывает различные варианты эмбеддинга документов, в частности есть workaround с бертом: towardsdatascience.com/...hniques-fed3e7a6a25d#bbe8
Что касается удовлетворенности клиента — бывает по-разному, поэтому я писал про важность управления ожиданиями. Если задача решается без ML — мы первыми это говорим и рекомендуем на цепляться за хайп :)
Когда не уверены в результате, пытаемся адресовать возможные риски с помощью максимально итеративного процесса, часто показываем результаты, описываем перспективы. В принципе, максимум того, что мы можем сделать — вовремя предупредить, что-то порекомендовать, объяснить, что результат вероятностный, что зависит от качества и количества данных. Главное сделать это вовремя.
Спасибо! В дополнение к отличной статье от Саши, скажу, что действительно оценка ROI на начальном этапе часто является проблемой.
Мы обычно идем несколькими путями:
— если есть данные, делаем фазу feasibility study, обычно она занимает от 20 до 80 часов, часто за свой счет, это грубая прикидка самым простым способом. Например, если задача фрод детекшн, то кластеризовать данные, посмотреть на маленькие кластера вручную, вероятно в них есть фрод. Если задача по экстракции данных из документов — вручную разметить 100, 200, 300 документов, посмотреть как будет расти точность. Эта фаза позволяет нам понять какие данные доступны и их качество, а клиентам — посмотреть как выглядит процесс и лучше понять что они получат на выходе;
— если к данным доступа нет, но есть примерное понимание области, можем оперировать отраслевыми стандартами. К примеру, в computer vision мы знаем, что распознать меланому с Jaccard index выше 0.8 крайне сложно, а в фрод детекшне есть оптимальная точка баланса ручной валидации результатов и кол-ва false positives, на уровне 87.5% действительных случаев фрода из распознанных. От таких чисел можно отталкиваться для оценки абстрактных примеров;
— в конце концов, есть инвестиционный аспект: решение использовать ML — это всегда риск для компании, но если на него не идти, то конкуренты обгонят. У компаний часто есть бюджет на инновации и R&D, можно попробовать понять сколько компания готова потратить на эксперимент. Возможно, этого будет достаточно, чтобы оценить ROI в будущем и в целом перспективы использования ML.
Надеюсь, это поможет :)
Андрей, спасибо! Цитата про детали — прямо беру себе, очень полезная!
Спасибо большое за статью, замечательно, когда делятся реальным опытом!
Маленький вопрос: project administrator — это Junior PM, чем он обычно занимается вне PI?
Спасибо за статью!
Мне кажется, что ответ на вопрос в чем отличие от технического ПМа, кроется не в «как появилась эта роль», а в «зачем появилась эта роль».
В моем понимании, ДМ отличается от технического ПМ тем, что помимо стандартного набора задач ведения проекта, лидерства команды, управления ожиданиями клиента итд., он еще в состоянии развивать текущие аккаунты, делая апсейл и успешно участвуя в продаже новых комплексных решений «под ключ» (тот самый консалтинг, в который все хотят). И, разумеется, это гораздо проще делать, имея технический бэкграунд, чем не имея его.
Дима, классный список компетенций менеджера — прям бери и прописывай цели по smart по каждой! :)
Спасибо за интервью, очень интересно было прочитать. И удачи Алексею в новых начинаниях.
Много комментариев, уже не поймешь :)
На машине я предельно спокойно езжу, жажду скорости компенсирую байком либо вне города, либо в городе на пустых улицах, т.к. риск для мотоциклиста всегда очень высок, не говоря уже об окружающих.
Я готов к любому пари по мастерству вождения с тобой на твой вкус и уверен, что буду более профессионален и безопасен на дороге, что позволяют мне говорить 7 лет безаварийного вождения.
И еще, я несколько устал от твоих «пока такие как ты живут», «пример отстуствия мозгов», «желаю приехать в столб», «жаль не увольняют» — эта трусливая писанина недостойна мужчины.
Очевидно, что перепалка в фейсбуке основательно тебе что-то подпалила и ты, спустя месяц, трусливо решил самореализоваться на форуме. Если считаешь, что тебе нужно донести до меня какой-то посыл — я всегда готов встретиться персонально и выслушать твою позицию, иначе я буду воспринимать этот пост как мелкий злопамятный высер в мою сторону.
Леха, это вы про меня?
Ира, мне они не льстят. Когда человек сперва желает мне врезаться в столб, а потом быть уволенным — я не могу воспринимать его серьезно.
Ну почему же. Если товарища спустя месяц бомбит после перепалки в фейсбуке — о чем говорить.
Детка, уже месяц прошел, а ты до сих пор не выбросишь меня из головы. Польщен твоим вниманием.
Попробуйте посмотреть на вещи с другой стороны. Все мы люди и люди бывают разные.
Очень содержательный и обоснованный комментарий.
Спасибо за статью, интересно почитать взгляд со стороны человека, впервые столкнувшегося с тестированием ИИ.
От себя могу порекомендовать несколько ключевых слов и один базовый курс, который помог бы вам быстрее прийти к нужным выводам:
1. Во-первых, есть прекрасная статья в целом про ML, которую поймет и пятиклассник, объясняющая базовые вещи (ее можно читать и не-техническим людям): vas3k.ru/blog/machine_learning
2. Во-вторых, когда уже есть какое-то понимание того, что происходит в таких проектах, есть часть курса Andrew Ng, посвященная оптимальной структуре проектов и нюансам обучения, например, нейросеток. Это уже более продвинутое чтиво, но оно позволяет гораздо лучше понять как делать надо и как не надо: www.coursera.org/...machine-learning-projects
3. Стоит разобраться в базовых метриках (например, Confusion Matrix, Precision/Recall/F1, Correlation Matrix, etc.), они помогут понять как оцениваются получившиеся модели, а также методах интерпретации (например, SHAP values), которые помогают понять какие факторы повлияли на решение.
Надеюсь, это поможет в следующих проектах! ;)