"Мы рождены, чтоб сказку сделать былью"
Команду NSR Specification узнают в основном по уникальным решениям для преобразования текста требований в "машинопонимаемый" (правильнее даже сказать "машиноприменяемый") формат. Иными словами, речь о переводе с русского на, например, python. Все это прекрасно, может применяться для автоматизации проверки ЦИМ...Только этих самых ЦИМ, содержащих достаточно исходных данных для анализа соответствия условиям нормативного требования, не так много (почти нет).
Это присказка, а сказка....
Недавно мы взяли в проработку задачу более прикладную: проверка текста технических документов (например, комплекта ПД) на соответствие требованиям. И, попробовали решить задачу с наскока (разумеется, не смогли). Но, зато сделали выводы, необходимые для продолжения работы:
1⃣ LLM действительно способна сделать вывод о наличии несоответствия, и даже дать +/- грамотное обоснование, если на вход дать два текстовых фрагмента.
2⃣ Как же эти самые фрагменты подобрать? Разумеется, векторный поиск в помощь. Но, для точного определения смыслового вектора необходимо, чтобы в одном чанке смысл был только один. Кроме этого, должен быть сохранен контекст. Поделить таким образом текст, не нарушив исходной структуры документа - нельзя.
Но, что если оставить перформулированные тезисы " под капотом"? Реализовав многоуровневый поиск?
3⃣ В любом случае, сперва требуется разделить текст на "стуктурные" чанки. И, даже этот процесс - довольно непростая задача. С одной стороны, у нас уже есть инструмент "Модуль семантической разметки " для нарезки нормативных документов. Что если попробовать использовать его для обработки текста технических документов ПД?
4⃣ В любом случае, правильнее будет сразу разрабатывать новые документы с явной структурой чанков. У нас уже есть инструмент для специалистов-разработчиков по написанию текстов стандартов. Хочется адаптировать его для разработки текстовой части ПД. В качестве приятного бонуса - возможность добавления в новый текст фрагментов уже выпущенных разделов с сохранением информации об источнике.
А базу архивных фрагментов можно будет нарезать с помощью "Модуля семантической разметки".
5⃣ Есть ещё одна проблема. Исходные документы чаще всего были разработаны в продуктах MS Office Word и содержат целый зоопарк пользовательских стилей, которые здорово мешают при обработке. Нужна очистка от форматирования, а, затем, восстановление. Но, у нас и на этот счёт есть наработки =)
В общем, впереди долгая и трудная работа.
А пока, предлагаю Вам насладиться видео-демонстрацией прототипа: https://disk.yandex.ru/i/bAl9y1ZJp6PQmA
Команду NSR Specification узнают в основном по уникальным решениям для преобразования текста требований в "машинопонимаемый" (правильнее даже сказать "машиноприменяемый") формат. Иными словами, речь о переводе с русского на, например, python. Все это прекрасно, может применяться для автоматизации проверки ЦИМ...Только этих самых ЦИМ, содержащих достаточно исходных данных для анализа соответствия условиям нормативного требования, не так много (почти нет).
Это присказка, а сказка....
Недавно мы взяли в проработку задачу более прикладную: проверка текста технических документов (например, комплекта ПД) на соответствие требованиям. И, попробовали решить задачу с наскока (разумеется, не смогли). Но, зато сделали выводы, необходимые для продолжения работы:
1⃣ LLM действительно способна сделать вывод о наличии несоответствия, и даже дать +/- грамотное обоснование, если на вход дать два текстовых фрагмента.
2⃣ Как же эти самые фрагменты подобрать? Разумеется, векторный поиск в помощь. Но, для точного определения смыслового вектора необходимо, чтобы в одном чанке смысл был только один. Кроме этого, должен быть сохранен контекст. Поделить таким образом текст, не нарушив исходной структуры документа - нельзя.
Но, что если оставить перформулированные тезисы " под капотом"? Реализовав многоуровневый поиск?
3⃣ В любом случае, сперва требуется разделить текст на "стуктурные" чанки. И, даже этот процесс - довольно непростая задача. С одной стороны, у нас уже есть инструмент "Модуль семантической разметки " для нарезки нормативных документов. Что если попробовать использовать его для обработки текста технических документов ПД?
4⃣ В любом случае, правильнее будет сразу разрабатывать новые документы с явной структурой чанков. У нас уже есть инструмент для специалистов-разработчиков по написанию текстов стандартов. Хочется адаптировать его для разработки текстовой части ПД. В качестве приятного бонуса - возможность добавления в новый текст фрагментов уже выпущенных разделов с сохранением информации об источнике.
А базу архивных фрагментов можно будет нарезать с помощью "Модуля семантической разметки".
5⃣ Есть ещё одна проблема. Исходные документы чаще всего были разработаны в продуктах MS Office Word и содержат целый зоопарк пользовательских стилей, которые здорово мешают при обработке. Нужна очистка от форматирования, а, затем, восстановление. Но, у нас и на этот счёт есть наработки =)
В общем, впереди долгая и трудная работа.
А пока, предлагаю Вам насладиться видео-демонстрацией прототипа: https://disk.yandex.ru/i/bAl9y1ZJp6PQmA