Корпусная инженерия
В языкознании (так по-старинке у нас кличут linguistics) есть корпусная лингвистика (corpus linguistics): дисциплина, занимающаяся изучением наборов текстов с какими-то предзаданными характеристиками (например, "типичные транскрипты чатов 2004г.", "художественная проза XIX века", "милицейские протоколы лета 1993г.", "современные богослужебные тексты" и т.д.). Фишка в том, что эти наборы текстов тщательно отбирают, затем тщательно размечают (отмечают части речи, иногда делают более-менее полный разбор предложений -- кто во что горазд. Разметка проводится когда машинно, когда вручную, вычищая потом ошибки всем миром), а потом их используют для самых разных исследований и тестирования софта. И поскольку содержание этих корпусов (множественное число от corpus -- corpora) хорошо известно, то становится возможным как обучать и отлаживать алгоритмы работы с текстами на этих корпусах, так и сравнивать их. Про учебные (например, чтобы найти тексты, максимально охватывающие наиболее часто встречающиеся слова в какой-то предметной области -- и потом гарантировать ученикам освоение "словарного минимума") применения пока умолчим, но их тоже множество (обзорчик: http://www.corpus4u.org/forum/upload/forum/2005081523415585.pdf). Также корпусы используются для составления словарей (как в части "какие слова бывают", так и в части "примеры использования"). Ну, и для тестирования вполне определенных алгоритмов (например, алгоритмов сжатия: http://corpus.canterbury.ac.nz/).
Создание корпуса -- очень затратное и тяжёлое дело, больше всего похожее на создание стандарта, и поэтому занимаются созданием корпусов главным образом консорциумы. Пример такого консорциума -- Linguistic Data Consortium (http://www.ldc.upenn.edu/). Вот, например, один из тамошних продуктов: телефонные разговоры на русском (http://www.ldc.upenn.edu/Catalog/CatalogEntry.jsp?catalogId=LDC2006S34), можно купить по сходной цене $1000. И это даже не тексты, а записи речи (.wav-файлы). Так, если вы делаете распознавалку русской речи, то вас могут попросить протестировать её на этих данных. Это очень удобно: результаты будут много более объективны, нежели тестирование на собственных данных, да ещё и можно будет посравнивать с результатами других распознавалок.
Но не всё в мире корпусов так дорого, многое доступно бесплатно.
Вот Национальный корпус русского языка, объемом 364млн. словоупотреблений, плюс еще церковнославянский корпус на 4.7млн. словоупотреблений -- http://ruscorpora.ru/. Конечно, для такого огромного собрания текстов копирайтные проблемы весьма суровы, и статус нашего Национального корпуса пока неопределён. И отдельные корпусы получить сейчас нельзя. Но консорциум для поддержания Национального корпуса русского языка в организационной стадии, и ситуация с бесплатной раздачей его отдельных наборов данных постепенно наладится.
Адаптеры доступа к основным корпусам текстов есть практически во всех лингвистических платформах (frameworks: GATE, UIMA) и библиотеках (NLTK и т.д. -- поглядите, например, как корпуса используются для обучения студентов лингвистике с помощью NLTK: https://sites.google.com/site/naturallanguagetoolkit/book).
Этот же корпусной подход применяется и для кодов, прежде всего программных текстов. Если собрать в одном месте много-много разных текстов программ, то их потом можно долго и плодотворно изучать: http://qualitascorpus.com/pubs/QualitasCorpusAPSEC2010.pdf. Вот, например, попытка изучить "синтаксическую избыточность" кодов на C, C++ и Java с использованием исходных кодов 6000 разных проектов из sourceforge: http://www.utdallas.edu/~mgg110030/publications/papers/fse10.pdf
Основная мысль этого моего поста -- это необходимость собирать инженерные корпуса: технические стандарты, проекты, регламенты работы. И инженерный софт (который никогда не работает в одиночку) исследовать и проверять на этих корпусах, а студентов на этих корпусах учить.
Тут огромное число содержательных проблем, и только маленькая часть из них связана с организационными вопросами, финансированием работ, злобными копирайтами на данные инженерных моделей и проектов (я ведь не имею ввиду коды инженерного софта, меня интересуют тексты и коды, описывающие целевые системы инжиниринговых компаний, а также тексты и коды, описывающие сами компании -- в рамках организационной инженерии).
Так, огромное число инженерных данных существуют только в проприетарных форматах соответствующих САПР (ну, и часть информации доступна в форматах соответствующих PLM). Как хранить: оригинальные файлы? Выгруженную маленькую часть из наличных данных (например, в нейтральных форматах представлении геометрии)? Что делать с дополнениями данных, неизбежных для каждой конкретной организации ("настройки": например, P&ID с настройками, с использованием какой-то определённой системы идентификации) -- ибо без справочных данных невозможно прочесть данные проекта? Что делать, если массово используются ссылки на данные в других информационных системах (каталогах, PLM)? Что делать, ежели часть информации присутствует не в инженерных данных, а в коде софта -- и результирующая информация доступна только на чертежах (куда часть надписей приходит из данных, а часть -- из кода софта)? Что делать, если проект доступен не в одном формате данных, а сразу в десятке (не в том смысле, как "формат .doc и .txt для текстов", а в смысле "формат представления 3D геометрии и формат плана производства работ"-- для разных инженерных специальностей)?
Многие из этих вопросов в том или ином виде существовали и для лингвистических корпусов, и для корпусов исходных кодов софта. Но в случае зоопарка инженерных данных и справочных данных инжиниринговой компании заимствовать эти решения невозможно, разве что если собирать полнотекстовые документы только: регламенты и стандарты. Но в инженерных регламентах и стандартах будут таблицы, картинки, ссылки на элементы картинок и таблиц в тексте -- поэтому и тут придётся что-то придумывать.
Но без стабильных наборов данных -- корпусов -- нельзя отлаживаться, в том числе нельзя сравнивать работу разных программ с этими данными. Это шаг к стандартизации. Да, я знаю про "стандартизацию квадратных колёс" и последующую индустрию производства рельсов, совместимых с этими квадратными колёсами. Но стандартизация даже квадратных колёс обычно ведёт к бурному развитию рынка. Кстати, а почему "лучшие решения" с круглыми колёсами регулярно проигрывают? Почему люди готовы изготавливать рельсы для квадратных колёс, но что им мешает массово изготавливать рельсы для круглых колёс?! Наличие корпусов данных, наглядно демонстрирующих преимущество круглых колёс и рельсов для них перед простыми в изготовлении квадратными и рельсами для них, сильно бы помогло.
Нужны свободные инженерные данные. В количестве. Доступные всем разработчикам инженерного софта. Нужна не только корпусная лингвистика, но и корпусная инженерия.
Чем и займёмся.
Создание корпуса -- очень затратное и тяжёлое дело, больше всего похожее на создание стандарта, и поэтому занимаются созданием корпусов главным образом консорциумы. Пример такого консорциума -- Linguistic Data Consortium (http://www.ldc.upenn.edu/). Вот, например, один из тамошних продуктов: телефонные разговоры на русском (http://www.ldc.upenn.edu/Catalog/CatalogEntry.jsp?catalogId=LDC2006S34), можно купить по сходной цене $1000. И это даже не тексты, а записи речи (.wav-файлы). Так, если вы делаете распознавалку русской речи, то вас могут попросить протестировать её на этих данных. Это очень удобно: результаты будут много более объективны, нежели тестирование на собственных данных, да ещё и можно будет посравнивать с результатами других распознавалок.
Но не всё в мире корпусов так дорого, многое доступно бесплатно.
Вот Национальный корпус русского языка, объемом 364млн. словоупотреблений, плюс еще церковнославянский корпус на 4.7млн. словоупотреблений -- http://ruscorpora.ru/. Конечно, для такого огромного собрания текстов копирайтные проблемы весьма суровы, и статус нашего Национального корпуса пока неопределён. И отдельные корпусы получить сейчас нельзя. Но консорциум для поддержания Национального корпуса русского языка в организационной стадии, и ситуация с бесплатной раздачей его отдельных наборов данных постепенно наладится.
Адаптеры доступа к основным корпусам текстов есть практически во всех лингвистических платформах (frameworks: GATE, UIMA) и библиотеках (NLTK и т.д. -- поглядите, например, как корпуса используются для обучения студентов лингвистике с помощью NLTK: https://sites.google.com/site/naturallanguagetoolkit/book).
Этот же корпусной подход применяется и для кодов, прежде всего программных текстов. Если собрать в одном месте много-много разных текстов программ, то их потом можно долго и плодотворно изучать: http://qualitascorpus.com/pubs/QualitasCorpusAPSEC2010.pdf. Вот, например, попытка изучить "синтаксическую избыточность" кодов на C, C++ и Java с использованием исходных кодов 6000 разных проектов из sourceforge: http://www.utdallas.edu/~mgg110030/publications/papers/fse10.pdf
Основная мысль этого моего поста -- это необходимость собирать инженерные корпуса: технические стандарты, проекты, регламенты работы. И инженерный софт (который никогда не работает в одиночку) исследовать и проверять на этих корпусах, а студентов на этих корпусах учить.
Тут огромное число содержательных проблем, и только маленькая часть из них связана с организационными вопросами, финансированием работ, злобными копирайтами на данные инженерных моделей и проектов (я ведь не имею ввиду коды инженерного софта, меня интересуют тексты и коды, описывающие целевые системы инжиниринговых компаний, а также тексты и коды, описывающие сами компании -- в рамках организационной инженерии).
Так, огромное число инженерных данных существуют только в проприетарных форматах соответствующих САПР (ну, и часть информации доступна в форматах соответствующих PLM). Как хранить: оригинальные файлы? Выгруженную маленькую часть из наличных данных (например, в нейтральных форматах представлении геометрии)? Что делать с дополнениями данных, неизбежных для каждой конкретной организации ("настройки": например, P&ID с настройками, с использованием какой-то определённой системы идентификации) -- ибо без справочных данных невозможно прочесть данные проекта? Что делать, если массово используются ссылки на данные в других информационных системах (каталогах, PLM)? Что делать, ежели часть информации присутствует не в инженерных данных, а в коде софта -- и результирующая информация доступна только на чертежах (куда часть надписей приходит из данных, а часть -- из кода софта)? Что делать, если проект доступен не в одном формате данных, а сразу в десятке (не в том смысле, как "формат .doc и .txt для текстов", а в смысле "формат представления 3D геометрии и формат плана производства работ"-- для разных инженерных специальностей)?
Многие из этих вопросов в том или ином виде существовали и для лингвистических корпусов, и для корпусов исходных кодов софта. Но в случае зоопарка инженерных данных и справочных данных инжиниринговой компании заимствовать эти решения невозможно, разве что если собирать полнотекстовые документы только: регламенты и стандарты. Но в инженерных регламентах и стандартах будут таблицы, картинки, ссылки на элементы картинок и таблиц в тексте -- поэтому и тут придётся что-то придумывать.
Но без стабильных наборов данных -- корпусов -- нельзя отлаживаться, в том числе нельзя сравнивать работу разных программ с этими данными. Это шаг к стандартизации. Да, я знаю про "стандартизацию квадратных колёс" и последующую индустрию производства рельсов, совместимых с этими квадратными колёсами. Но стандартизация даже квадратных колёс обычно ведёт к бурному развитию рынка. Кстати, а почему "лучшие решения" с круглыми колёсами регулярно проигрывают? Почему люди готовы изготавливать рельсы для квадратных колёс, но что им мешает массово изготавливать рельсы для круглых колёс?! Наличие корпусов данных, наглядно демонстрирующих преимущество круглых колёс и рельсов для них перед простыми в изготовлении квадратными и рельсами для них, сильно бы помогло.
Нужны свободные инженерные данные. В количестве. Доступные всем разработчикам инженерного софта. Нужна не только корпусная лингвистика, но и корпусная инженерия.
Чем и займёмся.