Лингвистика в инженерной компании: наш путь
Для чего в инженерных компаниях пытаются использовать лингвистические технологии? Да для самого разного! Так что нам изо всех возможных применений нужно выделить какое-то одно. Я думаю, что стоит заняться извлечением из текстов формальных инженерных моделей, пригодных для обработки в CAD/PLM. Извлечение данных в соответствии с какой-то определенной моделью данных из текстов на естественном языке в лингвистике называется извлечением информации (information extraction), иногда особо выделяя темы добычи из текстов (text mining, оно же -- "раскопки текста", "глубинный анализ текста") и fact extraction (извлечение актуальных фактов, в отличие от извлечения общих знаний и закономерностей). Вот цветастенькие слайды с объяснениями "на пальцах": http://suchanek.name/work/teaching/IE2011a.pdf. Вот более формальный обзор: http://osm.cs.byu.edu/CS652s09/papers/Sarawagi.ieSurvey.pdf. Остальное легко нагуглить, выучив встречающиеся в этих обзорах ключевые слова.
Нам нужно вытаскивать из текстов инженерные модели, которые затем будут обрабатываться в конкретном САПР. Идеально-утопический вариант -- делать это сразу в языке программирования этого САПР, вытаскивая информацию в тамошние типы данных. Но тут сразу две засады:
1. информация всё равно будет храниться в объектной базе данных (часто это даже не база данных САПР, а база данных PLM). Модель данных базы данных CAD/PLM не эквивалентна модели данных языка программирования САПР.
2. одна и та же извлеченная информация может затем использоваться многократно, в самых разных САПР, а храниться в самых разных PLM.
То есть информацию правильно извлекать из текста не сразу в типы языка программирования, использованного в PLM/CAD системе, а либо в модели данных объектной базы данных CAD/PLM (сдаться какому-то вендору САПР с потрохами), либо в модели данных "общесапровского общеинженерного" формата.
Общесапровскую "резиновую" (то есть гарантированно закрывающих любую клиентскую кастомизацию инженерных данных, обрабатываемых CAD/PLM разных вендоров) я знаю только одну модель данных: это ISO 15926. Тем самым извлечение информации из текстов должно производиться в формат ISO 15926, из которого далее хорошо разработанными в тусовке ISO 15926 средствами архитектуры IRING (ISO 15926 outside) мэппиться в модель данных конкретной CAD/PLM системы, а затем уж использоваться внутри языка программирования этой системы в привычных для computer science системе типов языка программирования -- но этот последний вопрос мэппинга из "родной" для конкретной CAD/PLM системы объектной базы данных в типы языка программирования этой системы решается для каждой CAD/PLM системы её разработчиками.
Теперь можно сформулировать наш подход к лингвистике:
1. Нас интересует классическое извлечение онтологии из текста (это традиционная для лингвистов задача, обсуждается во всех учебниках).
2. Нас интересует извлечение не любой ad hoc онтологии (что у лингвистов часто), не онтологии semantic web (что не менее часто), а ISO 15926 онтологии.
3. Мы готовы предложить пошаговую процедуру для этого извлечения онтологии: распознавание паттернов шаблонов ISO 15926 по штучке за раз -- медленно повышая процент распознавания каждого отдельного паттерна, добиваясь роста precision (числа верно распознанных) и recall (числа всех найденных) до величин, сравнимых с ручным распознаванием.
Поскольку в самом ISO 15926 есть много вариантов (семантическая сетка части 2, шаблоны, паттерны шаблонов, OIMs, Gellish-подобные форматы и т.д.), то возможны самые разные варианты технологии -- над этим нужно будет ещё думать. Но в целом предлагается вытаскивать из инженерных текстов паттерны шаблонов ISO 15926 -- постепенно наращивая точность вытаскивания каждого паттерна и число вытаскиваемых паттернов. Дополнительный бонус: стандартный формат вытаскиваемой онтологии позволит сравнивать результаты работы разных лингвистических технологий над одними и теми же текстами. Ещё один бонус: если текст по-настоящему мутен, то его будут плохо понимать и компьютеры, и люди -- и мутные тексты можно будет просить переписать, это будет "машинный контроль качества".
Вытаскиваемые инженерные модели будут использоваться главным образом с использованием деонтической модальности (указаний на долженствование), что соответствует использованию в качестве требований технических заданий, стандартов, регламентов. Если удастся извлечь формальную модель инженерной системы из этих текстов-требований (возможно, эти требования будут разбросаны по многим текстам, явно или неявно ссылающихся друг на друга), то можно будет пробовать найти противоречия или подтвердить непротиворечивость этой модели с моделями, которые содержатся в CAD/PLM. Но это уже следующий шаг: для начала нужно научиться вытаскивать из текстов модели, совместимые с CAD/PLM представлениями, и только потом проводить анализ противоречивости.
Такая постановка задачи вытаскивания из текстов информации, осмысленной для CAD-программ, отличается от задачи вытаскивания из текстов информации, осмысленной для людей (т.е. совместимой с представлениями инженеров, а не предвзято компьютер-ориентированными представлениями программистов CAD/PLM). То есть вытаскиваемое должно верифицироваться не на соответствие теориям когнитивной науки (http://ailev.livejournal.com/1007293.html -- все эти "теории прототипов" и прочие попытки найти адекватные технические/контринтуитивные теории того, как представлено знание в мозгах у инженеров, чтобы затем извлекать из текстов формальные структуры, понятные самим инженерам), а на соответствие моделям данных, которые можно легко засунуть в CAD/PLM системы. И сама "лёгкость" засовывания в CAD/PLM может определяться самыми разными причинами -- например, наличием развитого инструментария мэппинга данных. Ибо CAD/PLM, основанных на теории прототипов, или теории теорий (или основанных любых других теориях представления понятий, которыми занимается когнитивная наука) пока не наблюдается. Сейчас нет CAD/PLM даже с логическим представлением информации, а есть только с объект-атрибутной моделью данных, так что "интеллектуальные изыски" просто некуда будет передать для обработки. Что, конечно, не мешает в фоновом режиме думать на тему о сегодняшней цепочке искажений по выражению человечьих инженерных мыслей средствами моделей данных CAD/PLM, а затем попыткам обрабатывать задокументированные в объектных базах данных инженерные данные средствами современных мультипарадигмальных языков программирования, на которых написаны CAD/PLM.
Нам нужно вытаскивать из текстов инженерные модели, которые затем будут обрабатываться в конкретном САПР. Идеально-утопический вариант -- делать это сразу в языке программирования этого САПР, вытаскивая информацию в тамошние типы данных. Но тут сразу две засады:
1. информация всё равно будет храниться в объектной базе данных (часто это даже не база данных САПР, а база данных PLM). Модель данных базы данных CAD/PLM не эквивалентна модели данных языка программирования САПР.
2. одна и та же извлеченная информация может затем использоваться многократно, в самых разных САПР, а храниться в самых разных PLM.
То есть информацию правильно извлекать из текста не сразу в типы языка программирования, использованного в PLM/CAD системе, а либо в модели данных объектной базы данных CAD/PLM (сдаться какому-то вендору САПР с потрохами), либо в модели данных "общесапровского общеинженерного" формата.
Общесапровскую "резиновую" (то есть гарантированно закрывающих любую клиентскую кастомизацию инженерных данных, обрабатываемых CAD/PLM разных вендоров) я знаю только одну модель данных: это ISO 15926. Тем самым извлечение информации из текстов должно производиться в формат ISO 15926, из которого далее хорошо разработанными в тусовке ISO 15926 средствами архитектуры IRING (ISO 15926 outside) мэппиться в модель данных конкретной CAD/PLM системы, а затем уж использоваться внутри языка программирования этой системы в привычных для computer science системе типов языка программирования -- но этот последний вопрос мэппинга из "родной" для конкретной CAD/PLM системы объектной базы данных в типы языка программирования этой системы решается для каждой CAD/PLM системы её разработчиками.
Теперь можно сформулировать наш подход к лингвистике:
1. Нас интересует классическое извлечение онтологии из текста (это традиционная для лингвистов задача, обсуждается во всех учебниках).
2. Нас интересует извлечение не любой ad hoc онтологии (что у лингвистов часто), не онтологии semantic web (что не менее часто), а ISO 15926 онтологии.
3. Мы готовы предложить пошаговую процедуру для этого извлечения онтологии: распознавание паттернов шаблонов ISO 15926 по штучке за раз -- медленно повышая процент распознавания каждого отдельного паттерна, добиваясь роста precision (числа верно распознанных) и recall (числа всех найденных) до величин, сравнимых с ручным распознаванием.
Поскольку в самом ISO 15926 есть много вариантов (семантическая сетка части 2, шаблоны, паттерны шаблонов, OIMs, Gellish-подобные форматы и т.д.), то возможны самые разные варианты технологии -- над этим нужно будет ещё думать. Но в целом предлагается вытаскивать из инженерных текстов паттерны шаблонов ISO 15926 -- постепенно наращивая точность вытаскивания каждого паттерна и число вытаскиваемых паттернов. Дополнительный бонус: стандартный формат вытаскиваемой онтологии позволит сравнивать результаты работы разных лингвистических технологий над одними и теми же текстами. Ещё один бонус: если текст по-настоящему мутен, то его будут плохо понимать и компьютеры, и люди -- и мутные тексты можно будет просить переписать, это будет "машинный контроль качества".
Вытаскиваемые инженерные модели будут использоваться главным образом с использованием деонтической модальности (указаний на долженствование), что соответствует использованию в качестве требований технических заданий, стандартов, регламентов. Если удастся извлечь формальную модель инженерной системы из этих текстов-требований (возможно, эти требования будут разбросаны по многим текстам, явно или неявно ссылающихся друг на друга), то можно будет пробовать найти противоречия или подтвердить непротиворечивость этой модели с моделями, которые содержатся в CAD/PLM. Но это уже следующий шаг: для начала нужно научиться вытаскивать из текстов модели, совместимые с CAD/PLM представлениями, и только потом проводить анализ противоречивости.
Такая постановка задачи вытаскивания из текстов информации, осмысленной для CAD-программ, отличается от задачи вытаскивания из текстов информации, осмысленной для людей (т.е. совместимой с представлениями инженеров, а не предвзято компьютер-ориентированными представлениями программистов CAD/PLM). То есть вытаскиваемое должно верифицироваться не на соответствие теориям когнитивной науки (http://ailev.livejournal.com/1007293.html -- все эти "теории прототипов" и прочие попытки найти адекватные технические/контринтуитивные теории того, как представлено знание в мозгах у инженеров, чтобы затем извлекать из текстов формальные структуры, понятные самим инженерам), а на соответствие моделям данных, которые можно легко засунуть в CAD/PLM системы. И сама "лёгкость" засовывания в CAD/PLM может определяться самыми разными причинами -- например, наличием развитого инструментария мэппинга данных. Ибо CAD/PLM, основанных на теории прототипов, или теории теорий (или основанных любых других теориях представления понятий, которыми занимается когнитивная наука) пока не наблюдается. Сейчас нет CAD/PLM даже с логическим представлением информации, а есть только с объект-атрибутной моделью данных, так что "интеллектуальные изыски" просто некуда будет передать для обработки. Что, конечно, не мешает в фоновом режиме думать на тему о сегодняшней цепочке искажений по выражению человечьих инженерных мыслей средствами моделей данных CAD/PLM, а затем попыткам обрабатывать задокументированные в объектных базах данных инженерные данные средствами современных мультипарадигмальных языков программирования, на которых написаны CAD/PLM.