Обновить

Как я научил ИИ читать советские ГОСТы и сократил подготовку карт контроля с 2 часов до 5 минут

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели11K
Всего голосов 11: ↑11 и ↓0+11
Комментарии13

Комментарии 13

  1. Перепроверка не занимала много времени или она была частичная? Ведь по сути надо пройти по всем таблицам и перепроверить все данные.

  2. На проверку теперь тратится всего 3-5 минут - это общее время или время работы LLM?

1. Перепроверка была частичной - вложенные таблицы, условия 'не более/не менее' и прочие грабли. Это сделал я. Дальше технологи месяц проверяли результаты по ссылкам в документе. Ошибок не возникало 

2. На получение карты контроля уходит 3-5 минуты. От ввода параметров до получения ответа LLM.

Что-то такое было уже )

Где-то однозначно было;)

А не проще оцифровать все по человечески, занести в базу, сверить и иметь железобетонно надежные данные? А то завтра что-нибудь в модели подкрутят, а потом мост где-нибудь рухнет...

Отличный вопрос — мы как раз с этого и начали. Год назад стартовали оцифровку и упёрлись в объём: сотни документов и таблиц. LLM работает как ускоритель: собирает параметры и всегда даёт ссылку на пункт ГОСТа, по которому технолог может перепроверить цифры. Модель подкрутят? Но правила и ссылки останутся, а модель можно заменить или перетюнить, не ломая саму методику

технолог может перепроверить

Перепроверит ведь? Энакин и Падме.jpg

Почему не оцифровать бумажные страницы как есть, целиком, с помощью той же LLM? Потом уже оцифрованные и проверенные человеком страницы точно так же давать на анализ LLM. Если работаете с графическими сканами, то тратите кучу времени на одни и теже операции - LLM при каждом обращении постоянно оцифровывает изображенние в текст. Если вы работаете с LLM через API, то просто выбрасываете кучу токенов на ветер.

...проверенные человекомстраницы...
Я переводил в docx и... вылезли проблемы со сложными таблицами - они не бились в нормальный вид. А вот промтом обрабатывались на ура
Вы предлагаете логичный вариант - на будущее

Так-то за 14 дней таблицы из 20 документов можно было не напрягаясь перенести в базу данных и написать достоверно работающие запросы SQL.

С таблицами согласен, возможно. Однако в таблицах хранится часть параметров. Большая их часть берется из текста. Плюс есть номенклатура, где параметры берутся из двух трёх ГОСТов. Подход с LLM выглядит универсальнее.

Хороший кейс. Вообще есть большая проблема с переводом старой советской документации в электронный вид и обработки с помощью LLM. Хотелось бы иметь сразу такого агента, который напечатает деталь по старой конструкторской документации, которой полно. По моему опыту еще есть проблема с парсером pdf. Как можно быть уверенным, что встроенный в gpt справляется правильно. Не пробовали через внешний парсер? Там хотя бы посмотреть на качество можно

Как можно быть уверенным, что встроенный в gpt справляется правильно.

Только тестированием и сравнением, которые... показали что внешние парсеры делают больше ошибок


Хотелось бы иметь сразу такого агента, который напечатает деталь по старой конструкторской документации

Всё впереди! Пока пробовал обратную задачу. На вход LLM подавал pdf чертеж - на выходе получал параметры детали (внешний диаметр, высоту кольца и тп)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации