Исходя из своего опыта, полагаться только на «на контекст, сформированный по топу полученных векторов» — очень наивный подход, теряется уйма важных деталей. Стоит сразу смотреть в сторону решений вроде GraphRAG, и аннотации чанков дополнительными метаданными, теми же NER к примеру.
Кто-то встречал удобный в использовании инструмент ведения кабельного журнала в электронном виде? Последнее с чем сталкивался сам - RackTables (стойки, юниты, порты), но не сказать, что прям сильно удобно
Взгляните на статью о SCIN и соответствующий дата-сет от Google на GitHub. Интересен как общий подход к формированию датасета, так и с точки расширения функциональности вашего мобильного приложения
До последнего был уверен, что статья — стёб в духе «Вредных советов» Григория Остера, сплошь перлы – нарочно не придумаешь))…
«Когда админы работают, как на конвейере», а количество «инженерных систем в районе тысячи» как раз спихнуть на них ещё одну — проще всего.
«Не смешно» — это глубина проработки проблемы… «Корневая причина: Неработоспособность БД. Накопление очередей SQL запросов»… Серьёзно?! Разработка / вендор — ни чем помочь не могут, DBA возможностей не видит.
«Потушили» проблему, «залив» её новым железом.. — идеальная модель решения проблем)
Попробую перефразировать данный опус. Менеджер проекта обо#%@лся, крайним остался отдел эксплуатации среды виртуализации. Из-за задействования резервных ресурсов, бедолаги теперь вынуждены решать не только проблемы горе-менеджера, но и «снежный ком» проблем от систем, уже находившихся в эксплуатации, ведь не зря же существовал резерв ресурсов!?
Но горе-менеджер не унывает, ведь есть Service Desk! Главное верно изложить контекст проблемы: { “корневая причина”: “неработоспособность БД”, “организационный фактор”: “кто угодно, кроме Я”, “зона ответственности”: “отдел эксплуатации виртуальной среды” }
Остаётся только «дёргать за нужные веревочки» для повышения приоритета выполнения «операции перезагрузки Postgre», чтобы снизить MTTR от простоя новодела.
Главное — грамотное разграничение ответственности между сотрудниками. Менеджер проектов не парится за реализацию обходных решений и развёртывание, мнение админа «за организационную составляющую» никого не интересует (снижаются затраты на футбол).
Такая модель управления хорошо подходит в ситуациях, когда некогда думать, сроки горят, и ничего нет.
P.S. последнюю фразу полностью позаимствовал из статьи, надеюсь автор не обидится.
В наиболее примитивных случаях построение "цифрового ядра" основывается на понимании бизнес-целей и декомпозиции KPI. И только спустя годы выясняется, что компания профукала по настоящему золотую жилу, когда решила не тратить ресурсы на сбор и накопление на первый взгляд "бессмысленной информации".
Статья - пустышка, про практику Data driven в ней ни слова
в первоначальном пресс-релизе Amazon Go тоже указывалось полностью автоматически, а на деле - индусы) На профильном ресурсе маркетинговый булшит без технических потрошков - ну такое себе(
Я прежде всего про то, чтобы была возможность загрузить готовый xml-файл BPMN2.0 в lsFusion и уже на платформе обвязать его узлы декларативно и использовать в рабочих процессах.
Просто тут круговая порука получается: если система классифицирована, как ГИС, то и бюджет и ФОТ на её защиту должен быть выделен. Иначе, зачем её классифицировать, как ГИС, и самим себя наказывать.
Самым сложным здесь представляется выполнение деперсонализации и обеспечение конфиденциальности (врачебной тайны)
При этом платформа не хранит в себе объёмные файлы, такие как рентгеновские исследования в формате DICOM, поскольку их размещение в хранилище очищенных данных замедляло бы работу системы.
Размещение в том же Yandex Object Storage вряд ли замедлит работу системы, другой вопрос - уложились ли бы вы в любезно выделенный Яндексом бюджет b2g под этот проект.
Опыт интересный, жаль что результаты пока не доступны для широкого круга исследователей.
Исходя из своего опыта, полагаться только на «на контекст, сформированный по топу полученных векторов» — очень наивный подход, теряется уйма важных деталей. Стоит сразу смотреть в сторону решений вроде GraphRAG, и аннотации чанков дополнительными метаданными, теми же NER к примеру.
Кто-то встречал удобный в использовании инструмент ведения кабельного журнала в электронном виде? Последнее с чем сталкивался сам - RackTables (стойки, юниты, порты), но не сказать, что прям сильно удобно
Снёс от греха подальше. А есть такое же, но про Firefox / Chrome?
Странно, что не упомянута Natasha
Взгляните на статью о SCIN и соответствующий дата-сет от Google на GitHub. Интересен как общий подход к формированию датасета, так и с точки расширения функциональности вашего мобильного приложения
Вместо
fuzzywuzzyуже пора использовать RapidFuzz наверно)Спасибо, интересное решение, надо попробовать
GEOMETRY например)
РедОС сертифицированная, или обычная? Полагаю с сертифицированной версией нюансов на порядок больше, любопытно почитать о подобном опыте
ORM справляется с чтением / записью в колонки с json-native и прочих СУБД-специфичных типов данных, или из коробки только текст, числа и булево?
До последнего был уверен, что статья — стёб в духе «Вредных советов» Григория Остера, сплошь перлы – нарочно не придумаешь))…
«Когда админы работают, как на конвейере», а количество «инженерных систем в районе тысячи» как раз спихнуть на них ещё одну — проще всего.
«Не смешно» — это глубина проработки проблемы… «Корневая причина: Неработоспособность БД. Накопление очередей SQL запросов»… Серьёзно?! Разработка / вендор — ни чем помочь не могут, DBA возможностей не видит.
«Потушили» проблему, «залив» её новым железом.. — идеальная модель решения проблем)
Попробую перефразировать данный опус. Менеджер проекта обо#%@лся, крайним остался отдел эксплуатации среды виртуализации. Из-за задействования резервных ресурсов, бедолаги теперь вынуждены решать не только проблемы горе-менеджера, но и «снежный ком» проблем от систем, уже находившихся в эксплуатации, ведь не зря же существовал резерв ресурсов!?
Но горе-менеджер не унывает, ведь есть Service Desk! Главное верно изложить контекст проблемы: { “корневая причина”: “неработоспособность БД”, “организационный фактор”: “кто угодно, кроме Я”, “зона ответственности”: “отдел эксплуатации виртуальной среды” }
Остаётся только «дёргать за нужные веревочки» для повышения приоритета выполнения «операции перезагрузки Postgre», чтобы снизить MTTR от простоя новодела.
Главное — грамотное разграничение ответственности между сотрудниками. Менеджер проектов не парится за реализацию обходных решений и развёртывание, мнение админа «за организационную составляющую» никого не интересует (снижаются затраты на футбол).
Такая модель управления хорошо подходит в ситуациях, когда некогда думать, сроки горят, и ничего нет.
P.S. последнюю фразу полностью позаимствовал из статьи, надеюсь автор не обидится.
В наиболее примитивных случаях построение "цифрового ядра" основывается на понимании бизнес-целей и декомпозиции KPI. И только спустя годы выясняется, что компания профукала по настоящему золотую жилу, когда решила не тратить ресурсы на сбор и накопление на первый взгляд "бессмысленной информации".
Статья - пустышка, про практику Data driven в ней ни слова
в первоначальном пресс-релизе Amazon Go тоже указывалось полностью автоматически, а на деле - индусы)
На профильном ресурсе маркетинговый булшит без технических потрошков - ну такое себе(
Я прежде всего про то, чтобы была возможность загрузить готовый xml-файл BPMN2.0 в lsFusion и уже на платформе обвязать его узлы декларативно и использовать в рабочих процессах.
А нет ли в планах "завезти на IsFusion" BPMN?
учитывая полное отсутствие технических делателей, выглядит как Amazon с 1000 индусов вместо ИИ
что позволено Юпитеру, то не позволено быку)
Самым сложным здесь представляется выполнение деперсонализации и обеспечение конфиденциальности (врачебной тайны)
Размещение в том же Yandex Object Storage вряд ли замедлит работу системы, другой вопрос - уложились ли бы вы в любезно выделенный Яндексом бюджет b2g под этот проект.
Опыт интересный, жаль что результаты пока не доступны для широкого круга исследователей.
Интересно, почему не выбрали готовые OTel и OpenTelemtry Collector, а начали со своего велосипеда?