>Если в работе много нюансов, мелочей и деталей, как вы смогли создать инициирующий промт, который, скорее всего, представляет собой объёмный файл или даже несколько файлов? Типа как в такой работе можно учесть все детали, описать это для LLM, и это не сожрёт всё контекстное окно?
Это на самом деле, наверное, было более времязатратной задачей, чем написать сам проверщик документов. Нужно было собрать все документы с требованиями по наполнению и оформлению (которые мы, естественно, передаём подрядчикам перед тем, как они начнут работу), собрать со всех коллег, которые работают с этим типом документов и занимаются их проверкой, всю информацию о возможных нюансах, и затем представить всё это в виде усвоябельного LLM перечня требований и критериев проверки. Постфактум я даже сделал «методичку» по составлению такого перечня для коллег из других отделов, которые захотят себе подобную систему. Эта методичка нескольких человек уже отпугнула. По поводу контекстного окна — сейчас оно уже не является такой проблемой, как пару лет назад. У современных LLM под наши задачи его хватает с большим запасом.
>Как будто «если написано мелом ХУZ — игнорируй», это скорее творческая человеческая работа, если даже инженеры «сидят и принимают решения по каждой мелочи».
Да, всё так. Конкретно момент, который вы привели в цитате, является инструкцией от составителя размечающему и является примером краевого случая, который может возникнуть на объекте. Знание краевых случаев для каждого проекта, объекта и камеры делегировать LLM пока кажется так себе идеей. В задаче проверки ТЗ на разметку это знание от LLM и не требуется — требуется проверка на соответствие перечню требований, производится проверка по нюансам и моментам, которые извлекли из специалистов работающих с такими документами.
>Или все эти мелочи уже давно известны и новых требований к ТЗ точно нет?
Касательно новых требований — формат документа ещё до введения LLM в работу был зафиксирован, но если появится новая версия требований — соответственно их придётся обновить в промте. За время работы и проверки документов пронаблюдали большое количество ошибок и недоработок от подрядчиков, все моменты, которые удалось вспомнить, — зафиксировали в перечне для LLM. Я думаю, естественно, от них будут появляться новые приколы. Тогда придётся дорабатывать промпты.
>Если в работе много нюансов, мелочей и деталей, как вы смогли создать инициирующий промт, который, скорее всего, представляет собой объёмный файл или даже несколько файлов? Типа как в такой работе можно учесть все детали, описать это для LLM, и это не сожрёт всё контекстное окно?
Это на самом деле, наверное, было более времязатратной задачей, чем написать сам проверщик документов. Нужно было собрать все документы с требованиями по наполнению и оформлению (которые мы, естественно, передаём подрядчикам перед тем, как они начнут работу), собрать со всех коллег, которые работают с этим типом документов и занимаются их проверкой, всю информацию о возможных нюансах, и затем представить всё это в виде усвоябельного LLM перечня требований и критериев проверки. Постфактум я даже сделал «методичку» по составлению такого перечня для коллег из других отделов, которые захотят себе подобную систему. Эта методичка нескольких человек уже отпугнула. По поводу контекстного окна — сейчас оно уже не является такой проблемой, как пару лет назад. У современных LLM под наши задачи его хватает с большим запасом.
>Как будто «если написано мелом ХУZ — игнорируй», это скорее творческая человеческая работа, если даже инженеры «сидят и принимают решения по каждой мелочи».
Да, всё так. Конкретно момент, который вы привели в цитате, является инструкцией от составителя размечающему и является примером краевого случая, который может возникнуть на объекте. Знание краевых случаев для каждого проекта, объекта и камеры делегировать LLM пока кажется так себе идеей. В задаче проверки ТЗ на разметку это знание от LLM и не требуется — требуется проверка на соответствие перечню требований, производится проверка по нюансам и моментам, которые извлекли из специалистов работающих с такими документами.
>Или все эти мелочи уже давно известны и новых требований к ТЗ точно нет?
Касательно новых требований — формат документа ещё до введения LLM в работу был зафиксирован, но если появится новая версия требований — соответственно их придётся обновить в промте. За время работы и проверки документов пронаблюдали большое количество ошибок и недоработок от подрядчиков, все моменты, которые удалось вспомнить, — зафиксировали в перечне для LLM. Я думаю, естественно, от них будут появляться новые приколы. Тогда придётся дорабатывать промпты.