Форум: Проблемы искусственного интеллекта

Регистрация | Вход

Все темы | Новая тема  Стр.3 (6) << < Пред. | След. > >>    Поиск:
Автор	Тема: На: автоматический перевод текстов.
admin Сообщений: 292	На: автоматический перевод текстов. Добавлено: 13 апр 07 12:27 Цитата: Автор: daner И вот еще вопрос : я еще не программировал под Линукс, но то что мы будем писать под windows, вообще можно будет под Линукс скомпилировать? или там половину кода менять надо будет? если сделать правильный дизайн у приложения, то перерабатывать под линукс придется лишь визуальную часть приложения/решения [Ответ][Цитата]
admin Сообщений: 292	На: автоматический перевод текстов. Добавлено: 13 апр 07 12:31 Цитата: Автор: daner А с windows заморочка, так как не хочется постоянно сидеть в линуксе (как оказалось в нем нормальных электронных таблиц нет, а у меня в них данные экспериментов). Судя по всему, OpenTrans тоже буду в NB писать. где нет нормальных электронных таблиц? под таблицами понимается что-то типа MS Excel-а? тогда рекомендую попробовать пакет Open Office - доступен как под Linux, так и под Windows. Кстати, опять же согласен с anatoli-ем, Eclipse - приятнее в сравнении с NB, и у них тоже есть достаточно продвинутый плагин преварщающий платформу в C++ IDE, дайте ему шанс, не пожалеете [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 13 апр 07 14:05 Для админа: Мне VS не подходит, так как надо будет под линукс писать (это не для OpenTrans) и приложение коммерческое будет (а не просто "для обучения и домашнего использования"). Про Eclipse я уже написал. Он мне в принципе нравился, пока не заглючил при установки плагина для С\С++. Да и если честно, пока особой разницы не ощутил (последние версии NB намного лучше предыдущих). Единственная проблемка была с компилятором g++(а точнее с make). Не уверен, что в Eclipse, этого не было бы, так как все равно компилятор у него внешний а значит g++. Не так ли? Цитата: где нет нормальных электронных таблиц? под таблицами понимается что-то типа MS Excel-а? тогда рекомендую попробовать пакет Open Office - доступен как под Linux, так и под Windows. К сожалению, это я уже попробовал. Calc от OpenOffice работает замечательно, пока речь идет о маленьких таблицах. Но как только данных переваливает за пару тысячь, Calc начинает ЖУТКО тормозить при любой групповой операции. Создавать графики просто не возможно, на это уходит по 2,3 а то и 5 минут. Есть конечно и другие программы в Линуксе, но они не очень корректно работают с .xls форматом (опять таки, проблема в графиках). [Ответ][Цитата]
admin Сообщений: 292	На: автоматический перевод текстов. Добавлено: 13 апр 07 18:11 понятно, спасибо за интересные факты [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 14 апр 07 0:16 Я не против С++, будем считать этот вопрос решенным. С юникодом проблем на с/с++ не возникает, юзаем w_char и фсе.. Другой вопрос это передача в прогу юникода с веб-сервера и поиск по базе в юникоде. На многих хостинговых серверах стоит mysql, который некорректно работает с юникодом, php только с 5-й версии имеет функции для работы с юникодом, так что надо будет посмотреть. Но если сделать через веб-сервис, то это уже будет не так критично, т.к. будет много способов подсоединения к нему. Для компиляции под линуксом нужно будет использовать другие header'ы и кое-какие функции, имеющиеся под виндой нельзя будет использовать (особенно связанные с multithreading'гом и подсистемой I/O). С'шный stdlib и C++'сный stl есть на обоих системах и работает без изменений. Собственно, их функции и надо использовать при написании платформо-независимых программ. > нужна хоть какая-то синхронизация работы Это верно, для этого надо определить базу проекта, что будет и как. Машинные переводы я предлагаю использовать, как дополнительный источник, имеющий меньший приоритет, чем все остальные. Самый главный - занесенный людьми, второй - симметрично переведенные тексты, а потом уже - переводы других систем. ООНовские доки юзает сам гугл [а я-то думал, у них там сотня-две профессиональных переводчиков сидит и круглые сутки переводят тексты.. а-н нет, все проще и дешевле.. причем способ, доступный всем, а не только мега-.com'ам] Для перевода pdf в текст - нет никаких проблем, если документ не защищен. Если нет защиты, можно просто выделить все (ctrl + a), потом скопировать и вставить в блокнот. Можно заюзать различные проги (http://www.google.com/search?hl=en&q=pdf+to+text&btnG=Google+Search). А еще можно заюзать сам гугл для этих целей. У гугла есть опция конвертинга pdf и ppt в текст, можно ввести название документа (или текст из него) и почти наверняка он появится в гугле с опцией "View as HTML". Насчет MS - это хорошая идея заюзать некоторые крупные сайты, продублированные на разных языках. Надо только проверить, насколько точен перевод. man'ы - тоже хорошая идея, но надо проверить. Все же думаю, такой тип источников надо использовать лишь после исчерпания первого типа, т.к. анализ текста займет очень много времени. А вот передовы художественной литературы - это уже лучше. Там можно глянуть лишь перевод на паре страниц и, если он устраивает, то целиком обработать всю книгу. Т.е. соотношение количество внесенного текста к количеству затраченного на него времени будет выше. Еще тут вопрос - а что делать с языками, которые мы сами проверить не можем? Я хорошо знаю английский, немецкий и испанский. А вот китайский или арабский - не знаю... Что делать с такими направлениями? Или пока ограничиться лишь англо-русско-английским направлением? Но для многих это направление - неактуально. Многих интересует en-sp-en, en-fr-en, en-ge-en. > если сделать правильный дизайн у приложения, то перерабатывать под линукс придется лишь визуальную часть приложения/решения Если сделать через веб-сервис, то на с/с++ будет лишь back-end, front-end же будет на совести другого приложения, которое может быть хоть на java, хоть на php (а может быть вообще что-нить стандартное заюзать). > Единственная проблемка была с компилятором g++(а точнее с make). Не уверен, что в Eclipse, этого не было бы, так как все равно компилятор у него внешний а значит g++ Eclipse без проблем работает с make. Не вижу, в чем тут может быть проблема.. Вот, например, короткая дока: http://www.cs.duke.edu/courses/fall03/cps006x/resources/eclipsemake.html Таким образом, Вы возьмете на себя, daner, поиск и анализ документов/источников перевода (пункт 1)? Я тогда в это время зарегистрирую проект на sf (название OpenTrans) + начну обдумывать структуру БЗ (пункт 2) и, возможно, подниму wiki для проекта. [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 14 апр 07 1:32 Цитата: ООНовские доки юзает сам гугл [а я-то думал, у них там сотня-две профессиональных переводчиков сидит и круглые сутки переводят тексты.. а-н нет, все проще и дешевле.. причем способ, доступный всем, а не только мега-.com''ам] Даже если и так, то эти тексты явно пере-проверяются. Я бегло посмотрел, русский в них хороший, а качество машинного перевода пока еще не спутаешь. ПОКА, OpenTrans не появился шутка. PDF, я знаю как переводить в текст, но как не странно, всегда с этим какие-то проблемы появляются (формат или еще какая фигня). Цитата: Еще тут вопрос - а что делать с языками, которые мы сами проверить не можем? Я хорошо знаю английский, немецкий и испанский. А вот китайский или арабский - не знаю... Что делать с такими направлениями? Или пока ограничиться лишь англо-русско-английским направлением? Но для многих это направление - неактуально. Многих интересует en-sp-en, en-fr-en, en-ge-en. Ну кого интересует, пусть присоединяется к проекту, и берет эти языки на себя. От себя добавлю, что знаю иврит(hebrow). Но думаю нам сейчас достаточно будет на en-ru-en сосредоточится. Цитата: > Единственная проблемка была с компилятором g++(а точнее с make). Не уверен, что в Eclipse, этого не было бы, так как все равно компилятор у него внешний а значит g++ Eclipse без проблем работает с make. Не вижу, в чем тут может быть проблема.. Вот, например, короткая дока: http://www.cs.duke.edu/courses/fall03/cps006x/resources/eclipsemake.html Вы не поняли. Проблема не у Eclipse или Netbeans с make, а просто у make (от GNU) проблема с windows. так что у всех IDE с ним работающих, скорее всего эта проблема будет возникать (он явно не требует cygwin, но и работать ВНЕ cygwin не хочет, судя по всему из-за предопределенных pathes). Я решил ее на пролом : вызываю NB прямо из cygwin. Цитата: Таким образом, Вы возьмете на себя, daner, поиск и анализ документов/источников перевода (пункт 1)? Попробую. Цитата: начну обдумывать структуру БЗ Ну мыслями-то, делитесь. Кстати, не забывайте, что важной частью, является возможность интеграции различных методов перевода. Так что, и база знаний, думаю должна как-то это отражать. [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 14 апр 07 3:02 > Ну кого интересует, пусть присоединяется к проекту, и берет эти языки на себя. Хорошая мысль.. > Ну мыслями-то, делитесь. Делюсь.. Я вижу 2 структуры БЗ. Одна - это внешняя (визуальная), ту, что будут видеть пользователи. С ней, думаю, мудрить не надо и сделать просто: 1. Ручная и автоматическая классификация фраз/предложений по категориям (категории в виде дерева, от общих – 10-20, до частных – сотни-тысячи). Т.е. каждая фраза принадлежит к какой-то категории и ее можно найти пройдясь по дереву категорий. 2. Хранение фраз по парам (при этом не обязательно 1-to-1 соответствие, можно 1-to-2, 3-to-3). Т.е. пользователь будет видеть сразу фразы/предложения на 2х языках (а может даже сделать n-ное количество сразу отображаемых языков, в соответствии с предпочтениями пользователя) 3. Поиск фраз по словам, словосочетаниям. Т.е. фразу можно найти прямо в категории через дерево, или же - через поиск. В принципе, это почти то же самое, что и запрашивать перевод. 4. Debug-информация. Возможность вывода детальной информации о том, на основании чего был сделан именно такой перевод, что послужило источником, какие фразы и какие правила использовались и т.п. А о второй, внутренней структуре (та, с которой будет работать система) еще надо подумать. Чтобы можно было интегрировать новые способы перевода и все такое.. [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 14 апр 07 5:12 Что то я не понял. А зачем это все пользователю? в конце концов, пользователю, надо ввести текст на русском или английском и получить его перевод! А все остальное это чепуха. я думаю, что вы правильно предложили деление на 2 уровня. Только не согласен с уровнями. Мне кажется, это должно быть так : low level: общее описание всей базы знаний. на вскидку, пример: table "worlds" :<id><word><id of language> table "proposals" :<id of word><id of proposal><location><form> table "translation" :<id of proposal><id of proposal> Примичение1: для каждого слово должно быть одно предложение состоящее из этого слова. таким образом мы покрываем в единой формой как простые переводы "слово-слово", так и переводы "предложение-предложение" и "словосочетание-словосочетание" и любые их комбинации (если потребуется). Примичание2: слова нужно хранить в какой-то нормализованной форме (например корни, но есть и другие варианты) Таким образом, это уровень полностью сохранит всю полезную информацию, для любого из методов. high level: дополнительная информация связанная с конкретным методом перевода. тут надо уже конкретно по методам прикидывать. Т.е. этот уровень, это уже скорее уровень оптимизации чем хранения данных. Хотя... возможно здесь будут таблицы "категорий слов", если метод оперирует такими понятиями и прочее. В общем, это надо уже из алгоритма самих методов исходить. [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 16 апр 07 19:39 > А зачем это все пользователю? Я так предположил, что будет 2 типа пользователей (по аналогии с wikipedia). Один тип - это "читатели", другой тип - "авторы". Для читателей (для тех, кому нужен только перевод и ничего больше), тем действительно это ничего не нужно. А вот "авторам" (тем, кто будут вносить новые переводы, править ошибки и т.п.) эта информация будет нужна. Поэтому можно будет сделать настройку: "кто ты?" - "читатель/автор" и, соответсветственно, выводить информацию. Не совсем понял, что означает "id of proposal", но потом подумав, решил, что это - "id предложения" в грамматическом контексте (на англ. это будет sentence). Я прав? Я пока не спешу с внутренним устройством базы, т.к. еще нет четкого алгоритма перевода. Возможно, стоит ввести еще один уровень и тогда получится всего 3: 1. то, что было собрано из источников (начальные источники, типа документов и книг + коррекции пользователей) 2. для пользователей "авторов" 3. какое-то промежуточное состояние для каждой подсистемы перевода Первые 2 можно даже совместить, т.к. они будут отражать почти одно и то же. Хотя, может быть п2 будет более удобочитаемым, нежели п1 (то же самое, что и в п1, но после оптимизации для удобства восприятия). И их устройство - достаточно ясно. А вот п3 - пока не ясен, т.к. нет конкретного представления функционирования алгоритма перевода. Более того, возможно придется создавать дополнительную базу для каждого используемого алгоритма/субсистемы перевода. Если это так, то думаю, мой пункт 2 из общего списка todo будет завершен с определением первых 2х типов из вышеприведенного списка, т.к. определение п3 будет возможным только на этапе написания кода (т.е. пункт 3 из списка todo). И насчет Примичания2: в соответствие с моим представлением о функционировании системы перевода, ей вообще не придется понимать и различать слова (т.е. не будет такого понятия, как корень, которое, кстати, существует далеко не во всех языках), и она сможет работать без дополнительной заточки с любым направлением перевода (была бы под него база знаний)... [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 16 апр 07 21:02 По поводу регистрации проекта на sourceforge: еще в пятницу подал заявку на регистрацию с названием OpenTrans (Unix name: opentrans). Однако с таким названием уже был один проект, но проект полузаброшенный, без каких-либо файлов и только с одним участником. Для этих случаев сф предусматривает возможность замены заброшенного проекта новым не связанным с ним (дабы заюзать его название). На всю эту процедуру им требуется 2.5 недели, и исход может быть как положительным, так и отрицательным. Так что, если через 2 недели откажут с OpenTrans, придется придумывать новое имя. Насчет netbeans, eclipse и разработок под unix: вообще, это целая проблема разрабатывать из-под винды приложения под unix. Я-то думал, Вам надо NB и make под никсом. Вообще, самый пригодный вариант для меня - это использовать UltraEdit под виндой, а файлы чтобы лежали на юниксовом хосте, с поднятым ftp-сервером. Тогда из UtraEdit пишем код (там есть подсветка и фсе такое), а под никсом компилим. У нового UE (UtraEdit Studio) есть возможность компилить и парсить аутпут компилера и других утилит (make сотоварищи) с виндового хоста на никсовом (то ли через шелл, то ли еще как, не смотрел подробно) + полная поддержка проктов, солющнов и т.п. Так что, если уж не юзать, то хотя бы посмотреть рекомендую. Кстати, хорошо настроеный, грамотно изученый и сильно привыкнутый vim очень удобен. У него есть даже аутокомплит (не говоря уж о подсветке синтаксиса и подобных базовых функциях). [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 16 апр 07 22:48 todo-список из поста на 3й странице: 1. Подбор текстов как источников базы знаний 2. Определение/уточнение формата базы знаний 3. Написание кода системы Хотел уже зарегистрировать wiki на wikia.com, но тут подумал, что wiki пока нам будет не нужна еще какое-то время, т.к. сначала нужно будет написать софт для обработки текстов, занести тексты в базу и написать софт для перевода. Стал задумываться над софтом для обработки текстов. Для него требуется распарсить текст и соотнести предложения друг с другом на разных языках. Еще желательно в рамках этой утилиты создать программку для определения годности текста, как источника. Т.е. ей даются 2 текста, а она определяет насколько точен перевод. Есть идеи как это лучше сделать? Я думаю, стоит для каждого направления перевода иметь обычный словарь, т.е. слово -> перевод, и на основании этого просматривать предложения. Если в серии идущих один за одним предложений не встречается ни одного слова (или его форм, или его синонимов/равносильных слов) из тех, что должны были бы быть, значит эти предожения не являются переводом. В целом, эта программа будет полезна и в дальнейшем, когда пользователи будут вносить свои варианты. Если в тексте идет слово "красный", а его заносят, как "green", то тут надо будет либо заблокировать перевод, либо поставить предупреждение, как "возможно некорректный перевод". Теперь вопрос: где взять обычный словарь? Кто-нибудь знает, являются ли копирайтными работами содержимое словарей? Например, права на телефонный список не могут быть получены и его содержимое можно использовать без каких-либо проблем. А как обстоят дела с содержимым словарей? Если их можно использовать в своих нуждах, то можно было бы вытащить базу из лингво по наиболее распространенным направлениям (en, fr, sp, de, it, pt, ru). Кстати, подобная база пригодилась бы и в целом, когда пользователь хочет знать точный перевод конкретного слова. [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 16 апр 07 22:50 Нда... с proposal я прогнал, это конечно же sentence. Что касается корней. Это был пример. Я имел в виду вообще, какую-то базовую форму слова. или вы предлагаете "mail" и "mails" хранить отдельно? На счет названия. ну через две недели, так через две недели. Что касается представления БЗ для пользователей-авторов, то думаю, это вопрос скорее GUI, чем самой БЗ. Хотя, вообще, деление на 2 типа пользователей, я согласен, должно присутствовать. [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 16 апр 07 23:00 Касательно первичной обработки. Я думал точно также делать, как вы описали, только думаю, опред. процента слов достаточно , что бы сказать, что предложение подходит (причем не обязать. по порядку). А вот на счет "фильтра" переводов... думаю, это весьма не тривиально... так что, не знаю, стоит ли им заниматься (хотя конечно это удобная вешь ). По поводу словарей. Вроде бы, у меня был словарь анг-рус и рус-анг, в txt формате. [Ответ][Цитата]
anatoli Сообщений: 249	На: автоматический перевод текстов. Добавлено: 16 апр 07 23:24 > вы предлагаете "mail" и "mails" хранить отдельно? Я предлагаю их не хранить вообще. А хранить, например: "I've sent him a mail", "You have 3 new mails", и т.д. При этом, предложения типа: "Она насыпала кошке еды и пошла прибирать спальню" хранить как 2 раздельных: "Она насыпала кошке еды" и "пошла прибирать спальню". Но при этом хранить информацию о том, что они были изначально одним предложением (для контекста и/или для иных целей). > Что касается представления БЗ для пользователей-авторов, то думаю, это вопрос скорее GUI, чем самой БЗ. Отчасти да, но с другой стороны это представление будет являться самой БЗ. Вот интересно, как хранится информация в wikipedia? Надо будет посмотреть содержимое таблиц. > Я думал точно также делать, как вы описали, только думаю, опред. процента слов достаточно, что бы сказать, что предложение подходит (причем не обязать. по порядку). Да, само собой. Но процент этот, мне кажется, дожен быть достаточно высоким. Т.е. если определенного слова (а не союзов/предлогов), которое в принципе встречается в таких случаях (т.е. НЕ случаи, аналогичные "есть" в настоящем времени при переводи "It is here"), нет вообще ни в какой форме, ни его синонимов, то это уже выглядит несколько подозрительно. А если уже нет 2х слов, то, вероятно, это упрощенная форма перевода, которая, может быть, в определенных случаях и подойдет как перевод, но не может служить источником правильного перевода. Не присматривались к субтитрам в фильмах? В них обычно содержится не более 40-50% оригинальной фразы. Смысл в целом они доносят, но не являются правильным переводом. Еще тут есть такой нюанс, как очень кородкие предложения, к тому же являющиеся чем-нибудь вроде поговорки, которую нельзя перевести буквально. Для этого мы анализируем предложение до него и после. Если те предложения корректны, значит это предложение мы тоже считаем корректным. Следует заметить, что это может приводить к ошибкам, но с другой стороны, во-первых, имея большую БЗ подобные случаи будут просто теряться, а во-вторых мы же не претендуем на 100%ную правильность перевода. Если правильность/корректность будет более 95%, это уже будет лучше многих людей-переводчиков. Вот статистические данные: в своих произведениях Пушкин в сумме использовал 25К слов, в то время как образованные люди используют в своей речи не более 5К, а обычные люди (скажем, без высшего образования) используют не более 2-3К. Так что, если обработать большинство произведений классиков, то уже эта БЗ будет иметь многократно перекрывающиеся "обычные" фразы и выражения. > А вот на счет "фильтра" переводов... думаю, это весьма не тривиально... так что, не знаю, стоит ли им заниматься (хотя конечно это удобная вешь). Вообще, многие считают машинный перевод чем-то сильно сложным. Однако уже существующие идеи - достаточно просты. Что же касается фильтра и системы анализа текста - тут мы просто рассчитываем вероятность появления того или иного слова (или его отсутствие) в предложении и ничего больше. Если вероятность велика, а его нет, или присутствует соовсем другое слово, вероятность появления которого крайне мала, то мы помечаем перевод как _возможно_ неправильный и/или некорректный/неточный. Ничего сверхъестественного.. Да, вот еще.. надо будет дать людям возможность загружать свои переводы (само собой, проверяя их каким-либо образом в какой-либо момент времени). Таким образом мы добьемся того, что КПД переводчиков в планетарном масштабе значительно увеличится. То, что сделал однажды один, не придется заново делать другому. Сейчас оно практически так мало, как 1 / общее количество переводчиков. [Ответ][Цитата]
daner Сообщений: 4593	На: автоматический перевод текстов. Добавлено: 17 апр 07 0:18 Цитата: Я предлагаю их не хранить вообще. А хранить, например: "I''''ve sent him a mail", "You have 3 new mails", и т.д. При этом, предложения типа: "Она насыпала кошке еды и пошла прибирать спальню" хранить как 2 раздельных: "Она насыпала кошке еды" и "пошла прибирать спальню". Но при этом хранить информацию о том, что они были изначально одним предложением (для контекста и/или для иных целей). Ну совершенно с этим не согласен. Это не рационально и не удобно. Т.е при сравнение двух предложений, вам каждый раз понадобится их парсить. Ну оооочень "удобно". Та структура БЗ, которую я предложил, с лихвой покрывает ваш пример. Кроме этого, не забывайте, что главное условие дизайна - интеграция различных способов, и это не значит, что сама БЗ должна быть просто сырым текстом. Если вы не до конца поняли, предложенный мной вариант low level, то лучше я его еще раз поясню. Все что я хотел, это только один раз прапарсить исходники, а дальше работать только с id слов. Что касается разбиения на различные предложения, это можно и над предложенной мной БЗ сделать. Но сразу хочу предупредить. Я бы не советовал, на это сильно налегать. Такое разбиение сложно сделать, а если учитывать, что в разных языках, разные правила построения и препинания, вообще почти не реально (единым способом). [Ответ][Цитата]
Стр.3 (6): 1  2  [3]  4  5  6 << < Пред. | След. > >>