Trzech redaktorów przegląda odbitki przy stole w procesie redakcyjnym Droptica dla alt textów AI.

Drupal AI: alt texty, metadane i podsumowania

Gdy w backlogu redakcyjnym czeka już dwusetna strona do opracowania, zespół zwykle skupia się na jej głównej treści. Meta opisy, teksty alternatywne obrazów i podsumowania wyświetlane na listach łatwo schodzą wtedy na dalszy plan. Generowanie tekstów alternatywnych za pomocą Drupal AI oraz automatyzacja podobnych zadań mogą pomóc zmniejszyć ten backlog. Redaktorzy otrzymują szkice do weryfikacji bezpośrednio przy treściach, których one dotyczą.

Warto zacząć od czterech zadań: tekstów alternatywnych, meta opisów, podsumowań i sugestii słów kluczowych. Każde z nich ma jasno określone dane źródłowe i pole, w którym powinien zostać zapisany wynik. Kluczowa jest jedna zasada: każda wygenerowana wartość najpierw trafia do weryfikacji, a nie bezpośrednio na opublikowaną stronę.

Ustrukturyzowane pola Drupala pozwalają skutecznie zastosować ten model w praktyce. Zatwierdzone treści mogą zasilać strony, listy, metadane oraz odpowiednio skonfigurowane API bez konieczności utrzymywania osobnych kopii. Taka spójność pomaga zarówno czytelnikom, jak i systemom AI korzystającym z informacji publikowanych na stronach. Wygenerowany tekst nadal wymaga sprawdzenia. Ustrukturyzowanie treści pozwala wykorzystywać informacje w wielu miejscach, ale samo w sobie nie gwarantuje ich poprawności.

W tym artykule:

Jak zapisać wygenerowany tekst we właściwym polu Drupala?

Redaktorzy oszczędzają czas, gdy mogą przejrzeć szkic bezpośrednio w Drupalu, zamiast kopiować treść do zewnętrznego narzędzia i przenosić odpowiedź z powrotem do CMS-a. Dla każdego zadania trzeba wskazać pola źródłowe, reguły walidacji, pole przeznaczone na wygenerowany szkic oraz miejsce jego weryfikacji.

Na początku sprawdź zainstalowane moduły Drupal AI oraz skonfigurowane integracje z dostawcami modeli. Generowanie tekstu alternatywnego wymaga modelu obsługującego obrazy. Sposób zapisywania wyników w polach, obsługa kolejek i integracja z moderacją treści zależą od wybranych modułów i konfiguracji. Niektóre scenariusze wymagają dodatkowych prac programistycznych.

Podstawowa ścieżka wygląda tak:

  1. Wybór dostawcy AI i modelu obsługiwanego przez zainstalowane moduły.
  2. Przekazanie do modelu wyłącznie zatwierdzonych pól źródłowych potrzebnych do wykonania zadania.
  3. Uruchomienie wersjonowanego promptu z określonymi limitami danych wejściowych i odpowiedzi.
  4. Walidacja formatu odpowiedzi i ograniczeń specyficznych dla zadania.
  5. Zapisanie wygenerowanego szkicu do weryfikacji.
  6. Przeniesienie zatwierdzonej wartości do pola wykorzystywanego podczas publikacji.

Moderacja całej treści i zatwierdzanie wartości pojedynczego pola to dwa różne mechanizmy. Oczekująca rewizja może przechowywać wygenerowane zmiany, podczas gdy bieżąca rewizja pozostaje opublikowana. Osobne pole może przechowywać wygenerowany szkic obok wcześniej zaakceptowanej wartości. Sam status „do weryfikacji” nie zapobiega wyświetleniu niezatwierdzonego tekstu na stronie, jeśli szablon korzysta z tego pola.

Sposób przechowywania wygenerowanych i zatwierdzonych wartości warto ustalić przed podłączeniem modelu. Pola przeznaczone na szkice nie powinny być uwzględniane w publicznych szablonach, kanałach RSS ani odpowiedziach API. Trzeba to zapewnić przez odpowiednią konfigurację renderowania i dostępu. Trzeba przetestować wszystkie kanały publikacji, w tym anonimowy dostęp do API. Samo przeznaczenie pola na szkic nie oznacza, że jego zawartość jest automatycznie prywatna.

Ponowne generowanie treści również wymaga jasno określonych zasad. Zachowaj zaakceptowane wartości, dopóki redaktor nie zatwierdzi zamiennika. Przy każdym szkicu zapisuj rewizję i język treści źródłowej, wersję promptu, użyty model oraz status generowania. Przed zatwierdzeniem sprawdź, czy źródło się nie zmieniło.

Mechanizmy te trzeba zaprojektować podczas wdrożenia. Nie są one automatycznie zapewniane przez każdą integrację Drupal AI. Wprowadzenie do opcji modułowych znajduje się w artykule Jak wygenerować alt text i strategię treści za pomocą modułów AI w Drupalu?. W tym artykule skupiamy się na procesie prowadzącym od wygenerowanego szkicu do zatwierdzonej wartości pola.

Jakich danych potrzebuje AI, aby przygotować trafny tekst alternatywny?

W przypadku prostych, typowych obrazów AI może przygotować użyteczny szkic tekstu alternatywnego. Redaktor może wtedy skupić się na ocenie, czy opis właściwie oddaje funkcję obrazu w kontekście danej strony.

Na pierwszym miejscu jest kontekst. Przekaż:

  • sam obraz przekazany do modelu obsługującego dane wizualne;
  • podpis, jeśli istnieje;
  • tekst w pobliżu, który wyjaśnia, dlaczego obraz tam jest;
  • język treści;
  • funkcję obrazu, na przykład zilustrowanie cechy produktu albo wsparcie instrukcji.

Sama nazwa pliku nie wystarczy. Nawet ten sam obraz może wymagać różnych tekstów alternatywnych zależnie od miejsca i celu jego wykorzystania.

Przykładowy prompt startowy:

Przygotuj zwięzły alt text dla tego obrazu w podanym kontekście strony i języku. Opisz informacje istotne dla czytelnika. Nie zgaduj tożsamości, wymiarów ani szczegółów, których nie da się ustalić. Jeśli obraz wymaga dłuższego wyjaśnienia, zwróć ostrzeżenie do weryfikacji zamiast krótkiego, zbyt pewnego opisu.

Zaprojektuj format odpowiedzi tak, aby system mógł odróżnić proponowany tekst od ostrzeżenia wymagającego dodatkowej weryfikacji. Na przykład strukturalna odpowiedź może mieć osobne właściwości candidate i review_warning. Zanim zapiszesz wynik, zwaliduj tę strukturę.

Miejsce docelowe: przechowuj wygenerowany szkic w polu widocznym wyłącznie podczas weryfikacji i powiązanym z konkretnym użyciem obrazu. Po zatwierdzeniu zapisz go jako wartość atrybutu alt przypisaną do obrazu użytego w danym miejscu.

Uwzględnij możliwość wykorzystania tego samego elementu Media w różnych miejscach. Wspólny element mediów może pojawić się na stronie produktu, w aktualności i w instrukcji. Jeden wspólny tekst alternatywny może nie pasować do wszystkich tych kontekstów. Jeśli serwis przechowuje tekst alternatywny wyłącznie w encji Media, może być potrzebne jego nadpisanie w konkretnym miejscu użycia obrazu albo przyjęcie innej zasady redakcyjnej.

Decyzje o obrazach dekoracyjnych pozostaw redaktorom. Pusty atrybut alt bywa poprawny, gdy obraz nie niesie informacji. Celem jest przekazanie użytkownikowi potrzebnej informacji, a nie mechaniczne wypełnienie pola przy każdym obrazie.

Jak AI może przygotować meta opisy bez wymyślonych obietnic?

Meta opisy są dobrym zadaniem pilotażowym, ponieważ można precyzyjnie określić dane źródłowe i oczekiwany format wyniku. Redaktor dostaje krótki szkic zamiast pustego pola.

Przekaż tytuł strony, zatwierdzoną treść główną, typ strony i język. Nie przekazuj do modelu nawigacji, stopki ani niepowiązanych bloków promocyjnych. W przeciwnym razie model może opisać organizację zamiast strony.

Przykładowy prompt:

Napisz meta opis o długości 150–160 znaków w podanym języku, korzystając wyłącznie z podanej treści strony. Podaj główną korzyść lub cel strony. Nie dodawaj twierdzeń, cen ani obietnic. Zwróć sam opis.

Miejsce docelowe: zapisz wynik w polu przeznaczonym na szkic albo w rewizji oczekującej na weryfikację. Po zatwierdzeniu zapisz wartość w polu lub konfiguracji wykorzystywanej przez moduł Metatag, zgodnie z modelem treści i konfiguracją tokenów w serwisie.

Długość w znakach sprawdź w kodzie. Modele potrafią podać sensowne zdanie i jednocześnie pominąć wymagany zakres. Traktuj ten zakres jako wytyczną redakcyjną, a nie gwarancję długości fragmentu wyświetlanego przez wyszukiwarkę.

Weryfikacja merytoryczna to więcej niż pomiar długości. Szkic może mieścić się w wymaganym limicie, a mimo to zawierać niepotwierdzone obietnice albo nieaktualne informacje. Wyświetl treść źródłową obok szkicu i oznacz słowa, liczby lub sformułowania wymagające dokładniejszej kontroli.

Uzupełniony meta opis jest efektem procesu redakcyjnego, ale nie gwarantuje sposobu prezentacji strony w wynikach wyszukiwania. Wyszukiwarka może wyświetlić inny fragment strony, dlatego samo uzupełnienie pola nie świadczy o wzroście ruchu organicznego.

Jak zachować sens źródła w podsumowaniach?

Szkice podsumowań generowane przez AI mogą ograniczyć pracę związaną z aktualizowaniem opisów wyświetlanych na listach treści. Najlepiej sprawdzają się wtedy, gdy wiadomo, gdzie podsumowanie będzie wyświetlane i jakiego poziomu szczegółowości potrzebuje czytelnik.

Przekaż zatwierdzoną treść główną, tytuł, docelową długość, język oraz warunki potrzebne do zrozumienia strony. Jeśli warunek cenowy jest w osobnym polu, dołącz to pole zamiast liczyć na domysły modelu.

Prompt startowy:

Streść tę stronę w dwóch zdaniach do listy treści, w podanym języku. Użyj wyłącznie podanych faktów. Zachowaj zastrzeżenia i niepewność. Nie licz, nie wnioskuj ani nie wprowadzaj liczb. Zwróć samo podsumowanie.

Miejsce docelowe: przechowuj szkic w polu przeznaczonym do weryfikacji. Po zatwierdzeniu zapisz go we właściwości summary pola treści, jeśli serwis z niej korzysta, albo w osobnym polu podsumowania wykorzystywanym na listach.

Załóżmy, że strona podaje 40 USD za użytkownika miesięcznie w abonamencie, z rabatem 15% przy rozliczeniu rocznym do 30 września. Podsumowanie „Abonament kosztuje 34 USD miesięcznie” samodzielnie oblicza kwotę, pomija informację „za użytkownika” oraz usuwa warunek rozliczenia i termin obowiązywania rabatu.

Podsumowanie bez liczb też może wprowadzać w błąd. „Dostępne są tańsze abonamenty” ukrywa warunki, które wyjaśniają, kto kwalifikuje się do rabatu i do kiedy.

Każda wygenerowana wartość z liczbą wymaga sprawdzenia przez człowieka względem źródła. Dotyczy to cen, procentów, dat, wymiarów i liczb zapisanych słownie.

Po zmianie treści źródłowej system powinien oznaczyć zaakceptowane podsumowanie jako wymagające ponownej weryfikacji, zamiast automatycznie je zastępować. W przypadku treści ograniczonych czasowo powiąż ten status z procesem publikacji, aby nieaktualne podsumowanie nie pozostało niezauważone w innych kanałach.

Jak przygotować użyteczne sugestie słów kluczowych dla redaktorów?

Sugestie słów kluczowych mogą zapewnić redaktorom krótką listę terminów pomocnych podczas tagowania i przeglądu treści. Zakres zadania powinien być wąski: model ma wskazywać wyłącznie terminy rzeczywiście obecne w treści lub bezpośrednio przez nią uzasadnione.

Wejścia to tytuł, zatwierdzona treść główna i język. Jeśli sugestie mają zostać przypisane do taksonomii, przekaż modelowi listę dozwolonych terminów.

Przykład:

Zaproponuj do pięciu terminów popartych tą stroną. Gdy podano dozwolone słownictwo, wybieraj wyłącznie z niego. Nie wymyślaj tematów ani twierdzeń o popycie w wyszukiwarce. Zwróć tablicę JSON z terminami.

Miejsce docelowe: zapisz sugestie w polu tylko do weryfikacji. Jeśli redaktor zatwierdzi sugestie, dopasuj je do istniejących encji terminów taksonomii i zapisz odpowiednie referencje w polu docelowym.

Zanim pokażesz sugestie, zwaliduj format JSON i dopasowanie do słownictwa. Jeśli różne terminy mają takie same etykiety, przekaż wraz z listą ich identyfikatory i informacje o słowniku, aby system mógł wskazać właściwą encję. Nieznane lub niejednoznaczne terminy kieruj do weryfikacji, zamiast automatycznie tworzyć nowe elementy taksonomii.

Redaktorzy potrzebują prostej akcji odrzucenia, która nie zmienia opublikowanej strony.

To nie jest badanie słów kluczowych. Na podstawie samej treści strony nie można określić wolumenu wyszukiwań, trudności osiągnięcia wysokiej pozycji ani rzeczywistego zainteresowania użytkowników. Takie sugestie mogą pomóc klasyfikować istniejące treści, ale nie zastępują strategii treści ani badania słów kluczowych.

Jak zaplanować proces weryfikacji, aby zachować kontrolę nad jakością?

Dobrze zaprojektowany ekran weryfikacji skraca czas potrzebny na ocenę szkicu. Pokaż obok siebie źródło, wygenerowany szkic, dotychczasową zaakceptowaną wartość i ostrzeżenia. Daj redaktorom jasne akcje: zaakceptuj, edytuj, odrzuć.

Trzymaj porównanie w jednym widoku. Otwieranie kilku kart, żeby zweryfikować krótki opis, może zniweczyć czas zaoszczędzony dzięki generowaniu.

Na początku pilotażu każda wygenerowana wartość powinna zostać zweryfikowana przez człowieka. Zapisuj powody zmian i odrzuceń w kilku praktycznych kategoriach: brak kontekstu, niepotwierdzone twierdzenie, zły język, niewłaściwy opis obrazu.

Gdy zadanie działa stabilnie, można rozważyć weryfikację próbkową dla partii o niższym ryzyku. Przykładowa reguła startowa:

Grupa treści Sugerowana reguła weryfikacji
Nowe zadanie, prompt, model lub mapowanie źródła Weryfikacja każdej wygenerowanej wartości
Ugruntowane zadanie o niższym ryzyku Losowa kontrola 10% partii, zaokrąglone w górę, minimum jeden element na parę zadanie–język
Każda wygenerowana wartość z liczbą Sprawdzenie każdej wartości względem źródła
Diagramy techniczne i inne treści wysokiego ryzyka Weryfikacja każdego elementu przez osobę z wiedzą merytoryczną

Stawka 10% to przykładowa reguła operacyjna, a nie branżowy benchmark ani gwarancja poprawności. Dobierz ją do skutków błędu i wyników pilotażu.

Treści wysokiego ryzyka nie powinny być oceniane wyłącznie na podstawie losowej próbki. Do tej grupy należy zaliczyć również podsumowania stron zawierających wiele danych liczbowych, nawet jeśli liczby nie pojawiają się w samym wygenerowanym wyniku.

Wstrzymaj publikację całej partii do czasu jej zatwierdzenia przez redaktora. Kontrola próbkowa zmienia jedynie sposób oceny partii o niższym ryzyku. Nie oznacza zgody na automatyczne publikowanie wyników przez model. Gdy próbka ujawni błąd merytoryczny, wstrzymaj partię i poszerz weryfikację, w razie potrzeby do każdego elementu.

Po zmianie modelu, promptu lub mapowania pól źródłowych wróć do pełnej weryfikacji. Wcześniejsze wyniki nie dowodzą jakości zmienionego procesu pracy.

W jakich sytuacjach generowanie treści najczęściej zawodzi?

Powtarzające się problemy zwykle wynikają z niewystarczających danych źródłowych, ograniczeń modelu albo nieprecyzyjnie zdefiniowanego zadania. Takie przypadki warto automatycznie kierować do odpowiedniej ścieżki obsługi, zamiast za każdym razem prosić redaktorów o naprawianie tego samego rodzaju błędu.

Diagramy techniczne wymagają wiedzy merytorycznej

Model może rozpoznać prostokąty, strzałki i etykiety bez zrozumienia relacji między nimi. Krótki alt text może pominąć kierunek, zależności lub sens wykresu.

Diagramy techniczne kieruj do weryfikacji przez osobę posiadającą odpowiednią wiedzę merytoryczną. Może zdecydować, czy obraz potrzebuje zwięzłego alt textu plus wyjaśnienia w pobliżu, tabeli danych czy innego tekstu zastępczego.

Liczby łatwo tracą kontekst

Podsumowania i opisy mogą przypisać liczbę do niewłaściwego twierdzenia, zmienić jednostkę albo pominąć datę ograniczającą ważność.

Powtórz regułę w interfejsie weryfikacji: wygenerowana wartość z liczbą wymaga sprawdzenia przez człowieka. Treść bez liczb też wymaga uwagi, gdy źródło opiera się na progach, wyjątkach lub warunkach.

Niepełne dane źródłowe zwiększają ryzyko dopisywania niepotwierdzonych szczegółów

Tytuł i krótki akapit mogą nie wystarczyć do sensownego opisu. Sprzeczne pola dają podobny efekt.

Zdefiniuj w procesie pracy wynik „wymaga doprecyzowania źródła”. Brak wygenerowanego szkicu jest bezpieczniejszy niż wiarygodnie brzmiące zdanie, które nie wynika z żadnego zatwierdzonego źródła.

Tłumaczenia potrzebują własnego źródła i weryfikatora

Generuj z zatwierdzonej treści w docelowym języku, wraz z przetłumaczonymi podpisami i terminami taksonomii. Automatyczne podstawienie wersji w innym języku może wprowadzić na lokalną stronę szczegóły, które tam nie pasują.

Weryfikator powinien oceniać język i terminologię. Śledź jakość osobno dla każdego języka, żeby dobry wynik w jednym nie maskował problemów w drugim.

Jeśli błąd się powtarza, zmień sposób obsługi zadania: dodaj brakujące pole źródłowe, popraw prompt albo skieruj ten typ treści do ręcznego opracowania.

Jak kontrolować koszty tokenów i liczbę ponowień?

Zasady kontroli kosztów ustal przed uruchomieniem przetwarzania masowego. Koszt wielu niewielkich zapytań szybko rośnie, szczególnie gdy proces obejmuje kilka języków, rewizje i wielokrotne ponowienia.

Wysyłaj tylko to, czego potrzebuje dane zadanie. Generowanie meta opisu zwykle nie wymaga całej wyrenderowanej strony. Opis obrazu potrzebuje grafiki i kontekstu, a nie każdego akapitu na witrynie.

Ustal limity rozmiaru wejścia, rozmiaru wyjścia, wielkości partii i liczby ponownych prób. Gdy treść źródłowa przekracza limit wejścia, oznacz to albo zastosuj świadomą selekcję; ciche obcięcie może usunąć zastrzeżenie, od którego zależy trafność podsumowania.

Kolejkuj pracę masową tak, by redaktorzy mogli ją wstrzymać przy wzroście błędów lub kosztów. Obsłuż awarie dostawcy z ograniczoną liczbą ponownych prób i opóźnieniem (backoff). Nie ponawiaj generowania bez ograniczeń tylko dlatego, że odpowiedź nie spełniła wymaganego limitu długości albo formatu.

Aby uniknąć zbędnego ponawiania operacji, porównuj skrót kontrolny istotnych pól źródłowych, język, wersję promptu i konfigurację modelu z danymi poprzedniego uruchomienia. Pomijaj niezmienione wejścia i zaakceptowane pola, chyba że redaktor poprosi o regenerację albo proces wykryje zmianę źródła.

Porównaj modele na tej samej reprezentatywnej próbce, zanim wybierzesz tańszą opcję. Zadania wyłącznie tekstowe i z obrazami mogą wymagać różnych modeli. Tańszy model może zwiększyć całkowity koszt procesu, jeśli redaktorzy muszą poświęcać więcej czasu na poprawianie jego wyników.

Monitoruj koszty i wykorzystanie zasobów według zadania, modelu i języka, uwzględniając:

  • tokeny wejściowe i wyjściowe;
  • opłaty za przetwarzanie obrazów;
  • ponowne próby i nieudane zapytania, za które dostawca nalicza koszt;
  • liczbę zaakceptowanych pól wyjściowych.

Ustal budżety dla poszczególnych partii i skonfiguruj alerty na podstawie aktualnych cenników dostawcy. Gdy ważny jest twardy limit wydatków, dodaj zatrzymanie kolejki zamiast polegać wyłącznie na alercie. Bez informacji o długości treści, liczbie przetwarzanych obrazów, wybranym modelu i zasadach ponawiania nie da się przygotować wiarygodnego, uniwersalnego kosztu przetworzenia jednej strony.

Ogranicz też ekspozycję danych. Wysyłaj tylko zatwierdzone wejścia, sprawdź warunki przechowywania u dostawcy i unikaj przekazywania treści objętych ograniczeniami przez proces zaprojektowany pod strony publiczne.

Jak sprawdzić, czy automatyzacja przyniosła oczekiwany efekt?

Mierz liczbę poprawnie uzupełnionych i zaakceptowanych pól, a nie liczbę wygenerowanych odpowiedzi. System może wygenerować wiele szkiców, nie zmniejszając przy tym liczby treści oczekujących na publikację.

Przed rozpoczęciem pilotażu określ skalę backlogu osobno dla każdego zadania:

  • brakujące lub nieaktualne meta opisy;
  • brakujące lub nieaktualne podsumowania;
  • umiejscowienia obrazów czekające na właściwy tekst zastępczy;
  • strony oczekujące na przegląd słów kluczowych lub taksonomii.

Za ukończoną należy uznać poprawną i zaakceptowaną wartość opartą na aktualnej wersji treści źródłowej. Celowo pusty alt text rejestruj osobno od brakującej pracy. Przy sugestiach słów kluczowych decyzja redaktora, że żadne przypisanie nie jest potrzebne, może liczyć się jako zamknięta weryfikacja bez dodawania tagu.

Porównaj liczbę zaakceptowanych pól przed i po pilotażu. Szkice oczekujące na weryfikację raportuj osobno.

Następnie oceń nakład pracy potrzebny do uzyskania zaakceptowanych wartości:

Miara Co pokazuje
Akceptacja bez edycji Jak często szkic pasuje od razu
Edycje i odrzucenia według powodu Które wejścia lub prompty wymagają uwagi
Czas weryfikacji na zaakceptowane pole Czy generowanie skraca pracę redakcji
Koszt dostawcy na zaakceptowane pole Ile kosztuje użyteczny wynik
Odsetek zaakceptowanych pól zgodnych z treścią źródłową Czy zaakceptowane treści nadal odpowiadają aktualnej wersji źródła

Przy ocenie całkowitych kosztów uwzględnij czas redaktorów. Porównaj pracę wspieraną przez AI z małą ręczną próbką podobnych treści, zamiast zakładać, że każdy szkic oszczędza czas.

Część zadań wymaga korekty. Gdy weryfikacja opisów obrazów technicznych trwa dłużej niż pisanie od zera, zostaw takie przypadki w trybie ręcznym. Gdy meta opisy regularnie przechodzą po drobnych poprawkach, to może być zadanie do rozszerzenia.

Ustrukturyzowane pola Drupala ułatwiają prowadzenie takich pomiarów. Zespół może mierzyć ukończenie według zadania, języka i typu treści, a potem ponownie używać zaakceptowanych wartości w skonfigurowanych kanałach publikacji. Znaczenie każdego pola pozostaje jednoznaczne niezależnie od tego, czy wartość jest wyświetlana na stronie, wykorzystywana na liście czy udostępniana przez API.

Od czego zacząć pilotaż Drupal AI?

Na początek wystarczy jeden typ treści i reprezentatywny zestaw materiałów: typowe obrazy, diagram techniczny, strona zawierająca dane liczbowe oraz wersje językowe planowane do obsługi.

Droptica może pomóc zaplanować niewielki pilotaż Drupal AI: wskazać pola przeznaczone na szkice, sprawdzić dostępne integracje, uzgodnić zasady weryfikacji i określić limit kosztów. Wspólnie ocenimy jakość zaakceptowanych wyników, koszty i czas potrzebny na weryfikację, zanim zdecydujecie o rozszerzeniu rozwiązania.

Porozmawiajmy o pilotażu Drupal AI. Przygotuj przykładowe treści z backlogu, który chcesz zmniejszyć. Pomożemy wskazać praktyczny punkt wyjścia.