LangChain, LangGraph czy API OpenAI. Jak wybrać swój stos technologiczny RAG?

Rozpoczynasz nowy projekt RAG i stoisz przed decyzją, która będzie miała wpływ na najbliższe 6–12 miesięcy: skorzystać z frameworka takiego jak LangChain czy budować bezpośrednio z wykorzystaniem API OpenAI? W Internecie można znaleźć sprzeczne porady. W wątkach na X LangChain jest określany jako „przesadny” i „zbyt abstrakcyjny”. W postach blogowych autorzy chwalą jego dojrzałe wzorce i ekosystem. Twój zespół jest podzielony między opcją „działajmy szybko z frameworkiem” a „powinniśmy kontrolować nasz własny kod”?

Stanęliśmy przed dokładnie taką samą decyzją podczas tworzenia chatbota AI do obsługi dokumentów dla profesjonalnej platformy zarządzania wiedzą. Po ocenie obu podejść i ponad sześciomiesięcznym korzystaniu z naszego wyboru na produkcji, mamy jasną perspektywę: wybraliśmy LangChain + LangGraph i ponownie podjęlibyśmy tę samą decyzję.

W tym artykule omówię dylemat związany z wyborem frameworka i wyjaśnię, co faktycznie oferują LangChain i LangGraph. Pokażę również, kiedy bardziej sensowne jest użycie surowego API OpenAI. Następnie podzielę się naszym doświadczeniem produkcyjnym z wszystkimi trzema technologiami i przedstawię ramy decyzyjne, które pomogą Ci dokonać konkretnego wyboru.

W tym artykule:

• Co sprawia, że wybór między LangChain, LangGraph i API OpenAI jest tak trudny?
• LangChain: co faktycznie oferuje (i ile kosztuje)?
• LangGraph: w jaki sposób poprawia koordynację przepływu pracy?
• LangSmith: w jaki sposób zmienia on obserwowalność w stosie RAG?
• Surowy interfejs API OpenAI: kiedy to ma sens
• Czego nauczyliśmy się po sześciu miesiącach korzystania z LangChain i LangGraph na produkcji?
• LangChain, LangGraph lub Raw OpenAI API dla stosu RAG – wnioski
• Chcesz dokonywać mądrzejszych wyborów technologicznych dla swojego stosu RAG?

Co sprawia, że wybór między LangChain, LangGraph i API OpenAI jest tak trudny?

Wybór między frameworkiem a surowym API odzwierciedla zasadniczo różne filozofie dotyczące tworzenia oprogramowania, a społeczność RAG jest głęboko podzielona.

Argument „po prostu używaj OpenAI API”

Ta grupa ceni sobie przede wszystkim prostotę i kontrolę.

Maksymalna kontrola 

Kiedy piszesz surowe wywołania API, widzisz dokładnie, co się dzieje. Żadnej magii frameworka, żadnych ukrytych abstrakcji, żadnych niespodziewanych zachowań. Każde generowanie osadzenia, każde wyszukiwanie wektora, każde wywołanie LLM to kod, który napisałeś i który możesz debugować.

Minimalne zależności 

Twój plik requirements.txt zawiera 3–5 pakietów zamiast 50. Wdrożenie jest lekkie. Nie jesteś narażony na błędy frameworka ani przełomowe zmiany. Kiedy OpenAI aktualizuje swoje API, aktualizujesz swój kod zgodnie z własnym harmonogramem.

Wydajność 

Brak obciążenia frameworku lub warstw abstrakcji. Twój kod działa dokładnie tak, jak mu każesz. Niektóre zespoły zgłaszają szybszą realizację bez przetwarzania frameworku.

Walidacja społeczności 

Znane osobistości zajmujące się rozwojem sztucznej inteligencji krytykują złożoność LangChain. Często pojawiająca się krytyka dotyczy tego, że framework dodaje warstwy abstrakcji, które raczej zaciemniają niż wyjaśniają, przez co styl przeważa nad treścią.

Argument „użyj frameworka”

Ta grupa ceni sobie produktywność i sprawdzone wzorce.

Dojrzałe wzorce RAG gotowe do użycia 

Nie wymyślaj na nowo ładowania dokumentów, dzielenia tekstu, integracji wyszukiwania wektorowego, strategii odzyskiwania, zarządzania podpowiedziami i strumieniowego przesyłania odpowiedzi. Korzystaj ze sprawdzonych implementacji, nad których doskonaleniem pracowało tysiące programistów.

Szybsze wdrożenie 

Rozpocznij pracę z RAG w ciągu kilku godzin, a nie tygodni. Zamień bazy danych wektorowych poprzez zmiany konfiguracji, a nie przepisywanie. Testuj różne strategie wyszukiwania bez konieczności przebudowywania potoku.

Ekosystem i społeczność 

Uzyskaj dostęp do setek integracji: magazynów wektorowych, dostawców LLM, modułów ładowania dokumentów, specjalistycznych modułów wyszukiwania. Ucz się na podstawie wzorców społeczności rozwiązujących te same problemy, z którymi będziesz się mierzyć.

Wbudowana obserwowalność 

Narzędzia takie jak LangSmith zapewniają wgląd w interakcje LLM, których samodzielne zbudowanie zajęłoby tygodnie. Zobacz wszystkie polecenia, odpowiedzi, użycie tokenów i opóźnienia w produkcji.

Dlaczego wybór odpowiedniego stosu technologicznego RAG ma znaczenie?

Wybór stosu technologicznego RAG stanowi podstawę dla wszystkich kolejnych etapów projektu — od decyzji projektowych, po łatwość późniejszej ewolucji.

• Dług technologiczny narasta: jeśli zaczniesz od surowego API, ale później będziesz potrzebować możliwości frameworka (np. pod względem routingu, zarządzania stanem, obserwowalności), migracja będzie bolesna. I odwrotnie, jeśli zastosujesz framework, ale nie potrzebujesz jego złożoności, obciążysz swój zespół niepotrzebnymi abstrakcjami.
• Wpływ na produktywność zespołu: frameworki wymagają nauki, ale potem przyspieszają rozwój. Z kolei surowe API zapewnia natychmiastową przejrzystość, ale powoduje wzrost obciążenia związanego z utrzymaniem. Niewłaściwy wybór wpływa na tempo pracy przez wiele miesięcy.
• Niezawodność produkcji: frameworki zapewniają obsługę błędów, logikę ponawiania prób i wzorce awaryjne. Surowe implementacje wymagają ich zbudowania. Twój wybór ma wpływ na odporność systemu i częstotliwość występowania incydentów.

LangChain: co faktycznie oferuje (i ile kosztuje)?

Przyjrzyjmy się, co zyskujesz (i z czego rezygnujesz) dzięki LangChain, w oparciu o nasze doświadczenia produkcyjne.

Jakie komponenty RAG są gotowe do użycia w LangChain?

Podstawową wartością LangChain są kompleksowe elementy składowe RAG:

Dlaczego wybraliśmy LangChain

Nasza decyzja wynikała z czterech pragmatycznych czynników:

1. Dojrzałe możliwości RAG: nie chcieliśmy na nowo wymyślać wzorców wyszukiwania. Implementacje LangChain są przetestowane w warunkach produkcyjnych i obsługują skrajne przypadki, które odkrylibyśmy dopiero podczas incydentów produkcyjnych.

2. Aktywny rozwój: LangChain wydaje aktualizacje co tydzień. Błędy są szybko naprawiane. Nowe modele i dostawcy pojawiają się szybko. Projekt ma dynamikę, która sugeruje długowieczność.

3. Wsparcie finansowe: LangChain ma silne wsparcie firmy. Nie jest to projekt poboczny, który może zostać porzucony. W przypadku systemów produkcyjnych stabilność frameworka ma znaczenie.

4. Integracja z LangSmith: bezpłatny poziom deweloperski LangSmith zapewnia obserwowalność, której stworzenie zajęłoby wiele miesięcy pracy. Już samo to uzasadnia wybór frameworka.

Przykład projektu, w którym wykorzystaliśmy LangChain i LangSmith

Sprawdź case study: Chatbot AI z użyciem LangChain →

Jakie koszty ponieśliśmy, korzystając z LangChain?

LangChain nie jest darmowy, akceptujesz jego złożoność i takie aspekty jak:

• Krzywa uczenia się: zrozumienie abstrakcji LangChain (dokumenty, moduły pobierające, łańcuchy, moduły uruchamialne) zajmuje tygodnie. Nowi członkowie zespołu potrzebują czasu na wdrożenie. Dokumentacja czasami nie nadąża za wdrożeniem.
• Abstrakcje ukrywające szczegóły: czasami trzeba zagłębić się w kod źródłowy LangChain, aby zrozumieć jego działanie. „Magia”, która przyspiesza rozwój, może przesłaniać ważne szczegóły podczas debugowania.
• Zależność od aktualizacji frameworka: istotne zmiany wymagają czasami aktualizacji kodu. Zmiany w API OpenAI są wprowadzane w LangChain z pewnym opóźnieniem. Jesteś uzależniony od cyklu wydawniczego frameworka.
• Krytyka społeczności: opinia, że „LangChain jest zbyt złożony” jest prawdziwa. Niektórzy programiści uważają abstrakcje za mylące. Framework ma silne opinie, które nie pasują do każdego przypadku użycia.
• Pewne obciążenie wydajnościowe: przetwarzanie frameworka dodaje mikrosekundy do milisekund na operację. W przypadku większości aplikacji RAG jest to nieistotne, ale w scenariuszach wymagających wysokiej wydajności może to być zauważalne.

LangGraph: w jaki sposób poprawia koordynację przepływu pracy?

LangGraph rozwiązuje konkretny problem, który pojawia się w produkcyjnych systemach RAG: złożone przepływy pracy warunkowe są trudne do zbudowania i debugowania za pomocą prostych łańcuchów.

Co zapewnia LangGraph?

LangGraph rozszerza LangChain, dodając strukturę i przejrzystość do złożonych przepływów pracy RAG.

Zarządzanie stanem 

Zdefiniuj typowany stan, który przepływa przez przepływ pracy:

from typing import TypedDict, List
from langchain.schema import Document

class ChatbotState(TypedDict):
    question: str
    question_type: str
    confidence: float
    retrieved_docs: List[Document]
    graded_docs: List[Document]
    answer: str

Każdy węzeł otrzymuje stan, modyfikuje go i zwraca zaktualizowany – wyraźny i możliwy do debugowania.

Wizualna definicja przepływu pracy 

Wyraź złożone przepływy jako wykresy z węzłami i krawędziami:

from langgraph.graph import StateGraph, END

workflow = StateGraph(ChatbotState)

# Define nodes
workflow.add_node("classify_question", classify_question)
workflow.add_node("route_question", route_question)
workflow.add_node("retrieve", retrieve_documents)
workflow.add_node("grade_documents", grade_all_documents)
workflow.add_node("generate", generate_answer)

# Conditional routing
workflow.add_conditional_edges(
    "classify_question",
    route_question,
    {
        "generic": "handle_generic",
        "conversational": "handle_conversational",
        "document_search": "retrieve"
    }
)

# Linear flow for document search path
workflow.add_edge("retrieve", "grade_documents")
workflow.add_edge("grade_documents", "generate")
workflow.add_edge("generate", END)

app = workflow.compile()

Struktura przepływu pracy jest przejrzysta i wizualna. Dodawanie nowych węzłów lub tras jest proste.

Wbudowane debugowanie 

LangSmith wizualizuje wykonanie LangGraph: 

• Zobacz, jaką ścieżką podążało zapytanie.
• Sprawdź stan w każdym węźle.
• Zidentyfikuj, gdzie występują awarie.
• Zmierz opóźnienie dla każdego węzła.

Jak wygląda nasz przepływ pracy LangGraph w środowisku produkcyjnym?

Oto nasz rzeczywisty przepływ produkcyjny (nieco uproszczony poprzez usunięcie buforowania):

Start
  ↓
classify_question
  ↓
route_question
  ├→ [generic] → handle_generic → END
  ├→ [conversational] → handle_conversational → END
  └→ [document_search]
       ↓
     generate_search_phrase
       ↓
     retrieve (~20 docs)
       ↓
     grade_documents (select top 12)
       ↓
     generate_answer
       ↓
     END

Dlaczego warto wybrać LangGraph zamiast niestandardowej koordynacji przepływu pracy?

LangGraph oferuje wyraźne korzyści w porównaniu z tworzeniem logiki koordynacji od podstaw, zwłaszcza gdy potrzebna jest przejrzystość, łatwość utrzymania i szybka iteracja.

Wizualne debugowanie 

Gdy użytkownik zgłasza „błędną odpowiedź”, otwieramy LangSmith i sprawdzamy dokładną ścieżkę wykonania: 

• classify_question → „document_search” ✓
• retrieve → znaleziono 20 dokumentów ✓
• grade_documents → 0 dokumentów przekroczyło próg ✗ (znaleziono błąd!)

Bez LangGraph wymagałoby to obszernego logowania i ręcznego korelowania śladów.

Czyste zarządzanie stanem 

Stan przepływa wyraźnie przez węzły. Brak zmiennych globalnych, brak ukrytych zależności. Każdy węzeł jest czystą funkcją: stan wejściowy → stan wyjściowy.

Łatwe modyfikacje 

Dodanie nowego routingu (np. pytania „pilne” omijają ocenianie) jest zmianą konfiguracji:

workflow.add_conditional_edges(
    "classify_question",
    route_with_urgency,
    {
        "generic": "handle_generic",
        "urgent": "generate_immediately",  # New path
        "document_search": "retrieve"
    }
)

Komponenty testowalne 

Testuj poszczególne węzły w izolacji:

def test_classify_question():
    state = {"question": "What is GDPR?"}
    result = classify_question(state)
    assert result["question_type"] == "document_search"
    assert result["confidence"] > 0.7

Jakie są zalety i wady korzystania z LangGraph?

Jak każda technologia, LangGraph ma swoje wady i zalety.

LangSmith: w jaki sposób zmienia on obserwowalność w stosie RAG?

LangSmith to powód, dla którego ponownie wybralibyśmy LangChain, nawet gdyby nic innego nie miało znaczenia. Bezpłatny poziom dla programistów zapewnia obserwowalność na poziomie produkcyjnym, której zbudowanie zajęłoby wiele miesięcy pracy.

Co zapewnia LangSmith (na bezpłatnym poziomie)?

LangSmith zapewnia obserwowalność na poziomie produkcyjnym dla każdego przepływu pracy RAG, dając programistom pełny wgląd w zachowanie ich systemów opartych na LLM.

Kompletne ślady interakcji LLM 

Każde wywołanie dowolnego LLM jest automatycznie rejestrowane:

• Dokładny wysłany komunikat.
• Pełna otrzymana odpowiedź.
• Wykorzystany model i parametry.
• Wykorzystanie tokenów (podział na dane wejściowe/wyjściowe).
• Pomiar opóźnienia.
• Status powodzenia/błędu.

Śledzenie kosztów 

Na podstawie cen modelu i rzeczywistego wykorzystania tokenów LangSmith szacuje koszty każdego zapytania. Od razu widać, które operacje są drogie.

Wizualizacja LangGraph 

Wizualna reprezentacja wykonania przepływu pracy: 

• Które węzły zostały uruchomione.
• Czas spędzony w każdym węźle.
• Przejścia między stanami.
• Decyzje dotyczące warunkowego routingu.

Badanie błędów 

Nieudane zapytania zawierają pełny kontekst: 

• Jakie dane wejściowe spowodowały niepowodzenie.
• Który węzeł nie powiódł się.
• Komunikat o błędzie i ślad stosu.
• Stan w momencie wystąpienia błędu.

Przeczytaj również: Jak poprawiliśmy dokładność chatbota RAG o 40% dzięki ocenie dokumentów →

Przykład debugowania na produkcji za pomocą LangSmith

Skarga użytkownika:

„Kiedy zapytałem o szyfrowanie danych, chatbot podał mi zupełnie nieistotne informacje dotyczące uwierzytelniania”.

Bez LangSmith: 

• Przejrzyj logi aplikacji (ogólne żądania/odpowiedzi).
• Spróbuj odtworzyć problem.
• Dodaj więcej logów.
• Wdróż nową wersję.
• Poczekaj, aż problem wystąpi ponownie.
• Spróbuj ustalić przyczynę źródłową.

Za pomocą LangSmith: 

1. Wyszukaj ślady tekstu zapytania użytkownika. 

2. Otwórz ślad, zobacz pełne wykonanie LangGraph: 

• classify_question → sklasyfikowane jako „document_search” ✓
• generate_search_phrase → wygenerowano: „authentication security” ✗ (błędnie!).
• retrieve → zwrócono dokumenty uwierzytelniające (technicznie poprawne dla błędnej frazy wyszukiwania).
• grade_documents → dokumenty uwierzytelniające uznane za istotne.
• generate → udzielono odpowiedzi na temat uwierzytelniania (poprawnie wykonano polecenie).

3. Przyczyna źródłowa znaleziona w ciągu 2 minut: podczas generowania frazy wyszukiwania „szyfrowanie danych” zostało błędnie zrozumiane jako „uwierzytelnianie”.

4. Rozwiązanie: ulepszenie podpowiedzi generowania frazy wyszukiwania poprzez dodanie lepszych przykładów zapytań dotyczących szyfrowania.

Optymalizacja wykorzystania tokenów

LangSmith pokazuje zużycie tokenów na węzeł:

Przykładowy podział zapytania 

• classify_question: 150 tokenów (0,000375 USD)
• grade_documents: 20 wywołań × 250 tokenów = 5000 tokenów (0,0125 USD)
• generate: 15 000 tokenów (0,0375 USD)
• Razem: 20 150 tokenów (0,050375 USD)

Odkryliśmy, że ocena dokumentów pochłaniała 25% kosztów. Ta wiedza doprowadziła do optymalizacji podpowiedzi dotyczących oceny (krótszych, bardziej skoncentrowanych) oraz wdrożenia buforowania często zadawanych pytań.

Dlaczego LangSmith uzasadnia wybór LangChain?

Stworzenie równoważnego systemu obserwacji wymagałoby: 

• Systemu rejestrowania interakcji LLM
• Śledzenia wykorzystania tokenów
• Obliczania kosztów dla każdego modelu
• Wizualnej przeglądarki śladów
• Interfejsu użytkownika do wyszukiwania i filtrowania
• Narzędzia do kontroli stanu

LangSmith udostępnia te funkcje bezpłatnie (poziom deweloperski) lub za niewielką miesięczną opłatą (poziom zespołowy). Nawet gdyby LangChain nie miał żadnych innych zalet, LangSmith uzasadnia korzystanie z tego frameworka.

Surowy interfejs API OpenAI: kiedy to ma sens

Pomimo naszej decyzji, surowe API jest absolutnie właściwym wyborem dla niektórych projektów. Bądźmy szczerzy w temacie, kiedy obciążenie frameworkiem nie jest uzasadnione.

Przykłady zastosowań, dla których surowe API sprawdza się najlepiej

Chociaż frameworki upraszczają złożone procesy RAG, istnieje wiele scenariuszy, w których bezpośrednia praca z surowym API OpenAI jest szybsza, czystsza i bardziej praktyczna.

Proste odpowiedzi na pytania 

Jeśli tworzysz proste pytania i odpowiedzi bez pobierania dokumentów:

import openai

def simple_qa(question: str) -> str:
    response = openai.ChatCompletion.create(
        model="gpt-4o",
        messages=[
            {"role": "system", "content": "You are a helpful assistant."},
            {"role": "user", "content": question}
        ]
    )
    return response.choices[0].message.content

Nie wymaga żadnej struktury. Przejrzysty, prosty, łatwy w utrzymaniu.

Maksymalne wymagania dotyczące kontroli 

Projekty badawcze zajmujące się nowatorskimi architekturami RAG korzystają z pełnej kontroli. Niestandardowe strategie osadzania, specjalistyczne algorytmy wyszukiwania, eksperymentalne podejścia — wszystko to jest łatwiejsze bez abstrakcji frameworków.

Minimalne ograniczenia zależności 

Systemy osadzone, funkcje AWS Lambda z ograniczeniami rozmiaru lub organizacje o ścisłych zasadach dotyczących zależności mogą zabraniać stosowania frameworków. Surowy interfejs API zapewnia dokładnie to, czego potrzebujesz.

Nauka i edukacja 

Zrozumienie RAG od podstaw oznacza tworzenie bez frameworków. Wdrożenia edukacyjne zyskują dzięki wyraźnemu pokazaniu każdego kroku.

Przeczytaj również: Jak przyspieszyć odpowiedzi chatbota AI dzięki inteligentnemu buforowaniu →

Jakie są główne zalety wdrożenia surowego OpenAI?

Korzystanie z surowego API OpenAI ma kilka wyraźnych zalet, które sprawiają, że jest to dobry wybór dla niektórych zespołów i projektów.

• Pełna przejrzystość: każda linijka kodu należy do Ciebie. Żadnej magii frameworków. Żadnych ukrytych zachowań. Debugowanie oznacza czytanie kodu, który sam napisałeś.
• Zero obciążenia frameworku: brak warstw abstrakcji, brak przetwarzania frameworku. Twój kod działa dokładnie tak, jak to określiłeś.
• Brak krzywej uczenia się: członkowie zespołu rozumieją Python i OpenAI API. Nie ma potrzeby uczenia się wzorców specyficznych dla frameworka.

Jakie są wady korzystania z surowego API OpenAI bez frameworka?

Korzystanie z surowego API OpenAI zapewnia pełną kontrolę, ale wiąże się również z szeregiem wyzwań i ograniczeń, które zespoły muszą uwzględnić w swoich planach.

• Odkrywanie wzorców na nowo:
  • Strategie dzielenia dokumentów na fragmenty (z poszanowaniem granic semantycznych).
  • Optymalizacja wyszukiwania (MMR, wyszukiwanie hybrydowe).
  • Odpowiadanie strumieniowe (obsługa asynchroniczna).
  • Obsługa błędów i ponowne próby.
  • Zarządzanie szablonami podpowiedzi.
  • Pamięć konwersacji.
• Brak wbudowanej obserwowalności: logowanie, śledzenie i monitorowanie trzeba budować od podstaw. Szacunkowy czas potrzebny do uzyskania obserwowalności na poziomie produkcyjnym to 2–4 tygodnie.
• Praca integracyjna: każda baza danych wektorowych wymaga niestandardowego kodu integracyjnego. Zmiana dostawcy oznacza przepisanie warstwy bazy danych.
• Obciążenie związane z utrzymaniem: cały kod należy utrzymywać samodzielnie. Zmiany w API OpenAI wymagają natychmiastowych aktualizacji. Brak społeczności współtworzącej poprawki.

Czego nauczyliśmy się po sześciu miesiącach korzystania z LangChain i LangGraph na produkcji?

Używaliśmy LangChain + LangGraph w środowisku produkcyjnym przez ponad 6 miesięcy, obsługując prawdziwych użytkowników. Czas na brutalną szczerość.

Czy ponownie wybralibyśmy LangChain?

TAK, pomimo krytyki społeczności i jego złożoności.

Dlaczego ponownie wybralibyśmy LangChain dla naszego stosu technologicznego RAG?

Po kilku miesiącach pracy w środowisku produkcyjnym niektóre aspekty LangChain okazały się na tyle cenne, że z pewnością wybralibyśmy go ponownie dla naszego stosu RAG.

1. Obserwowalność LangSmith: zaoszczędziło nam to dziesiątki godzin debugowania. Wgląd w optymalizację kosztów. Widoczność produkcji, której sami nigdy byśmy nie zbudowali. Warte samego obciążenia frameworku.

2. Krótszy czas wprowadzenia na produkcję: działający RAG w ciągu dni, a nie tygodni. Natychmiastowa integracja z Elasticsearch. Wbudowane pobieranie MMR. Automatyczna obsługa strumieniowania. Te przyspieszenia się sumują.

3. Produktywność zespołu: nowi programiści szybciej wdrażają się dzięki ustalonym wzorcom. Istnieją rozwiązania społecznościowe dla typowych problemów. Aktualizacje frameworka przynoszą ulepszenia, których sami nigdy byśmy nie wdrożyli.

4. Rzeczywistość utrzymania: obawialiśmy się, że będziemy zmagać się z ograniczeniami frameworka. W ciągu 6 miesięcy: zdarzyło się to dwa razy, ale oba problemy zostały szybko rozwiązane. Framework został włączony, a nie ograniczony.

5. Optymalizacja kosztów: LangSmith ujawnił kosztowne operacje. Elastyczność frameworka umożliwiła optymalizacje (buforowanie, routing), które znacznie obniżyły koszty.

Krytyka społeczności wobec LangChain: z czym się zgadzamy

„LangChain jest złożony”: PRAWDA 

Krzywa uczenia się jest realna. Dokumentacja jest czasami myląca. Zrozumienie abstrakcji wymaga czasu. Framework jest obiektywnie złożony.

„Przesada w prostych przypadkach”: ZDECYDOWANIE

W przypadku podstawowych pytań i odpowiedzi lub prostych poleceń LangChain stanowi niepotrzebne obciążenie. Surowy interfejs API jest obiektywnie lepszy w prostych przypadkach użycia.

Krytyka społeczności wobec LangChain: z czym się nie zgadzamy

„Wystarczy użyć OpenAI API”: nie w przypadku złożonego RAG 

Ta rada dotyczy prostych poleceń. W przypadku oceniania dokumentów, routingu warunkowego, zarządzania stanem i obserwowalności framework zapewnia rzeczywistą wartość.

„Framework będzie Cię hamował”: nie według naszego doświadczenia

Sześć miesięcy później: wszystkie potrzebne nam funkcje były osiągalne. Framework okazał się elastyczny.

„Znaczne obciążenie wydajnościowe”: w praktyce nieistotne 

Nasze pomiary pokazują, że framework dodaje kilka milisekund. W przypadku RAG, gdzie dominują wywołania LLM, opóźnienie jest nieistotne. Obciążenie frameworku nie ma znaczenia.

„Nie jest gotowy do produkcji”: z powodzeniem działamy w środowisku produkcyjnym 

Klient jest zadowolony. System jest niezawodny i obsługuje rzeczywisty ruch użytkowników. Framework spełnia nasze wymagania produkcyjne.

LangChain, LangGraph lub Raw OpenAI API dla stosu RAG – wnioski

Po 6 miesiącach pracy z LangChain, LangGraph i LangSmith nasz werdykt jest jasny: w przypadku złożonych systemów RAG obciążenie frameworku jest uzasadnione wzrostem produktywności i korzyściami wynikającymi z obserwowalności. Krytyka społeczności jest słuszna — LangChain jest złożony, abstrakcje są czasami niejasne, a krzywa uczenia się jest realna. Jednak rzeczywistość produkcyjna sprzyja sprawdzonym wzorcom i wbudowanym narzędziom, a nie maksymalnej prostocie.

Nasza kluczowa obserwacja: sam LangSmith uzasadnia użycie LangChain. Obserwowalność na poziomie produkcyjnym, której zbudowanie zajęłoby wiele miesięcy pracy, jest dostępna bezpłatnie. Gdy debugowanie „dlaczego to zapytanie nie powiodło się?” zajmuje 2 minuty zamiast 2 godzin, obciążenie związane z frameworkiem staje się nieistotne. Dodaj integrację z Elasticsearch, pobieranie MMR, strategie dzielenia dokumentów na fragmenty i obsługę strumieniowania, a wzrost wydajności będzie jeszcze większy.

Decyzja nie jest ideologiczna, ale pragmatyczna. Oceń złożoność, preferencje zespołu, presję czasową i potrzeby w zakresie obserwowalności. Wybierz podejście, które przyspieszy realizację konkretnego projektu. Obie ścieżki prowadzą do działających systemów.

Chcesz dokonywać mądrzejszych wyborów technologicznych dla swojego stosu RAG?

Ten wpis na blogu opiera się na naszym rzeczywistym wdrożeniu produkcyjnym z wykorzystaniem LangChain, LangGraph i LangSmith przez ponad sześć miesięcy obsługi użytkowników. Tu przeczytasz pełne case study chatbota AI do obsługi dokumentów, które zawiera szczegółowe informacje na temat stosu technologicznego, oceny dokumentów, buforowania odpowiedzi, synchronizacji w czasie rzeczywistym i kompleksowej obserwowalności.

Jesteś zainteresowany budową lub optymalizacją systemów RAG na poziomie produkcyjnym przy użyciu odpowiednich narzędzi dla Twojego przypadku użycia? Nasz zespół specjalizuje się w tworzeniu rozwiązań AI, które łączą elastyczność, wydajność i efektywność kosztową. Zapoznaj się z naszymi usługami rozwoju AI, aby dowiedzieć się, jak możemy pomóc Ci wybrać i wdrożyć najlepszy stos dla Twojego projektu.