Hybrid search RAG with reranking and citations

Manuals are full of exact tokens: model numbers, part numbers, error codes like E-04, and firmware versions. Dense embeddings capture meaning well but often blur these exact strings, so a question about one error code can retrieve a similar-looking code. BM25 matches those tokens precisely but fails on paraphrases like 'it won't drain' versus 'drain pump fault'. Running both and fusing with reciprocal rank fusion gives the union of their strengths without having to calibrate their scores against each other. Then a cross-encoder reranker reads question and chunk together to pick the truly relevant few. I would prove the benefit on a labelled eval set by comparing recall@k for keyword-only, vector-only and hybrid.

Sourced from Docs by LangChain (MCP)

There are two halves. Offline, an ingestion job loads PDF and HTML manuals with LangChain document loaders. It splits them by section and tags each chunk with product model, manual version, section and page. Each chunk gets a stable ID and is written to both a BM25 index and a vector store. Online, the query service normalises the question, extracts filters and keeps tokens like error codes exact. Keyword and vector retrieval run in parallel with the same filters. Results are fused with reciprocal rank fusion, deduplicated by chunk ID and reranked by a cross-encoder. A relevance gate decides whether to call the LLM at all. The model answers from numbered chunks and returns structured output with cited IDs. A citation check validates those IDs before the answer is rendered with page links.

Sourced from Docs by LangChain (MCP)

Manuals already have a logical structure: chapters, sections, procedures, warnings and tables. Splitting on that structure keeps a procedure or troubleshooting entry together, so the reranker and the LLM see a complete, self-contained unit. Fixed-size splitting often cuts a step list in half or separates a warning from the step it applies to. In practice I split on headings first. Then I apply a size limit with a small overlap only when a section is too long. I prepend the section title path to each chunk so it keeps its context. I also keep tables whole where I can. Chunk size is something I tune on the eval set, not guess. Too small loses context; too large dilutes the embeddings and wastes prompt tokens.

Sourced from Docs by LangChain (MCP)

RRF only combines positions from two first-stage retrievers. It never looks at the question and passage together. BM25 and bi-encoder embeddings are built for fast recall, not fine-grained relevance. A cross-encoder reads the query and each candidate jointly, so it is much better at ranking things like the right troubleshooting step for a specific symptom. It is too slow to run over the whole corpus, so the pattern is: wide, cheap recall first, then precise reranking of a few dozen candidates. A second benefit is that reranker scores are a better basis for the relevance gate than RRF scores, because RRF reflects rank positions, not relevance. The cost is extra latency and an extra dependency, which I bound with candidate limits and timeouts.

Sourced from Docs by LangChain (MCP)

I collect real or realistic questions from support tickets and search logs, covering every product family. I include exact error-code lookups, procedural how-tos, multi-step questions and version-specific questions. For each answerable question, subject matter experts label the gold chunk IDs and a reference answer. Just as important, I add unanswerable questions: off-topic ones, questions about products not in the corpus, and near misses that sound similar but are not covered. This lets me measure both false refusals and false answers. I track retrieval recall at each stage, reranker score distributions for answerable versus unanswerable questions, faithfulness and citation correctness. The set is versioned, and I rerun it whenever the chunker, embeddings, reranker, prompt or model changes.

Sourced from Docs by LangChain (MCP)

I put the decision before the LLM, on the reranker scores, because a cross-encoder judges relevance of the full question-chunk pair and is more reliable than raw retriever similarity. I build an eval set that mixes answerable questions with deliberately out-of-scope ones, then sweep the threshold and pick the point that balances false refusals against unsupported answers, usually leaning toward refusing since a wrong safety or repair instruction is costly. There is a second guard after generation: if the structured output has no citations or cites IDs not in the context, the answer is replaced with a refusal. The refusal itself should be useful, saying what was searched and pointing to human support.

Sourced from Docs by LangChain (MCP)

First, the model never produces the citation text itself. Each chunk is given a stable ID in the prompt, and the model returns structured output containing the answer and the list of IDs it used. Code then checks every ID was actually in the context and renders the manual title, section and page from stored metadata, so page numbers cannot be invented. Second, I evaluate faithfulness offline, using LangSmith or a judge model to check each claim against its cited chunk, and I sample production traces regularly. Third, the system prompt instructs the model to answer only from the supplied chunks and to say so when they are insufficient, which pairs with the post-generation refusal path.

Sourced from Docs by LangChain (MCP)

At minimum I store the stable chunk ID and the source document ID. I also store manual title, product model, manual version or firmware range, section path, page number, language and an ingestion timestamp or content hash. Product model and version drive the metadata filters applied to both retrievers, so a question about one model never pulls another model's instructions. Section and page feed the rendered citations, so users can open the exact page. The content hash tells re-ingestion what changed. If access is restricted, I add a tenant or entitlement field so filtering can be enforced at retrieval time. Metadata is part of the data contract: both indexes must hold identical values for the same chunk ID.

Sourced from Docs by LangChain (MCP)

The same chunk ID links everything. It is how RRF deduplicates a passage returned by both retrievers. It is how the LLM cites sources, how the citation check validates them, and how re-ingestion updates or deletes a chunk in both indexes consistently. If IDs changed on every run, citations stored in logs or feedback would point to nothing, and stale duplicates could pile up. I derive the ID deterministically, for example from document ID, manual version, section path and chunk ordinal, or I hash those together. A separate content hash detects text changes without changing identity. I avoid random UUIDs per run and make sure both the BM25 index and the vector store use exactly the same ID.

Sourced from Docs by LangChain (MCP)

Normalisation should be conservative. I trim whitespace, fix obvious casing for natural-language words and maybe expand known abbreviations. Before any of that, I detect and protect patterns like error codes, part numbers and firmware versions using regexes built from the manual corpus. Those tokens pass unchanged to BM25, which is where exact matching matters most. The BM25 tokenizer must treat them the same way at index time and at query time. For example, it must not split 'E-104' differently in the two places. Extracted filters such as product model are removed from the free text only if that helps relevance, and they are always applied as structured filters. I test normalisation against a list of real codes from the manuals.

Sourced from Docs by LangChain (MCP)

I define one filter model in code, for example product model, version range and tenant. I translate it into each backend's filter syntax through a small adapter, rather than building filters separately in two places. Both indexes are populated from the same ingestion record, so the metadata values are identical. I write contract tests that run the same filter against both backends and compare the returned chunk ID sets on fixtures. If one backend cannot express a filter natively, such as a version range, I store normalised fields at ingestion, like min and max version. That way both can filter the same way. Inconsistent filters are dangerous because RRF would then fuse candidates from different products.

Sourced from Docs by LangChain (MCP)

There are three knobs. The first is k per retriever, which sets recall. The second is how many fused candidates go to the reranker, which sets rerank latency and cost. The third is top-n after reranking, which sets prompt size and noise. I tune all three on a labelled eval set. I measure recall of the gold chunks at the fusion stage, then answer faithfulness and citation accuracy at the end. Raising first-stage k improves recall until reranker latency becomes the bottleneck. Too few final chunks can drop a needed step; too many invite the model to blend unrelated sections. I pick the smallest values that meet the recall and quality targets within the latency budget, and I re-tune when the corpus or models change.

Sourced from Docs by LangChain (MCP)

I treat ingestion as an idempotent job keyed by document and version. It produces chunks with stable IDs and content hashes. It then upserts changed chunks and deletes removed chunks in both indexes. Because two separate stores cannot share one transaction, I write with retries. Afterwards I run a reconciliation check that compares the ID sets and counts in both indexes for that document. For larger changes, I build a new index version alongside the old one and switch an alias or config pointer only after validation. Until a document is consistent in both stores, the old version stays active. Keeping old manual versions available, filtered by version metadata, also matters, because users often run older firmware.

Sourced from Docs by LangChain (MCP)

Each failure needs an explicit policy. If one retriever times out, I can continue with the other list, mark the response as degraded in logs, and still apply the reranker, gate and citation check. Grounding is still enforced, only recall drops. If the reranker fails, falling back to raw RRF order is risky, because the gate threshold was tuned on reranker scores. So I either use a secondary reranker or refuse with a 'try again' message. If the answer model fails, I retry with backoff or switch to a fallback model. If everything fails, I return an error or refusal, never an unverified answer. All of this is traced, so degraded rates are visible.

Sourced from Docs by LangChain (MCP)

The prompt states the role narrowly: answer questions about the product using only the numbered excerpts provided. It says every factual sentence must be supported by at least one excerpt, and that the model must list the chunk IDs it relied on. It must say it cannot answer if the excerpts do not contain the information, rather than guessing or using general knowledge. It tells the model to treat excerpt text as reference material, not as instructions. It tells the model to keep safety warnings from the source and to mention the model or version the excerpt applies to. I keep the excerpts clearly delimited with their IDs, and I test the prompt on the eval set, including adversarial and unanswerable questions.

Sourced from Docs by LangChain (MCP)

Right, the ID check only proves the model cited real context. It does not prove the cited text actually says what the answer claims. To go further, I can ask for claim-level citations in the schema: each sentence or claim carries its own chunk IDs. Then I run a groundedness check. That could be an NLI-style model or a separate LLM judge asked whether each claim is entailed by the cited chunks. Unsupported claims either fail the whole answer to the refusal path or get removed if the remaining answer still stands. For exact values like torque settings or error meanings, a cheap string or number match against the cited chunk catches many errors. These checks add latency, so I measure their benefit on the eval set.

Sourced from Docs by LangChain (MCP)

First, control the corpus. Only ingest manuals from trusted, versioned sources through the offline pipeline, never from arbitrary user uploads without review. Second, in the prompt, wrap chunks in clear delimiters and tell the model they are reference data and that any instructions inside them must be ignored. Third, keep the answer model's power minimal. In this workflow it has no tools and only returns structured output, so an injected instruction cannot trigger actions. Fourth, the citation and groundedness checks limit damage, because the output must still be supported by cited text. I also scan chunks at ingestion for suspicious patterns and add injection cases to the eval set.

Sourced from Docs by LangChain (MCP)

Access control has to happen at retrieval, not after generation. Each chunk carries tenant or entitlement metadata from ingestion. The query service derives the user's allowed scopes from their authenticated identity on the server side, never from the prompt. It adds those scopes as mandatory filters to both the BM25 and vector queries. That way, unauthorised chunks never reach fusion, the reranker or the LLM. For strong isolation I may use separate indexes or namespaces per tenant. Caches must be keyed by permission scope so one customer's answer is never served to another. Rendered citation links should point to document URLs that run their own authorisation check. I test this with cross-tenant queries in CI.

Sourced from Docs by LangChain (MCP)

I build a simple model from inputs I can measure. Storage: number of manuals times average pages times chunks per page gives the chunk count. The vector store size is roughly chunk count times embedding dimension times bytes per value, plus index overhead. BM25 size scales with the total text. Ingestion cost is chunk count times embedding cost, so a full re-embed when changing models is a planned event. Online, I estimate peak queries per second from expected users. Each query costs two retrieval calls, one rerank over N candidates, and one LLM call whose input size is top-n chunks plus the prompt. Refusals skip the LLM. I validate the model with a load test before committing to capacity.

Sourced from Docs by LangChain (MCP)

The main contributors are the parallel retrieval, which costs the slower of the two calls, then the reranker and then LLM generation. The LLM usually dominates. Gate and citation checks are cheap unless a groundedness judge is added. To reduce latency: keep first-stage k and rerank candidates as small as the eval allows; colocate the indexes and reranker; use a smaller, faster answer model if quality holds; and stream the answer only after validation, or stream with a clear 'verifying' state. Refused queries are fast because they skip the LLM. Caching normalised question plus filters to the final validated answer helps for frequent questions, but the cache must be keyed by permission scope and invalidated when manuals change.

Sourced from Docs by LangChain (MCP)

For this use case, I prefer a fixed pipeline. The steps are known, and the safety guarantees depend on deterministic gates: always rerank, always check the threshold, always validate citations. A fixed pipeline is easier to test, cheaper and has predictable latency. An agent built with create_agent, where retrieval is a tool, adds flexibility. It can search again with different terms or decompose multi-part questions. But it may skip retrieval or loop, and the gate and citation checks then have to be enforced through middleware or post-processing. A reasonable middle ground is a fixed pipeline with an optional query-rewrite retry. I would reach for an agent only if evals showed complex questions needing multiple retrieval rounds.

Sourced from Docs by LangChain (MCP)

The rule is to never fill gaps from general knowledge. If the reranked chunks pass the gate but cover only part of the question, the model answers the supported part with citations and explicitly says which part the manuals do not cover. It then points to support for that part. I make this possible in the schema, for example with an optional field for unanswered aspects. I also tell the prompt that partial answers are acceptable and guessing is not. The groundedness check verifies that the answered part is fully supported. The eval set includes multi-part questions where only one part is answerable, so I can measure whether the model correctly holds back.

Sourced from Docs by LangChain (MCP)

They are independent I/O calls, so running them one after the other only adds latency. Parallel execution makes retrieval latency roughly the slower of the two rather than their sum. In LangChain I can use async retriever calls with asyncio.gather, or a RunnableParallel that maps both retrievers over the same normalised query and filters. I also set a timeout on each call. If one retriever is slow or fails, I decide explicitly what happens next: continue with the other list and log it, or fail closed. Both calls must receive identical filters and a consistent candidate count, so that fusion compares like with like.

Sourced from Docs by LangChain (MCP)

Users sometimes paste serial numbers, emails or phone numbers. If part of the flow is built with create_agent, I can use PIIMiddleware to redact, mask or block types such as email and phone before text reaches the model or logs. In a plain chain, I apply an equivalent redaction step in the query service. I keep identifiers that are needed for retrieval, such as a product model, but avoid storing personal details in traces and analytics. Logs and conversation memory follow a retention policy. For Indian users, the design should respect obligations under the Digital Personal Data Protection Act, such as purpose limitation and minimisation. I would confirm the details with the legal team rather than assume them.

Sourced from Docs by LangChain (MCP)

Follow-ups like 'what about the second step?' are unclear on their own. So before retrieval, I rewrite the latest message into a standalone query, using recent turns and the previously extracted filters such as product model. Retrieval always runs on that rewritten query, and grounding rules stay the same: the answer may only use chunks retrieved for this turn. Conversation state is short-term and thread-scoped. In LangChain v1, that is handled with a checkpointer keyed by a thread ID. If conversations get long, summarisation keeps the context bounded. I log both the original and rewritten query so rewrite errors can be debugged and evaluated.

Sourced from Docs by LangChain (MCP)

Text loaders often flatten tables badly, and they miss content inside images. For tables, I use a loader or parser that keeps rows and headers. I store a table as one chunk, converted to markdown or plain rows with its caption, so the values stay linked to the column names. For scanned pages, I run OCR during ingestion and flag low-confidence output for review. For diagrams, I index the caption, surrounding text and any labels. If needed, I generate a text description, marked as derived, so it is not treated as the manual's own wording. The page number is kept, so the citation lets the user open the original figure. Answers about diagrams should point users to the page.

Sourced from Docs by LangChain (MCP)

There are two parts: retrieval and answering. BM25 will not match Hindi words to English text. A multilingual embedding model can help vector retrieval, but exact-term matching still suffers. A practical approach is to detect the language and translate or rewrite the query into English for retrieval, while keeping error codes and model numbers untouched. Then I answer in the user's language, citing the English chunks. Grounding checks should compare claims against the original English text, not a translation. The eval set must include Hindi and code-mixed questions, because gate thresholds and recall can behave differently. If localised manuals exist, I index them with language metadata and prefer them.

Sourced from Docs by LangChain (MCP)

For every request, I trace the original and normalised query and the extracted filters. I record each retriever's returned IDs and latency, the fused list, the reranker scores, the gate decision, the prompt chunk IDs, the model output, the citation-check result and the final response type. LangSmith works well for tracing LangChain components. Key metrics include refusal rate, citation-check failure rate, degraded-mode rate, latency per stage, token use and user feedback. A sudden rise in refusals may mean an ingestion problem or filter bug; a drop may mean the gate is too loose. Sampled traces get human review, and flagged failures are added to the eval set. Personal data is redacted before storage.

Sourced from Docs by LangChain (MCP)

First, try to avoid the conflict with filters. If the user's product model or firmware version is known, retrieve only matching versions. If it is unknown and the top chunks come from different versions with different instructions, the answer should not merge them. It should state that the instructions differ by version, cite each version's chunk, and ask the user to confirm their version. The prompt explicitly asks for version-scoped statements, and the rendered citations show the manual version. At ingestion, I mark superseded manuals but keep them searchable when relevant, because many users run older firmware.

Sourced from Docs by LangChain (MCP)

Both changes alter the vector index. Vectors from different embedding models are not comparable, so a new model means re-embedding every chunk. A new chunker means new chunks and possibly new IDs. I build a complete new index version side by side, populated by the same ingestion pipeline. I run the full eval set against it, comparing recall, faithfulness, refusal accuracy and latency with the current version. The relevance threshold may need re-tuning, since score distributions shift. If results hold, I switch traffic through a config pointer, possibly via a gradual or shadow rollout. The old index stays available for quick rollback until the new one is proven.

Sourced from Docs by LangChain (MCP)

I keep it small and easy to verify. Fields: answer text; a list of cited chunk IDs; optionally claim-level entries pairing each sentence with its supporting IDs; a flag the model sets when the context is insufficient; and optionally a list of unanswered parts. I pass the schema through structured output support, for example a Pydantic model with the model's with_structured_output, or response_format if using create_agent. Downstream code validates it, checks that IDs are in the provided set and that citations are not empty, and routes failures to refusal. A model-set 'insufficient context' flag is a useful extra signal, but the deterministic checks still run.

Sourced from Docs by LangChain (MCP)

The renderer maps each cited chunk ID back to its metadata: manual title, version, section path and page. It shows inline citation markers in the answer, with a source list that links to the exact page, for example a PDF page anchor or the HTML section anchor. Showing the version helps users confirm the instructions match their device. I preserve safety warnings and step numbering from the answer. The links should go through the document service's authorisation check for restricted manuals. I also log which citations users click and collect thumbs up or down feedback, which feeds new eval cases.

Sourced from Docs by LangChain (MCP)

I would scale the stateless query service horizontally. Retrieval backends and the reranker need enough replicas or provider quota. LLM provider rate limits are often the real ceiling, so I would queue requests or shed load gracefully with a clear 'busy' message instead of timing out. Caching validated answers to repeated questions helps a lot during recalls, because many users ask the same thing. Keys include normalised query, filters, permission scope and manual version, and entries are invalidated when that manual is updated. Refusals are cheap, since they skip the LLM. I would load-test the expected peak and set per-stage timeouts, so one slow dependency does not consume every worker.

Sourced from Docs by LangChain (MCP)

1. AIt replaces the need for a reranker
2. BIt re-embeds documents to make scores comparable
3. CIt uses rank positions, so the different score scales of BM25 and cosine similarity do not need calibratingCorrect answer
4. DIt always returns fewer documents than either retriever

Why: RRF combines lists by rank position rather than raw score, which avoids comparing BM25 scores with cosine similarities on different scales.

Sourced from Docs by LangChain (MCP)

1. AThe highest raw score the document received in any list
2. BThe product of the document's ranks across lists
3. CThe sum over lists of 1 / (k + rank of the document in that list)Correct answer
4. DThe average of the raw BM25 score and the cosine similarity

Why: RRF adds 1/(k + rank) from each list, using only rank positions. This is why it can merge retrievers whose raw scores are on different scales.

Sourced from Docs by LangChain (MCP)

1. AIt looks up exact keywords before embedding
2. BIt caches embeddings for faster similarity
3. CIt uses a larger vector dimension
4. DIt encodes the query and the passage together and scores the pair jointlyCorrect answer

Why: A cross-encoder reads the query and passage together, which captures fine-grained relevance. It is too slow for full-corpus search, so it is used only for reranking.

Sourced from Docs by LangChain (MCP)

1. AThat the answer contains at least one citation
2. BThat the cited chunk text actually supports each claim in the answerCorrect answer
3. CThat the chunks came from the allowed filters
4. DThat the IDs exist

Why: ID validation proves the citations reference provided chunks, not that the cited text supports what the answer claims. That requires a groundedness check.

Sourced from Docs by LangChain (MCP)

1. AOn the raw BM25 scores only
2. BOn the cross-encoder reranker scores, tuned on a labelled eval setCorrect answer
3. COn the LLM's token count
4. DOn the number of chunks returned by the vector store

Why: The reranker scores the question and chunk jointly, so its scores are better relevance signals, and tuning on labelled data sets the threshold objectively.

Sourced from Docs by LangChain (MCP)

1. Alangchain-core
2. Blangchain-classicCorrect answer
3. Clanggraph
4. Dlangchain-cohere

Why: Legacy chains and retrievers like EnsembleRetriever moved to the langchain-classic package in v1.

Sourced from Docs by LangChain (MCP)

1. A"provider:model"Correct answer
2. BA URL to the provider endpoint
3. C"provider/model/version" only
4. D"model@provider"

Why: init_chat_model takes an identifier like "provider:model", which lets you switch providers through configuration.

Sourced from Docs by LangChain (MCP)

1. AThe reranker alone
2. BAn LLM generating the answer without retrieval
3. CVector retriever with a general embedding model
4. DBM25 keyword retriever with consistent tokenisationCorrect answer

Why: Exact tokens like error codes are matched well by lexical retrieval. Embeddings may treat similar-looking codes as near neighbours.

Sourced from Docs by LangChain (MCP)

1. ATo shrink the vector store on disk
2. BSo one passage found by both retrievers does not take two reranker and prompt slotsCorrect answer
3. CBecause the reranker cannot read metadata
4. DTo change the chunk's citation page

Why: A passage returned by both retrievers should appear once. Duplicates waste rerank compute and context space and can skew the final selection.

Sourced from Docs by LangChain (MCP)

1. AIt makes BM25 scores equal to cosine scores
2. BSo fusion only combines candidates for the same product, version and permission scopeCorrect answer
3. CFilters are needed only by the reranker
4. DIt removes the need for a relevance gate

Why: Different filters would let one list bring in wrong-model or unauthorised chunks, which fusion would then mix into the candidates.

Sourced from Docs by LangChain (MCP)

1. AIt improves BM25 recall
2. BIt prevents ungrounded answers and avoids spending an LLM call on an unanswerable queryCorrect answer
3. CIt retrains the reranker online
4. DIt lets the model use its general knowledge instead

Why: With no relevant context, any generated answer would be unsupported. Refusing early is both safer and cheaper.

Sourced from Docs by LangChain (MCP)

1. ARoute it to the refusal pathCorrect answer
2. BAttach the top reranked chunk as a citation automatically
3. CRetry with a higher temperature until it cites
4. DShow it with a disclaimer

Why: The workflow treats an answer with no citations as a failure. Adding citations automatically would fake support that was never checked.

Sourced from Docs by LangChain (MCP)

1. ATo encrypt the chunk text
2. BTo speed up the LLM
3. CTo make embeddings smaller
4. DTo link deduplication, citations, validation and re-ingestion updates across both indexesCorrect answer

Why: The same ID is used in fusion, citation, validation and updates. It must be stable across runs and identical in BM25 and the vector store.

Sourced from Docs by LangChain (MCP)

1. ANothing; old vectors remain compatible
2. BRe-embed all chunks with the new model, ideally into a new index versionCorrect answer
3. COnly new chunks need the new model
4. DConvert old vectors with a fixed scaling factor

Why: Vectors from different embedding models are not comparable. The whole corpus must be re-embedded, and validating side by side allows rollback.

Sourced from Docs by LangChain (MCP)

1. ALower the reranker threshold
2. BRemove the system prompt
3. CTrust it because it came from a manual
4. DTreat chunk text as delimited reference data, keep the model without tools, and rely on grounding checksCorrect answer

Why: Retrieved content must be treated as data, not instructions. A tool-less model plus validation limits what an injected instruction can do.

Sourced from Docs by LangChain (MCP)

1. AIn the LLM prompt, asking the model not to reveal restricted content
2. BAs server-side filters on both retrievers, derived from the authenticated userCorrect answer
3. COnly when rendering citation links
4. DBy the reranker's scores

Why: Unauthorised chunks must never reach fusion, the reranker or the model. Prompt instructions are not a security boundary.

Sourced from Docs by LangChain (MCP)

1. ANo effect, because BM25 ignores tokens
2. BThe reranker will fix the tokenisation
3. CBetter recall for exact codes
4. DMissed or wrong matches, because the token no longer matches how it was indexedCorrect answer

Why: Exact identifiers must be protected, and tokenised the same way at index and query time, or lexical matching breaks.

Sourced from Docs by LangChain (MCP)

1. APrompts become too long
2. BA chunk needed for a complete answer is dropped, causing false refusals or partial answersCorrect answer
3. CBM25 stops working
4. DCitations become duplicated

Why: Too few final chunks can leave out required steps. Too many add noise and cost, so top-n is tuned on the eval set.

Sourced from Docs by LangChain (MCP)

1. AUse SummarizationMiddleware to shorten the context
2. BAsk for citations in free text and parse with regex
3. CUse structured output, e.g. with_structured_output or create_agent's response_format, with a schema containing answer and citation IDsCorrect answer
4. DIncrease the temperature so the model lists more sources

Why: Structured output enforces a schema, so code can reliably read and validate the cited IDs against the supplied context.

Sourced from Docs by LangChain (MCP)

1. AReranker scores do not depend on the query
2. BLangChain forbids thresholds on RRF
3. CRRF scores reflect rank positions, not how relevant a passage actually isCorrect answer
4. DRRF scores are always zero

Why: Even irrelevant candidates get a top RRF rank. Reranker scores judge the actual query and passage pair, so they make a more meaningful threshold.

Sourced from Docs by LangChain (MCP)

1. AFixed-size chunks cannot be embedded
2. BSections remove the need for metadata
3. CSections always have the same length
4. DIt keeps procedures, warnings and troubleshooting entries intact as meaningful unitsCorrect answer

Why: Section-aware splitting keeps related steps together. This improves both retrieval quality and grounded answers.

Sourced from Docs by LangChain (MCP)

1. AOnly by a long-term store namespace
2. BThread-scoped via a checkpointerCorrect answer
3. CStored inside the vector store as chunks
4. DThrough the BM25 index

Why: Short-term memory is scoped to a thread and persisted by a checkpointer, while long-term memory uses LangGraph stores.

Sourced from Docs by LangChain (MCP)

1. AIndex, embed or rerank
2. BEncrypt, hash or compress
3. CRedact, mask or blockCorrect answer
4. DTranslate, summarise or drop

Why: PIIMiddleware can redact, mask or block detected PII such as email addresses and phone numbers.

Sourced from Docs by LangChain (MCP)

1. AIt always switches to the cheapest model first
2. BIt retries the same model forever
3. CIt returns an empty answer
4. DIt tries the configured fallback models in orderCorrect answer

Why: Fallback models are tried in the configured order when a model call fails.

Sourced from Docs by LangChain (MCP)

1. AAverage token cost per query
2. BNumber of indexed manuals
3. CRecall of labelled gold chunk IDs at kCorrect answer
4. DLLM response length

Why: Recall at k against labelled gold chunks isolates retrieval quality from generation quality.

Sourced from Docs by LangChain (MCP)

1. AAsk the LLM to answer from general knowledge
2. BContinue with BM25 results, keep the reranker, gate and citation checks, and log degraded modeCorrect answer
3. CSkip the gate to avoid refusing
4. DReturn BM25 results unranked as the answer

Why: Degrading recall is acceptable if grounding is still enforced. Skipping checks would break the no-unsupported-claims rule.

Sourced from Docs by LangChain (MCP)

1. AUpdate only the vector store; BM25 catches up later
2. BIdempotent upserts and deletes by stable chunk ID in both stores, followed by a reconciliation checkCorrect answer
3. CAppend new chunks with random IDs
4. DRebuild BM25 from vector store embeddings

Why: Two stores cannot share a transaction. Idempotent keyed writes plus a check that ID sets match prevent drift.

Sourced from Docs by LangChain (MCP)

1. AAs SQL tables per user
2. BAs JSON documents by namespace and key, with optional semantic searchCorrect answer
3. CAs BM25 postings lists
4. DAs checkpoints per message

Why: LangGraph stores hold JSON documents addressed by namespace and key, and can optionally support semantic search.

Sourced from Docs by LangChain (MCP)

1. ARetry, cache or skip
2. BEscalate, archive or delete
3. CRerank, filter or fuse
4. DApprove, edit or rejectCorrect answer

Why: interrupt_on is set per tool, with allowed decisions of approve, edit and reject.

Sourced from Docs by LangChain (MCP)

1. Awrap_model_callCorrect answer
2. Bwrap_tool_call
3. Cbefore_model
4. Dafter_model

Why: wrap_model_call surrounds the model invocation, for example to add retries, timing or request changes. wrap_tool_call does the same for tool calls.

Sourced from Docs by LangChain (MCP)

1. ASummarising manuals at ingestion
2. BCondensing older conversation history once a trigger such as a token count is reached, keeping recent messagesCorrect answer
3. CShortening reranker outputs
4. DCompressing vector embeddings

Why: It triggers on thresholds such as ('tokens', 4000) and keeps recent context, such as ('messages', 20), to bound the context size.

Sourced from Docs by LangChain (MCP)

1. AA text splitter
2. Binit_chat_model with an mcp: prefix
3. CThe MCP adapters, such as MultiServerMCPClientCorrect answer
4. DEnsembleRetriever

Why: The MCP adapters turn MCP tools into LangChain tools that an agent can call.

Sourced from Docs by LangChain (MCP)

1. AIt only works in JavaScript
2. BIt cannot call models
3. CIt is designed for long multi-step tasks, with filesystem, subagents and summarisation, which a fixed retrieval pipeline does not needCorrect answer
4. DIt does not support structured output

Why: Deep Agents bundle extras for long tasks. A deterministic retrieve, gate and answer pipeline is simpler and easier to verify.

Sourced from Docs by LangChain (MCP)