End-to-end тесты -- штука дорогая и затратная, особенно в корпоративных системах. Собственно, для снижения стоимости обнаружения ошибки и существует пирамида тестирования с опорой на модульные тесты.
В ряде случаев, по пути от требования к коду требуется добавить промежуточные контроли. Строго формализованный DSL -- это один из проверенных временем подходов.
Как бы вы организовали её валидацию и версионирование при изменении API — например, через контрактные тесты на nullable-поля, диапазоны значений и совместимость схем?
Я бы пошёл по пути обратной шаблонизации по аналогии с режимом validate ORM Hibernate. Имея XML, мы путём несложных преобразований сможем восстановить JSON-представление, которое поэлементно можно сравнить уже со схемой самого IMDG. А дальше остаётся определиться с режимом сверки: только при старте приложения сверять схемы данных или ещё добавить ежечасные проверки для контроля миграции на лету. Тут уже дело за выбором инженерного решения под бизнес задачу: сразу ронять приложение при малейшей несовместимости или продолжать работать и сигнализировать о проблемах через каналы телеметрии.
Большие модели общего назначения не дают преимуществ в узких задачах потому что они общего назначения.
Для разработки модели под задачу должна быть обеспечена экономика. Есть более простые и эффективные способы автоматизации, чем нейронные сети любых классов. Могу сказать по нашему ИТ -- очень небольшое количество задач имеет потенцию выйти в плюс от ML-автоматизации, зачастую дешевле просто полечить бардак в головах бизнеса.
LoRA-адаптация как раз и смещает веса внимания в нужные стороны.
Про файн-тюнинг соглашусь в целом, но это путь эксперимента -- может взлететь, а может и не получиться :) Опять-таки, экономика и бюджет управляют объёмом вложений.
От 2х недель до 2х месяцев работы ML-инженера.
Только если данные надо собрать и причесать, но не разметить с нуля.
Работа с большими языковыми моделями подкупает своей "универсальностью". Специально разработанные или глубоко тюненные модели -- это удел дата-саентистов. Разумеется, мы можем сделать специальную модель под конкретную узкую задачу, но это совсем другой процесс и стоимость вывода в бой. Недавно даже цифра попадалась, что стоимость обучения GPT-3 (1.7B параметров) составила 12-16 млн. долларов США, только на аренду видеокарт и серверов. Стоимость сбора обучающего набора мне не попадалась, но предположу, что цифра сопоставимая.
"За неимением гербовой пишем на обычной", как гласит народная мудрость.
Отличительное свойство любой LLM -- это работа с вероятностями, что обратной стороной может дать нам галлюцинации, как следствие, нерабочий код. Второй вариант -- это рабочий код, но с открытыми уязвимостями. В некоторых деликатных областях работа с абстрактным синтаксическим деревом и строгая проверка инвариантов являются неплохим компромиссом между гибкостью и безопасностью.
Мы в своей работе используем не голый VCS, а с web-оболочкой. В нашем случае, это GitLab.
У него достаточно приятный интерфейс, довольно удобная система обработки merge request, CI. Встроенным трекером не пользуемся, так как есть Jira.
VCS — это лишь базовый функционал, а для удобства команды требуются более высокоуровневые вещи.
Понятие «лучшее» очень сильно субъективировано и зависит от конкретного варианта использования. Без сомнения у Mercurial гораздо более низкий порог старта и для маленькой команды он проще. Но в большой команде, где активно используются временные ветки и управление правами на основе шаблонов имен веток, Git даёт преимущества.
Добрый день.
Нет, запроса в проект я не делал и в имеющемся виде не считаю это нужным. Есть несколько аспектов.
Нелинейные функции по своей природе очень отличаются между собой и для качественной подгонки нужно иметь в виду специфические условия и области сходимости.
В отличие от линейной регрессии сложно описать универсальный механизм обработки.
Например, для большинства нелинейных функций нельзя выполнить «обезразмеривание», что, в свою очередь, для линейной регрессии даёт существенное улучшение сходимости и устойчивости решения.
Я считаю переход к нелинейным моделям мерой вынужденной и надо понимать их негативные стороны. Моя работа показывает качественную возможность решения таких задач, а уже меры предосторожности — дело разработчиков.
В TFS такие свойства, как выходной каталог, прекрасно наследуются вдоль всей цепочки. Я уже забыл, как это было сделано, но такая возможность в msbuild точно есть.
Давайте не мешать французское с нижегородским. TFS и MSBuild вещи немного разные. У нас в команде не получилось нормально передавать кастомные свойства (версии 3.5 и 4.0), например, полностью квалифицированный номер сборки, кроме как прямой передачей при вызове файла targets. Во-вторых, места агрегации dll, msi и отчетов по тестам разные. Как это нормально оформить в MSBuild?
Ещё один интересный аспект — это работа версии MSBuild x64. Непонятно каким образом, но многие дополнительные task'и не работают в этой версии. Ярким примером можно привести Wix.
Но главный недостаток для меня лично — это невозможность в одном скрипте и загружать, и использовать task'и.
Я не хочу навязывать один инструмент. Мне интересен опыт сообщества по допиливанию функционала «из коробки» под собственные весьма специфичные условия.
Насчет необходимости изучения PowerShell исключительно для сборки проектов меня терзают смутные сомнения. Ну, а весёлые пародии из PS на утилиты Unix полностью отбивают желание его изучать.
Имена веток публикуются среди всех участников, поэтому в качестве имен обычно используют устойчивые во времени номера версий.
Если в проекте одновременно поддерживается столько версий, то мне искренне жаль его менеджера.
Если хочется порядка в «большом» хранилище, то локальную историю можно сжимать, прежде чем пересылать на сборку. Но если вы перешлете на сборку гига-патч, то в результате бисекции вы получите «ищите иголку где-то в этом стоге».
End-to-end тесты -- штука дорогая и затратная, особенно в корпоративных системах. Собственно, для снижения стоимости обнаружения ошибки и существует пирамида тестирования с опорой на модульные тесты.
В ряде случаев, по пути от требования к коду требуется добавить промежуточные контроли. Строго формализованный DSL -- это один из проверенных временем подходов.
Я бы пошёл по пути обратной шаблонизации по аналогии с режимом validate ORM Hibernate. Имея XML, мы путём несложных преобразований сможем восстановить JSON-представление, которое поэлементно можно сравнить уже со схемой самого IMDG. А дальше остаётся определиться с режимом сверки: только при старте приложения сверять схемы данных или ещё добавить ежечасные проверки для контроля миграции на лету. Тут уже дело за выбором инженерного решения под бизнес задачу: сразу ронять приложение при малейшей несовместимости или продолжать работать и сигнализировать о проблемах через каналы телеметрии.
Для разработки модели под задачу должна быть обеспечена экономика. Есть более простые и эффективные способы автоматизации, чем нейронные сети любых классов. Могу сказать по нашему ИТ -- очень небольшое количество задач имеет потенцию выйти в плюс от ML-автоматизации, зачастую дешевле просто полечить бардак в головах бизнеса.
Про файн-тюнинг соглашусь в целом, но это путь эксперимента -- может взлететь, а может и не получиться :) Опять-таки, экономика и бюджет управляют объёмом вложений.
Только если данные надо собрать и причесать, но не разметить с нуля.
Работа с большими языковыми моделями подкупает своей "универсальностью". Специально разработанные или глубоко тюненные модели -- это удел дата-саентистов. Разумеется, мы можем сделать специальную модель под конкретную узкую задачу, но это совсем другой процесс и стоимость вывода в бой. Недавно даже цифра попадалась, что стоимость обучения GPT-3 (1.7B параметров) составила 12-16 млн. долларов США, только на аренду видеокарт и серверов. Стоимость сбора обучающего набора мне не попадалась, но предположу, что цифра сопоставимая.
"За неимением гербовой пишем на обычной", как гласит народная мудрость.
Отличительное свойство любой LLM -- это работа с вероятностями, что обратной стороной может дать нам галлюцинации, как следствие, нерабочий код. Второй вариант -- это рабочий код, но с открытыми уязвимостями. В некоторых деликатных областях работа с абстрактным синтаксическим деревом и строгая проверка инвариантов являются неплохим компромиссом между гибкостью и безопасностью.
Спасибо. Будем работать над другими материалами по теме.
У него достаточно приятный интерфейс, довольно удобная система обработки merge request, CI. Встроенным трекером не пользуемся, так как есть Jira.
VCS — это лишь базовый функционал, а для удобства команды требуются более высокоуровневые вещи.
Как говорил Фредерик Брукс в своей бессмертной книге: «No silver bullet ©»
Нет, запроса в проект я не делал и в имеющемся виде не считаю это нужным. Есть несколько аспектов.
Нелинейные функции по своей природе очень отличаются между собой и для качественной подгонки нужно иметь в виду специфические условия и области сходимости.
В отличие от линейной регрессии сложно описать универсальный механизм обработки.
Например, для большинства нелинейных функций нельзя выполнить «обезразмеривание», что, в свою очередь, для линейной регрессии даёт существенное улучшение сходимости и устойчивости решения.
Я считаю переход к нелинейным моделям мерой вынужденной и надо понимать их негативные стороны. Моя работа показывает качественную возможность решения таких задач, а уже меры предосторожности — дело разработчиков.
Надеюсь, на Ваш вопрос я ответил.
Давайте не мешать французское с нижегородским. TFS и MSBuild вещи немного разные. У нас в команде не получилось нормально передавать кастомные свойства (версии 3.5 и 4.0), например, полностью квалифицированный номер сборки, кроме как прямой передачей при вызове файла targets. Во-вторых, места агрегации dll, msi и отчетов по тестам разные. Как это нормально оформить в MSBuild?
Ещё один интересный аспект — это работа версии MSBuild x64. Непонятно каким образом, но многие дополнительные task'и не работают в этой версии. Ярким примером можно привести Wix.
Но главный недостаток для меня лично — это невозможность в одном скрипте и загружать, и использовать task'и.
Я не хочу навязывать один инструмент. Мне интересен опыт сообщества по допиливанию функционала «из коробки» под собственные весьма специфичные условия.
NAnt под Mono уже уже работает.
Инструкции по отделению тестового движка от VS есть тут.
Мы запускали MSTest так:
Того же эффекта можно достичь, используя MSBuild Extension Pack.
Если в проекте одновременно поддерживается столько версий, то мне искренне жаль его менеджера.
Если хочется порядка в «большом» хранилище, то локальную историю можно сжимать, прежде чем пересылать на сборку. Но если вы перешлете на сборку гига-патч, то в результате бисекции вы получите «ищите иголку где-то в этом стоге».