Startseite / Artikel

LangChain-Interview-Vorbereitung mit kurzen Antworten, tiefergehenden Erklärungen und häufigen Fallstricken

LangChain-Interview-Vorbereitung: kurze Antworten, die zuerst das Problem beschreiben, tiefere Nachfragen und Fallstricke bei RAG, strukturierte Ausgaben und Nachrichten sowie Code-Übungen anhand eines echten Ausfalls.

Verlag: REACTAPP.TOP11 Min. Lesezeit2591 Wörter

Quellen: 35 LangChain Interview Questions: Fundamentals and Code

Interviewfragen zu LangChain gehen schief, wenn sie sich in Faktenwissen über Klassennamen verwandeln. Personalverantwortliche, die bereits Systeme im Einsatz haben, interessieren sich dafür, ob Sie das Problem benennen können, die richtige Abstraktion wählen, angeben können, was Ihre Anwendung noch beherrscht, und einen Fehlerfall einräumen. API-Bezeichnungen ändern sich – diese Struktur nicht.

Dieser Leitfaden folgt diesem Muster bei Grundlagen, Nachrichten und Prompts, strukturiertem Ausgabeformat, Werkzeugen, Komposition sowie einigen Übungen zum Lesen von Code. Die Beispiele verwenden jeweils dasselbe Helpdesk-Ticket, damit die Antworten konkret bleiben:

Nach der Veröffentlichung um 14:05 beginnt der EU-Checkout-Verkehr, Fehler aufzuweisen. Die Logs in checkout-api zeigen Zeitüberschreitungen beim Aufruf von payments-svc.

Betrachten Sie jeden Punkt als Probeskript: eine kurze Antwort von dreißig Sekunden, eine tiefere Nachfrage sowie den häufigen Fehler, bei dem zwar flüssig gesprochen wird, aber der technische Aspekt übersehen bleibt.

Abschnitt 1: LangChain und Modellaufrufe

Was ist LangChain? Kurz gesagt: ein Orchestrierungstoolkit zur Kombination von Modellaufrufen mit Prompts, Tools, Informationsabrufmechanismen und Steuerflussregeln. Genauer gesagt: Es handelt sich dabei weder um einen Anbieter von Modellen noch um eine Alternative zur Produktlogik. Ihre Anwendung bleibt weiterhin für Authentifizierung, Berechtigungen, Bewertung sowie dafür verantwortlich, was unter „erledigt“ für ein Ticket zu verstehen ist. Fehler: Es als „einen LLM“ zu bezeichnen oder es für jeden OpenAI-Aufruf als zwingend erforderlich anzusehen.

Wann sollten Sie stattdessen ein SDK eines direkten Anbieters verwenden? Kurz gesagt: Wenn es sich um einen einzigen Modellaufruf mit stabilen Prompts handelt und es keinen Tool-/Informationsabrufgraphen gibt. Genauer gesagt: SDKs reduzieren die Anzahl der Komponenten bei einfachen Funktionen; LangChain lohnt sich, wenn Sie ausführbare Kombinationen, Tool-Schleifen oder gemeinsame Abstraktionen zwischen verschiedenen Anbietern benötigen. Fehler: Alles „für zukünftige Flexibilität“ abzuschließen, bevor es einen zweiten Anbieter oder eine weitere Ebene gibt.

Anbieter versus Modell versus LangChain-Schnittstelle. Kurz gesagt: Der Anbieter hostet die Modelle; ein Modell ist eine konkrete Endpunkt- oder Gewichtsauswahl; LangChains Schnittstelle ist ein portabler Wrapper, damit Aufrufe, Ströme und Batch-Operationen ähnlich aussehen. Genauer: Die Portabilität ist nur teilweise gegeben – Besonderheiten der Tools sowie Token-Beschränkungen treten weiterhin auf. Fehler: Zu annehmen, dass das Ändern der Argumente von init_chat_model niemals das Verhalten verändert.

Was macht init_chat_model? Kurz gesagt: Es erstellt ein Chat-Modell-Objekt aus dem Modellnamen sowie optionalen Anbietereinstellungen.

from langchain.chat_models import init_chat_model
model = init_chat_model(
    "provider:model-name",
    temperature=0,
    timeout=20,
)

Genauer: Es zentralisiert die Konfiguration, sodass der Rest des Graphen von einem Runnable abhängt und nicht von einem fest kodierten SDK-Client. Fehler: Es als Magie zu betrachten, die das Verständnis von Bandbreitenbeschränkungen und Kontextfenstern überflüssig macht.

Hauptaufrufmethoden. Kurz: invoke für einen einmaligen Aufruf, stream für Tokens, batch für Listen, plus asynchrone Varianten, sofern unterstützt. Im Detail: Das Streaming verändert die Art und Weise, wie Toolaufrufe und UI-Updates gehandhabt werden; das Batching beeinflusst die Feingranularität von Fehlern. Fehler: batch verwenden, wenn eine Einzelstück-Kündigung erforderlich ist.

Macht Temperaturen ein Modell deterministisch? Kurz: Nein. Im Detail: Temperaturen prägen die Zufälligkeit, doch Seeds, Sampling-Einstellungen sowie Änderungen auf der Seite des Anbieters sind weiterhin entscheidend. Für Audits sollten deterministische Modi des Anbieters verwendet werden, sofern vorhanden, und dennoch überprüft werden. Fehler: Allein durch temperature=0 bitgenaue Ausgaben zu versprechen.

Abschnitt 2: Nachrichten und Prompts

Warum Nachrichtenobjekte anstelle eines langen Strings? Kurz gesagt: Rollen (System/Benutzer/Assistent/Werkzeug) liefern die Struktur, die die Anwendungen für Aufrufe von Werkzeugen und den Mehrschritt-Zustand erwarten.

from langchain.messages import HumanMessage, SystemMessage
messages = [
    SystemMessage(
        "Review tickets using only the supplied evidence."
    ),
    HumanMessage(ticket_text),
]

Erläuterter: Strukturierte Nachrichten ermöglichen es, Werkzeugergebnisse ohne umfangreiche Textmanipulation hinzuzufügen. Fehler: Transkripte zu einem einzigen Benutzerblock zusammenzufügen und sich zu wundern, warum die Werkzeugschleifen nicht funktionieren.

Aufforderungsvorlagen gegenüber Chat-Aufforderungsvorlagen. Kurz gesagt: String-Vorlagen formatieren Text; Chat-Vorlagen formatieren Listen von Nachrichten mit Variablen.

from langchain_core.prompts import ChatPromptTemplate
prompt = ChatPromptTemplate.from_messages([
    ("system", "Classify the ticket. Return the schema."),
    ("human", "Service: {service}\nTicket: {ticket_text}"),
])

Erläuterter: Chat-Vorlagen halten die Systemanweisungen stabil, während sich die Benutzerfelder pro Ticket ändern. Fehler: Veränderbaren Richtlinientext nur in Benutzernachrichten zu platzieren, sodass er unter Druck zuerst entfernt wird.

Wie debuggt man ein Template? Kurz gesagt: Formatieren oder aufrufen und die entstehenden Nachrichten ohne Aufruf eines Modells überprüfen.

value = prompt.invoke({
    "service": "checkout-api",
    "ticket_text": "database connection refused",
})
assert value.messages[0].type == "system"
assert "checkout-api" in value.messages[1].content

Etwas ausführlicher: In Tests Snapshots der formatierten Nachrichten erstellen, damit schnelle Änderungen keine Variablen heimlich entfernen können. Fehler: Nur durch das Lesen der Antworten des Modells debuggen.

Abschnitt 3: Strukturierte Ausgabe

Warum Parser/strukturierte Ausgabe? Kurz gesagt: Sie wandeln freitextbasierte Antworten von Modellen in Felder um, die normales Code validieren kann.

from typing import Literal
from pydantic import BaseModel, Field
class TicketClass(BaseModel):
    severity: Literal["SEV1", "SEV2", "SEV3", "SEV4"]
    service: str
    confidence: float = Field(ge=0, le=1)classifier = model.with_structured_output(TicketClass)
result = classifier.invoke(messages)

Etwas ausführlicher: Vorzugsweise Schemata verwenden, die der Art entsprechen, wie das Helpdesk-Ticket geschrieben wird – Schweregrad, betroffener Service, nächste Aktion – anstatt offener Essays. Fehler: Mit brüchigen Regex-Regeln parsen, nachdem man in Prosa um „JSON bitte“ gebeten hat.

Häufiger Fehler. Modelle überspringen Felder oder erfinden Enums. Schützen Sie sich mit Validierungsfehlern, die einmal nachgefragt werden und anschließend an einen Menschen weitergeleitet werden. Stille Standardwerte verbergen Probleme.

Abschnitt 4: Werkzeuge

Was ist ein Werkzeug? Kurz gesagt: eine typisierte, aufrufbare Funktion, die vom Modell angefordert werden kann, mit Namen, Beschreibung und Schema.

from langchain.tools import tool
@tool
def lookup_service(service: str) -> dict:
    """Return the owner and runbook ID for one service."""
    return service_catalog[service]

Ergänzend: Die Beschreibung ist Teil der Anfrage. Unklare Werkzeuge werden zufällig aufgerufen; allzu umfassende Werkzeuge bilden Sicherheitslücken. Fehler: Rohes SQL oder Shell als „flexibles“ Werkzeug in einer Demo zu verwenden, die später in der Produktion eingesetzt wird.

Wie enden Werkzeugschleifen? Kurz gesagt: durch maximale Iterationen, explizite Aktionen für die Endantwort oder Graphenbedingungen. Ergänzend: Die Eingaben/Ausgaben der Werkzeuge müssen stets für die Auditspur des Support-Teams protokolliert werden. Fehler: Unbegrenzte Schleifen bei instabilen APIs.

Abschnitt 5: Komposition

Was bewirkt das Verketten von Runnables? Kurz gesagt: Es leitet die Ausgabe einer Stufe an die nächste weiter.

chain = prompt | model | parser
result = chain.invoke({"ticket_text": ticket_text})

Erläuterter: Die kompositionelle Struktur im LCEL-Stil ist lesbar, solange es keine Verzweigungen und Wiederholungen gibt; dann haben explizite Graphen (LangGraph oder handgefertigte Zustandsmaschinen) in der Regel Vorteile. Fehler: Übermäßiges Verwenden von Lambda-Funktionen, sodass niemand den Ablauf in der Mitte des Pipelines testen kann.

RunnableParallel / Batchen. Verwenden Sie parallele Ausführung, wenn die Datenerfassung und die Erweiterung der Metadaten unabhängig voneinander sind. Achten Sie auf die Kosten: Parallelisierung ist nicht kostenlos.

Kapitel 6: Antworten im Format von Suchergebnissen

Interviewer fragen oft, wie LangChain in RAG integriert wird. Kurze Antwort: Lader, Trenner, Suchfunktionen und Ketten können den Ablauf steuern; Ihre Anwendung bleibt weiterhin für die Chunking-Strategie, den Zugriffskontrollmechanismus und die Bewertung verantwortlich. Erläuterter: Zitieren Sie Dokumente im strukturierten Ausgabeschema, nicht nur in Prosa. Fehler: „VectorStoreRetriever“ mit einem vollwertigen RAG-System gleichzusetzen.

Code-Übungen

Übung 1: Was gibt das zurück?

reply = model.invoke([
    SystemMessage("Use only the supplied ticket text."),
    HumanMessage(ticket_text),
])

Gehen Sie die Typen sowie die Frage durch, ob ein Modell tatsächlich aufgerufen wird. Viele Beispiele formatieren lediglich die Anfragen.

Übung 2: Was garantiert der Parser?

chain = prompt | model.with_structured_output(TicketClass)
result = chain.invoke(values)

Unterscheiden Sie zwischen „der Anbieter verspricht JSON-Modus“ und „Ihr Schema wurde validiert.“

Übung 3: Was ist mit diesem Tool nicht in Ordnung?

@tool
def ticket(action: str, payload: dict) -> dict:
    """Do ticket operations."""

Achten Sie auf fehlende Dokumentationsstrings/Schemata, Nebeneffekte oder Authentifizierungsprobleme – der Support darf refund_all ohne Ticket-ID nicht aufrufen.

Übung 4: Können diese Aufrufe zusammen ausgeführt werden?

owner = lookup_owner(service)
incidents = recent_incidents(service)

Berücksichtigen Sie den gemeinsamen Zustand, Rate Limits sowie die Frage, ob eine parallele Ausführung für denselben Konversationsthread sicher ist.

Übung 5: Was fehlt in dieser RAG-Antwort?

docs = retriever.invoke(question)
answer = model.invoke(format_prompt(question, docs))

In der Regel: Zitate, Zugriffsfilter oder ein leerer Abrufpfad, der ablehnen sollte anstatt fiktive Informationen über den Checkout zu erfinden.

Wie man ohne Auswendiglernen von APIs übt

Wählen Sie zehn Fragen aus und beantworten Sie sie laut anhand des Checkout-Tickets. Messen Sie die Dauer der kurzen Antworten. Fügen Sie nur dann eine tiefere Erklärung hinzu, wenn weitere Fragen kommen. Halten Sie ein persönliches Verzeichnis der Fehler, die Sie beobachtet haben – leere Abrufe, Halluzinationen der Tools, Mythen bezüglich der Temperatur – denn Interviewer erinnern sich eher an Geschichten als an Importpfade.

Falls der Name einer API seit Ihrem letzten Projekt geändert wurde, geben Sie das an. „In dem aktuellen LangChain ist es init_chat_model; früher haben wir den Provider-Client manuell konfiguriert“ zeigt, dass Sie Veränderungen verfolgen und nicht an einem Tutorial festhalten.

Was starke Antworten gemeinsam haben

Sie gehen von dem Schaden für den Helpdesk-Benutzer aus, nicht vom Paketnamen. Sie trennen die „Zuckerschichten“ des Frameworks von den systemischen Verantwortlichkeiten. Sie benennen Kompromisse: Latenz gegen Ausführlichkeit, Autonomie gegen Prüfbarkeit, Portabilität gegen Anbieterfunktionen. Abschließend beschreiben sie, wie sie die Lösung in der Staging-Umgebung überprüfen würden – mithilfe von Fixtures, Spuren oder Evaluationsmengen – anstatt mit einer beiläufigen Bemerkung wie „Wir würden es überwachen“.

Fragen der Helpdesk-Geschichte zuordnen

Nutzen Sie den Ausfall beim EU-Zahlungsverfahren als Leitfaden. Modellierungen zur Klassifizierung der Schweregrade werden verwendet. Vorlagen fügen die Servicebezeichnungen ein. Die strukturierte Ausgabe erzeugt einen Entwurf für ein Ticket. Tools holen Protokolle aus payments-svc ab. Ketten oder Graphen bilden die Antwort im Runbook zusammen. Die Abfrage holt das Postmortem aus einem ähnlichen Timeout des letzten Quartals ab. Jede Abstraktion rechtfertigt sich durch diese Darstellung – genau so sollte man antworten, wenn eine Whiteboard-Sitzung in die Länge zieht.

Falls der Interviewer auf LangGraph zu sprechen kommt, beibehalten Sie denselben Aufbau: Die Struktur enthält die Felder der Tickets, die Knoten klassifizieren und Daten abrufen, und bedingte Kanten führen zu einer Vertiefung der Analyse bei geringem Vertrauensgrad. Sie müssen nicht jede Klasse aufzählen – es reicht aus, zu zeigen, dass Sie wissen, wann eine lineare Abfolge nicht mehr ausreicht.

Checkliste vor dem Interview

  • Erklären Sie LangChain in einem Satz, ohne es als LLM zu bezeichnen.
  • Wissen Sie, wann Sie darauf verzichten und stattdessen direkt das SDK verwenden sollten.
  • Formatieren Sie eine Chat-Anfrage und zeigen Sie die Nachrichten an.
  • Skizzieren Sie ein Tool-Schema, das keine Geheimnisse ausleiten kann.
  • Beschreiben Sie, wie Sie einen RAG-Pfad mit leeren Abfragedaten testen.
  • Geben Sie zu, was die Temperatur-Einstellung nicht garantiert.
  • Erzählen Sie eine Praxisgeschichte, in der Aufzeichnungen bessere Ergebnisse liefern als Vermutungen.

Üben Sie diese sieben sowie die oben genannten fünfunddreißig Anleitungen, dann werden sie zu Variationen eines Themas statt zu einer mühsamen Auswendiglernerei. Das Ziel ist es nicht, wie Dokumentation zu klingen, sondern wie jemand, der bereits einen Helpdesk-Assistenten implementiert hat und sich noch daran erinnert, wo es versagt hat.

Zusätzliche Übungshinweise zu den Grundlagen

Interviewgruppen beginnen oft mit Definitionen, um die Atmosphäre zu beruhigen, wechseln anschließend zum Thema Fehler. Bereiten Sie beides vor. Bei der Frage „Was ist ein Retriever?“ geben Sie die übliche Antwort – Eingabe einer Abfrage, Ausgabe von Dokumenten – und fügen Sie sofort hinzu, wie Sie leere Ergebnisse im Helpdesk-Verfahren bewerten. Bei der Frage „Was ist ein Dokument?“ nennen Sie den Seiteninhalt sowie die Metadaten und erläutern Sie, welche Metadatenspalten für Zitate und ACL-Filter erforderlich sind.

Sie sollten bereit sein, Hilfsfunktionen im Stil von ConversationalRetrievalChain mit selbst erstellten LCEL-Strukturen oder Graphenpfaden zu vergleichen. Hilfsfunktionen eignen sich gut für Prototypen. Selbst erstellte Pfade sind vorteilhaft, wenn Sie benutzerdefinierte Fallback-Lösungen, tenant-spezifische Indizes oder strukturierte Ausgaben mit Zitatenlisten benötigen.

Was die Speicherung angeht: Unterscheiden Sie Chat-Historie-Puffer von speichergestütztem Speicher. Helpdesk-Assistenten, die sich über mehrere Tage hinweg „erinnern“ müssen, benötigen Persistenz und Redaktion, nicht nur eine Liste im Arbeitsspeicher. Erklären Sie, wie Sie verhindern, dass personenbezogene Daten in Langzeit-Speicher gelangen.

Was die Bewertung betrifft: Nennen Sie Offline-Testfälle („Golden Tickets“), Online-Spuren sowie Regressionstests, die bei Änderungen der Anfragen ausgeführt werden. Falls Sie LangSmith oder ein ähnliches Tool verwendet haben, beschreiben Sie ein Dashboard-Signal, auf das Sie tatsächlich reagiert haben – beispielsweise Anstiege der Latenz nach dem Hinzufügen eines Tools oder einen Rückgang der Zitatenabdeckung.

Zu Versionierung: Fixieren Sie die Paketversionen, dokumentieren Sie die Hash-Werte der Ausführungen neben den bereitgestellten Builds und weigern Sie sich, „Produktivsysteme“ mit einem nicht fixierten Notebook zu debuggen. Interviewer, die durch stille Updates Schaden erlitten haben, schätzen diese Antwort sehr.

Zu Sicherheit: Tool-Allowlists, Ausgabefilter für Rückerstattungsanfragen sowie menschliche Freigabe für hochwirksame Aktionen gehören in die Erklärung. LangChain erleichtert die Integration – es wählt jedoch nicht Ihre Risikopolitik aus.

Zu Setups mit mehreren Anbietern: Nennen Sie einen konkreten Grund, warum Sie die Modellkonstruktion abstrahiert haben – Preise, Region oder Ausfallüberbrückung – sowie ein Verhalten, das auch nach der Abstraktion noch unterschiedlich war, wie beispielsweise die Formatierung von Tool-Aufrufen. Ehrlichkeit bezüglich möglicher Probleme ist besser als die Behauptung einer perfekten Portabilität.

Zur Übertragung an Benutzeroberflächen: Erwähnen Sie, dass teilweise ausgeführte Tool-Aufrufe eine sorgfältige Handhabung seitens des Clients erfordern und dass Sie bis zum Eintreffen des vollständigen Tool-Namens warten, bevor Sie einen Spinner für payments-svc anzeigen. Kleine Details zeigen echte Implementierungsarbeit.

Zu den Tests: Zeigen Sie, dass Sie reine Funktionen innerhalb des Graphen – wie Schweregrad-Klassifizierer oder Zitierformatierer – unitgetestet werden können, ohne den gesamten Anbieter zu mocken. Behalten Sie die Integrationstests für den tatsächlichen Aufrufweg vor.

Diese Notizen sind keine separaten Fragen; sie stellen die vertiefenden Erklärungen dar, die Sie abgeben, wenn der Interviewer sagt „Erzählen Sie mehr“. Halten Sie sie kurz, beziehen Sie sie auf die Auftragsbestätigung und vermeiden Sie übermäßigen Lobpreis des Anbieters. So verwandeln sich grundlegende Fragen in konkrete Angebote. Bleiben Sie bei konkreten Antworten, zitieren Sie die Auftragsbestätigung und bevorzugen Sie Beispiele aus der Praxis statt allgemeiner Lobeshymnen auf das Framework. Bleiben Sie bei konkreten Antworten, zitieren Sie die Auftragsbestätigung und bevorzugen Sie Beispiele aus der Praxis statt allgemeiner Lobeshymnen auf das Framework. Bleiben Sie bei konkreten Antworten, zitieren Sie die Auftragsbestätigung und bevorzugen Sie Beispiele aus der Praxis statt allgemeiner Lobeshymnen auf das Framework. Bleiben Sie bei konkreten Antworten, zitieren Sie die Auftragsbestätigung und bevorzugen Sie Beispiele aus der Praxis statt allgemeiner Lobeshymnen auf das Framework. Bleiben Sie bei konkreten Antworten, zitieren Sie die Auftragsbestätigung und bevorzugen Sie Beispiele aus der Praxis statt allgemeiner Lobeshymnen auf das Framework. Bleiben Sie bei konkreten Antworten, zitieren Sie die Auftragsbestätigung und bevorzugen Sie Beispiele aus der Praxis statt allgemeiner Lobeshymnen auf das Framework. Bleiben Sie bei konkreten Antworten, zitieren Sie die Auftragsbestätigung und bevorzugen Sie Beispiele aus der Praxis statt allgemeiner Lobeshymnen auf das Framework.

Bleiben Sie bei konkreten Antworten, zitieren Sie das Ticket und bevorzugen Sie Verifizierungsbeispiele gegenüber lobenden Aussagen auf Slogankosten.Bleiben Sie bei konkreten Antworten, zitieren Sie das Ticket und bevorzugen Sie Verifizierungsbeispiele gegenüber lobenden Aussagen auf Slogankosten.Bleiben Sie bei konkreten Antworten, zitieren Sie das Ticket und bevorzugen Sie Verifizierungsbeispiele gegenüber lobenden Aussagen auf Slogankosten über das Framework.Bleiben Sie bei konkreten Antworten, zitieren Sie das Ticket und bevorzugen Sie Verifizierungsbeispiele gegenüber lobenden Aussagen auf Slogankosten.Verifizierungsbeispiele statt lobender Aussagen auf Slogankosten. Bleiben Sie bei konkreten Antworten, nennen Sie das Ticket und bevorzugen Sie Verifizierungsbeispiele gegenüber lobenden Aussagen auf Slogankosten.