Использование code interpreter от OpenAI в 1С

Забавно, но я то думал в итоге код на питоне будет написан.
А вообще, если так уж подумать - не каждой компании захочется передавать конфиденциальные данные в сторонний сервис, чтобы он их обработал и выдал готовый - опять же - конфиденциальный результат.
Да ещё и за каждый такой вот вызов придётся платить и ждать (особенно когда данные очень объёмные - тут свои заморочки появляются)
Как мне кажется, куда логичнее было бы как раз подавать тестовые данные - и контрольный пример с конечным ответом.
Алгоритм бы на его основе (+ промт) построил бы простой алгоритм - сверился бы с контрольным примеров и ответом, построил статистическую карту тестового примера (кстати их хорошо бы передавать минимум 2: один небольшой, и один очень большой, но тоже не реальный, хотя и очень близкий к нему - для оптимизации - кстати, получение таких птестовых данны - это тоже задача на создание такого алгоритма для языковой модели - решается аналогично, а потом на основе этого алгоритма уже локально создаются тестовые данные на основе рабочих) потом построил оптимизированный алгоритм (учитывая статистическую карту) - сверился с контрольным примером, а потом и с тестовыми данными (сверив их и первой простой реализацией). Сгенерировал бы свой новый контрольный пример - ещё разв всё сверил если всё совпало - вернул бы результирующий оптимизированный алгоритм; настроенный алгоритм его тестирования; сгенерированную автодокументацию - и результаты тестовых прогонов (включая сгенерированный контрольный пример) - чтобы, если захочется, можно было с ними свериться.

А уже на рабочих, секретных данных - выполнять алгоритм сугубо локально (и изолированно) - и использовать его же в дальнейшем "сколько душе угодно будет".

Ну тут ещё потом можно проводить динамическую оптимизацию этого алгоритма - если в результате будет выданы и алгоритмы сбора статистики, и оценки оптимальности сформированного алгооритма (читай - глубокий замер его производительности и этапов выполнения) - что периодически так же можно будет запускать локально на рабочих данных - производить оценку - и если она выйдет за заданные рамки отклонений - повторять процедуру получения нового алгоритма по новым тестовым данным, но основе новой ситуации.

Ну и само собой, а дальше это всё может ещё усложняться - добавление архитектуры хранения и обработки данных, со статистическими данными оценки их производительности при разных способах использования.
Но потом всё начнёт требовать включения в задачи смежных алгоритмов, которые уже есть, их не надо переписывать. И тут может встать как вопрос конфиденциальности уже самих алгоритмов, так и вопрос их лавинообразного нарастания в объёме как и задействованных в обработке источников данных, которые ещё и разные могут быть, в зависимости от ветвления.
Если с конфиденциальностью алгоритмов как-то ещё можно было бы бороться представляя их черными ящиками с описанием API и статистическими сведениями использования - но это лишает возможности их вызывать на стороне сервиса языковой модели.
То с лавинообразным ростом зависимостей от других алгоритмов и данных - всё куда сложнее.

Один вариант решения - это всё выносить в облако - где будут и все алгоритмы и все данные - и большая лингвистическая модель со всеми накопленными служебными сведениями по проекту - всё будет в одном месте - и локально (в облаке) будет исполняться. Будет проблема с конфиденциальностью, хотя "мнимо" её можно решать - изолируя весь облачный контур (хотя языковые модели это не любят - им нужно постоянное общее накопление знаний), да и гарантий от утечек и взломов тут 100% нет (впрочем локально у компаний тоже всё может утекать и взваливаться).
Но можно, хотя бы данные в облако загрузить все тестовые - останутся только конфиденциальные алгоритмы.

Другой вариант - это многоэтапная двустороння обработка - когда часть выполняется на стороне удалённого сервиса языковой модели, где только часть данных - тестовых, и нет всех алгоритмов - но, само собой, не все операции такая языковая модель сможет проделать у себя - тогда она будет возвращаться частичный результат, который частично будет дообрабатываться локально (да - тут придётся часть базы данных и движка языковой модели переносить локально к клиенту) - здесь буду доступны все данные - все алгоритмы - после обработки - частичный результат будет возвращаться в удалённый сервис и цикл будет повторяться - пока не дойдёт до финала, который окончательно тестируется на стороне клиента. Всё, само собой - полностью автоматически (по возможности, а то ситуации разные могут быть - всё зависит от заморочек постановки задачи)!

Да - это будет куда дольше - чем всё выполнить в удалённом сервисе "за раз" - но позволяет более глубоко решать вопросы конфиденциальных алгоритмов - если их будет не много и не будет нужды их часто дёргать - то всё не так уж печально будет. Другое решение - это уже полностью переносить всю языковую модель локально клиенту - но это уже вопрос конфиденциальности алгоритмов самой языковой модели, и её стоимости (пуская даже в аренду), объёмов её базы данных и требуемых объёмах вычислительных мощностей - впрочем большую часть этих проблем кому это действительно будет надо думаю решат!

Ну и в итоге - вся эта кодогенерация должна встраиваться в локальные бизнес-продукты - для пользовательского использования (пусть они и не буду вникать в скрипты программного кода, но будут понимать, что вся обработка данных только на у них локально осуществляется). Так и внутрь IDE для программистов - для кодогенерации "не отходя от кассы" с автоматической передачей языковой модели нужных сопутствующих разрешённых данных архитектуры проекта, и текущего контекста применения (чтобы сразу под него адаптироваться), и выдачей результата прямо в этот контекст (тут же с документацией, и автотрестами, которые тут же можно и запустить, по контрольные примерами и по каким-то данным - тестовым и/или рабочим, со сбором реальной статистики выполнения, условно, в один клик; и если что - тут же запросить доработки и исправления).

А потом поставить это всё уже в локальной системе на контроль - автослежение за статистикой выполнения и подачи алёрта на необходимость перестроить. Или вообще - самостоятельно динамически перестроить и уже по факту уведомить - если получилось улучшить на необходимость замены одной реализации алгоритма на другую - или вообще полностью автоматически заменить, вообще без участия программиста (всё залогировав конечно, и проведят все наборы тестов на надёжность и достоверность, и производительность) - потом позже могу прийти аудиторы - и всё проверить!

Вот это всё - я и называю - языки программирования 5-го поколения, и бизнес-приложения 5-го поколения! Не просто с новомодными AI технологиями, а с полноценным контуром, в т.ч. замкнутого цикла, по полному автономному сопровождению всей бизнес- логики, выполняемой локально (ну или в изолированном облаке), без передачи конфиденциальны сведений сторонним сервисам, с постоянным контроль и постоянным динамическим самосовершенствованием исполнения бизнес-логики!

А большие языковые модели нынешнего периода развития - это всё так - детский сад, по сравнению с тем, что грядёт во второй половине XXI века (в XXII веке - если процесс затянется на старте)

сколько стоил один такой Промт в итоге (Входящие + Исходящие)?