dlaczego dspy zazwyczaj marnuje twój czas (a kiedy nie) pytanie: "czy powinienem używać dspy do optymalizacji promptów? wydaje się, że to idealne narzędzie do poprawy mojego systemu rag." odpowiedź: dspy jest świetny do bardzo specyficznych, dobrze zdefiniowanych zadań. ale w przypadku większości systemów rag, to rozpraszanie od tego, co naprawdę ma znaczenie. oto rzeczywistość: dspy działa najlepiej, gdy masz jasne zadanie klasyfikacyjne z mierzalną dokładnością. pomyśl o 35-klasowej kategoryzacji, gdzie możesz wspinać się na pojedynczym wskaźniku. ale większość problemów rag nie jest taka. gdy buduję system do wydobywania informacji o sprzedaży z transkryptów, nie mam zbioru danych "oto wszystkie informacje o sprzedaży." prawdziwa praca polega na wydobywaniu wszystkiego, ręcznym etykietowaniu niektórych przykładów i budowaniu intuicji na temat tego, czego użytkownicy naprawdę potrzebują. twój produkt to nie tylko prompt - obejmuje to, jak zbierasz opinie, ustalasz oczekiwania w interfejsie użytkownika, obsługujesz wydobywanie danych i reprezentujesz fragmenty w kontekście. jeśli spędzisz czas na analizowaniu, jak model popełnia błędy i czego użytkownicy oczekują, znacznie bardziej posuniesz się naprzód w poprawie produktu jako całości. jedno miejsce, w którym dspy błyszczy: scenariusze llm-jako-sędzia. jeśli masz ocenę tonalności lub faktualności, na której naprawdę ci zależy, ma sens samodzielne oznaczenie 100 przykładów, a następnie użycie narzędzi do optymalizacji promptów, aby stworzyć własnego sędziego, który będzie zgodny z twoimi ocenami. ale w przypadku większości systemów rag? lepiej ręcznie dostosowywać prompty, budując intuicję na temat swojego konkretnego przypadku użycia. ta intuicja poprowadzi lepsze decyzje w całej architekturze twojego systemu.