30 мая сего года на территории «Школы 21» Сбербанка прошло совещание по вопросам развития технологий в области искусственного интеллекта. Совещание можно считать немного эпохальным — во-первых, его вёл Президент России В.В. Путин, а участвовали президенты, генеральные директора и заместители генеральных директоров государственных корпораций и крупных коммерческих компаний. Во-вторых, обсуждалась ни много, ни мало, а национальная Стратегия по развитию технологий искусственного интеллекта, подготовленная Сбербанком, о которой доложил Г.О. Греф.



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

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

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

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

Про этот тест даже снят короткометражный игровой фильм «Кто за стеной». Можно сказать, фантастический, потому что действие по сюжету происходит в конце 2000 года, а снят он, на минуточку, в 1977 году. Если не видели — посмотрите обязательно, и обязательно до конца — как и положено в короткометражном фильме, развязка будет неожиданна.



Так вот, в фильме был интересный способ выбора участников теста — они выбирались среди абонентов городской телефонной сети случайным образом и отвечали на вопросы из дома в онлайне. С видео, фильм же фантастический. Я и подумал, а неплохо бы запилить подобный тест, пользуясь современными технологиями, а именно технологией чатов, в том же Telegram, например.

Здесь я расскажу, как сделать канбан-доску для проекта в Jira, пользуясь только QML и JavaScript. С небольшими доработками вместо Jira вы можете использовать любой другой трекер, имеющий REST API.

Предыстория

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

Существует несколько парсеров, подходящих для русского языка. Некоторые из них могут даже выполнять синтаксический анализ, как SyntaxNet, MaltParser и AOT:

… или выявлять факты, как Tomita.

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

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

В типичной реализации генетический алгоритм оперирует параметрами какой-то сложной функции (диофантовые уравнения в статье "Генетический алгоритм. Просто о сложном" mrk-andreev) или алгоритма ("Эволюция гоночных автомобилей на JavaScript" ilya42). Количество параметров неизменно, операции над ними тоже изменить невозможно, как генетика не старается, потому что они заданы нами.

Хьюстон, у нас проблема

Сложилась странная ситуация — прежде чем применять генетические алгоритмы (ГА) к реальной задаче, мы сначала должны найти алгоритм, которым эта задача в принципе решается, и только потом его попытаться оптимизировать с помощью генетического алгоритма. Если мы ошиблись с выбором «основного» алгоритма, то генетика не найдет оптимум и не скажет, в чем ошибка.

Часто, а в последнее время и модно, вместо детерминированного алгоритма использовать нейронную сеть. Тут у нас тоже открывается широчайший выбор (FNN, CNN, RNN, LTSM, ...), но проблема остается той же — выбрать нужно правильно. Согласно Википедии "Выбирать тип сети следует, исходя из постановки задачи и имеющихся данных для обучения".

А что, если...? Если заставить ГА не оптимизировать параметры, а создавать другой алгоритм, наиболее подходящий для данной задачи. Вот этим я и занимался ради интереса.

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


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

А если мы не будем ограничиваться одним форматом doc, тогда в качестве бонуса получим возможность просмотра вложенных документов в других форматах, для которых в Windows зарегистрированы стандартные просмотрщики.

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

В предыдущей серии я пытался сделать из мухи разумное существо. Коротко — не вышло. Муха упорно не хотела учиться.



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

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

Обучение проходило кое-как, результата не было. Затем, оставив попытки обучения по уважительным причинам (как то — вечер субботы, ночь и утро воскресенья), я все же думал, что делать дальше. Какие-то возможные решения были намечены в конце первой статьи, с них и продолжил.

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

Самая простая сеть

Самая простая сеть нашлась в статье "Нейросеть в 11 строчек на Python" (это перевод от SLY_G статьи "A Neural Network in 11 lines of Python (Part 1)", вообще у автора есть еще продолжение "A Neural Network in 13 lines of Python (Part 2 — Gradient Descent)", но здесь достаточно первой статьи).

Краткое описание сетки — в этой сети есть ровно одна зависимость — NumPy.

Множество входов рассматривается как матрица $$, множество выходов — как вектор $$. В оригинальной статье сеть умножает входную матрицу, размерностью (4 x 3), на матрицу весов входов $$ (3 x 4), к произведению применяет передаточную функцию, и получает матрицу слоя $$ (4 x 4).

Для работы с web-сервисами традиционно используется SoapUI от SmartBear Software. Отличный инструмент и к тому же бесплатный. Но… это инструмент разработчика, тестировщика, архитектора, но никак не ориентированный на работу конечного пользователя.

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



Чтобы обратиться к web-сервису существует огромное количество способов. В Python есть requests (статьи на Хабре 1, 2), но я буду использовать средства Qt, отчасти по привычке, отчасти для уменьшения зависимостей, так как PyQt5 уже подключен, отчасти для уменьшения промежуточных преобразований данных. Соответственно, для преобразования полученного xml-ответа использую XPath и XQuery, так же заложенные в Qt.

В предыдущей части я рассказывал о создании модуля для запуска SQL-запросов и оболочки, в которой эти модули запускаются. После недолгой работы с запросами возникает очевидный вопрос — а как воспользоваться результатом выборки, кроме как посмотреть на экране?

Для этого стоит сделать дополнительные инструменты экспорта и копирования данных. Экспортировать будем в файл в формате Excel, а копировать в системный буфер в формате HTML.

Но для начала прилепим к нашему главному окну панель инструментов.

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



Но простой и удобный. Тут надо отметить, что на основной работе я не разработчик, поэтому постоянной среды программирования на рабочем компе не имею и, когда это требуется, пишу на чем придется — bat, JScript, VBA в MSOffice (да, это Windows, корпоративные системы, тут нет bash и perl «из коробки»), макросы в разном ПО и т.д. Все это помогает решить текущую задачу, но уровень и возможности маленько не те, что хотелось бы иметь.

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

Вы скажете, что сейчас есть инструменты на любой вкус и цвет, только выбирай. Лягушка aka TOAD под Oracle, SoapUI для шины и продукты GNU и Apache для всего остального.
Но проблема в том, что все они они специализированы под одну какую-то деятельность, а с другой стороны слишком универсальны — можно сделать многое, но многими действиями. А если возможность в продукте отсутствует, то добавить ее нельзя. Либо продукт закрытый, либо нужно разрабатывать/покупать плагин, либо качать исходники и в них разбираться. А мне нужен был инструмент, в котором простые действия делаются просто, а на сложные сначала тратится немного времени и дальше опять все просто.