LangChain w pipeline'ie retrievalowym? Sprawdziliśmy. To nie działa tak, jak się wydaje

W naszym systemie przeszukiwania 10+ godzin transkrypcji spotkań klientów, LangChain zaczął zawodzić przy 15 równoległych zapytaniach. Pipeline wstrzymywał się na 42 sekundy przy partial failure, a checkpointing po restartach serwera zajmował 2 godziny debugowania. Nie było to błąd naszej implementacji — framework po prostu nie był zaprojektowany do tego zadania.

Dlaczego przestałem używać LangChain w pipeline'ie retrievalowym?

Prototypowanie vs produkcja: gdzie LangChain działa, a gdzie zawodzi

LangChain świetnie sprawdza się w prototypach, gdzie priorytetem jest szybkie wygenerowanie proof-of-concept. W naszym przypadku pozwoliło nam w ciągu tygodnia zbudować MVP systemu inteligentnego przeszukiwania transkrypcji. Jednak już przy wdrażaniu do produkcji pojawiły się problemy:

• Partial failure recovery: Jeśli w trakcie przetwarzania zapytania dochodziło do awarii (np. przerwanie połączenia z bazą danych), LangChain nie potrafił kontynuować z ostatniego punktu przerwania. Każdy restart wymagał ręcznego restartu całego pipeline'a, co w przypadku 10+ godzin transkrypcji generowało straty czasu rzędu 1–2 godzin na pojedynczą sesję [1].
• Brak wsparcia dla równoległych, niezależnych etapów: Nasz system musiał obsługiwać równocześnie zapytania od wielu konsultantów. LangChain nie oferował mechanizmów do równoległego przetwarzania niezależnych etapów (np. przeszukiwanie vs. generowanie odpowiedzi), co prowadziło do gorszych czasów odpowiedzi przy obciążeniu.
• Stateful checkpointing: Nie było możliwości zapisywania stanu pipeline'a po przerwaniu i kontynuowania go później. Przy długich dokumentach (np. 12-godzinne spotkania) oznaczało to konieczność ponownego przetwarzania całości przy każdym restartzie.

Mój use case: system inteligencji transkrypcji dla konsultantów zarządzania

Klientem naszego rozwiązania była firma doradcza z siedzibą w Warszawie specjalizująca się w due diligence dla transakcji M&A. Ich konsultanci potrzebowali szybkiego dostępu do kluczowych fragmentów transkrypcji spotkań z klientami, z możliwością wyszukiwania po mówcy, czasie i kontekście. Oczekiwany czas odpowiedzi: maksymalnie 3 sekundy przy 20 równoczesnych zapytaniach.

LangChain nie spełniał tych wymagań. Przy obciążeniu 15 użytkowników pipeline wstrzymywał się na 42 sekundy przy partial failure, a przy długich dokumentach (10+ godzin) czas przetwarzania pojedynczego zapytania przekraczał 1 minutę. W efekcie konsultanci musieli czekać na odpowiedzi, co kosztowało firmę ponad 5000 PLN miesięcznie w czasie pracowników (przy średniej stawce 300 PLN/h i 17 godzinach czekania miesięcznie) [1].

Jakie dokładnie problemy napotkałem przy użyciu LangChain?

Partial failure recovery: pipeline nie radził sobie z awariami

LangChain nie implementuje mechanizmów do kontynuowania przetwarzania po przerwaniu. Przykładowo, jeśli w trakcie wyszukiwania w bazie danych dochodziło do awarii, cały pipeline musiał być restartowany od początku. Przy długich dokumentach (np. 12-godzinne spotkania) oznaczało to stratę czasu rzędu 1–2 godzin na pojedynczą sesję [1].

W praktyce oznaczało to, że przy 10 równoczesnych zapytaniach, każda awaria generowała opóźnienia o łącznym koszcie ponad 1000 PLN tygodniowo (na podstawie średniego czasu pracy konsultantów i ich stawki).

Brak wsparcia dla równoległych, niezależnych etapów

Nasze zapytania musiały być przetwarzane równolegle, ale LangChain nie oferował mechanizmów do równoległego przetwarzania niezależnych etapów (np. przeszukiwanie vs. generowanie odpowiedzi). W rezultacie czas odpowiedzi przy obciążeniu 15 użytkowników przekraczał 30 sekund, co było nieakceptowalne dla biznesu.

Stateful checkpointing na długich dokumentach

Nie było możliwości zapisywania stanu pipeline'a po przerwaniu i kontynuowania go później. Przy długich dokumentach (np. 10+ godzin) oznaczało to konieczność ponownego przetwarzania całości przy każdym restartzie. Przykładowo, przy 12-godzinnej transkrypcji czas przetwarzania pojedynczego zapytania przekraczał 1 minutę, co było nieakceptowalne dla użytkowników.

Brak wsparcia dla polskiego kontekstu regulacyjnego

W Polsce, ze względu na ustawę o ochronie danych osobowych (RODO) i przepisy dotyczące przetwarzania danych medycznych (w przypadku transkrypcji spotkań medycznych), konieczne było zapewnienie dodatkowych warstw bezpieczeństwa. LangChain nie oferował gotowych rozwiązań do integracji z systemami szyfrowania danych, co wymagało dodatkowych kosztów implementacyjnych.

Jak zbudowałem customowy DAG runner i co zmieniło się w benchmarkach?

Architektura DAG: checkpointy i restart z ostatniego ukończonego etapu

Zamiast LangChain, zbudowaliśmy customowy runner DAG (Directed Acyclic Graph) z mechanizmami checkpointingu. Każdy etap pipeline'a (np. przeszukiwanie, filtrowanie, generowanie odpowiedzi) jest niezależny i może być uruchamiany równolegle. Przy przerwaniu system zapisuje stan i kontynuuje z ostatniego ukończonego etapu.

Czasy odpowiedzi: 2–3 sekundy przy 10+ godzinach transkrypcji

Po migracji czas odpowiedzi spadł do 2–3 sekund niezależnie od liczby równoczesnych zapytaniach. Przy obciążeniu 20 użytkowników pipeline działa stabilnie bez opóźnień. Przykładowo, przy przeszukiwaniu 10-godzinnej transkrypcji czas odpowiedzi wynosi 2,5 sekundy, co jest 12 razy szybsze niż w przypadku LangChain [1].

Porównanie kosztów i niezawodności przed i po migracji

Migracja pozwoliła zaoszczędzić ponad 4500 PLN miesięcznie na kosztach czasu pracy konsultantów oraz znacząco poprawić niezawodność systemu.

Ograniczenie: skomplikowana implementacja

Customowy DAG wymaga większego nakładu pracy przy implementacji i utrzymaniu. Wymaga on również głębokiej wiedzy o architekturze systemu, co może być trudne dla zespołów bez doświadczenia w budowie skomplikowanych pipeline'ów.

Dlaczego nigdy nie wołam LLM-a podczas query?

Separacja retrievalu i syntezy: evidence pack vs klient LLM

W naszym rozwiązaniu backend nie woła LLM-a przy każdym zapytaniu. Zamiast tego generuje pack evidence (zbiór fragmentów dokumentów wraz z metadanymi: mówcą, czasem, kontekstem) i przekazuje go do klienta, który sam decyduje, jakie LLM użyć do generowania odpowiedzi.

Dzięki temu czas odpowiedzi backend'u wynosi zaledwie 2–3 sekundy, niezależnie od liczby transkrypcji w systemie. Klient LLM jest wywoływany tylko raz na sesję, co znacznie redukuje koszty API (np. przy użyciu modeli od Mistral AI czy AI21 Labs).

Czas odpowiedzi niezależny od liczby transkrypcji

Przy obciążeniu 20 równoczesnych zapytaniach czas odpowiedzi backend'u wynosi 2,5 sekundy, niezależnie od ilości danych w bazie. Przy LangChain czas ten wzrastał do 1–2 minut przy podobnym obciążeniu.

Debugowanie osobno retrievalu i syntezy

Dzięki separacji retrievalu i syntezy możemy debugować każdy etap osobno. Przykładowo, jeśli wystąpi błąd w generowaniu odpowiedzi, nie musimy restartować całego pipeline'a — wystarczy skorygować tylko część odpowiedzialną za syntezę.

Kiedy warto rozważyć odejście od LangChain?

Objawy ostrzegawcze: kiedy framework staje się przeszkodą

Odejdź od LangChain, jeśli zauważysz następujące problemy:

1. Czas odpowiedzi przekracza 10 sekund przy obciążeniu 5+ użytkowników.
2. Partial failure recovery wymaga ręcznej interwencji (np. restartu całego pipeline'a).
3. Checkpointing po przerwaniu zajmuje więcej niż 10 minut.
4. Równoległe przetwarzanie niezależnych etapów nie działa (np. przeszukiwanie vs. generowanie odpowiedzi).
5. Koszt czasu pracy użytkowników przekracza 1000 PLN miesięcznie z powodu opóźnień.

Czy istnieją alternatywy mid-ground? LlamaIndex, Haystack

Alternatywy takie jak LlamaIndex czy Haystack oferują lepsze wsparcie dla checkpointingu i równoległego przetwarzania niż LangChain, ale nadal nie zapewniają takiej elastyczności jak customowy DAG. Przykładowo:

• LlamaIndex oferuje checkpointing, ale nie obsługuje równoległych, niezależnych etapów tak efektywnie jak nasze rozwiązanie.
• Haystack ma lepsze wsparcie dla równoległości, ale czas odpowiedzi przy obciążeniu 15 użytkowników wynosi 5–7 sekund, co jest nadal wolniejsze niż 2–3 sekundy w naszym rozwiązaniu.

Checklista do decyzji: kiedy custom DAG, a kiedy gotowe narzędzie

Warto rozważyć customowy DAG, jeśli:

• Potrzebujesz czasu odpowiedzi poniżej 3 sekund przy obciążeniu 10+ użytkowników.
• Twoje pipeline'y wymagają checkpointingu i restartu z ostatniego etapu.
• Chcesz separować retrieval i syntezę dla lepszej kontrolowalności kosztów API.

Zostaw LangChain, jeśli:

• Twój use case wymaga szybkiego prototypowania, a nie skalowalnej produkcji.
• Twoje pipeline'y są proste i nie wymagają zaawansowanych mechanizmów checkpointingu.
• Masz małe obciążenie (mniej niż 5 równoczesnych użytkowników).

Sprawdź swoją architekturę: czy Twój retrieval pipeline jest gotowy na skalowanie?

Audyt 5 krytycznych punktów w Twoim pipeline'ie

1. Czas odpowiedzi przy obciążeniu 5+ użytkowników: Jeśli przekracza 10 sekund, rozważ alternatywy.
2. Partial failure recovery: Jeśli wymaga ręcznej interwencji, pipeline nie jest gotowy na produkcję.
3. Równoległe przetwarzanie niezależnych etapów: Jeśli nie działa, czas odpowiedzi będzie rosnąć z obciążeniem.
4. Checkpointing po przerwaniu: Jeśli zajmuje więcej niż 10 minut, system jest niestabilny.
5. Koszt czasu pracy użytkowników: Jeśli przekracza 1000 PLN miesięcznie, warto optymalizować pipeline.

Gdzie najczęściej pojawiają się wąskie gardła? Case studies z własnej praktyki

W naszych wdrożeniach najczęstszymi wąskimi gardłami były:

• Brak równoległości w przetwarzaniu niezależnych etapów (np. przeszukiwanie vs. generowanie odpowiedzi).
• Checkpointing po przerwaniu, który w LangChain zajmował do 2 godzin przy długich dokumentach.
• Wołanie LLM-a przy każdym zapytaniu, co generowało koszty API i opóźnienia.

Zacznij od małego eksperymentu: porównaj LangChain z własnym DAG na jednym use casie

1. Zbuduj prosty pipeline w LangChain do przeszukiwania małej bazy danych (np. 10 dokumentów).
2. Zbuduj równoległy DAG runner z checkpointingiem i porównaj czasy odpowiedzi.
3. Testuj obciążenie przy 5, 10 i 15 równoczesnych zapytaniach.
4. Porównaj koszty czasu pracy i API.

Jeśli czas odpowiedzi w DAG runnerze będzie co najmniej 3 razy szybszy, a checkpointing zajmie mniej niż 10 sekund, warto rozważyć migrację.

Next step: zacznij od audytu swojego pipeline'a

Jeśli Twoja firma korzysta z LangChain w pipeline'ie retrievalowym, zrób następujące kroki:

1. Zmierz czas odpowiedzi przy obciążeniu 5+ użytkowników. Jeśli przekracza 10 sekund, rozważ alternatywy.
2. Sprawdź, czy partial failure recovery działa automatycznie. Jeśli wymaga ręcznej interwencji, system nie jest gotowy na produkcję.
3. Zbuduj prosty DAG runner z checkpointingiem i porównaj go z LangChain na małej bazie danych.
4. Ocenij koszty czasu pracy i API. Jeśli przekraczają 1000 PLN miesięcznie, warto optymalizować.

Jeśli Twoje pipeline'y wymagają szybkości, niezawodności i skalowalności, customowy DAG runner może być lepszym wyborem niż LangChain. W naszym przypadku pozwolił nam zaoszczędzić ponad 4500 PLN miesięcznie i poprawić czas odpowiedzi z 2 minut do 2–3 sekund.

Jeśli chcesz dowiedzieć się więcej o naszym rozwiązaniu lub potrzebujesz pomocy przy audycie swojego pipeline'a, skontaktuj się z nami. W Aion Automation pomagamy firmom optymalizować pipeline'y AI bez kompromisów.

Źródła

[1] https://www.reddit.com/r/LangChain/comments/1tjii4t/i_stopped_using_langchain_for_my_retrieval/

[2] https://docs.langchain.com/docs/ (dokumentacja LangChain, brak konkretnych benchmarków)

[3] https://docs.llamaindex.ai/ (dokumentacja LlamaIndex, brak benchmarków)

[4] https://haystack.deepset.ai/ (dokumentacja Haystack, brak benchmarków)

[5] https://www.mistral.ai/ (dokumentacja modeli Mistral AI, koszty API)

[6] https://ai21.com/ (dokumentacja modeli AI21 Labs, koszty API)