Programowanie w .NET
SEMANTIC KERNEL
Paweł Łukasiewicz: programista blogger
Paweł Łukasiewicz
2025-05-18
Udostępnij Udostępnij Kontakt
Paweł Łukasiewicz
2025-05-18
Udostępnij Udostępnij Kontakt
🧭 Najlepsze praktyki, wskazówki i pułapki

czyli co działa, co nie działa i czego unikać jak ognia 🔥

✨ Wprowadzenie

Semantic Kernel to potężne SDK, ale jak każda technologia – daje dużo swobody.
A tam, gdzie swoboda… tam i pułapki.

W tym wpisie dzielę się doświadczeniami, które zebrałem budując własne agenty, pluginy i planery.
Zobaczysz:

  • co działa najlepiej

  • jak pisać kod, który się nie rozleci

  • na co uważać przy integracjach, pamięci i promptach

✅ Najlepsze praktyki

🔹 1. Myśl jak architekt, nie jak haker

Nie buduj wszystkiego w jednym agencie.
Zamiast tego:

  • twórz modularne pluginy – małe, odpowiedzialne funkcje

  • oddziel logikę LLM od infrastruktury

  • nie ładuj całego świata do prompta – korzystaj z pamięci

🧠 Dobra praktyka: traktuj każdego agenta jak usługę – powinien mieć jasno określone API i odpowiedzialność.

🔹 2. Testuj prompty na zimno

Nie czekaj, aż coś "zadziała".
Testuj swoje prompty:

  • w Playgroundzie (OpenAI/Azure) zanim wrzucisz do kodu

  • na różnych danych wejściowych

  • z różnymi temperaturami

Zapisuj testy w .prompt.txt i wersjonuj.
Będziesz wiedział, co zmieniło się między deployami.

🔹 3. Traktuj pamięć jak cache, nie bazę danych

Memory w Semantic Kernelu to tymczasowy kontekst, nie repo wiedzy.
Nie wrzucaj tam całych książek ani transkrypcji.
Segmentuj dane, używaj tagów, twórz embeddingi z głową.

🧠 Jeśli potrzebujesz „bazy wiedzy” – użyj zewnętrznego wektora (np. Qdrant, Pinecone).

🔹 4. Używaj FunctionResult i SKContext świadomie

Jeśli wtyczka może się wysypać – zabezpiecz ją.
Jeśli prompt ma wiele ścieżek – sprawdzaj output.

Nie wszystko da się przewidzieć, ale możesz:

  • sprawdzać context.Variables.ContainsName(...)

  • pisać testy na funkcje promptowe

  • logować każdy FunctionResult

🔹 5. Debuguj jak człowiek, nie wróżbita

Dodaj middleware, który loguje:

  • nazwę funkcji

  • prompt wejściowy

  • output

  • ewentualne wyjątki

To naprawdę pomaga, kiedy po 10 minutach działania Twój agent mówi:

"Sorry, I don't know what to do next" 🙃

⚠️ Najczęstsze pułapki

❌ 1. Prompt, który "działał wczoraj"

Prompty są wrażliwe na kontekst. Zmiana modelu, inputu, czy nawet kolejności pluginów – może rozwalić działanie.
Używaj PromptTemplateConfig, a nie gołych stringów.

❌ 2. Zbyt wiele funkcji w jednym planie

Planery są świetne, ale jeśli wrzucisz 15 funkcji – model się zgubi.
Ogranicz się do 3-5 opcji, najlepiej powiązanych tematycznie.

❌ 3. Niezabezpieczony dostęp do pluginów

Jeśli tworzysz plugin do wysyłania maili – zabezpiecz go.
Nie każdy prompt powinien móc wywołać DeleteAllUserData(). 😅

Używaj filtrów (FunctionFilter), ograniczeń i logiki kontekstowej.

❌ 4. Brak fallbacku, gdy model się wysypie

Czasem model nie odpowie. Czasem poda bzdury.
Zawsze warto mieć:

  • defaultowy komunikat

  • retry logic

  • plan B (np. kontakt z człowiekiem)

❌ 5. Robienie wszystkiego w promptach

Nie wszystko trzeba wrzucać do LLM-a.
Prosta walidacja? Pętla? Logika?
Zrób to po stronie C#, nie GPT-4.

🔧 Wskazówki ekstra

  • 📄 Zawsze loguj pełne zapytania i odpowiedzi – przyda się do retrainów

  • 🔁 Jeśli coś nie działa – zmień prompt zanim zmienisz kod

  • 🧪 Testuj z różnymi modelami (GPT-3.5 vs GPT-4 vs lokalny LLM)

  • 🧩 Baw się planowaniem funkcji – ale rób to iteracyjnie

🧠 TL;DR

✅ Rób❌ Nie rób
Twórz małe pluginyŁaduj wszystko w jedno
Testuj promptyZakładaj, że "zadziała"
Używaj pamięci z umiaremWrzuć wszystko do memory
Dodawaj logi i fallbackiLicz, że się nie wysypie
Ogranicz liczbę funkcjiWrzuć wszystko do planera

👣 Co dalej?

W kolejnym wpisie stworzymy finalny projekt, tj. połączymy pluginy, scoring, podsumowania i szablony promptów w jedną sensowną aplikację.