Разработка AI-ботов с .NET и Microsoft-экосистемой: от поддержки клиентов до агентного ИИ

Разработка умных ботов на .NET: Bot Framework, Graph API, Azure OpenAI и практические кейсы внедрения.
Облачная платформа Microsoft
Разработка умных ботов на .NET: Bot Framework, Graph API, Azure OpenAI и практические кейсы внедрения.
Обработка счетов — важная и рутинная часть документооборота, которую всё чаще доверяют AI-моделям. Наша компания часто занимается интеллектуальной обработкой счетов для клиентов, а значит мы постоянно ищем лучший способ для их распознавания. Поэтому мы провели практическое исследование и сравнили, как с этой задачей справляются разные решения: от популярных open-source моделей до коммерческих API.
Исследование включало несколько этапов: мы собрали разнообразный датасет из реальных счетов, привели его к единому формату, определили метрики и протестировали 7 популярных на наш взгляд моделей, чтобы понять:
Вопрос, чем заменить Power BI, стал актуален для многих пользователей одной из самых популярных BI-платформ. С точки зрения синтаксиса DAX и удобства работы с моделью данных наиболее очевидной альтернативой является Visiology. Но у этой платформы до недавнего времени не было своего ETL-инструментария. Недавно вендор представил свой Self-Service ETL, и у меня возник логичный профессиональный интерес к его тестированию. В этой статье я делюсь своими исследованиями возможностей SS ETL от Visiology по сравнению с Power Query.
Здравствуйте! Меня зовут Антон Боев, я исполнительный директор компании DD Planet. В статье поделюсь опытом работы с платформой .NET в условиях санкций и расскажу о нашем взгляде на перспективы импортозамещения ПО в России после ухода Microsoft.
В марте 2022 года корпорация Microsoft присоединилась к антироссийским санкциям и объявила о прекращении поддержки своего программного обеспечения. Вплоть до начала 2024-го, в связи с уходом вендора, мы отметили тенденцию к замораживанию множества проектов, которые планировалось разрабатывать на .NET. Хотя наша компания на протяжении 20 лет успешно реализовывает масштабные решения на .NET и входит в топ-5 интеграторов разработки ПО на этой платформе, за последние два года мы также неоднократно обсуждали возможность переквалификации специалистов на другие технологии и прежде всего рассматривали прямого конкурента — Java. Однако мы не сделали этот шаг по ряду причин.
Давайте разбираться, почему наш выбор продолжать разработку на .NET полностью оправдан.
Привет! Сегодня хотим рассказать две короткие истории о миграции крупных российских компаний из Microsoft Azure в наше облако.
Сегодня я начинаю небольшой цикл статей, посвященных операционной системе Microsoft - Azure Stack HCI. Да, именно посвященных ОС, а не решениям Azure, рассматривать я буду именно серверную ОС на базе ядра Windows Server с названием издания Azure Stack HCI, которая вот уже пять лет как ежегодно выходит по программе ежегодного (не долгосрочного) цикла выхода серверных ОС. На данный момент мой план таков:
1) В первой (этой) статье я опишу своё видение того, что такое Azure Stack HCI, чем он отличается от ОС Windows Server Datacenter Azure Edition (Core), что отличает Azure Stack HCI от сервисов Azure Stack, самое главное, для чего вам такая странная ОС в вашем датацентре;
2) Во второй статье я буду рассказывать о том, что такое Hot Patching, - процедура установки обновлений безопасности Microsoft без перезагрузки, какие требования к ОС имеются, - и самое главное, как обойти обязательность наличия подписки Azure, то есть как пользоваться Hot Patching в вашем датацентре без каких-либо Azure Benefits, как создавать виртуальные машины на базе ОС Windows Server и любых её ролей так, чтобы обновления ОС внутри ВМ не требовали их перезагрузки (как вы прекрасно понимаете, обновление хост ОС не требует перезагрузки ВМ в виду живой миграции между узлами кластера). Это весомый аргумент в пользу виртуализации Windows сервисов именно на базе Hyper-V;
3) В третьей статье я расскажу о том, как превратить ОС AzureStackHCI, которая поставляется исключительно в режиме Server Core в ОС с полным рабочим столом, чтобы у вас была возможность полноценно её администрировать. Причем сделать это таким образом, чтобы на ОС все так же продолжали приходить обновления с Windows Update.
При чтении логов из базы данных, а именно, из LDF данных, в большинстве случаев вы наткнётесь на такие функции в запросе sys.fn_dblog(null, null), sys.fn_dblog_xtp(null, null)
Читать из LDF Вы захотите по различным причинам, но так или иначе основная проблема будет «у нас откуда‑то списались деньги остатки, пропал товар, упал прод, разберитесь».
Допустим, Вы захотите воскресить удалённый, дропнутый объект из базы.
Типичный скрипт
Один из наших длительных проектов — это крупное многопользовательское SaaS-решение (CRM-система) основанное на микросервисной архитектуре и развернутое в облаке Azure. Изначально это был MVP, где все части (сервисы, базы данных и т. д.) располагались на одной виртуальной машине. Со временем проект вырос в облачное распределенное решение с множеством веб- и мобильных клиентов.
В этой статье мы расскажем, как решили одну из проблем, с которой столкнулись в процессе разработки.
Бизнес все чаще и чаще предпочитают отдать искусственному интеллекту извлечение данных из документов: при таком подходе меньше ошибок и выше скорость обработки документов. И все чаще звучит вопрос — каким решением пользоваться и к какому подрядчику пойти за оказанием услуги?
Поэтому мы сделали сравнительный обзор двух популярных решений от лидеров рынка по обработке документов — AWS Textract, Microsoft Azure Document Intelligence и собственного решения Ripper Service. Сравнивали решения по нескольким основаниям: по производительности, по результатам извлечения значений из форм, а также по стоимости.
Надеемся, что данная статья будет полезна руководителям компаний, которые уже задумались о применении ИИ для массовой обработки документов.
Существует множество определений термина "Архитектура ПО", от устаревших и неформальных до слишком абстрактных и претендующих на остроумие. К примеру, можно упомянуть сайт Института Программной Инженерии (SEI) Университета Карнеги-Меллона, в электронной библиотеке которого есть соответствующий документ.
Привет, Хабр!
Сегодня мы поговорим о том, какие LLM лучше всего работаю на бизнес-задачах. AI-хайп находится на локальном пике, похоже, что весь мир только и делает, что внедряет AI-фичи в свои продукты, собирает миллионы на разработку еще одной оболочки для ChatGPT, заполняет свои ряды AI-тулами и, кажется, предоставляет работу роботам, пока сами попивают кофе в старбаксе.
Привет, Хабр!
В Kubernetes кластер состоит из множества узлов (nodes), которые представляют собой виртуальные или физические машины, на которых запущены приложения. Node Pools — это группы узлов с одинаковой конфигурацией, управляемые как единое целое.
С Node Pools можно иметь разные пулы для разных задач или приложений, оптимизировать стоимость, используя различные типы виртуальных машин, и применять разные ОС в рамках одного кластера.
Azure Kubernetes Service (AKS) — это управляемый сервис Kubernetes от Microsoft, предназначенный для упрощения развертывания, управления и масштабирования приложений на базе контейнеров. AKS автоматически управляет хостовыми инфраструктурами, снимая бремя настройки и мониторинга, позволяя сосредоточиться на разработке приложений.
VPN обеспечивает доступ удаленных пользователей в корпоративную сеть. Решений много, но выбор оптимального не всегда очевиден. В данной статье хотел бы поделиться опытом внедрения и использования такого продуктового решении как Always On VPN от компании Microsoft. Подчеркну, что это не просто технология постоянно работающего соединения (многие вендоры используют похожие слова), а название продукта или даже целой экосистемы.
Статья будет полезна архитекторам решений и тем, кто планирует внедрять VPN на основе технологии Always On VPN (или еще сомневается). В документации вендора вопросы, затронутые в данной статье совсем не освещены и понять возможные трудности можно только на основе личного опыта.
Привет Хабр!
В мире быстро развивающихся технологий быстродействие и доступность играют ключевую роль в обеспечении удовлетворения потребностей пользователей. В этой эпохе, где каждая миллисекунда имеет значение, использование современных инструментов для оптимизации скорости доставки контента становится неотъемлемой частью стратегии любого онлайн-проекта. Сети доставки контента (CDN) представляют собой одно из ключевых решений для сокращения времени загрузки и улучшения доступности контента для глобальных аудиторий.
В контексте облачных вычислений Microsoft Azure предоставляет мощный инструментарий для эффективной реализации CDN. Путем распределения контента по всему миру с использованием глобальной сети серверов, CDN в Azure позволяет организациям улучшить производительность, снизить задержки и обеспечить надежную доставку контента пользователям в любой точке земного шара.
В данной статье мы рассмотрим основные принципы работы CDN в Microsoft Azure, его особенности, преимущества и способы эффективного использования для оптимизации процесса доставки контента, улучшения пользовательского опыта и повышения конкурентоспособности онлайн-платформ.
В этой статье поговорим о том, как сделать простой процесс загрузки данных с помощью Microsoft Azure Data Factory и Databricks в 2023/2024 году. Во второй части разберем миграцию init scripts из DBFS в Workspace в связи с новым обновлением от Databricks, если ее не сделать, то не удивляйтесь, что в конце 2023 года у вас начнут падать ADF pipelines и кластера в Databricks. 1 декабря 2023 г. Databricks отключит сценарии инициализации (init scripts) с именем кластера для всех рабочих областей. Этот тип сценария инициализации ранее считался устаревшим и не будет больше использоваться.
В этой статье я рассмотрю, как в .NET приложении можно эффективно использовать Application Insights и Serilog, а также как можно воспользоваться специфичным функционалом Azure для логгирования. Вместе эти два прекрасных инструмента дают очень богатые и гибкие возможности по логгированию для любого приложения. В статье будут показаны разнообразные варианты настройки этих инструментов и приведены примеры кода для разных сценариев логгирования.
Application Insights - это мощный инструмент для сбора и анализа метрик и логов приложений, как размещенных в облаке, там и исполняемых локально.
Serilog реализует "структурное логгирование", которое сохраняет сообщения и данные в формате, удобном для поиска и анализа, используя так называемые "sinks" для записи логов в различные хранилища. С помощью Serilog можно одновременно сохранять логи в Application Insights, локальные файлы и любые другие хранилища. Эти sinks можно очень тонко настраивать, а также включать и выключать в ходе работы приложения.
О чем и для кого статья
В какой-то момент в нашей компании возникла необходимость уметь быстро разворачивать множество тестовых сред в Azure. Данная статья расскажет об архитектуре данного решения и о его ключевых деталях.
Я подразумеваю, что читатель статьи уже владеет основами Terraform.
Предполсылки и требования
Для начала хотелось бы рассказать о нашей компании. Мы финтех стартап, занимающийся факторингом. Мы с самого начала развивались как cloud native. Все наши вычислительные мощности и сервера находятся в Azure.
На момент событий, описываемых в статье, большинство наших ресурсов составляли Azure App Service, Azure Sql Servers и Azure Blob storages. У нас было два крупных монолита и около 10 микросервисов вокруг. Честно говоря, это было больше похоже на распределённый монолит, потому что тестировать приходилось всю экосистему, а не отдельные сервисы.
В определенный момент мы начали очень быстро расти с, примерно, 20 человек в Tech отделе до 120 за год. В это время основной нашей болью было количество тестовых сред. У нас были три среды: test, staging и prod. Команды толкались в этих средах, test был постоянно разломан, протестировать что-либо было невозможно. От этого staging тоже забивался неработающим функционалом и выпуски затягивались на недели.
Быстрым решением на тот момент было увеличение числа контуров. Мы хотели дать по тестовому контуру на команду. То есть попросту продублировать все сервисы столько раз сколько есть команд. Понятно, что это не идеальное решение, и в идеале для работы над одним микросервисом команде не нужны все остальные сервисы и инфраструктура вокруг них. Но наличие крупных сервисов, над которыми работали несколько команд, и сильная связность между микросервисами не позволяли нам так сделать. Поэтому мы стали искать решение по автоматизации создания нашей облачной инфраструктуры. Нужна была возможность быстро создавать и уничтожать тестовые контура.
Привет Хабр сегодня мы поработаем с Azure Monitor Activity Logs в три простых шага: логгинг, мониторинг и алертинг.