kmike

Проблема не в том, что с нейронными сетями дела не имели, а в том, что не знаете, как задачу сформулировать так, что ее можно было решать методами машинного обучения. Я бы посоветовал какой-нибудь вводный курс по ML (на coursera или udacity?), без разницы, с нейросетями или без. Если поймете, как задачу сформулировать (что на входе, что на выходе - что найти надо), то станет очевидно, как нейросеть (или любой другой классификатор) применять. Если в задаче не нужно код для нейросети писать, можно готовую реализацию взять, если нужно - ну написать можно; я так понимаю, проблема-то не в этом.

Конкретно для примеров из вопроса все решается в рамках pymorphy2 как-то так:

from pymorphy2.shapes import restore_capitalization

def inflect_all(morph, text, required_grammemes):
    tokens = text.split()
    inflected = [
        restore_capitalization(
            morph.parse(tok)[0].inflect(required_grammemes).word,
            tok
        )
        for tok in tokens
    ]
    return " ".join(inflected)

Больше информации - см. в гуглогруппе: https://groups.google.com/forum/?fromgroups#!topic...

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

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

Дальше, вы пишете, что «округляли значения до 0 или 1» — ваши «кластеры значений» — это < 0.5 и > 0.5? «Кучкуются около 2 уровней» — около 0 и 1, или около каких-то других? Какой смысл имеют выходные переменные, там точно уровень имеет значение? ну там x1=0.1, x2=0.3, x3=1 и можно ли сказать, что в каком-то смысле x3 > x2 > x1, и что «еще немного, и x2 стал бы x1»? Если на самом деле там не непрерывная входная переменная, то можно попробовать заменить ее на несколько логических («вероятности принадлежности к кластерам значений») — в тренировочных данных они 0 или 1 будут, т.к. эти для тестовых данных известно, принадлежит значение к кластеру или нет (это то же самое, что вы сделали, или нет?).

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

Производное произведение от словаря — да, под CC. При этом коммерческий продукт может так и оставаться закрытым и коммерческим. Если вы коммерческий продукт распространяете, то нужно просто где-то указать, что словари взяли из OpenCorpora.

Там в FAQ ( opencorpora.org/?page=faq ) написано: «На условиях лицензии Creative Commons Attribution-ShareAlike 3.0. Т.е. бесплатно, но при создании чего-либо на основе этих данных вы обязаны указать, что эти данные взяли у нас, а распространять их дальше можно только на этих же условиях.»

Cначала было вот так написано:

«На условиях лицензии Creative Commons Attribution-ShareAlike 3.0. То есть бесплатно, но при создании чего-либо на основе этих данных вы обязаны, во-первых, указать, что эти данные взяли у нас, во-вторых, лицензировать свой продукт или данные на тех же условиях.»

Т.е. к лицензии CC добавлялось еще ограничение «лицензировать свой продукт на тех же условиях» (смотря как читать); я с ребятами связался и они сказали, что это просто неточность была, такого ограничения нет, и текст переписали.

Если совсем точно знать хотите — спросите в groups.google.com/forum/?fromgroups#!forum/opencorpora-dev, да и на хабре разработчики OpenCorpora бывают.

Проблема в неправильной настройке STATIC_ROOT и STATICFILES_DIRS.

STATIC_ROOT — это временная папка, куда статика собирается в продакшне командой ./manage.py collectstatic. При разработке она может быть пустой. Я обычно ее «collected_static» называю, и делаю где-нибудь папку

files
    user_uploads      <- сюда указывает MEDIA_ROOT
    collected_static   <- сюда указывает STATIC_ROOT

STATICFILES_DIRS — это список папок, в которых хранится общая статика проекта, и из которых она собирается в STATIC_ROOT командой ./manage.py collectstatic.

Кроме папок из STATICFILES_DIRS collectstatic по умолчанию смотрит еще в папку static у каждого приложения из INSTALLED_APPS.

У html5lib самый корректный и надежный парсер (по спецификации), но она медленная. lxml быстрее всех и парсит достаточно хорошо. Вместо SAX можно iterparse использовать, это удобнее часто, и часто быстрее.

Со своими репозиториями на гитхабе работаю через hg (с помощью hg-git). С чужими — через git.

Что тут можно сказать — использовать hg как клиент к гитхабу можно, и интерфейс командной строки у hg поприятнее, чем у git, но много тонкостей: есть штуки в hg, у которых нет аналогов в гите (named branches) и поэтому полноценного преобразования hg <-> git не получается; у hg-git бывают глюки, и он не все фичи поддерживает. Подход этот точно не для человека, который только взялся за системы контроля версий; чтоб его использовать, нужно достаточно хорошо как hg, так и git знать, и работает он хорошо только для несложных репозиториев (у меня там несколько коммитов в месяц, в основном линейные репозитории).

Если хотите размещать репозитории на github, git выучить смысл есть в любом случае.