Розширення .NET MAUI для Visual Studio Code тепер загальнодоступне

Сьогодні ми раді повідомити, що попереднього перегляду розширення .NET MAUI VS Code немає, і воно включає деякі довгоочікувані нові функції, зокрема XAML IntelliSense і Hot Reload!

Що таке розширення .NET MAUI?

Розширення .NET MAUI містить інструменти, необхідні для розробки програм .NET MAUI, у спрощений Visual Studio Code. Його створено на основі C# Dev Kit і розширення C#, які містять Solution Explorer, C# Hot Reload, потужний C# IntelliSense та багато іншого. Розширення .NET MAUI додає можливість орієнтуватися на мобільні та настільні пристрої, а також (з останніми версіями розширень) XAML IntelliSense та XAML Hot Reload, зберігаючи при цьому роботу з VS Code оптимізованою та простою.

Новий і покращений досвід редагування XAML

Попередня версія розширення .NET MAUI постачалася з базовим підсвічуванням синтаксису XAML і завершеннями, але це було далеко не повне враження, яке ми хотіли надати. Протягом останнього року ми модернізували наявну службу мови XAML у Visual Studio, запакували її та перенесли у VS Code для вашої розробки .NET MAUI. Це доповнення, яке також працює з Copilot, дає вам інтелектуальне автозаповнення, корисні підказки та безперебійну навігацію кодом під час створення інтерфейсів користувача.

https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2024/06/IntellisenseDemo-1.mp4?_=1 

Гаряче перезавантаження тут 🔥

Можливість редагувати свій код без перезапуску програми є однією з найпотужніших функцій продуктивності, які є у розробників .NET. З останньою версією тепер ви можете гаряче перезавантажувати редагування файлів C# і XAML у Visual Studio Code. XAML Hot Reload уже ввімкнено – просто редагуйте свій XAML під час роботи програми та дивіться, як зміни автоматично відображаються у вашому інтерфейсі користувача!

https://devblogs.microsoft.com/dotnet/wp-content/uploads/sites/10/2024/06/XAML-hot-reload-1.mp4?_=2 

C# Hot Reload все ще перебуває в експериментальному стані, але ви можете ввімкнути його, відкривши VS Code Settings (CTRL/CMD + SHIFT + ,), знайшовши “hot reload” і встановивши прапорець “”[Experimental“ ] Вмикає «Hot Reload» під час налагодження».

Потім відредагуйте свій C# та збережіть або натисніть значок вогню на панелі інструментів налагодження, щоб застосувати зміни!

Почніть сьогодні

Сьогоднішній випуск є важливою віхою в нашій подорожі VS Code, але ми ще не закінчили! Ми продовжуватимемо прислухатися до ваших відгуків і працюватимемо над покращенням продуктивності, надійності та додаванням функцій, щоб зробити розробку вашої програми .NET MAUI більш оптимізованою. Щоб повідомити про помилку чи поділитися пропозицією, ви можете скористатися діалоговим вікном Help > Report Issue у VS Code. Так само, як C# і C# Dev Kit, ми будемо випускати щомісяця з щотижневим оновленням у попередньому каналі.

 

Щоб почати використовувати розширення, ви можете прочитати наш Посібник із початку роботи або завантажити розширення та виконати покрокове керівництво у VS Code!

Квантування за допомогою DirectML допомагає вам ще більше масштабувати в Windows

Підтримка DirectML для Phi 3 mini була запущена минулого місяця, і з тих пір ми внесли кілька покращень, розблокувавши більше моделей і навіть покращивши продуктивність!

Розробники можуть отримати вже квантовані версії Phi-3 mini (з варіантами для версій 4k і 128k). Тепер вони також можуть отримати середній Phi 3 (4k і 128k) і Mistral v0.2. Слідкуйте за додатковими попередньо квантованими моделями! Ми також надіслали інтерфейс gradio, щоб спростити тестування цих моделей за допомогою нового API ONNX Runtime Generate(). Дізнайтесь більше.

Обов’язково перегляньте наші сесії зі створення, щоб дізнатися більше. Подробиці дивіться нижче.

Дивіться тут, щоб дізнатися, що мають сказати наші партнери-постачальники обладнання:

• AMD:https://community.amd.com/t5/ai/reduce-memory-footprint-and-improve-performance-running-llms-on/ba-p/686157

• Intel:https://community.intel.com/t5/Blogs/Tech-Innovation/Artificial-Intelligence-AI/Accelerating-Language-Models-Intel-and-Microsoft-Collaborate-to/post/1598013

• NVIDIA: https://blogs.nvidia.com/blog/microsoft-build-optimized-ai-developers

Що таке квантування? 

Пропускна здатність пам’яті часто є вузьким місцем для запуску моделей на початковому та старішому обладнанні, особливо коли мова йде про мовні моделі. Це означає, що зменшення розмірів мовних моделей безпосередньо означає розширення діапазону пристроїв, на які розробники можуть орієнтуватися.

Було проведено багато досліджень щодо зменшення розміру моделі за допомогою квантування, процесу, який зменшує точність і, отже, розмір ваг моделі.

Наша мета — забезпечити масштабованість, зберігаючи при цьому точність моделі, тому ми інтегрували підтримку моделей, до яких застосовано  Activation-Aware Quantization  (AWQ). AWQ — це техніка, яка дає нам змогу отримати економію пам’яті від квантування з мінімальним впливом на точність. AWQ досягає цього, визначаючи 1% основних ваг, необхідних для підтримки точності моделі, а потім квантує решту 99% ваг. Це призводить до значно меншої втрати точності з AWQ порівняно з іншими методами.

Середня людина читає до 5 слів за секунду. Завдяки значним перевагам пам’яті від AWQ, Phi-3-mini працює з такою швидкістю або швидше на старих дискретних GPUs і навіть інтегрованих GPUs у ноутбуки. Це означає можливість запускати Phi-3-mini на сотнях мільйонів пристроїв!

Щоб побачити це в дії, ознайомтеся з нашою розмовою про збірку нижче!

Вимірювання здивування

Здивування – це показник, який використовується для кількісного визначення того, наскільки добре модель прогнозує вибірку. Не вдаючись у математику всього цього, нижча оцінка здивування означає, що модель є більш впевненою щодо своїх прогнозів і припускає, що розподіл ймовірностей моделі ближчий до справжнього розподілу даних.

Здивування можна розглядати як спосіб кількісного визначення середньої кількості гілок перед моделлю в кожній точці прийняття рішення. На кожному кроці менша плутанина означатиме, що модель має менше, більш впевнених виборів, що відображає більш витончене розуміння теми. Вища збентеженість означатиме більше, менш впевнений вибір і, отже, вибір, який є менш передбачуваним, релевантним та/або різноманітним за якістю.

 

Як ви бачите нижче, наші дані показують, що AWQ призводить до невеликої втрати точності моделі з лише невеликим збільшенням здивування. Натомість використання AWQ означає зменшення ваги моделі в 4 рази, що призводить до різкого збільшення кількості пристроїв, які можуть працювати з Phi-3-mini!

Дізнайтесь більше

Перегляньте ці сесії на Build, щоб дізнатися більше:

• BRK240: Bring AI experiences to all your Windows Devices

• BRK247: Create Generative AI experiences using Phi

• LAB371: Test Drive AI on Windows with DirectML, ONNX Runtime, and Olive 

Почати

Перегляньте репозиторій ONNX Runtime Generate() API, щоб почати вже сьогодні:

https://github.com/microsoft/onnxruntime-genai

Перегляньте тут наш додаток для чату зі зручним інтерфейсом Gradio:

https://github.com/microsoft/onnxruntime-genai/tree/main/examples/chat_app 

Це дозволяє розробникам вибирати з різних типів мовних моделей, які найкраще підходять для їх конкретного випадку використання. Слідкуйте за новинами, щоб дізнатися більше!

Драйвери 

Ми рекомендуємо оновити драйвери до останніх версій для найкращої продуктивності. 

• AMD: покращене прискорення драйвера для генеративного AI, включаючи великі мовні моделі 

• (AMD Software: Adrenalin Edition 23.40.27.06 for DirectML)

• Intel рада співпрацювати з Microsoft і надати драйвер, оптимізований для цих сценаріїв AWQ для широкого діапазону апаратного забезпечення. Будь ласка, завантажте наш загальнодоступний сертифікований WHQL драйвер із повною підтримкою сьогодні, доступний тут.

• NVIDIA: R555 Game Ready, Studio or NVIDIA RTX Enterprise

Створіть наступну хвилю AI у Windows із підтримкою DirectML для PyTorch 2.2

Сьогодні розробники Windows можуть використовувати PyTorch, щоб запускати висновки на останніх моделях у всіх графічних процесорах в екосистемі Windows завдяки DirectML. Ми оновили Torch-DirectML для використання DirectML 1.13 для прискорення та підтримки PyTorch 2.2. PyTorch із DirectML спрощує процес налаштування за допомогою інсталяції в одному пакеті, що полегшує випробування технологій штучного інтелекту та підтримує вашу здатність масштабувати штучний інтелект для ваших клієнтів у Windows.

Щоб побачити ці оновлення в дії, ознайомтеся з нашим сеансом збірки. Додайте можливості AI на всі свої Windows Devices. 

Перегляньте тут, щоб дізнатися, як наші партнери-постачальники апаратного забезпечення покращують цей досвід:

• AMD: AMD рада, що PyTorch із DirectML дозволяє ще більшій кількості розробників запускати LLM локально. Дізнайтеся більше про те, куди ще AMD інвестує за допомогою DirectML.

• Intel: Intel із задоволенням підтримує PyTorch від Microsoft із цілями DirectML. Перегляньте наш блог, щоб дізнатися більше про повну підтримку, доступну сьогодні.

• NVIDIA: NVIDIA з нетерпінням чекає на розробників, які використовують пакет torch-directml, прискорений RTX GPUs. Ознайомтеся з усіма оголошеннями Microsoft Build, пов’язаними з NVIDIA, щодо RTX AI PCs і їх розширеною співпрацею з Microsoft.

PyTorch із DirectML простий у використанні з останніми моделями Generative AI

PyTorch із DirectML надає розробникам простий у використанні спосіб випробувати найновіші та найкращі моделі штучного інтелекту на своїй машині Windows. Це оновлення базується на платформі інференційного висновку світового класу DirectML, яка гарантує, що ці оптимізації забезпечують масштабований і ефективний досвід для останніх моделей Generative AI. Наша мета в цьому оновленні — забезпечити безперебійну роботу з відповідними моделями Gen AI, такими як Llama 2, Llama 3, Mistral, Phi 2 і Phi 3 Mini, і ми розширимо наше покриття ще більше в найближчі місяці!

Найкраще те, що використовувати останній пакет Torch-DirectML із Windows GPU так само просто, як запустити: 

pip install torch-directml

Після встановлення перегляньте наш зразок мовної моделі, який миттєво допоможе вам запустити мовну модель локально! Почніть із встановлення кількох вимог і входу в Hugging Face CLI:

pip install –r requirements.txt 

huggingface-cli login

Далі виконайте таку команду, яка завантажить вказану модель Hugging Face, оптимізує її для DirectML і запустить модель в інтерактивному сеансі Gradio на основі чату!

python app.py —model_repo “microsoft/Phi-3-mini-4k-instruct”

Phi 3 Mini 4K працює локально за допомогою DirectML через інтерфейс Gradio Chatbot.

Ці найновіші зразки PyTorch із DirectML працюють на різних машинах і найкраще працюють на останніх GPUs, обладнаних найновішими драйверами. Перегляньте розділ Supported Models  зразка, щоб дізнатися більше про вимоги до пам’яті GPU для кожної моделі.

Цей бездоганний досвід інференції забезпечується нашими тісними відносинами спільного проектування з нашими апаратними партнерами, щоб переконатися, що ви отримуєте максимум від свого Windows GPU під час використання DirectML.

Спробуйте PyTorch із DirectML сьогодні

Випробувати це оновлення справді так само просто, як запустити «pip install torch-directml» у вашому існуючому середовищі Python і виконати вказівки в одному з наших зразків. Щоб отримати додаткові вказівки щодо встановлення, відвідайте сторінку «Увімкнути PyTorch із DirectML у Windows» на сайті Microsoft Learn.

Це лише початок наступної глави з DirectML і PyTorch! Слідкуйте за оновленнями, щоб отримати ширший охоплення випадків використання, розширення до інших локальних прискорювачів, як-от NPU, тощо. Наша мета — зустріти розробників там, де вони є, щоб вони могли використовувати правильні інструменти для створення наступної хвилі інновацій ШІ.

 

Ми раді, що розробники продовжуватимуть впроваджувати інновації з передовим Generative AI у Windows і створювати програми AI майбутнього!

Microsoft Photos: перехід від UWP до Windows App SDK

Команда Microsoft Photos App нещодавно випустила велике оновлення, змінивши платформу з UWP на Windows App SDK. Ця публікація в блозі документує наш досвід зміни платформи, включаючи деякі вражаючі переваги та цікаві технічні проблеми.

Нова програма «Фотографії» вже повністю розгорнута для Windows Insiders і тепер розгортається для роздрібних клієнтів, починаючи з версії 2024.11050.3002.0 і вище.

Паралельна розробка та переформатування

Будучи однією з найбільш часто використовуваних програм, ми постійно випускаємо нові функції, такі як Slideshow, Background Removal та Generative Erase. Збереження можливості надсилати нові функції, подібні до цих, на UWP, а також прогрес у переході платформи на Windows App SDK було першорядним. Простіше кажучи, це означало, що всі зміни – як нові функції, так і зміни SDK для додатків Windows – повинні були вноситися в нашу основну галузь розробки. Щоб зробити це з найменшими збоями, ми прийняли деякі стратегії, щоб забезпечити сумісність змін коду з обома платформами одночасно:

1. Перевірка складання Parallel Pull Request для варіантів програми UWP і Windows App SDK

2. Умовна компіляція (ifdefs) для схожих, але несумісних API

3. Псевдоніми простору імен для еквівалентних Windows:: і Microsoft:: API

#ifdef WIN_APP_SDK

namespace WUXM = winrt::Microsoft::UI::Xaml::Media;

#else

namespace WUXM = winrt::Windows::UI::Xaml::Media;

#endif

1. Умовне включення вихідних файлів XAML, оскільки умовна компіляція не підтримується.

Процеси та рівень цілісності

У програмах UWP процеси виконуються на низькому рівні цілісності (lowIL), також відомому як «AppContainer», що означає, що певні API обмежені або можуть вимагати додаткових запитів на підтвердження користувача. У програмах Win32, включаючи Windows App SDK, процеси зазвичай виконуються на середньому рівні цілісності (medium IL), тобто програма має вищий рівень привілеїв.

Використовуючи Windows App SDK, тепер ми можемо зберегти відредагований файл у тій же папці, що й оригінальний файл (наприклад, «foo_edited.jpg»), не вимагаючи від користувача вибору папки призначення.

Через такі причини, як кросплатформна сумісність і перевірка привілеїв, еквівалентні API UWP, такі як StorageFolder.GetFilesAsync, можуть бути на порядки повільнішими, ніж відповідні API Win32, такі як FindNextFile. Це особливо вірно для API файлової системи, і коли ви маєте справу з великими колекціями фотографій, що охоплюють понад 100 000 файлів, різниця в продуктивності може бути значною – секунди проти хвилин.

 

 

PhotosService.exe

Вимагати від користувачів чекати кілька хвилин, щоб переглянути всі їхні медіафайли, не буде чудовим користуванням. Щоб досягти прийнятної продуктивності з версією  Photos App UWP, ми використали багатопроцесну архітектуру, яка включає як основний процес lowIL, так і фоновий процес mediumIL «PhotosService.exe» – обмежена можливість, доступна лише для перевірених видавців.

Реалізація цього вимагала значної складності:

1. Використання WAP (пакування програм Windows) для упаковки програм UWP і Win32 для розгортання

2. Додавання обмеженої можливості «runFullTrust» у AppxManifest, щоб дозволити включення виконуваного файлу mediumIL у пакет

Побудова системи IPC (міжпроцесового зв’язку) з використанням Named Pipes для дозволу викликів RPC між двома процесами:

З переходом на Windows App SDK цю складну логіку було видалено та інтегровано в єдиний процес, що значно спростило архітектуру нашої програми та покращило продуктивність завдяки видаленню міжпроцесного зв’язку.

Одним із важливих моментів нового підходу є те, що Photos все ще є багатопотоковою програмою, і для отримання подій сповіщень File System необхідно було реалізувати безголове вікно в окремому потоці, щоб ізолювати його від потоку XAML UI.

 

Windows App SDK Photos Архітектура процесу програми

 

WebView2

Ще однією великою перевагою Windows App SDK є додавання WebView2, побудованого на новому браузері Edge на основі Chromium. Photos App використовує веб-технології в кількох місцях, у тому числі з нашим кросплатформним редактором зображень, який використовується як у OneDrive, так і в Photos App. Серед ключових переваг WebView2:

1. Підтримка WebGL забезпечує покращену якість візуалізації зображень.

2. Чудова продуктивність під час обміну високоякісними зображеннями між нативним і веб-шарами за допомогою SharedBuffer.

3. Підтримка найновішої версії Chromium, яка містить останні вдосконалення та оновлення безпеки.

4. Дозволяє нам оптимізувати продуктивність нашої служби  AI, яка вимагає надсилання піксельних буферів туди й назад із нашого Web Editor до нашої Native App для визначення  AI. 

Технічне обслуговування та підтримка

Як програма Inbox (входить до складу Windows), ми маємо переконатися, що Photos працює надійно для користувачів у всіх підтримуваних версіях Windows. У Windows App SDK більшість коду платформи постачається як частина пакета WindowsAppRuntime, на відміну від UWP, де все це постачається як частина операційної системи Windows.

Ключова відмінність між цими двома моделями полягає в тому, що користувачі автоматично отримують найновіші оновлення платформи для Photos App на Windows App SDK, тоді як в UWP їм доведеться чекати, поки ці зміни будуть включені в сервісні виправлення Windows Update.

На практиці це означає, що нам часто доводилося використовувати полізаповнення для виправлення помилок, повторної реалізації відсутніх API або навіть повного відключення функцій у старіших версіях ОС. З Windows App SDK це більше не потрібно, що економить дорогоцінний час розробки та зменшує витрати на тестування, необхідні для різних версій ОС.

Технічні виклики

ASTA vs STA

В UWP модель потоків ґрунтувалася на ASTA (Application Single-Threaded Apartment), яка має механізм захисту потоку інтерфейсу користувача XAML від повторного входу. На відміну від цього, Windows App SDK використовує звичайну модель STA, яка потребує особливої ​​обережності під час виконання певних викликів із потоку інтерфейсу користувача XAML, що інакше може спричинити повторне входження та Stowed Exceptions.

У більшості випадків виправлення полягало б у повторному поставленні в чергу проблемного виклику за допомогою DispatcherQueue, якщо його потрібно виконати в потоці інтерфейсу користувача. Інший підхід полягає в тому, щоб перевантажити певні завдання у фоновий потік, щоб відокремити логіку повторного входу від потоку інтерфейсу користувача.

Підтримка AutoPlay

Однією з головних особливостей Photos є можливість для користувачів підключати флеш-накопичувачі та мобільні телефони, щоб імпортувати свої мультимедійні файли. У Windows App SDK ця функція ще не реалізована, але є хороша альтернатива, використовуючи API оболонки Win32 і desktop3:AutoPlayHandler.

Ця функція працює шляхом розгортання та запуску окремого процесу COM-сервера, який обробляє активацію автоматичного відтворення та запускає робочий процес імпорту Photos App.

Дивлячись вперед

Перехід на Windows App SDK дозволив додатку Photos продовжувати використовувати красиві, згуртовані компоненти рідного інтерфейсу користувача, включені в WinUI, додавши можливість безпосереднього виклику API Win32 і зберігаючи сумісність з більшістю API UWP. З боку платформи перехід на Windows App SDK дає змогу всім користувачам Photos App негайно отримати найновіші покращення стабільності та продуктивності, оскільки Windows App Runtime оновлюється залежно від встановлення пакета Photos App.

Оновлення з UWP на Windows App SDK представляє більшу зміну, ніж попередні оновлення платформи Windows, однак відповідні переваги значно перевищують вартість розробки.

https://i.ytimg.com/vi/-72BHXxS2os/maxresdefault.jpg 

У майбутньому ми скористаємося перевагами Windows App SDK, створивши кожне вікно Photos App, що запускається в окремому процесі – архітектура, яка вже використовується з приголомшливим успіхом у веб-переглядачах на базі Chromium, таких як Microsoft Edge. Насолоджуйтеся цим коротким оглядом майбутніх покращень продуктивності!

 

Ресурси

Щоб дізнатися більше про початок роботи з WinUI & Windows App SDK, відвідайте https://aka.ms/windev і перегляньте ці відео:

Навігація у розробці програм Win32 за допомогою WinUI та WPF | BRK241

Як створити чудовий досвід за допомогою WinUI та WPF | BRK244

Рефакторинг коду з використанням псевдонімів будь-якого типу

Ця стаття є третьою в серії з чотирьох частин, в яких ми розглянемо різні можливості C# 12. У цій частині ми зануримося у функцію «псевдонім будь-якого типу», яка дозволяє створювати псевдонім для будь-якого типу за допомогою директиви using. Ця серія статей дійсно починає набувати гарних рис:

1. Рефакторинг вашого C# коду за допомогою первинних конструкторів

2. Рефакторинг вашого C# коду за допомогою виразів колекцій

3. Рефакторинг C# коду за допомогою псевдонімів для будь-яких типів (ця стаття)

4. Рефакторинг вашого C# коду для використання лямбда-параметрів за замовчуванням

 

Всі ці можливості продовжують наш шлях до того, щоб зробити наш код більш читабельним і зручним для супроводу, і вважаються «повсякденними можливостями C#», які повинні знати розробники. Давайте зануримося!

Псевдонім будь-якого типу *️⃣

У C# 12 з’явилася можливість псевдонімізувати будь-який тип за допомогою директиви using. Ця функція дозволяє вказувати псевдоніми, які відображаються на інші типи. Це стосується типів кортежів, вказівників, масивів і навіть не відкритих узагальнених типів, і всі вони будуть доступні у вашому коді. Ця можливість є особливо корисною:

• При роботі з довгими або складними іменами типів.

• Коли вам потрібно розмежувати типи і вирішити потенційні конфлікти імен.

• При визначенні типів кортежів значень, які ви маєте намір спільно використовувати у збірці.

• Коли ви хочете додати ясності до вашого коду, використовуючи більш описові імена.

Офіційна документація C# містить багато прикладів використання цієї можливості, але замість того, щоб повторювати ці приклади тут, я вирішив написати демонстраційну програму, яка ілюструє різні аспекти цієї можливості.

Типи посилань з нульовим значенням

_________________________________________________________________________

 

Ця функція підтримує більшість типів, за єдиним винятком типів посилань, які можна обнулити. Тобто, ви не можете створити псевдонім для nullable reference type, і компілятор C# повідомить про помилку CS9132: Using alias cannot be a nullable reference type. Наступні біти були вилучені зі специфікації функції, щоб допомогти прояснити цей момент:

Захистіть збірку контейнера та публікуйте за допомогою .NET 8

.NET 8 піднімає планку безпеки контейнерів для образів контейнерів .NET та інструментів SDK. За замовчуванням SDK створює образи додатків, які відповідають найкращим галузевим практикам і стандартам. Ми також пропонуємо додаткове посилення безпеки за допомогою образів Chiseled для додаткового рівня захисту.

dotnet publish створить для вас образ контейнера і за замовчуванням налаштує його як non-root. За допомогою .NET дуже просто швидко покращити безпеку ваших виробничих додатків.

У цій статті ви дізнаєтеся, як це зробити:

• Створення образів non-root контейнерів

• Налаштуйте Kubernetes, щоб вимагати non-root образи

• Перевірка образів і контейнерів

• Використання root  (або інших користувачів)

Ця стаття є продовженням статті Оптимізуйте збірку та публікацію контейнерів за допомогою .NET 8, опублікованої раніше цього місяця. Вона базується на статтях Захистіть свої хмарні додатки .NET за допомогою безкореневих Linux Containers та Запуск non-root контейнерів .NET за допомогою Kubernetes, опублікованих минулого року.

Модель загроз 

Будь-яку розмову про безпеку варто починати з чіткого уявлення про існуючі загрози.

Існує дві основні загрози, які слід враховувати:

• Порушення цілісності контейнера – зловмисник може вийти з контейнера і виконати операції всередині хоста.

• Віддалене виконання коду (RCE) – зловмисник може змусити програму виконувати операції всередині контейнера. Не є специфічною для контейнерів.

Незважаючи на те, що Docker не продається як програмне забезпечення для пісочниці, його налаштування за замовчуванням призначене для захисту ресурсів хоста від доступу до них процесів всередині контейнера.

Це чудовий опис ситуації, від втечі з контейнерів Docker та Kubernetes до root на хості (з посиланням на CVE-2019-5736). Автор говорить, що ми всі разом дуже покладаємося на «налаштування за замовчуванням» різних контейнерних рішень, які ми використовуємо, маючи на увазі, що прорив контейнера є реальною загрозою.

З тієї ж публікації, в розділі «Mitigations»:

Використовуйте низькопривілейованого користувача всередині контейнера

Тут автор фактично говорить про те, що вам потрібно зробити свій внесок, щоб безпечніше покладатися на псевдо-пісочницю контейнерних рішень. Якщо ви цього не зробите, і буде виявлено чергову вразливість контейнерів, то частина тягаря ляже на розробників, які розміщують свої додатки з правами root. Інакше кажучи, «caveat emptor».

У ландшафті безпеки та вразливостей може бути важко орієнтуватися навіть у найкращі часи. Актуалізація залежностей – це перший і найважливіший спосіб зменшити ці ризики, як для хоста, так і для гостя контейнера. Non-root хостинг є чудовим заходом глибокого захисту, який може захистити від невідомих майбутніх вразливостей.

Контейнерна екосистема: root за замовчуванням

 

Базові образи за замовчуванням налаштовано під користувачем root .

Після того, як я пояснив, що образи слід налаштовувати як non-root як важливий захід безпеки, я демонструю, що більшість базових образів публікуються з правами root, в тому числі і ті, які публікуємо ми. Чому?

Зручність використання переважає над безпекою для базових образів загального призначення і завжди буде переважати. Важливо, щоб керування пакунками та інші привілейовані операції були простими і щоб образи вищих рівнів могли вибирати потрібного користувача.

Однак, залишається вірним, що зловмисник з активною RCE-уразливістю зможе робити все, що завгодно, маючи привілеї root.

На відміну від них, базові образи Ubuntu Chiseled і Chainguard орієнтовані на пристрої і використовують інший підхід, ніж образи загального призначення. Вони обмінюють зручність використання і сумісність на безпеку. Ми підтримуємо цю точку зору.

Примітка: див. Образи захищених контейнерів: Зображення для безпечного ланцюга постачання.

Це багато контексту про базові образи і відмінний перехід до образів додатків, які (на нашу думку) повинні бути побудовані з філософією безпеки в першу чергу.

.NET екосистеми: Non-root за замовчуванням

За замовчуванням dotnet publish створює образи без права доступу до кореневого каталогу. Давайте подивимося на це за допомогою простої консольної програми. Я пропущу ряд кроків, які описано у статті Спрощення збірки контейнера та публікації за допомогою .NET 8.

Це вихідний код програми.

Створити зображення контейнера дуже просто.

 

 

Додаток привітається з користувачем, який запускає процес, як ви можете бачити з вихідного коду.

 

Як і очікувалося, ми бачимо Hello app.

Ми також можемо запустити whoami так само, як це було зроблено з базовими зображеннями.

 

Як видно, цей образ не використовує root, на відміну від базових образів, які ми розглянули.

Запуск whoami вимагає запуску образу. Kubernetes не робить цього; він дивиться на метадані зображення контейнера, щоб визначити користувача.

Давайте подивимося на метадані контейнера.

 

Подорож до доступних програм: 

доступність клавіатури та .NET MAUI

Чи доступна клавіатура ваших додатків? Давайте перевіримо:

1. Запустіть одну з ваших програм.

2. Підключіть фізичну клавіатуру, якщо вона ще не підключена до вашого пристрою.

3. Переміщайтеся у програмі так, як ви зазвичай це робите, і використовуйте для цього лише клавіатуру.

Як вам це вдалося? Чи було легко? Чи збігається це з вашим звичним досвідом навігації у додатку?

Забезпечення того, щоб користуватися додатком так само чудово, як і за допомогою клавіатури, є важливим для створення інклюзивного та доступного для всіх досвіду роботи з додатком.

Настанови з доступності веб-контенту (WCAG)

Щоб зрозуміти, що саме являє собою клавіатурна доступність, варто почати з Керівництва з доступності веб-контенту (WCAG).

WCAG – це набір технічних стандартів веб-доступності, на який часто посилаються і який поширюється на різні додатки та платформи за межами Інтернету. Він став глобальним стандартом і правовим орієнтиром і продовжує розвиватися разом з мінливим ландшафтом технологій.

Серед різних настанов є Guideline 2.1, яку часто не беруть до уваги, в якій йдеться про те, що розробники повинні «Зробити всю функціональність доступною з клавіатури».

Це включає в себе чотири критерії успіху:

Критерій успіху 2.1.1 Клавіатура

Вся функціональність контенту доступна через клавіатурний інтерфейс, не вимагаючи специфічного часу для окремих натискань клавіш, за винятком випадків, коли основна функція вимагає введення, яке залежить від шляху руху користувача, а не тільки від кінцевих точок.

Критерій успіху 2.1.2 Відсутність пастки клавіатури

Якщо фокус клавіатури можна перемістити на компонент сторінки за допомогою клавіатурного інтерфейсу, то фокус можна перемістити з цього компоненту за допомогою лише клавіатурного інтерфейсу, і, якщо для цього потрібно більше, ніж немодифіковані клавіші зі стрілками, табуляції або інші стандартні методи виходу, користувачеві надається інформація про метод переміщення фокусу.

Критерій успіху 2.1.3 Клавіатура (без винятків)

Вся функціональність контенту доступна через клавіатурний інтерфейс, не вимагаючи спеціального часу для окремих натискань клавіш.

Критерій успіху 2.1.4 Символьні комбінації клавіш

Якщо комбінація клавіш реалізована у контенті з використанням лише літер (включаючи великі та малі літери), розділових знаків, цифр або символів, то принаймні одна з наведених нижче ознак є істинною:

Вимкнути Існує механізм для вимкнення комбінації клавіш;

Змінити комбінацію клавіш Існує механізм для зміни комбінації клавіш, щоб додати до неї одну або кілька недрукованих клавіш клавіатури (наприклад, Ctrl, Alt);

Активна лише у фокусі Комбінація клавіш для компонента користувацького інтерфейсу активна лише тоді, коли на цьому компоненті є фокус.

Фундаментальне розуміння цих критеріїв допоможе вам розпочати розробку програм, доступних з клавіатури.

Доступ до клавіатури та .NET MAUI

Окрім інших міркувань, .NET MAUI було розроблено з метою полегшити розробку клавіатурного інтерфейсу. Отже, розробники, знайомі з поведінкою клавіатури Xamarin.Forms, помітили деякі зміни, які були зроблені для покращення доступності клавіатури в їхніх додатках.

Для того, щоб вся функціональність працювала через клавіатурний інтерфейс, важливо, щоб всі інтерактивні елементи управління були клавіатурно орієнтованими (могли отримувати фокус клавіатури) і клавіатурно навігаційними (могли переходити до них і з них за допомогою клавіатури). Це також включає в себе уникнення того, щоб невидимий вміст був доступний за допомогою клавіатури. Так само, як ми повинні очікувати, що видимі елементи керування будуть доступними для клавіатурного фокусу та навігації, ми повинні очікувати, що невидимі/неіснуючі елементи керування не будуть доступними для клавіатури або взагалі не будуть присутніми.

Щоб уникнути клавіатурних пасток, ми гарантуємо, що клавіатурна навігація можлива до всіх відповідних елементів керування у поточному поданні, всередині них та поза ними. Наприклад, якщо ви переміщуєтесь по екрану з декількома CollectionViews, .NET MAUI узгоджується зі стандартними очікуваннями клавіатурної доступності, дозволяючи вам легко переходити до будь-якого з CollectionViews та з нього за допомогою стандартних шаблонів клавіатурної навігації.

Тож як саме .NET MAUI дозволяє вам створювати клавіатурні інтерфейси з більшою легкістю? Ось 3 приклади:

1. Клавіатурна навігація на модальних сторінках

Однією з областей, в якій .NET MAUI навмисно враховує доступність клавіатури, є модальні сторінки. Коли з’являється модальна сторінка, як і для всіх інших сторінок, важливо переконатися, що все на ній доступно. Однак для модальних сторінок особливо важливо переконатися, що все, що знаходиться на основній сторінці, не доступне з клавіатури і не з’являється на модальній сторінці.

Коли з’являється модальна сторінка, фокус має бути на першому клавіатурному елементі керування на сторінці. Після цього весь вміст модальної сторінки має бути доступним, а всі інтерактивні елементи керування, які мають містити опцію виходу (зазвичай «Зберегти» або «Закрити») з модальної сторінки, мають бути сфокусовані на клавіатурі. Після виходу з модальної сторінки фокус має бути повернутий на основну сторінку, і перший елемент керування на основній сторінці повинен знову отримати фокус на клавіатурі.

Цю складність вирішує фреймворк .NET MAUI, тож ваші модальні сторінки будуть доступними для навігації одразу з коробки!

2. Фокусування/розфокусування клавіатури на Android

Під час розробки .NET MAUI ми дізналися ще одну річ, що неможливо «розфокусувати» запис на ранніх версіях Android. Якийсь елемент управління завжди повинен бути сфокусований. У Xamarin.Forms «розфокусувати» елемент можна було, встановивши фокус на макеті сторінки; на жаль, такий підхід створював серйозні проблеми з доступністю. З цих причин .NET MAUI не дозволяє таку недоступну поведінку за замовчуванням і наполегливо рекомендує використовувати інший підхід.

Мотивація використання «фокусування» і «розфокусування» часто пов’язана з показом і приховуванням клавіатури м’якого введення. Замість того, щоб маніпулювати фокусом для досягнення цієї мети, керуйте поведінкою клавіатури за допомогою нових SoftInputExtensions APIs! 

 

Наприклад:

Якщо SoftInputExtensions або інші альтернативні рішення не працюють для ваших потреб у фокусуванні клавіатури, команда .NET MAUI буде рада дізнатися більше про ваш сценарій. Будь ласка, поділіться з нами, щоб ми могли краще зрозуміти ваші потреби в розробці!

З огляду на це, у .NET 8 було введено додаткову властивість HideSoftInputOnTapped. Застосування цієї властивості дозволяє користувачам натискати на сторінку, щоб приховати клавіатуру м’якого введення, і ми рекомендуємо використовувати її лише у виняткових випадках.

3. Прискорювачі клавіатури

Як і у випадку з усіма чудовими, доступними рішеннями, проектування з урахуванням доступності означає проектування для всіх. Це особливо стосується доступності клавіатури, де ввімкнення витонченої поведінки клавіатури приносить користь усім користувачам, від тих, хто використовує клавіатуру як основний режим введення, до досвідчених користувачів, які полюбляють використовувати клавіатурні скорочення, також відомі як клавіатурні прискорювачі.

У .NET MAUI ми створили рішення для клавіатурних прискорювачів. За допомогою клавіатурних прискорювачів усі користувачі клавіатури та робочого столу можуть використовувати комбінації клавіш для активації команд пунктів меню!

 

Як описано в документації .NET MAUI, ось як можна почати додавати клавіатурні прискорювачі до MenuFlyoutItem в XAML або C#:

Обов’язково включіть клавіатурні прискорювачі у свій додаток .NET MAUI, якщо ви цього ще не зробили, і застосуйте свої нові знання з Критерію Успіху WCAG 2.1.4!

Подорож до доступних додатків

З інтерфейсом .NET MAUI ви можете створювати додатки, повністю доступні з клавіатури і позбавлені клавіатурних пасток, і зробити це простіше, ніж будь-коли раніше.

Якщо ви вперше читаєте «Подорож до доступних додатків», ласкаво просимо! Не забудьте переглянути мої попередні публікації в блозі, щоб дізнатися більше про створення доступних додатків і про те, як .NET MAUI полегшує цей процес.

Ви можете отримати більше інформації про інші покращення доступності клавіатури, зроблені в .NET MAUI, переглянувши останню публікацію в блозі про змістовне впорядкування контенту та рішення про видалення індексу вкладок.

.NET MAUI допомагає вам створювати доступні програми простіше, ніж будь-коли раніше. Як завжди, дайте нам знати, як ми можемо зробити це ще простіше для вас!

Представляємо вам .NET MAUI Community Tookit v8: з’явилася підтримка TouchBehavior!

Команда .NET MAUI Community Toolkit з гордістю представляє вам 8 версію інструментарію .NET MAUI Community Toolkit!

У цьому останньому великому випуску ми представили довгоочікувану TouchBehavior (раніше відому як TouchEffect). Але також, остерігайтеся змін у Snackbar у Windows, і чи знаєте ви, що ви можете розфарбувати навігаційну панель Android?

TouchBehavior

Якщо ви використовували Xamarin Community Toolkit у вашому додатку Xamarin.Forms, ви, ймовірно, знаєте про TouchEffect. Починаючи з .NET MAUI, ефекти були застарілими і їх слід перенести до (Platform)Behaviors. Це саме те, що ми зробили для цієї функціональності, реалізувавши її для .NET MAUI.

TouchBehavior надає можливість взаємодіяти з будь-яким візуальним елементом у вашому додатку на основі дотиків, кліків миші та наведення. Реалізація TouchBehavior дозволяє налаштовувати багато різних візуальних властивостей VisualElement, до якого він приєднаний, таких як колір фону, непрозорість, обертання і масштаб, а також багато інших властивостей. Крім того, TouchBehavior дозволяє реалізувати жести довгого натискання і викликати код, коли користувач довго натискає на будь-який візуальний елемент у вашому додатку.

 

 

Величезне спасибі Олександру, також відомому як Axemasta, члену спільноти, який тісно співпрацював з нами над цим проектом. Він проробив дивовижну роботу, щоб реалізувати цю величезну функцію, на яку багато людей чекали. Величезне йому спасибі!

Функція не є повною без документації, тому ми також підготували її для вас. Зверніть увагу, що є деякі зміни порівняно з TouchEffect для Xamarin, тому ми додали розділ, який допоможе вам з міграцією.

(Breaking) зміни в Behaviors

Під час роботи над TouchBehavior ми виявили, що контекст прив’язки застосовувався неправильно. Хороша новина полягає в тому, що ми знайшли причину цього, погана новина полягає в тому, що це стосувалося не тільки TouchBehavior, але й усіх інших поведінок у Toolkit.

На щастя, Брендон швидко знайшов першопричину і надав виправлення, яке ми невдовзі випустили.

Технічно, це зміна, яка порушує семантичну схему версій, але ми вирішили, що це не вплине на велику кількість людей. Якщо ми помилилися, приносимо свої вибачення і просимо зв’язатися з нами, щоб ми могли допомогти вам розібратися. Будь ласка, зробіть це, відкривши питання у сховищі з усіма необхідними деталями.

Breaking зміни для Snackbar у Windows

Нова велика версія зазвичай означає нові цікаві можливості, але також і докорінні зміни. У цьому випадку є кілька докорінних змін для використання Snackbar у Windows.

Власне, Владислав повністю переписав реалізацію Snackbar у Windows. Цими змінами ми замінили те, що використовується під капотом для реалізації Snackbar і Toast у Windows. В результаті ми виправили деякі збої, але, що більш важливо, ваш додаток для Windows більше не запускатиме інший екземпляр при взаємодії з Toast або Snackbar.

Обов’язково ознайомтеся з документацією до Snackbar, щоб дізнатися, як це може вплинути на ваш проект. Або, якщо ви дійсно хочете зануритися в деталі, подивіться запит на витягування цієї зміни.

Колір навігаційної панелі Android

Перш ніж ми перейдемо до цієї нової функції, давайте спочатку прояснимо, про що саме ми говоримо. Термін «панель навігації», здається, викликає деяку плутанину. Зазвичай, коли люди думають про панель навігації, вони мають на увазі панель у верхній частині сторінки з заголовком і, можливо, деякими елементами панелі інструментів. Однак, в контексті Android існує також системна панель навігації. Це та, що має 3 кнопки для повернення на попередню сторінку, відкриття багатозадачного режиму і переходу на головний екран вашого пристрою. Саме про цю навігаційну панель ми зараз говоримо!

Маючи це на увазі, давайте поговоримо про саму функцію. Тепер ви можете розфарбувати цю панель на Android так, щоб ваш додаток виглядав ще більш захоплююче, а ваша тема повністю інтегрувалася з усім, що ви бачите на екрані.

Ви також можете керувати тим, чи показуватиме панель навігації світлий або темний вміст, тобто чи будуть іконки світлого або темного кольору. Це дає змогу переконатися, що панель навігації завжди відповідає стилю вашого додатка.

Як почати роботу і все, що вам потрібно знати про цю функцію, можна знайти в документації.

Багато виправлень та оптимізацій

Звичайно, у цьому випуску було виконано багато іншої роботи, не забудьте переглянути повний список у примітках до випуску з усіма виправленнями та іншими оптимізаціями, які було зроблено у цьому випуску.

Велике спасибі всім, хто зробив цей випуск можливим, особливо всім учасникам спільноти, які так люб’язно витратили свій дорогоцінний час на наш проект і внесли свій вклад в екосистему .NET MAUI.

Що далі?

Ми раді представити вам останню велику версію .NET MAUI Community Toolkit, але, звичайно, ми не зупиняємося на досягнутому. Над наступною важливою функцією вже ведеться робота – CameraView, яка зараз переноситься з Xamarin на .NET MAUI. Хоча це частина сімейства Toolkit, він буде випущений окремим пакетом, тому слідкуйте за його появою. Крім того, ми працюємо над покращенням MediaElement, щоб забезпечити глибшу інтеграцію з операційною системою, наприклад, відтворення медіа з екрану блокування та відображення відповідних метаданих, і, звісно, багато іншого.

Повідомте нам, що ви думаєте про цей останній випуск, зв’яжіться з нами через GitHub repository, приєднайтеся до нашого Discord server і приходьте на наші прямі трансляції, які відбуваються кожного першого четверга місяця на  .NET Foundation YouTube channel  о 12:00 за тихоокеанським часом.

 

Ви можете отримати все це добро вже сьогодні! Отже, не забудьте оновити свій пакет .NET MAUI Community Toolkit до версії 8 сьогодні і починайте кодувати!

Windows Photos починає попередній перегляд версії Windows App SDK для інсайдерів Windows

Ми починаємо розгортати попередню версію програми “Фотографії”, створену за допомогою Windows App SDK (WASDK), для інсайдерів Windows у каналах Canary та Dev на Windows 11. Ця зміна переносить програму “Фотографії” на найновішу платформу для розробки додатків для Windows із сучасним інтерфейсом користувача та іншими покращеннями якості й продуктивності.

У цій версії збережено всі поточні функції та можливості програми “Фотографії”. Однак, зважаючи на значні зміни, ця версія може бути дещо недопрацьованою, оскільки ми продовжуємо вдосконалювати її роботу. Щоб випробувати цю версію, інсайдери Windows 11 на каналах Canary та Dev можуть оновити програму “Фото” до версії 2024.11040.1002.0.

Ми цінуємо ваші коментарі та пропозиції, тому діліться з нами своїми відгуками!

ВІДГУК: надішліть відгук у розділі Feedback Hub (WIN + F) «Програми» > «Фотографії» .

 

Щоб дізнатися більше про Windows App SDK, відвідайте: Створення настільних програм Windows за допомогою Windows App SDK – програми Windows | Microsoft Learn .

 

Source

Трансформуйте свій бізнес за допомогою розумних .NET-додатків на базі Azure та ChatGPT

За допомогою ChatGPT ви можете розкрити весь потенціал штучного інтелекту у своїх програмах .NET і гарантувати неймовірний досвід для користувачів від використання природної мови. ChatGPT — це більше, ніж просто інструмент; це те, що кардинально змінює те, як ми отримуємо доступ до даних і аналізуємо їх. Незалежно від того, використовуєте ви Azure, SQL Server або будь-яке інше джерело даних, ви можете легко інтегрувати ChatGPT у свої проєкти .NET і почати створювати інтелектуальні програми вже сьогодні.

У цій публікації я дам короткий огляд того, що таке інтелектуальні програми. Потім, використовуючи зразок програми, я покажу, як за допомогою комбінації служб Azure, таких як Azure OpenAI Service і Azure Cognitive Search, ви можете створювати власні інтелектуальні програми .NET.

TLDR

Ви найкраще вчитеся на практичному досвіді? Ознайомтеся з репозиторієм і приступайте прямо зараз!

Створіть свій власний розумний додаток .NET

Що таке розумні програми?

Розумні програми — це програми на основі штучного інтелекту, які змінюють продуктивність користувачів, автоматизують процеси та дають змогу отримувати різну інформацію.

Bing Chat є прикладом інтелектуальної програми.

ШІ лежить в основі Bing Chat. Bing Chat використовує штучний інтелект для обробки складних запитів, узагальнення релевантної інформації з різних джерел і створення відповідей.

Створюйте інтелектуальні програми за допомогою .NET

Тепер, коли ви маєте уявлення про те, що таке інтелектуальні програми, давайте подивимося на приклад програми, створеної за допомогою .NET, Azure і ChatGPT.

Переглянути відео

Припустімо, у вас є внутрішня корпоративна база знань, яка містить інформацію про посади, плани охорони здоров’я та інші ділові документи.

Можливо, ваші користувачі вже можуть здійснювати пошук у цій базі знань, але пошук відповідей на конкретні запитання шляхом фільтрування всіх документів у результатах пошуку може зайняти багато часу.

Використовуючи моделі штучного інтелекту, такі як ChatGPT, ви можете змінити продуктивність своїх користувачів, узагальнюючи інформацію, що міститься в цих документах, формуючи ключові висновки.

Архітектура програми

Вихідний код програми знаходиться на GitHub. Нижче наведено основні компоненти програми.

Інтерфейс користувача

Інтерфейс програми є статичною веб-програмою Blazor WebAssembly . Цей інтерфейс приймає запити користувачів, направляє запити до серверної частини програми та відображає згенеровані відповіді. Якщо ви працюєте з клієнтськими програмами на мобільному телефоні чи настільному комп’ютері, .NET MAUI також буде хорошим варіантом для цього компонента.

Сервер програми

Бекенд програми — це мінімальний API ASP.NET Core . Серверна частина містить статичну веб-програму Blazor і те, що організовує взаємодію між різними службами. Послуги, які використовуються в цій програмі, включають:

– Azure Cognitive Search – індексує документи з даних, що зберігаються в обліковому записі Azure Storage. Це робить документи доступними для пошуку.

– Служба Azure OpenAI – надає моделі ChatGPT для створення відповідей. Крім того, Semantic Kernel використовується в поєднанні зі службою Azure OpenAI Service для організації більш складних робочих процесів ШІ.

– Azure Redis Cache – кешує відповіді. Це зменшує затримку під час створення відповідей на схожі запитання та допомагає керувати витратами, оскільки вам не потрібно робити інший запит до служби Azure OpenAI.

Надання ресурсів і середовища для розробника

З усіма згаданими послугами процес початкового налаштування може здатися складним. Однак ми спростили цей процес за допомогою Azure Developer CLI . Якщо ви не хочете встановлювати будь-яку залежність, ми також можемо вам допомогти. Просто відкрийте репозиторій у GitHub Codespaces і використовуйте Azure Developer CLI, щоб надати свої послуги.

Використання ChatGPT у ваших документах

Тепер, коли ви знаєте компоненти, з яких складається ця програма, давайте подивимося, як вони працюють разом у контексті чату.

Перш ніж почати спілкуватися в чаті зі своїми документами, ви захочете мати базу знань, до якої можна зробити запит. Швидше за все, у вас вона вже є. Для цього прикладу програми ми зробили просту базу знань. У каталозі даних програми є набір PDF-документів. Щоб завантажити їх у Azure Storage та індексувати в Azure Cognitive Search, ми створили консольну програму C#.

Консольна програма C# виконує такі дії:

1. Використовує Azure Form Recognizer для вилучення тексту з кожного документа.

2. Розбиває документи на менші уривки. (нарізка)

3. Створює новий документ PDF для кожного з уривків.

4. Завантажує уривок до облікового запису сховища Azure.

5. Створює індекс у Azure Cognitive Search.

6. Додає документи до індексу когнітивного пошуку Azure.

 

Чому PDF-файли розбиваються на частини?

Моделі OpenAI, такі як ChatGPT, мають обмеження на токени. Щоб отримати додаткові відомості про обмеження маркерів, перегляньте довідковий посібник із квот і обмежень служби Azure OpenAI.

У цьому прикладі процес створення бази знань є ручним. Однак, залежно від ваших потреб, ви можете запускати його як завдання на основі подій щоразу, коли новий документ додається до облікового запису Azure Storage, або пакетно як фонове завдання.

Ще один шаблон, про який варто згадати, передбачає використання вбудовування для кодування семантичної інформації про ваші дані. Ці вбудовування зазвичай зберігаються у векторних базах даних. Щоб отримати коротку інформацію про вбудовування, перегляньте документацію щодо вбудовування Azure OpenAI . Цей шаблон не є основним, що використовується в цьому прикладі, і виходить за рамки цієї публікації. Однак у наступних публікаціях ми розглянемо ці теми більш детально, тож слідкуйте за оновленнями!

Спілкуйтеся зі своїми даними

Коли ви налаштуєте свою базу знань, настав час поспілкуватися з нею.

Запит до бази знань починається з того, що користувач вводить запитання у веб-програмі Blazor. Потім запит користувача направляється до ASP.NET Core Minimal Web API.

Всередині веб-інтерфейсу API кінцева точка chat обробляє запит.

api.MapPost(“chat”, OnPostChatAsync);

Щоб обробити запит, ми застосовуємо шаблон, відомий як Retrieval Augmented Generation, який робить наступне:

1. Запитує в базі знань відповідні документи

2. Використовує відповідні документи як контекст для створення відповіді

Запит до бази знань

Запити до Бази знань відбуваються за допомогою когнітивного пошуку Azure. Хоча когнітивний пошук Azure не розуміє природну мову, надану користувачем. На щастя, ми можемо використовувати ChatGPT, щоб допомогти перекласти природну мову в запит.

 

Використовуючи семантичне ядро, ми створюємо метод, який визначає шаблон підказки та додає історію чату та запитання користувача як додатковий контекст для створення запиту Azure Cognitive Search.

Потім цей метод використовується для створення запиту на створення команди.

Коли ви запускаєте функцію семантичного ядра, вона надає складену команду моделі Azure OpenAI Service ChatGPT, яка генерує відповідь.

З огляду на питання “Що входить до мого плану Northwind Health Plus, чого немає в стандарті?”, сформований запит може виглядати так: “Покриття плану Northwind Health Plus

Після створення запиту скористайтеся клієнтом Azure Cognitive Search, щоб зробити запит до індексу, що містить ваші документи.

На цьому етапі когнітивний пошук Azure поверне результати, які містять документи, які найбільше відповідають вашому запиту. Результати можуть виглядати так:

Northwind_Health_Plus_Benefits_Details-108.pdf: ви повинні надати Northwind Health Plus з копією EOB для первинного страхування, а також копію заяви, яку ви подали до свого первинного страхування. Це дозволить нам визначити переваги, доступні вам за Northwind Health Plus. Важливо зазначити, що Northwind Health Plus не покриває жодних витрат, які вважаються відповідальністю Основного покриття.

Benefit_Options-3.pdf: Плани також охоплюють профілактичні послуги, такі як мамографія, колоноскопія та інші скринінги на рак. Northwind Health Plus пропонує більш повне покриття, ніж Northwind Standard. Цей план пропонує покриття екстрених служб, як у мережі, так і поза мережею, а також покриття психічного здоров’я та зловживання психоактивними речовинами. Northwind Standard не пропонує покриття послуг екстреної допомоги, психічного здоров’я та токсикоманія, а також послуги поза мережею

Створення відповіді

Тепер, коли у вас є документи з відповідною інформацією, яка допоможе відповісти на запитання користувача, настав час використати їх для створення відповіді.

Ми починаємо з використання семантичного ядра для створення функції, яка створює запит, що містить історію чату, документи та додаткові запитання.

Чи жорстко ми кодуємо відповіді в запиті?

НЕ жорстко. Приклади в запиті слугують вказівками для моделі для створення відповіді. Відоме як кількакратне навчання.

Коли ви запускаєте функцію семантичного ядра, вона надає скомпонований запит для моделі Azure OpenAI Service ChatGPT, яка генерує відповідь.

Після деякого форматування відповідь повертається до веб-програми та відображається. Результат може виглядати приблизно так:

Щоб підвищити довіру до відповідей, відповідь включає цитати, повну підказку, яка використовується для створення відповіді, і допоміжний вміст, що містить документи з результатів пошуку.

Створюйте власні інтелектуальні програми

Ми з нетерпінням чекаємо майбутнього інтелектуальних програм у .NET.

Перегляньте вихідний код програми на GitHub і використовуйте його як шаблон, щоб почати створювати інтелектуальні програми на основі власних даних.

 

Створіть свій власний розумний додаток .NET

 

Source