Не подскажите, а как организовать именно диалог? Чтобы например можно было задать вопрос1-ответ1-вопрос2-ответ2(с учетом предыдущего ответа). Встала такая задача, отвечать с учетом предыдущего контекста.
Была мысль учебные данные компоновать удлиняя строки: Строки диалога 1: 1) Вопрос1-ответ1 2) Вопрос1-ответ1, Вопрос2-ответ2 3) Вопрос1-ответ1, Вопрос2-ответ2, Вопрос3-ответ3 4) Вопрос2-ответ2, Вопрос3-ответ3 5) Вопрос3-ответ3 и т.п.
Потом подавать в модель стыкуя к текущему вопросу предыдущие вопрос-ответ.
Но учить ресурсоемко, в холостую просто так не хочется. Буду благодарен если кто-то поделился опытом и можно будет минимизировать тесты сразу сделав достаточно оптимально.
Доброго времени суток! Большое спасибо за предобученную модель. QuartzNet15x5_golos.nemo - работает, но качество весьма так себе если чисто ее использовать.
При подключении BeamSearchDecoder выдает "BeamSearchDecoderWithLM requires the installation of ctc_decoders". Подскажите, где ctc_decoders взять?
Конечно желательно в github добавить какую-то инструкцию по установке всего. Это не очень очевидное дело оказалось... много гуглить пришлось.
Я в целом сторонник обработки на стороне БД.
Но справедливости ради должен сказать, что план запроса можно писать в sql запросе и базе не надо будет его создавать на ходу. Например
В общем суть в том, что базе можно дать план с запросом, а не заставлять ее вычислять его.
Но я сторонник того чтобы все оборачивать в процедуры и по большей части обрабатывать на уровне БД, а не гонять по сети и нагружать веб сервер. Процедуры — это уже скомпилированный оптимизированный элемент внутри БД, он будет быстрее работать и давать уже готовый результат.
Когда ядро реализовывалось, закладывалось как раз то, что можно напрямую из интерфейса создать процедуру, которая будет скомпилирована в БД и ее дергать. Т.е. чтобы такие операции выполнялись на уровне БД. В общем ядро дергает уже скомпилированный в БД элемент, передавая ему только нужные параметры, и получает от него готовый результат. Поэтому это будет быстро и при конфигурировании из интерфейса. Да и в целом на таком принципе все работает, поэтому работает быстро. В этом ключевое отличие от ядра 1С.
В целом кстати и на уровне БД не так все сложно. Есть конфигурационные таблицы где можно по пользовательскому имени найти идентфикатор, с которым это в БД, и лезть уже предметно.
Заглядывал. На то это и разработка. Когда разрабатываешь ядро полюбе надо копаться.
Более того, было 3 версии ядра. Первая была на именах кстати. И 2 первые были выброшены на помойку из-за изначально неправильно выбранного пути, когда упирались в технически непроходимые вещи и понимали что надо было не так делать. Но на набитых шишках была сделана 3 версия, быстрая, стабильная и расширяемая. В общем покапаться дай боже пришлось.
Но разработка ядра не относится к работе программистов на платформе.
Для этого прямо в веб интерфейсе можно писать процедуры и триггера с нормальными именами, которые будут компилироваться в БД. Нет необходимость лезть в саму базу.
Но SQL надо понимать. Без этого никуда.
Ведь разработчики платформы могли бы создать БД с классическими названиями таблиц: documents, journal, agents и т.д. Могли бы не менять эти названия в обновлениях
Дело тут в уровне абстракций. Я сам создавал платформу, чем то напоминающую платформу 1С, но структурно более правильно устроенную, на уровне ядра, и полностью конфиугрируемую в вебе (можно здесь почитать если интересно https://erp-platforma.com/s?tex=1).
Надо разделять пользовательский и системный уровни. И для удобства и для безопасности. На пользовательском — читаемые имена. Но если пользователь накосячит, физически это не должно уйти в БД, а должно на уровне компилирования дать отбой.
А имена на системном это уже не важно, удобнее при компиляции и интерпитации с числовыми значениями работать.
И кстати не только в этом удобство. Если есть четкая стуктура хранения конфигурации, можно делать удивительные вещи. Снапшоты элементов конфигурации, версии, умные обновления (копирование и встраивание в другие конфигурации элементов новых конфигураций), расширение функций БД: например можно sql запросом выводить изображения (тип данных такой сделали для удобства), штатно одной фнунцией делать контрольные суммы строк + блокчейн (со связью с хешами других строк), автоматизацию работы (CRUD).
Все это позволяет делать разделение на уровни абстракций.
Например вывод изображений в sql запросе физически хранится как число — идентификатор записи в таблице с blob изображений, а интерпретатор это уже тосует и подсовывает сам на пользовательский уровень. И для пользователя это выглядит как работа с изображениями в sql запросе.
Но если залезть при этом у саму БД — вы увидите таблицы, триггера и процедуры в виде наборов чисел.
Андрей, даже не представляю как вы перечитываете эти 700+ комментариев…
В своем ценовом диапазоне я вообще не знаю аналогов, напишите в комментариях, если таковые есть.
Есть ЕРП-Платформа. Тоже как и 1С «суперфреймворк» в вашей терминологии.
Как технически устроена можно здесь почитать https://erp-platforma.com/s?tex=1
Плюсы:
Работает сильно быстрее чем 1С и все конфигурирование в вебе.
Ценовой диапазон ниже
PDF — по сути одной галочкой
Программирование построено на концептуальном подходе аналогичном PL\SQL + как в экселе из ячеек строится интерфейс что тоже в целом понятно для пользователя.
Т.е. для человека имеющего опыт работы с БД — низкий прогр вхождения.
Минусы:
Нет такой экосистемы вокруг. Причина — компания не зарабатывает 60 миллиардов в год как 1С.
Нет бухглатерии. За ненадобностью. Можно разработать такую конфигурацию — но нет смысла. Большие трудозатраты — а на выходе маркетинговая конкуренция с 1С, которая будет проиграна в виду сильно разных весовых категорий.
(есть CRM, Управление проектами, HelpDesk, Документооборот и т.д. — то что востребовано)
Почему ЕРП-Платформа сильно быстрее работает: 1С хранит в БД только данные (насколько я понимаю). Обработку программ производит в ядре-интерпритаторе. Т.е. во время работы надо интерпретировать и выполнять, производить считывание данных из БД, их обработку, запись результатов и т.д.
ЕРП-Платформа делает по другому. Ядро само при разработке компилирует программы в процедуры и триггера в БД. И получает быстро-работающие элементы на уровне базы. В итоге ядру не нужно затрачивать ресурсы на интерпретацию программы, а просто нужно обратиться к уже скомпилированному элементу. Который кстати еще и произведет обработку данных на уровне БД без передачи ядру.
Ядру только надо построить интерфейс в зависимости от конфигурации и прав доступа, и обратиться к базе данных для получения или обработки нужной информации, которая сразу будет предоставлена и обработана на уровне БД.
Так же у ЕРП-Платформы нет проблем с обработкой событий. Это просто получается автоматически через триггера в БД. И я даже не могу себе представить, с какими сложностями 1С-овцы это реализовывали у себя в ядре… И даже думаю что если напрямую в БД изменить какие-то данные, 1С это не обработает, даже если в конфигурации стоит обработка на это событие. 1С просто не узнает об этом…
Настройка серверов — веб сервер и сервер БД. Это очень отработанные в мире вещи.
Хорошую идею убили моторколесом. В общем машина будет ездить до первой хорошей ямы. И их воровать будут запросто.
Такое авто должно 200-250 стоить, а не 450, чтобы его поеупали.
Если этот кадр с записи реального полета, что весьма вероятно, учитывая визуальную разницу с простой компьютерной графикой в других частях видео, то конструкторы воплотили второй вариант — вентилятор с электродвигателем дымить не должен
Нагретый воздух тоже дымить не должен. В нем ведь сгорания не будет. Он от реактора нагревается.
Строительство АЭС — идиотизм сам по себе. (С)
Строительство БелАЭС в Беларуси с целью поставки электроэнергии за границу (в Прибалтику или Польшу) — идиотизм в квадрате.
Для конечных пользователей тоже, если у них будет желание. Мы редактор не закрываем.
По умолчанию редактор доступен создателю аккаунта, главному Администратору, ну и тем пользователям кому он даст такие права.
Но проще позвонить. Над мелочами — если делов на 10 минут, мы не паримся. Так же в абонку входят определенные часы работы программиста (если что-то серьезное)
Да, конечно. Справка. Тут листайте до «Часть 4. Программирование веб интерфейса системы», там много всяких таких скриншотов.
Конкретно тот в разделе «25.4.1 Структура закладки. Ячейки. Интерфейс управления.»
Не подскажите, а как организовать именно диалог? Чтобы например можно было задать вопрос1-ответ1-вопрос2-ответ2(с учетом предыдущего ответа). Встала такая задача, отвечать с учетом предыдущего контекста.
Была мысль учебные данные компоновать удлиняя строки:
Строки диалога 1:
1) Вопрос1-ответ1
2) Вопрос1-ответ1, Вопрос2-ответ2
3) Вопрос1-ответ1, Вопрос2-ответ2, Вопрос3-ответ3
4) Вопрос2-ответ2, Вопрос3-ответ3
5) Вопрос3-ответ3
и т.п.
Потом подавать в модель стыкуя к текущему вопросу предыдущие вопрос-ответ.
Но учить ресурсоемко, в холостую просто так не хочется. Буду благодарен если кто-то поделился опытом и можно будет минимизировать тесты сразу сделав достаточно оптимально.
Доброго времени суток!
Большое спасибо за предобученную модель.
QuartzNet15x5_golos.nemo - работает, но качество весьма так себе если чисто ее использовать.
При подключении BeamSearchDecoder выдает "BeamSearchDecoderWithLM requires the installation of ctc_decoders". Подскажите, где ctc_decoders взять?
Конечно желательно в github добавить какую-то инструкцию по установке всего. Это не очень очевидное дело оказалось... много гуглить пришлось.
Старые данные. На 2020 год. В 2022 как бы не очень актуально уже все.
Но справедливости ради должен сказать, что план запроса можно писать в sql запросе и базе не надо будет его создавать на ходу. Например
Так же есть хорошая статья по оптимизации запросов при помощи плана, включенного в sql
http://www.ibase.ru/files/articles/performance/Firebird%20Optimizer%20-%20ORDER%20vs%20SORT.pdf
В общем суть в том, что базе можно дать план с запросом, а не заставлять ее вычислять его.
Но я сторонник того чтобы все оборачивать в процедуры и по большей части обрабатывать на уровне БД, а не гонять по сети и нагружать веб сервер. Процедуры — это уже скомпилированный оптимизированный элемент внутри БД, он будет быстрее работать и давать уже готовый результат.
В 1С наверное тоже есть нечто подобное.
Более того, было 3 версии ядра. Первая была на именах кстати. И 2 первые были выброшены на помойку из-за изначально неправильно выбранного пути, когда упирались в технически непроходимые вещи и понимали что надо было не так делать. Но на набитых шишках была сделана 3 версия, быстрая, стабильная и расширяемая. В общем покапаться дай боже пришлось.
Но разработка ядра не относится к работе программистов на платформе.
Для этого прямо в веб интерфейсе можно писать процедуры и триггера с нормальными именами, которые будут компилироваться в БД. Нет необходимость лезть в саму базу.
Но SQL надо понимать. Без этого никуда.
Дело тут в уровне абстракций. Я сам создавал платформу, чем то напоминающую платформу 1С, но структурно более правильно устроенную, на уровне ядра, и полностью конфиугрируемую в вебе (можно здесь почитать если интересно https://erp-platforma.com/s?tex=1).
Надо разделять пользовательский и системный уровни. И для удобства и для безопасности. На пользовательском — читаемые имена. Но если пользователь накосячит, физически это не должно уйти в БД, а должно на уровне компилирования дать отбой.
А имена на системном это уже не важно, удобнее при компиляции и интерпитации с числовыми значениями работать.
И кстати не только в этом удобство. Если есть четкая стуктура хранения конфигурации, можно делать удивительные вещи. Снапшоты элементов конфигурации, версии, умные обновления (копирование и встраивание в другие конфигурации элементов новых конфигураций), расширение функций БД: например можно sql запросом выводить изображения (тип данных такой сделали для удобства), штатно одной фнунцией делать контрольные суммы строк + блокчейн (со связью с хешами других строк), автоматизацию работы (CRUD).
Все это позволяет делать разделение на уровни абстракций.
Например вывод изображений в sql запросе физически хранится как число — идентификатор записи в таблице с blob изображений, а интерпретатор это уже тосует и подсовывает сам на пользовательский уровень. И для пользователя это выглядит как работа с изображениями в sql запросе.
Но если залезть при этом у саму БД — вы увидите таблицы, триггера и процедуры в виде наборов чисел.
Есть ЕРП-Платформа. Тоже как и 1С «суперфреймворк» в вашей терминологии.
Как технически устроена можно здесь почитать https://erp-platforma.com/s?tex=1
Плюсы:
Работает сильно быстрее чем 1С и все конфигурирование в вебе.
Ценовой диапазон ниже
PDF — по сути одной галочкой
Программирование построено на концептуальном подходе аналогичном PL\SQL + как в экселе из ячеек строится интерфейс что тоже в целом понятно для пользователя.
Т.е. для человека имеющего опыт работы с БД — низкий прогр вхождения.
Минусы:
Нет такой экосистемы вокруг. Причина — компания не зарабатывает 60 миллиардов в год как 1С.
Нет бухглатерии. За ненадобностью. Можно разработать такую конфигурацию — но нет смысла. Большие трудозатраты — а на выходе маркетинговая конкуренция с 1С, которая будет проиграна в виду сильно разных весовых категорий.
(есть CRM, Управление проектами, HelpDesk, Документооборот и т.д. — то что востребовано)
Почему ЕРП-Платформа сильно быстрее работает: 1С хранит в БД только данные (насколько я понимаю). Обработку программ производит в ядре-интерпритаторе. Т.е. во время работы надо интерпретировать и выполнять, производить считывание данных из БД, их обработку, запись результатов и т.д.
ЕРП-Платформа делает по другому. Ядро само при разработке компилирует программы в процедуры и триггера в БД. И получает быстро-работающие элементы на уровне базы. В итоге ядру не нужно затрачивать ресурсы на интерпретацию программы, а просто нужно обратиться к уже скомпилированному элементу. Который кстати еще и произведет обработку данных на уровне БД без передачи ядру.
Ядру только надо построить интерфейс в зависимости от конфигурации и прав доступа, и обратиться к базе данных для получения или обработки нужной информации, которая сразу будет предоставлена и обработана на уровне БД.
Так же у ЕРП-Платформы нет проблем с обработкой событий. Это просто получается автоматически через триггера в БД. И я даже не могу себе представить, с какими сложностями 1С-овцы это реализовывали у себя в ядре… И даже думаю что если напрямую в БД изменить какие-то данные, 1С это не обработает, даже если в конфигурации стоит обработка на это событие. 1С просто не узнает об этом…
Настройка серверов — веб сервер и сервер БД. Это очень отработанные в мире вещи.
Что мешало поставить мотор по центру и шрузами передавать крутящий момент....
Хорошую идею убили моторколесом. В общем машина будет ездить до первой хорошей ямы. И их воровать будут запросто.
Такое авто должно 200-250 стоить, а не 450, чтобы его поеупали.
Нагретый воздух тоже дымить не должен. В нем ведь сгорания не будет. Он от реактора нагревается.
Вот почитайте зачем нужна БелАЭС
Россия и Белоруссия могут исключить Прибалтику из энергокольца БРЭЛЛ
По умолчанию редактор доступен создателю аккаунта, главному Администратору, ну и тем пользователям кому он даст такие права.
Но проще позвонить. Над мелочами — если делов на 10 минут, мы не паримся. Так же в абонку входят определенные часы работы программиста (если что-то серьезное)
Конкретно тот в разделе «25.4.1 Структура закладки. Ячейки. Интерфейс управления.»