Есть лидер - тот кто хорошо видит снаружи команды и может задавать направление(product owner). А есть управленец, тот кто хорошо понимает команду и может строить внутренние процессы производства(project manager). Это 2 совершенно разные роли.
Для оценки результата можно запускать тесты, в которых происходит множество генераций статей, затем различные LLM много раз сравнивают с оригиналами по стилю, дают оценку, считается среднее. При достойно большом количестве генераций, сравнений и количестве LLM с разными температурами результат должен сходится к нужному. Или можно попробовать рейтинги основанные на парном сравнении как в шахматах.
Больше агентов - не всегда лучше Добавление агентов помогает, когда задачу можно распараллелить. Но в задачах с последовательной логикой это может даже ухудшить результат. Надо быть очень аккуратным при добавлении новых ролей.
Лучше писать код, который подойдёт под потребности бизнеса. Возможно, при ограниченных ресурсах ему будут важнее дополнительный функционал или дешёвая стоимость mvp, чтобы проверить больше идей на рентабельность.
Эмпатия необходима, но такой фокус на ней - тоже крайность и не выход. Если следовать эмпатии, то вы неизбежно погрязнете в субъективности эмоций, и ваша стратегия будет определяться некоторой случайностью текущего настроения людей. Эмпатия больше полезна для внутреннего управления командой. Когда речь идёт про определение глобальной стратегии(product owner), то тут большую ценность несёт понимание текущего состояния рынка. Так что некоторая доля цинизма, возможно, будет более полезна для CEO, чем эмпатия.
А как вы ответите на вопрос: почему spring еще не реализовал эти абстракции у себя, если это такая хорошая идея, и соответствует философии spring по устранению шаблонного кода? Вряд ли, они просто не додумались.
Я думаю ответ как раз в том - что текущий уровень абстракций инструментов оптимальный по соотношению функционал/гибкость.
Ну и для простых crud также spring data rest подойдёт.
Когда я был джуном, мне казалось, что круд на дженериках - хорошая идея.
Сейчас четко вижу, что такой общий код для сеньера станет обременением - если появится какой-то новый кастом(захотим файлы грузить), то вносить изменение в общее ядро станет долго и дорого.
Если же компания нанимает армию джунов, то для их контроля может быть разумным применение таких ограничений общего фраемворка. Но тогда уж лучше пойти по применению какого-нибудь jhipster.
Тоже такое чувство было при чтении статьи. От журнала миграции БД потенциально зависят все компоненты, которые используют данную БД. Добавление лишнего слоя процессинга в миграции не решит эту принципиальную проблему, а только все усложняет.
Нужно просто иметь модульную систему, независимые БД, достаточно малые, чтобы разработчики редко мешали другу другу в изменениях, и просто использовать инструмент для миграций. Ну и интегрироваться на уровне api, а не через базу.
Я работаю над разработкой BI системы, которая выполняет анализ данных по запросу на естественном языке.
Сейчас тестируем агентов на базе langchain. Вы не рассматривали данные решения? Там уже есть готовый агент, который может собрать всю необходимую информацию по схеме и данным в БД.
Если вам нужна строгая согласованность данных, то в случае больших систем по cap теореме вам придется идти на другие уступки.
Поэтому в больших системах сейчас так или иначе используют распределенные хранилища, которые можно строго согласовать только с недопустимыми для больших нагрузок последствиями. Поэтому в редких местах распределенные по разным бд транзакции решают сделать через сообщения, как некоторый компромисс.
Если переходить к DDD, то стратегические паттерны помогают найти в каких местах стоит делать этот компромисс, а тактические предлагают оформить это в виде саг.
Если у вас вся логика работает в рамках одной OLTP БД, то все компоненты этой логики будут потенциально сильно связанны со всей схемой данной БД. В таком случае по DDD вам будет тоже рациональней сделать 1 ограниченный контекст и согласованность данных в нем можно также контролировать с помощью движка БД используя при этом тактические паттерны DDD как обычно.
Но также имеют место быть решения in memory data grid с поддержкой sql, а также распределенные кластеры с архивацией данных на диске, которые могут просканировать весь объем за быстрое время. Такие решения как раз используются, когда данные анализируются на лету, без построения индексов.
На html также сильно проще делать адаптивную верстку, что стало очень весомым с развитием мобильного интернета в 2009
Есть лидер - тот кто хорошо видит снаружи команды и может задавать направление(product owner). А есть управленец, тот кто хорошо понимает команду и может строить внутренние процессы производства(project manager). Это 2 совершенно разные роли.
Для оценки результата можно запускать тесты, в которых происходит множество генераций статей, затем различные LLM много раз сравнивают с оригиналами по стилю, дают оценку, считается среднее. При достойно большом количестве генераций, сравнений и количестве LLM с разными температурами результат должен сходится к нужному. Или можно попробовать рейтинги основанные на парном сравнении как в шахматах.
Fowler вообще определяет ci как альтернативу feature branching'у:
https://martinfowler.com/articles/branching-patterns.html#ComparingFeatureBranchingAndContinuousIntegration
Если проблема была в сложности ручной разметки данных google maps, то почему нельзя было использовать модель для разметки?
Тут такое исследование вышло:
https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/
Главные выводы:
Больше агентов - не всегда лучше
Добавление агентов помогает, когда задачу можно распараллелить.
Но в задачах с последовательной логикой это может даже ухудшить результат. Надо быть очень аккуратным при добавлении новых ролей.
low coupling and high cohesion
Лучше писать код, который подойдёт под потребности бизнеса. Возможно, при ограниченных ресурсах ему будут важнее дополнительный функционал или дешёвая стоимость mvp, чтобы проверить больше идей на рентабельность.
Подскажите, пожалуйста, если используется строгое ограниченное декодирование, то зачем задавать LLM схему ответа внутри промпта на естественном языке?
Это либо хорошая постирония, либо уже какая-то шизофрения
Эмпатия необходима, но такой фокус на ней - тоже крайность и не выход. Если следовать эмпатии, то вы неизбежно погрязнете в субъективности эмоций, и ваша стратегия будет определяться некоторой случайностью текущего настроения людей. Эмпатия больше полезна для внутреннего управления командой. Когда речь идёт про определение глобальной стратегии(product owner), то тут большую ценность несёт понимание текущего состояния рынка. Так что некоторая доля цинизма, возможно, будет более полезна для CEO, чем эмпатия.
Именно так реальность будет расходиться со сказкой из статьи на каждом шагу
А как вы ответите на вопрос: почему spring еще не реализовал эти абстракции у себя, если это такая хорошая идея, и соответствует философии spring по устранению шаблонного кода? Вряд ли, они просто не додумались.
Я думаю ответ как раз в том - что текущий уровень абстракций инструментов оптимальный по соотношению функционал/гибкость.
Ну и для простых crud также spring data rest подойдёт.
Когда я был джуном, мне казалось, что круд на дженериках - хорошая идея.
Сейчас четко вижу, что такой общий код для сеньера станет обременением - если появится какой-то новый кастом(захотим файлы грузить), то вносить изменение в общее ядро станет долго и дорого.
Если же компания нанимает армию джунов, то для их контроля может быть разумным применение таких ограничений общего фраемворка. Но тогда уж лучше пойти по применению какого-нибудь jhipster.
Тоже такое чувство было при чтении статьи. От журнала миграции БД потенциально зависят все компоненты, которые используют данную БД. Добавление лишнего слоя процессинга в миграции не решит эту принципиальную проблему, а только все усложняет.
Нужно просто иметь модульную систему, независимые БД, достаточно малые, чтобы разработчики редко мешали другу другу в изменениях, и просто использовать инструмент для миграций. Ну и интегрироваться на уровне api, а не через базу.
Я работаю над разработкой BI системы, которая выполняет анализ данных по запросу на естественном языке.
Сейчас тестируем агентов на базе langchain. Вы не рассматривали данные решения? Там уже есть готовый агент, который может собрать всю необходимую информацию по схеме и данным в БД.
Если вам нужна строгая согласованность данных, то в случае больших систем по cap теореме вам придется идти на другие уступки.
Поэтому в больших системах сейчас так или иначе используют распределенные хранилища, которые можно строго согласовать только с недопустимыми для больших нагрузок последствиями. Поэтому в редких местах распределенные по разным бд транзакции решают сделать через сообщения, как некоторый компромисс.
Если переходить к DDD, то стратегические паттерны помогают найти в каких местах стоит делать этот компромисс, а тактические предлагают оформить это в виде саг.
Если у вас вся логика работает в рамках одной OLTP БД, то все компоненты этой логики будут потенциально сильно связанны со всей схемой данной БД. В таком случае по DDD вам будет тоже рациональней сделать 1 ограниченный контекст и согласованность данных в нем можно также контролировать с помощью движка БД используя при этом тактические паттерны DDD как обычно.
Но также имеют место быть решения in memory data grid с поддержкой sql, а также распределенные кластеры с архивацией данных на диске, которые могут просканировать весь объем за быстрое время. Такие решения как раз используются, когда данные анализируются на лету, без построения индексов.
Стоит добавить пару слов про dependency inversion
И кнопке "сделай игру про караваны"