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

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

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

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

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

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

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

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

** Memory connector ** — абстракція Semantic Kernel для зберігання і отримання вбудованих даних зі сховища векторів, використовується для надання моделі доступу до відповідного контексту за межами її безпосередньої команди. “Wire this up through the memory connector instead of stuffing the entire document into the prompt — then we only retrieve the chunks that are actually relevant to the question.”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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