В данном случае «по‑человечески» означает, что данные будут представлены человеку. В узком смысле мы поговорим здесь об «отчетах». В широком смысле нас будет интересовать организация интерфейса ПО — человек (но не ПО‑ПО, это тема отдельного разговора о способах интеграции 1С с внешним миром, которых множество).

История

Более полувека назад появился язык, который сейчас называется SQL, Structured Query Lanuage. При рождении у него было другое имя SEQL, Structured English Query Language. Создатели рассчитывали на то, что дадут пользователям простой инструмент. Проще не придумаешь. Чтобы получить ответ от базы данных, надо обратиться к ней на обычном (английском) языке. Немного «причесанном» (т. е. структурированном), но все еще вполне доступном обычным смертным.

Довольно быстро выяснилось, что этот «простой» язык слишком сложен для пользователей. Выглядит удивительно, но вот это сложно:

ВЫБРАТЬ * ИЗ ПРОДАЖИ ГДЕ ЦВЕТ="Эвкалипт"

и это сложно:

ВЫБРАТЬ * ИЗ ОСТАТКИ ГДЕ НОМЕНКЛАТУРА="чай"

А это просто:

и это просто

Разумеется, у этого есть объяснение. Если не вдаваться в подробности, то где сейчас найдешь такие таблицы, из которых можно что‑то получить без единого джойна?

Отчеты

В седьмой версии 1С отчеты с течением времени становились все «кучерявее». Мой первый пример не является чем‑то особенным. Средний отчет в седьмой версии выглядел примерно так:

В свое время я наблюдал за развитием этого процесса с некоторым беспокойством, понимая, что предел мельтешения полей ввода уже где‑то близко.

В восьмой версии все это спрятали под кнопку с названием «настройка». Но, судя по реакции пользователей, которую мне довелось наблюдать, сильно лучше не стало. Если раньше среднестатистический пользователь сидел, стиснув зубы, и искал нужное ему поле ввода, то теперь он только беспомощно смотрел на тебя. «И что я тут могу сделать?», спрашивал он вслух или про себя. «Ну вот же. Есть кнопка „настройка“ (просто запомни, что есть такая кнопка). Нажимаешь ее, открывается окно, а там есть кнопка „добавить фильтр“ (просто запомни, что есть такая кнопка). Нажимаешь ее...» В среднем, где‑то примерно на этих словах выражение беспомощности на лице пользователя сменялось на выражение твердой уверенности в себе. «Я никогда, никогда не смогу это сделать». К счастью, из этой ситуации всегда находился выход. Конкретное условие выносилось на видное место.

Пользователь переводил дух и просил добавить туда еще чего‑нибудь, например, склад. В целом, все расставались довольными друг другом. Но не покидало ощущение, что в некотором смысле мы ходим по кругу.

Я надеялся найти такой общий принцип доступа к данным, который будет принят большинством пользователей. Поэтому довольно долгое время пытался всем своим пользователям рассказывать следующее.

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

Нельзя сказать, что людям это было непонятно. Наоборот, за моими действиями наблюдали с неподдельным интересом. А в конце говорили: «Здорово! Отличный инструмент!» Проблема заключалась в том, что если мне случалось говорить на эту же тему с этим же пользователем буквально на следующий день, то я видел все тот же неподдельный интерес, все то же «Здорово!» и... tabula rasa.

Все же разработчикам платформы удалось какое‑то время назад сделать универсальный пользовательский инструмент, который, что называется «зашел». Речь идет вот об этом небольшом поле ввода в правом верхнем углу почти любого списка.

Причем, «зашел» настолько, что стоило мне сделать какую‑нибудь свою форму, где был список, но не было этого чудесного «окошка», я сразу получал вопрос: «а где..»

Всего лишь контекстный поиск по всему списку. Не так уж много задач можно решить с его помощью. Но, как оказалось, людям больше всего нужны простые ответы на простые вопросы. И самым простым способом.

В начало

Говорят, что развитие идет по спирали. И вот сегодня мы наблюдаем возврат в исходную точку полувековой давности. К идее общения с базой данных на человеческом языке. Только теперь у нас есть большие языковые модели и технология GPT. И нам уже не надо ничего «структурировать». Можно просто задать вопрос. Не задумываясь, как пойдет. Нейросеть поймет (что бы это ни значило), превратит в тот самый «структурированный» и выдаст результат

На данный момент это уже доступно всем желающим. А разработчики платформы очень вовремя выкатили распознавание речи. Мало того, что вопрос можно задавать на естественном языке, это можно делать еще и «с голоса».

Заключение

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

В заключение приглашаю всех желающих на открытый урок, на котором участники обсудят, как стать бизнес‑аналитиком 1С, какие функции он выполняет в командах разработки 1С, его возможные зоны ответственности, а также перспективы развития в должности. Записаться можно здесь.

Комментарии (39)


  1. iliabvf
    00.00.0000 00:00
    +1

    Я так понимаю сорсов не будет? гитхаба?


    1. exwill Автор
      00.00.0000 00:00
      -1

      Тут особый случай. "Сорсом" является обычный язык. В этом все дело


      1. lair
        00.00.0000 00:00
        -1

        Нет, не является. Где-то там есть волшебный код, который отправляет запрос в OpenAI, а потом применяет ответ.


        1. exwill Автор
          00.00.0000 00:00
          -1

          Этот "волшебный код" у OpenAI на каждой странице перед открытием Playground

          Я, конечно, мог бы выложить его на гит, как просит iliabvf, но меня засмеют


          1. lair
            00.00.0000 00:00
            -1

            Как уже неоднократно говорилось, примеров в интернете много. Но как конкретно работает то, что у вас на скриншотах, они не объясняют.


            1. exwill Автор
              00.00.0000 00:00
              -1

              Конкретно, языковая модель берет то, что вы понаписали и начинает дополнять слово за словом. Вы пишите (на русском языке) вот, дескать, есть у меня такие таблицы, хочу получить вот такое, в конце добавляете SELECT (это, как фас для овчарки). Вот, собственно, и все. Мы ведь с вами это уже проделывали, вспомните


              1. lair
                00.00.0000 00:00
                -1

                Мы ведь с вами это уже проделывали, вспомните

                Я как раз помню, что оно не работает ожидаемым образом.

                Так что смысл ожидать, что к вашим скриншотам будет прилагаться текст программы - вполне понятен. А вот причины, почему вы это не делаете - не очень.


          1. Rinsewind
            00.00.0000 00:00

            Не засмеют. Покажите уже код, народу спереть не терпится)


          1. iliabvf
            00.00.0000 00:00

            понятно не будет, типичный для 1Сников случай


  1. gennayo
    00.00.0000 00:00

    Михаил, когда вы пишите от своего имени, это намного интереснее...


  1. DMGarikk
    00.00.0000 00:00
    +3

    И нам уже не надо ничего «структурировать». Можно просто задать вопрос. Не задумываясь, как пойдет. Нейросеть поймет (что бы это ни значило), превратит в тот самый «структурированный» и выдаст результат

    ну вот виден тупой запрос в лоб, а что будет если чаев 10 видов? а если оно в разнобой по поставщикам? а если еще управленческий учет есть? поиск по «наименованию»… ну такоооое, а где исключение помеченных на удаление объектов?
    imho попытка заставить нейросеть писать код к существующим системам тупиковая, мне кажется было бы забавным заюзать саму нейросеть как учетную систему, пускай сама хранит данные как хочет и выдает значения… вот это была бы бомба


    1. exwill Автор
      00.00.0000 00:00

      Если чаев 10 видов, тогда вы спросите: "сколько на основном складе артикула ч-007" или что-то в этом роде


      1. DMGarikk
        00.00.0000 00:00

        тогда вы спросите

        ага, вы отчет для бухгатера делаете или для руководителя?

        Обычно он просит 'девочки сделайте отчет по чаю на основном складе который мы будем отгружать сети W15' а в бухгалтерии в экселе ваяют сводный отчет по номенклатуре которую вручную тыкают в отборе из списка вроде 'Чай Вес имп. партия 12' Чай Вес имп. партия (2) Новый' 'чай пак (для w15)' 'чай 1231 новый новый новый1'
        это вот так в реальном учете делают, а не в сферически-вакуумном 'как надо' и 'они понимают и сами научатся делать правильно запросы'
        Именно по этой причине и SQL не все менеджеры могут (хотя я был удивлён что он реально эксплуатируется в некоторых местах именно менеджерами на местах)

        я вот мечтаю об ИИ, который реаьно ИИ, а не тупо транслятор слов в запрос, причем надо всё правильно настроить чтобы оно работало… тэги там расставить номенклатуре, в правильные папочки положить.

        а то у меня даже элементарное не могут (в одной конторе помогаю с 1С)… есть всем известная федеральная сеть у которой много РЦ… так они постоянно для своих какихто странных целей один из этих РЦ таскают по разным разделам справочника, а потом орут что у них отчетность разъезжается на товары которые через него проходят


  1. malykhin
    00.00.0000 00:00
    +1

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


    1. exwill Автор
      00.00.0000 00:00

      SQL - это тоже точная наука. Откуда там рандомные величины возьмутся?

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

      В первом случае есть еще хоть какой-то шанс разобраться, в отличие от отчетов


      1. malykhin
        00.00.0000 00:00

        Я больше про то, что отчет - это более понятный пользователю инструмент, чем консоль запросов. Понятно, что отчет по факту выполнит этот же самый запрос.
        Через какое-то время, когда новый инструмент себя зарекомендует, таких сомнений, возможно и не будет.


        1. exwill Автор
          00.00.0000 00:00

          Тоже на это рассчитываю


  1. thevlad
    00.00.0000 00:00
    +3

    Удачи с ловлей "галюцинаций", вместо достоверной информации.


    1. exwill Автор
      00.00.0000 00:00

      Откуда они возьмутся, эти галлюцинации?

      У вас на складе 10 коробок мармелада. Вы спрашиваете "Сколько у меня мармелада?" Думаете , вам могут сказать "11" или "25"? Нет, такого не будет. SQL запросы так не работают. Вам либо скажут "10" либо "не понимаю (ошибка при выполнении запроса)"


      1. thevlad
        00.00.0000 00:00
        +3

        Очевидно, это будут валидные SQL запросы, выдающие не те данные, что заказывал пользователь. На тривиальных запросах это возможно и будет работать с не плохой вероятностью, но на таких можно и без нейросеток закодить.


        1. exwill Автор
          00.00.0000 00:00

          Вы рассуждаете умозрительно, а я практически. На основе того, что видел в процессе тестирования. Чтобы нам перейти на общую почву, предлагаю вам продемонстрировать такой вопрос от пользователя который в моем сервисе вернет валидный, но неверный запрос


          1. thevlad
            00.00.0000 00:00

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


            1. exwill Автор
              00.00.0000 00:00

              Опять умозрительные рассуждения.

              Вот у вас таблицы остатков, продаж и взаиморасчетов. Как вы будете определять ваши "ключевые слова", чтобы понять к какой таблице строить запрос? Все возможные языковые конструкции будете перебирать? Ну, ну


              1. thevlad
                00.00.0000 00:00
                +3

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


          1. lair
            00.00.0000 00:00

            предлагаю вам продемонстрировать такой вопрос от пользователя который в моем сервисе вернет валидный, но неверный запрос

            А "ваш сервис" (который, кстати, где доступен для тестирования) детерминирован?


            1. exwill Автор
              00.00.0000 00:00

              Информация в контактах. Что вы понимаете под "детерминирован"?


              1. lair
                00.00.0000 00:00

                Информация в контактах.

                По заявкам? Спасибо, нет.

                Что вы понимаете под "детерминирован"?

                Я понимаю под этим то, что в ответ на один и тот же запрос он гарантированно вернет один и тот же ответ.


              1. lair
                00.00.0000 00:00

                Информация в контактах.

                ...а еще в этот момент ваша статья начинает выглядеть двойной рекламой.


          1. AMenkova
            00.00.0000 00:00

            Извините, что вклиниваюсь. Можно я? Например, есть склад 1, в котором есть желтые апельсины, склад 2 с красными апельсинами, склад 3 с желтыми и красными апельсинами. Сколько складов с апельсинами?


            1. exwill Автор
              00.00.0000 00:00

              В данном случае сервис вернет запрос типа:

              ВЫБРАТЬ КОЛИЧЕСТВО(СправочникСклады.ссылка)
               ИЗ Справочник.Склады как СправочникСклады
               ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки как РегистрТоварыНаСкладах
               ПО РегистрТоварыНаСкладах.Склад = СправочникСклады.ссылка
               ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Номенклатура как СправочникНоменклатура
               ПО РегистрТоварыНаСкладах.Номенклатура = СправочникНоменклатура.ссылка
               ГДЕ СправочникНоменклатура.наименование = "апельсины"


              1. AMenkova
                00.00.0000 00:00

                Я не сильна в 2с, но хорошо представляю SQL. Правильно понимаю, что результат запроса (3 или 4) будет зависеть от того, как организованы данные?


                1. exwill Автор
                  00.00.0000 00:00
                  +1

                  Сейчас посмотрел внимательнее ваш вопрос:

                  В одном случае выдает:

                  ВЫБРАТЬ Количество(различные СправочникСклады.ссылка)...

                  В другом:

                  ВЫБРАТЬ склад.наименование

                  ...

                  СГРУППИРОВАТЬ ПО Склад.наименование

                  Вариативность присутствует. Она изначально заложена в языковую модель. Но обратите внимание, что неправильного результата мы не получаем. В первом случае это будет одна цифра: 3, во втором три строки в результате. 4 не появляется ни в первом, ни во втором случае


                  1. AMenkova
                    00.00.0000 00:00

                    Ясно, благодарю


              1. itmind
                00.00.0000 00:00

                Как то на первый взгляд плохо кажется с точки зрения оптимизации. Почему условия не указываются в параметрах виртуальной таблицы? Например 150 000 SKU (уникальных номенклатур в справочнике) и 100 скадов. Сначала будут перебираться десятки тысяч записей и потом на результат будет наложен отбор (итогом всего запроса например будет всего 3 записи)


                1. exwill Автор
                  00.00.0000 00:00

                  Тут вы правы. В рабочей версии планирую переносить условия в параметры виртуальных таблиц


  1. Lex_Stonehenge
    00.00.0000 00:00
    +1

    Статья высосанная из пальца, чтоб привлечь внимание к своему сервису. Короче чистая реклама. Автор говорит, что пользователи две кнопки запомнить не могут. А тут они сами сложные запросы (в деталях, что им нужно от базы) будут надиктовывать. Да причем еще как я понимаю каждый раз когда нужен отчет))


    1. exwill Автор
      00.00.0000 00:00

      А если запросы не сложные?


  1. itmind
    00.00.0000 00:00

    Реальные запросы типа "Стоимость остатков склада в продажной цене","какие плановые платежи на март запланированы" или "валовая прибыль и рентабельность за прошлый месяц по группе фрукты" данная система может отработать?


    1. exwill Автор
      00.00.0000 00:00

      Да, может