Comments 13
Интересная тема - но, всё-таки, мне кажется лучше делать основной спелчек в рантайм - т.е. во время основного набора текста программы - условно так же как это делается в офисных программах с обычным текстом. Так же и пополнять словари - в идеале они должны быть облачные
Здравая мысль) так будет, конечно, гораздо-гораздо лучше - человек сможет видеть опечатку, и чаще её не допустит. Однако спелчек в рантайме, во-первых, штука не принудительная (если вы хотите получать выборку текстов для алгоритма, то вас могут не устроить опечатки, сделанные по приколу или потому что пофиг), а во-вторых, это всё-таки решение на уровне архитектуры, не всегда это можно реализовать. Когда мы имеем дело с выборкой, вытащенной со стороннего источника (а это, имхо, частый случай в практике обработки текстов) - условно, с сайта социальной сети - мы никак не прикрутим туда спелчекер в рантайм, если его там нет (ну, если только это не наша собственная соцсеть, но тогда это не сторонний источник).
О какой выборке вы говорите. Я думал статья об исправлении ошибок в текстовых ресурсах, литералах и комментариях (ну может ещё в идентификаторах) внутри программного кода.
Если же речь идёт о переводе условно пользовательских текстов - то это совсем другой вопрос и другие решения.
Но всё равно, опечатки и ошибки куда проще анализировать и устранять в рантайм, чем автоматической обработкой готового результата, да ещё и без автора оного опуса.
Да, я не исключая, что обработка готовых текстов тоже важна - но её качество будет ниже. А настройка такой системы - куда сложнее и затратнее.
Просто я намедни тоже думал на подобную тему - но у меня задача другая - не исправление опечаток, а языковой перевод - с одной стороны те же ошибки и опечатки и уникальные термины и имена для перевода тоже большая проблема; с другой стороны - даже без них по сути у меня те же проблемы - анализ словоформы и поиск перевода по словарю по адаптированному слову (но у меня хуже - мне ещё и контекстный анализ делать нужно - но это уже другая проблема), а затем адаптация перевода к исходной словоформе.
И я как раз задумывался над тем, что в программных алгоритмах (вне самого программного кода) может быть внутри много специфической терминологии - в тех же комментариях могут быть просто алгоритмы, или их отдельные части. И всё это надо вычленять из обработки, и вообще там свою нюансы. А уж если говорить о литеральных строках - то там, в-первых, могут быть выражения программного кода (как нынче модно стало), или на крайняк какие-то идентификаторы, на которые ориентируется программный код; во-вторых, изменение текста в строке может нарушить всю работу программной обработки этой строки. Короче - проблем куча - вот и задумался я, как же это всё можно было бы порешать. Пока надумал только то - что нужно создавать специальные "словари" для описания исключений - где можно было бы их задавать (и нужен ещё удобный инструмент по их настройке, в т.ч. прям чтобы можно было в исходном коде настраивать даже), так же как нужен будет и специальный лог - куда алгоритм трансляции мог бы записывать выявленные условно сложные и не однозначные места - чтобы потом по ним настраивать исключения (с готовыми решениями). В общем тут есть над чем подумать. Увы, Вы пока эту тему никак не раскрыли - хотя проблемы у нас схожие
"Качество обработки готовых текстов не так хорошо работает, как в рантайме, но иногда это всё чем мы располагаем. Иногда просто говорят — вот у нас там есть база за десять лет — и спеллчек, будет он вам нужен, в рантайм уже не поставить.
Вообще проблема интерпретации в комментариях и кодах — это интересная тема. Все вот эти тонкости анализа на низком уровне: стили написания переменных, специальные машинные и обычные человечьи комментарии, куски кода. Но мне она в основном приходила в голову во времена, когда у меня была активная переписка кусками кода в перемешку с текстом, либо когда была необходимость, собственно настроить, спеллчек в IDE — на практике,чтобы надо было решать, не встречалось. Вообще-то мне казалось, в PyCharm это как-то интересно работает... И как-то он игнорирует конструкции кода. Но это ж IDE, она видит весь проект, либы, вычленяет функции и так далее.
Собственно, и с фамилиями, мне кажется, самый интересный путь — их оттуда выковыривать NER-ом, примерно как вы говорите о вашей задаче и о вычленении кода из комментариев. И попытаться специальную понималку сделать, отдельную. Её, технически, можно дополнять с каких-нибудь баз, если таковые для задачи имеются. Можно попытаться строить предположения по датам в контексте, по каким-то таким факторам…
А с переводом и комментариями, кстати, наверное, совсем весело — комментарий-то может быть написан на двух языках пополам (притом один из них может существовать только в голове автора). Но, возможно, это не кейс для больших и качественных проектов, которые станут проверять орфографию автоматически.
Но вообще-то, да, проблем действительно куча. Будем думать) Когда возьмёмся за что-нибудь интересненькое — постараемся рассказать."
Говоря о комментариях, наверное первую очередь имел в виду комментарии авто документирования (а там свои правила их написания есть; да на Python это литеральные строки, а не комментарии, но у меня C#) и TODO блоки. С остальными комментариями всё хуже - но перевести их тоже хоть как-то хотелось бы.
Ну а литеральные строки - так и есть - просто текст, всё бы ничего - вот только интерполированные строки всё портят (особенно учитывая, что там ещё и вложенная интерполяция может быть неограниченной глубины; ну и алгоритмы завязанные на содержимом строк, особенно когда в строке, условно, часть алгоритма или хотя бы какие-то идентификаторы содержатся - вот это да, проблема, наверное только через словарь исключений это решить можно.
К счастью, для меня этот перевод не являются ключевой задачей - пока хотя бы как-нибудь реализовать надо
Для неключевой задачи звучит очень серьёзно)
Очень любопытная задача у вас. Для чего же это требуется - по дороге - реализовать автоперевод? Есть какой-то вывод автокомментирования, и его хотелось бы иметь на другом языке?
Мне почему-то кажется, что если бы вот сделать какой-нибудь алгоритм, который бы смотрел на слово (токен) и определял, условно, исповедимы ли пути того, кто это написал (ну там, если это переменная, или конструкция, или вроде, то отбрасывать), то качество спелчека (и перевода, вероятно) возросло бы. В PyCharm - вроде как - они, хитрые черти, просто не проверяют слова, из 3-х букв и меньше. Но это тоже, на самом деле, не так качественно. Можно попробовать нейронку для этого сделать) Или какой-то ещё классификатор. Ну, и, вероятно, какой-нибудь специфицированный под такое токенизатор взять.
Можно попытаться засунуть в алгоритм вообще все существующие слова, но это чревато ошибками вроде «Барье» → «барье» как название географического объекта (Люблянское барье, болотный массив в Словении), вместо «Дарье» как дательный падеж распространённого женского имени. Такие ошибки не сделают данные лучше.
Не согласен в корне. Весь подобный софт (который работает с произвольным человеческим текстом, включая умные клавиатуры, голосовые распознавалки, и поиск Гугл) работает через оценку вероятностей (причем, не имеет значения, это прописано явно в коде, или скрыто в недрах нейросети). И, в данном случае, такие алгоритмы сравнивают вероятности P(написано Барье, вместо Дарье)*P(речь в контексте идет о Дарье) и P(написано Барье, вместо барье)*P(речь в контексте идет о барье).
Подобным допущением вы, по сути, приравниваете P(речь в контексте идет о барье) к 0, забив хардкод. Что в этом хорошего, - да, работать будет быстрее, и памяти понадобится меньше, но мы хотим качество, а не, чтобы айтишников заменяло на артишоки?
теперь посмотрим вот это
>letter = letters[min(random.randint(0, len(letters)), len(letters) - 1)] тут, снова таки, взят какой-то сферический конь в вакууме, ведь, ошибки не происходят просто так, - они обусловлены способом ввода (qwerty, надиктовка, кнопочный телефон) и особенностью конкретного человека (все ли у него исправны клавишы, печатает одной рукой, или двумя, насколько грамотен). Все это влияет на распределения, и хороший спеллчекер должен именно там черпать информацию для того, чтобы оценить, например, P(написано Барье, вместо Дарье). Если метать ошибки от балды при помощи randint, то, фактически, мы этим даем преимущество плохому спеллчекеру, ибо он не будет снижать качество работы, пытаясь найти вероятности, исходя, например, из раскладки клавиатуры, или статистики ошибок
Интересное замечание. Во-первых, не все алгоритмы анализа близости работают в стохастическом предположении - те же расстояние Левенштейна или алгоритм шинглов. Они отлично работают вне вероятностного подхода.
Анализ с контекстом - это принципиально другой путь, который труднее, и даёт определённые преимущества, однако в контексте рассматриваемой задачи - эти преимущества не особо помогают, а, наоборот могут помешать. Да, "барье" и "Дарье" вы отличите, но с контекстуальным подходом легко возможен следующий сценарий. Например, фамилии Барьев и Дарьев (никак не связанные, кроме похожести написания) встречаются в корпусе в разных контекстах, например Барьев встречается в контексте спорта, а Дарьев в контексте кульинарии и выпечки. Означает ли это, что все их однофамильцы поголовно (или, иначе - в строгом соответствии пропорции, которая отражена в выбранном корпусе) заняты исключительно соответствующей тематикой? Ну, нет. Сможем ли мы избежать этого эффекта "примагничивания тёзок и однофамильцев", пользуясь исключительно средствами контекстуальной вероятности? Без дополнительных телодвижений - очень вряд ли. Напомню, что контекст задачи в основном правописание фамилий.
Во-вторых, я не настаиваю на каком-то из подходов как на единственном. Фактически, я просто даю подспорье тем, кто ищет статистические данные для аналогичных задач. Jumspell, который я тестирую здесь, построен на работе с корпусом и контекстом, Pyenchant, который я также рассмаотриваю, работает на основе полностью прописанного экспертами словаря, без частот. Они интересны в применении к нетривиальной проблеме правки фамилий, которая на практике возникает довольно часто.
BTW, как-то раз мне попадался прекрасный сайт, на котором были представлены чьи-то результаты - просто англоязычный текст "Гордости и Предубеждения", к которому была применена контекстуальная замена. Всё не могу его найти, жалко - очень меня этот текст впечатлил в своё время. Там прямо с первых слов понимаешь, что у контекстуального представления о слове есть и свои минусы - "man" было заменено на "woman", "wife", кажется, на "bride" - и пословно всё выглядит ещё куда ни шло, но от прагматического смысла оригинальных строчек просто следа не остаётся.
Касательно внесения правок - да, я тестирую на рандомных правках - не то чтобы я как-то держу это в тайне. И я не обучаю эти алгоритмы на данной выборке (вот это действительно было бы вредно). Для начала мне интересно было получить эти результаты, на выборке, абстрагированной от механики ошибки. Чтобы специфицировать ошибку, нужно было бы выбрать конкретный характер текстов - рукописный сканируемый (это одни соответствия), вводимый голос (совсем другие), неаккуратная печать на клавиатуре (уже третьи) и т.д. Можно придумать, как прикрутить туда симуляцию более натуральной ошибки (и посмотреть, даст ли соединение классического расстояния Левенштейна и нечёткой матрицы соответствий букв что-то интересное по точности).
Сможем ли мы избежать этого эффекта "примагничивания тёзок и однофамильцев", пользуясь исключительно средствами контекстуальной вероятности?
Тут интересная философская проблема. Действительно, тому меньшинству, которому не повезло быть в тени какого-то большего созвучного смысла, предначертано страдать. На эту тему есть старая история о том, как кто-то из великих писателей писал (племянник) после своей фамилии в начале творческого пути, а в конце, уже его дядя стыдливо уточнял (дядя).
Если непонятно, что я имею ввиду, привожу поясняющий пример: слово «флешка» Гугл считает правильным, а слово «флэшка» — ошибочным, тогда как по-моему, должно быть наоборот.
Если мне ответят, что Гугл советуется с русскими языковыми академиками — извините, не поверю, там явно кто-то попроще, да ещё этот кто-то хорошо прикрыт от обращений простого народа с улицы.
Не знаю, как это происходит в Гугл, но вообще-то почему бы им не пользоваться услугами российских специалистов русской лингвистики? Так же как логично было бы привлечь испанского лингвиста для формирования языковой модели испанского языка. Даже если нет, у них могут быть лингвисты русского языка другой национальности - у нас же существуют углубленные специалисты по английскому, китайскому или немецкому. Если у вас есть в этом потребность, наверное, можно обратиться в поддержку Гугл. Или поискать какие-нибудь конференции, где Гугл, может быть выступал - может быть, касательно русского языка - может быть, там были какие-нибудь адреса почтовых ящиков. Но вообще-то это всё - зыбкие предположения. Меня вполне устраивает и вариант "флешка")
Ведь не секрет, что на практике многие подтягивают свою нормативную грамотность, хромающую ещё со школы, именно через пользование спеллчекерами. И если там в базах изначально присутствуют ошибки, то со временем эти ошибки в сознании людей устаканиваются, приобретают статус нормы. И никакие академические словари с их мизерными тиражами этого перебороть не смогут, потому что спеллчекер — это повседневность.
Так что меня удивляет ваше легковесное отношение к тому, что норма русского языка формируется не в русском обществе. Сразу скажу, политика тут ни причём, и если бы у меня была возможность влиять на гугловские языковые базы данных, я бы так не беспокоился.
Язык формируют люди, которые его используют: в том числе - и в первую очередь - читают на нём и пишут. Причём не просто пишут, но формируют литературу - книги, журналы, научные статьи. Когда человек корябает в социальной сети что-то полуправильное - это всё равно не литературная речь, по сути, а свободный разговор в письменной форме. Как на заборе.
Не представляю себе ситуации, в которой какой-нибудь писатель, рецензер, корректор - посмотрит в словарь Гугла или MS (или, ещё хуже - социальную сеть), чтобы скорректировать свои представления о правилах орфографии. То, что сервис "Google.Documents" не воспринимает букву "ё", никогда не было и не станет (для меня, во всяком случае) причиной заменять при письме букву "ё" на "е". Точно так же, между прочим, как игнорирование буквы "ё" в российском учебнике по русскому языку не было причиной писать иначе. Моя фамилия, которой обычно не бывает в словарях, не меняется на что-то попроще, чтобы только Word перестал её подчёркивать красненьким.
Спеллчекер - это такой же сервис, как все остальные. Из речи ведь не пропадают слова только потому, что в словаре Гугла их нет. Потому что сервис делают для реальности, но ни в коем случае не наоборот. Норма языка формируется совершенно иначе - не через то, как большинство людей пишет или думает надо писать - а через то, что считается правильным у довольно узкого круга действительно образованных людей.
Если вам кажется, что базы Гугла недостаточно хороши - наверное, нам с вами имеет смысл изучать официальные словари, через них проверять написания слов, в которых мы затрудняемся. Но вообще-то вполне вероятно, что базы Гугла во многом опираются на те же самые словари.
Мечты о хорошем спеллчекере без лишних заморочек