Комментарии 39
Я так понимаю сорсов не будет? гитхаба?
Тут особый случай. "Сорсом" является обычный язык. В этом все дело
Нет, не является. Где-то там есть волшебный код, который отправляет запрос в OpenAI, а потом применяет ответ.
Этот "волшебный код" у OpenAI на каждой странице перед открытием Playground
Я, конечно, мог бы выложить его на гит, как просит iliabvf, но меня засмеют
Как уже неоднократно говорилось, примеров в интернете много. Но как конкретно работает то, что у вас на скриншотах, они не объясняют.
Конкретно, языковая модель берет то, что вы понаписали и начинает дополнять слово за словом. Вы пишите (на русском языке) вот, дескать, есть у меня такие таблицы, хочу получить вот такое, в конце добавляете SELECT (это, как фас для овчарки). Вот, собственно, и все. Мы ведь с вами это уже проделывали, вспомните
понятно не будет, типичный для 1Сников случай
Михаил, когда вы пишите от своего имени, это намного интереснее...
И нам уже не надо ничего «структурировать». Можно просто задать вопрос. Не задумываясь, как пойдет. Нейросеть поймет (что бы это ни значило), превратит в тот самый «структурированный» и выдаст результат
ну вот виден тупой запрос в лоб, а что будет если чаев 10 видов? а если оно в разнобой по поставщикам? а если еще управленческий учет есть? поиск по «наименованию»… ну такоооое, а где исключение помеченных на удаление объектов?
imho попытка заставить нейросеть писать код к существующим системам тупиковая, мне кажется было бы забавным заюзать саму нейросеть как учетную систему, пускай сама хранит данные как хочет и выдает значения… вот это была бы бомба
Если чаев 10 видов, тогда вы спросите: "сколько на основном складе артикула ч-007" или что-то в этом роде
тогда вы спросите
ага, вы отчет для бухгатера делаете или для руководителя?
Обычно он просит 'девочки сделайте отчет по чаю на основном складе который мы будем отгружать сети W15' а в бухгалтерии в экселе ваяют сводный отчет по номенклатуре которую вручную тыкают в отборе из списка вроде 'Чай Вес имп. партия 12' Чай Вес имп. партия (2) Новый' 'чай пак (для w15)' 'чай 1231 новый новый новый1'
это вот так в реальном учете делают, а не в сферически-вакуумном 'как надо' и 'они понимают и сами научатся делать правильно запросы'
Именно по этой причине и SQL не все менеджеры могут (хотя я был удивлён что он реально эксплуатируется в некоторых местах именно менеджерами на местах)
я вот мечтаю об ИИ, который реаьно ИИ, а не тупо транслятор слов в запрос, причем надо всё правильно настроить чтобы оно работало… тэги там расставить номенклатуре, в правильные папочки положить.
а то у меня даже элементарное не могут (в одной конторе помогаю с 1С)… есть всем известная федеральная сеть у которой много РЦ… так они постоянно для своих какихто странных целей один из этих РЦ таскают по разным разделам справочника, а потом орут что у них отчетность разъезжается на товары которые через него проходят
Вот только бухгалтерия - это все же точная наука.
Бухгалтер не поймет сгенеренный запрос, а значит не сможет убедиться, что ему не рандомную цифру показывают.
Вот если бы результатом была автоматизированная настройка параметров отчета, вместо ручной, то есть то, что пользователь может сам перепроверить, то тогда можно было бы ощутить реальную пользу.
SQL - это тоже точная наука. Откуда там рандомные величины возьмутся?
В чем принципиальная разница между доверием бухгалтера к запросу, в котором он ничего не понимает и доверием к отчету, в котором он, на минуточку, понимает еще меньше? Бухгалтер жмет на кнопку "сформировать" и получает цифры, а что там "под капотом", откуда они взялись, как получились он не знает.
В первом случае есть еще хоть какой-то шанс разобраться, в отличие от отчетов
Удачи с ловлей "галюцинаций", вместо достоверной информации.
Откуда они возьмутся, эти галлюцинации?
У вас на складе 10 коробок мармелада. Вы спрашиваете "Сколько у меня мармелада?" Думаете , вам могут сказать "11" или "25"? Нет, такого не будет. SQL запросы так не работают. Вам либо скажут "10" либо "не понимаю (ошибка при выполнении запроса)"
Очевидно, это будут валидные SQL запросы, выдающие не те данные, что заказывал пользователь. На тривиальных запросах это возможно и будет работать с не плохой вероятностью, но на таких можно и без нейросеток закодить.
Вы рассуждаете умозрительно, а я практически. На основе того, что видел в процессе тестирования. Чтобы нам перейти на общую почву, предлагаю вам продемонстрировать такой вопрос от пользователя который в моем сервисе вернет валидный, но неверный запрос
Вы просто пока еще не дошли в своей практике до данного момента, продолжайте. Пока что тот функционал, что вы продемонстрировали без проблемно пишется без нейронок. (просто отмэтчил ключевое слово из запроса, на нужный столбец данных и все) Начните экспериментировать с запросами с нетривиальным WHERE и JOIN.
предлагаю вам продемонстрировать такой вопрос от пользователя который в моем сервисе вернет валидный, но неверный запрос
А "ваш сервис" (который, кстати, где доступен для тестирования) детерминирован?
Извините, что вклиниваюсь. Можно я? Например, есть склад 1, в котором есть желтые апельсины, склад 2 с красными апельсинами, склад 3 с желтыми и красными апельсинами. Сколько складов с апельсинами?
В данном случае сервис вернет запрос типа:
ВЫБРАТЬ КОЛИЧЕСТВО(СправочникСклады.ссылка)
ИЗ Справочник.Склады как СправочникСклады
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки как РегистрТоварыНаСкладах
ПО РегистрТоварыНаСкладах.Склад = СправочникСклады.ссылка
ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Номенклатура как СправочникНоменклатура
ПО РегистрТоварыНаСкладах.Номенклатура = СправочникНоменклатура.ссылка
ГДЕ СправочникНоменклатура.наименование = "апельсины"Я не сильна в 2с, но хорошо представляю SQL. Правильно понимаю, что результат запроса (3 или 4) будет зависеть от того, как организованы данные?
Сейчас посмотрел внимательнее ваш вопрос:
В одном случае выдает:
ВЫБРАТЬ Количество(различные СправочникСклады.ссылка)...
В другом:
ВЫБРАТЬ склад.наименование
...
СГРУППИРОВАТЬ ПО Склад.наименование
Вариативность присутствует. Она изначально заложена в языковую модель. Но обратите внимание, что неправильного результата мы не получаем. В первом случае это будет одна цифра: 3, во втором три строки в результате. 4 не появляется ни в первом, ни во втором случае
Как то на первый взгляд плохо кажется с точки зрения оптимизации. Почему условия не указываются в параметрах виртуальной таблицы? Например 150 000 SKU (уникальных номенклатур в справочнике) и 100 скадов. Сначала будут перебираться десятки тысяч записей и потом на результат будет наложен отбор (итогом всего запроса например будет всего 3 записи)
Статья высосанная из пальца, чтоб привлечь внимание к своему сервису. Короче чистая реклама. Автор говорит, что пользователи две кнопки запомнить не могут. А тут они сами сложные запросы (в деталях, что им нужно от базы) будут надиктовывать. Да причем еще как я понимаю каждый раз когда нужен отчет))
Реальные запросы типа "Стоимость остатков склада в продажной цене","какие плановые платежи на март запланированы" или "валовая прибыль и рентабельность за прошлый месяц по группе фрукты" данная система может отработать?
Как получить данные из 1С по-человечески