Англійська мова для розробників Semantic Kernel

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

Ключовий словник

** Kernel ** — центральний об’ єкт оркестрації у Semantic Kernel, який містить зареєстровані додатки, з’ єднується з налаштованими службами штучного інтелекту і виконує функції, діючи як середовище виконання, через яке проходять всі взаємодії моделі. “Зареєструвати цей додаток у ядрі один раз під час запуску — вам не слід створювати новий екземпляр ядра кожного разу, коли ви хочете викликати функцію.”

** Додаток ** — набір пов’ язаних функцій (натуральний код або шаблони підказок), які згруповано разом і виставлено на показ моделі як можливості виклику, подібні за змістом до набору інструментів. “Згрупувати ці три функції у єдиний додаток — зараз вони зареєстровані окремо, що ускладнює виявлення моделлю їх як пов’ язаного набору.”

** Нативна функція проти семантичної функції ** — відмінність Семантичного ядра між функцією, реалізованою як звичайний код (нативна), і функцією, реалізованою як шаблон підказки, інтерпретований моделлю (семантична), обидві з яких можна викликати таким же чином ядром. “Це не обов’язково має бути семантичної функцією - це чиста арифметика, тому рідна функція швидша, дешевша і більш надійна, ніж запитувати модель обчислити її.”

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

• “Замість того, щоб твердо кодувати цей трикроковий процес, дозвольте планувальнику визначити послідовність функцій — він може пристосуватися, якщо ми додамо або вилучимо додатки пізніше.” *

** Memory connector ** — абстракція Semantic Kernel для зберігання і отримання вбудованих даних зі сховища векторів, використовується для надання моделі доступу до відповідного контексту за межами її безпосередньої команди.

• “Подключіть це через з’ єднання пам’ яті замість того, щоб вставляти весь документ у запит — тоді ми отримаємо лише ті шматки, які справді відповідають запитові.” *

Звичайні фрази

• «Чи зареєстрована ця функція в ядрі, або це тому, що модель не може побачити її як доступну можливість?»
• Чи повинні ці функції бути згруповані в один плагін, або вони достатньо не пов’язані, щоб залишатися окремими?»
• «Чи це дійсно має бути семантичної функції, або буде рідна функція більш надійним тут?»
• Чи ми жорстко кодуємо цю послідовність, чи дозволяємо планувальнику визначати порядок функцій динамічно?»
• «Чи відбувається пошук через коннектор пам’яті, або ми просто переносяємо сирий текст у пропозицію?»

Приклади речення

Пояснення рішення щодо архітектури: “Ми використовуємо рідну функцію для обчислення і семантичну функцію тільки для підсумку — немає причини маршрутизувати детерміністичну логіку через модель.”

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

Обговорення проблем з надійністю: “Закодування послідовності функцій є більш передбачуваним, ніж покладатися на планувальник — я б використовував планувальник тільки там, де кроки дійсно повинні змінюватися за вхідними даними.”

Професійні поради

• Реєструвати можливості на ** ядрі ** при запуску, а не за викликом — це уникнення зайвих налаштувань і зберігає доступні функції моделі послідовними між запитами.
• Групувати пов’ язані функції у єдиний ** додаток **, щоб зробити набір можливостей більш легкодоступним як для моделі, так і для розробників, які читають код.
• Типове значення — ** нативні функції ** для будь- чого детермінованого — зберігати семантичні функції для справді мовозалежних завдань, таких як підсумування або класифікація.
• Забезпечити ** планувальник ** для потоків робіт, де послідовність кроків дійсно має змінюватися — послідовності з твердим кодом є більш передбачуваними і простішими для зневадження у фіксованих потоках робіт.

Практичні вправи

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

Наприклад, мова йде про мовлення: мовлення немовляти

Сила Semantic Kernel полягає не лише у його технічній архітектурі — плануванні, виконанні додатків, векторних базах даних — але й у тому, наскільки ефективно ви говорите про це. Для розробників, чия перша мова не є англійською, це може здатися значною перешкодою. Легко перекласти * концепції * безпосередньо, але професійне спілкування вимагає більше, ніж буквальної точності; це вимагає розуміння тонких нюансів фразування, тону і очікуваних конвенцій у процесі розробки. Будьмо чесними: ідеально перекладене речення все одно може не влучити в ціль, якщо воно не відповідає немовленим припущенням, поширеним у технічних командах.

Однією з ключових областей є ясність навколо наміру. При описі запланованої операції колегі, простого твердження « Я використовую додаток для отримання даних користувача » недостатньо. Потрібний контекст. Ефективнішою фразою буде: «Я налаштував додаток GetProfile для отримання імені користувача і адреси електронної пошти на основі їхнього ідентифікатора, забезпечуючи дотримання нашої політики конфіденційності щодо збору даних». Різниця полягає в явному вказіванні * чому * ви використовуєте додаток - бажаний результат - і демонструєте обізнаність про пов’язані з цим роздуми. Аналогічно, отримання зворотнього зв’язку на кшталт «Це трохи заплутано; чи можете ви спростити планувальник?» вимагає більше, ніж просто ввічливе підтвердження. Вам слід розуміти, що рецензент підкреслює потенційні проблеми з ясністю і можливістю підтримки у межах загального дизайну системи. Це передбачення питань до того, як вони будуть поставлені, активне надання достатньої інформації для інших, щоб зрозуміти ваші міркування.

Іншою частою проблемою є опис змін у запитах на витягування. Замість короткого повідомлення « Виправлено ваду », розгляньте щось на зразок: « Впроваджено механізм повторних спроб для невдалих викликів додатків, що використовує експоненціальне відновлення для покращення стійкості до перехідних помилок. Це вирішує проблему, звітну в # 1234, де періодичні помилки впливали на досвід користувача.” Зауважте рівень деталізації - конкретна проблема, технічний підхід рішення і вплив на користувачів. Ці дані потрібні не тільки для документації; вони є ключовими для перегляду коду, що дозволяє переглядачам оцінювати якість і надійність вашої роботи.

Нарешті, пам’ятайте, що активне слухання є ключем. Коли хтось пояснює поняття або просить вас щось пояснити, не вагайтеся попросити про роз’ яснення. Фрази на зразок « Чи можете ви розібратися, що ви маєте на увазі під « холодним стартом » у цьому контексті? » або « Чи можете ви дати мені приклад того, як буде використовуватися цей додаток? » демонструють залученість і бажання вчитися — цінні якості у будь- якого розробника.

SKPlanner --generate-plan "Retrieve user profile details" \
  --steps (
    GetProfile { ID: "user123" }
  )