RAG vs. fine-tuning in 2026: which one should your B2B AI product use?

Most B2B AI teams eventually ask some version of the same question: should we give the model our documents through retrieval, train the model on examples, or do something else entirely?

The tempting answer is a two-column comparison: RAG on one side, fine-tuning on the other. That framing is neat, memorable, and often wrong. Retrieval and fine-tuning change different parts of an AI product. Retrieval changes what information the model can see at request time. Fine-tuning changes how a model tends to respond to patterns in its training examples. Neither one repairs a broken workflow, a bad source system, or an undefined quality bar.

My short recommendation: start with a working baseline and diagnose the failure before choosing an adaptation method. Add retrieval when the model needs changing, private, or traceable information. Consider fine-tuning when the model needs to perform a stable behavior repeatedly and prompting plus structured application logic are not enough. Combine them only when you can name the separate job each layer performs. If you cannot yet describe the failure, keep the system simpler.

This is a practical decision guide, not a claim that one architecture wins for every company. The current evidence is more useful than a universal winner: official guidance from AWS, Google Cloud, and Microsoft separates knowledge access from task behavior; a May 2026 industrial study still finds the cost and quality trade-off depends on the application; and public practitioner discussions keep returning to the same unresolved problem—when a system fails, is the missing piece the document, the retrieval path, the model behavior, or the surrounding integration?

The short answer

Use retrieval when the answer depends on information that changes outside the model. Product documentation, pricing, inventory, policies, contracts, support history, and internal operating procedures belong in a controlled data path that can be updated, scoped, and inspected. A retrieval-augmented generation system, or RAG system, searches a source at runtime, places relevant material into the model's context, and asks the model to generate from that material.

Use fine-tuning when the answer depends on a repeatable behavior that you can demonstrate with reliable examples. That might be a classification task, a strict output format, a specialized extraction pattern, or a consistent style. Fine-tuning adjusts model parameters using a training dataset. It is not a secure document cabinet, and it is not a replacement for an authoritative source of current facts.

Use neither when the model already handles the task and the actual problem is a missing schema, weak prompt, unclear state transition, bad source data, or absent validation. A deterministic parser, a better field description, a small set of examples in the prompt, or a normal database query may be the highest-leverage improvement.

Use both when you need current information and a stable specialized behavior. For example, a support assistant might retrieve the latest account policy and use a tuned extraction model to turn the answer into a fixed internal schema. The two layers remain separate: retrieval supplies evidence; tuning shapes behavior. The combination is more expensive to operate, so it should earn its place through an evaluation rather than through architectural enthusiasm.

The real question: knowledge, behavior, or workflow?

Before choosing a technique, name what you are trying to change. This sounds obvious, but it prevents a surprising amount of wasted effort. Teams often say “the model needs to learn our business” when they mean three different things:

• It needs access to the business's current information.
• It needs to follow a particular process or output contract.
• It needs to take action inside a business system.

Those are different engineering jobs. Retrieval addresses the first. Fine-tuning can help with the second. Application code, APIs, permissions, and workflow state own most of the third.

In an agentic AI workflow, the distinction matters even more because the system may retrieve a source, choose a tool, inspect the result, and continue through several steps. Retrieval can provide context for that run, and fine-tuning can shape a narrow behavior inside it, but neither one should become the authority for permissions, side effects, or stopping conditions.

Here is a concrete example. Imagine a distributor wants an assistant for sales representatives. The assistant should answer questions about available products, draft a quote summary, and create a follow-up task. The product catalog changes every week. The company's preferred quote format is stable. Creating a task has a side effect and requires the representative's identity.

A sensible architecture would retrieve the current catalog and account rules, use a prompt or possibly a tuned model to produce the preferred quote format, and let application code validate the account, calculate the allowed fields, and create the task only after the required confirmation. Calling the entire thing “fine-tuning the sales assistant” hides the important boundaries.

Google Cloud's current generative AI application guidance describes grounding as anchoring a response to verifiable sources and identifies RAG as a common grounding technique. The same guidance describes tuning as a way to improve performance on specialized tasks and output requirements, and it recommends evaluating the effects of prompts and customizations with multiple methods rather than trusting one score. Microsoft Learn makes a similar distinction: RAG supports changing or broad content, while fine-tuning fits specialized, stable tasks when the team has enough data.

These are vendor explanations, not laws of nature. But they point to a durable model for the decision:

The wording matters. “What does the model know?” is often less useful than “What information should be available at this step, and which behavior must be repeatable after it is available?”

What retrieval actually buys you

Retrieval is a way to make an otherwise general model work with a selected information source at inference time. Documents are usually split into pieces, represented for search, stored with metadata, and fetched when a question arrives. The retrieved pieces are placed into the model's context along with instructions about how to use them.

The simple version is often enough to explain the value:

1. Store an approved source.
2. Prepare it for search.
3. Find material related to the current request.
4. Pass the selected material to the model.
5. Generate an answer that distinguishes evidence from uncertainty.

The important advantage is not that retrieval makes a model automatically accurate. It is that the information path can change without retraining the model. A product policy can be replaced, a new support article can be indexed, a customer's access can be revoked, or a record can be marked stale. The system can also show which source material influenced the answer.

AWS's current guidance recommends starting with a RAG-based approach when the job is question answering over custom documents. It notes that RAG can incorporate updated documents quickly and provide references, while fine-tuned models do not inherently provide a source reference in their responses. The same guidance also names a limitation that matters: RAG is not automatically good at summarizing an entire document. Retrieval can help you find evidence; it does not remove the need to design the task.

Retrieval is a data product, not a plug-in

People often describe RAG as if it were one feature: upload files, add a vector database, and ask questions. In production, retrieval is a data product with its own lifecycle.

You need to decide what can enter the index, how it is parsed, which metadata is attached, how tenant and document permissions are enforced, how updates and deletions propagate, what happens when no relevant result exists, and how an operator inspects a bad retrieval. A technically successful vector search can still return the wrong policy version, a document from another customer, a chunk with no useful heading, or an obsolete answer that happens to be semantically similar.

Current platform documentation reflects this operational reality. OpenAI's vector-store API documents searchable files, file processing status, metadata, expiration, and chunking configuration. AWS documents separate retrieve-only and retrieve-and-generate evaluations. The specific products differ, but the shape is consistent: retrieval quality is something you operate and test.

The common retrieval failure shapes

• The right document never entered the index. The source connector, parser, permissions filter, or update job failed.
• The right document entered, but the wrong passage was selected. Chunk boundaries, query wording, metadata, ranking, or filtering need attention.
• The passage was retrieved, but the answer ignored it. The generation prompt, context ordering, or model behavior may be the problem.
• The passage was retrieved from the wrong scope. Tenant filtering, authorization, or document identity is the problem.
• The system retrieved something when it should have abstained. The no-match behavior and confidence policy are underspecified.

A June 2026 Haystack discussion illustrates the first two categories from a practitioner perspective. A contributor who said they used RAG in production asked how others debug retrieval failures, inspect pipelines step by step, and detect duplicates, malformed documents, or missing metadata. That discussion is a user signal, not a benchmark. Its value is that it makes the maintenance burden visible: when an answer is poor, teams need to inspect the path between the question and the final response.

Another public production discussion in the mem0 repository reports problems that can appear as a corpus grows: retrieval drift, chunking choices, freshness, hybrid search, reranking, and the need to log sources and retrieval scores. Treat those comments as practitioner observations rather than universal thresholds. They reinforce a useful buying question: does the tool you are considering expose the retrieval evidence and controls you will need after the demo?

When retrieval is the better first move

Start with retrieval when the content changes, the source is private, the reader needs to see where the answer came from, or the application must enforce document-level access. These properties are especially common in internal knowledge, customer support, product documentation, sales enablement, operations, and policy workflows.

Retrieval is also a good first move when you are still discovering what people ask. You can update documents and inspect the questions without creating a new training job for every change. The data path stays separate from the model path, which makes it easier to learn whether the source is actually useful.

Do not present RAG as a guarantee against hallucination. AWS and Google describe grounding and reduced hallucination risk in their guidance, but retrieved context can be wrong, incomplete, stale, mis-scoped, or ignored. The safer claim is narrower: retrieval gives the application a source path that can be inspected and updated, and it can give the model evidence that was not in its original prompt.

What fine-tuning actually buys you

Fine-tuning starts with a base model and a training dataset that represents the behavior you want. The training process adjusts parameters so the model is more likely to produce the kinds of outputs represented by those examples. Depending on the provider and method, this can include supervised fine-tuning, preference optimization, reinforcement fine-tuning, parameter-efficient methods, or distillation into a smaller model.

That vocabulary can make fine-tuning sound like a way to install company knowledge inside a model. Sometimes domain adaptation can help, but the operational decision is safer when you think of fine-tuning as behavior shaping. A tuned model may learn how to classify a request, extract fields, follow a response pattern, or express a style. It still needs a live source path when the answer depends on facts that change.

Google Cloud's current fine-tuning guidance identifies specific language, task performance, style, edge cases, and high-volume cost or latency as possible reasons to consider fine-tuning. It also highlights the work around the training itself: collecting, cleaning, formatting, and splitting data, then monitoring validation performance. Microsoft similarly points to specialized, stable tasks and warns that fine-tuning is a poor fit for constantly changing information.

The dataset is the product

A fine-tuning experiment is only as good as the behavior your examples define. If the examples are inconsistent, outdated, biased toward easy cases, or written by people who disagree about the desired output, the model will learn that ambiguity. If the training set includes a shortcut that happens to correlate with the answer, the model may use the shortcut in situations where it no longer applies.

Before training, you need a clear task contract:

• What inputs are in scope?
• What is the exact output shape?
• Which cases must be refused, escalated, or marked unknown?
• What does a correct answer have to preserve?
• Which examples represent the difficult tail rather than only the happy path?
• How will you compare the tuned model with the current baseline?
• What happens when the base model, provider, or task changes?

Fine-tuning can be the right move when the task is stable and high-volume enough that repeatedly sending long instructions or examples is costly, slow, or inconsistent. It can also help a smaller model perform a narrow job. But “we have some transcripts” is not the same as “we have a training dataset.” You need labels or preferred outputs, a way to handle disagreements, held-out cases, and a plan to detect regressions.

The common fine-tuning failure shapes

• Overfitting. The tuned model performs well on familiar examples and poorly on new wording or edge cases.
• Behavior transfer is too broad. A style or rule leaks into tasks that should remain general.
• Knowledge is stale. The training set captured facts that changed, but the model has no automatic update path.
• Format improves while meaning degrades. The model emits valid structure that contains the wrong decision.
• The model becomes harder to compare. A provider update, base-model change, or training-data revision changes behavior without a clear route back.
• The job was not a model problem. The real defect was a missing validation rule, an ambiguous field, or a workflow that never defined “done.”

Public user signals show why this distinction remains confusing. In a July 2026 Reddit discussion, practitioners repeatedly separated missing facts from inconsistent formatting or behavior, while also noting that most teams should try prompting and retrieval before committing to a training pipeline. The thread is not evidence of an industry percentage. It is evidence that people building systems still need a practical diagnostic vocabulary.

A separate July 2026 discussion in r/LocalLLaMA asks whether people still fine-tune on consumer hardware and describes both lower demand for broad fine-tunes and continued interest in narrow LoRA experiments. That is a useful counter-signal to a simple “fine-tuning is over” story: the method remains attractive for specific behaviors and local constraints, but the reason to use it has to be more concrete than “make the model know our company.”

When fine-tuning is the better first move

Consider fine-tuning after you can show that the task is stable, the desired behavior is clear, the examples are good, the baseline misses the behavior in a repeatable way, and the cost of operating the tuned model is acceptable. Strong candidates include classification, extraction, structured transformations, narrow tool selection, and a consistent style that prompting alone cannot reliably maintain.

Fine-tuning is less attractive when the main requirement is current factual recall, when your source changes more quickly than your training cadence, when each customer needs different private information, or when you do not yet have a trustworthy evaluation set. In those cases, retrieval, structured prompting, or a better application boundary may teach you more at lower risk.

The buy, build, or postpone matrix

When a B2B team asks which tool to buy, the useful comparison is not only “which vendor has RAG?” or “which provider offers fine-tuning?” Compare the capability against the job, the data, and the consequences of getting it wrong.

“Buy” can mean a managed retrieval service, a hosted fine-tuning interface, a model gateway, or a specialist implementation. “Build” can mean owning ingestion, ranking, evaluation, and policy code. “Postpone” is not a failure. It is the right decision when the team cannot yet tell whether the proposed architecture fixes the real bottleneck.

Use a managed service when speed, ordinary operating controls, and a known provider boundary matter more than deep customization. Build more of the system when tenant isolation, auditability, data residency, special ranking behavior, or portability are core product requirements. In either case, ask what happens when the source changes, a document is deleted, a model is retired, a customer leaves, or a reviewer needs to explain an answer.

Why neither is often the right answer

There is a powerful social pressure in AI projects to add a named technique. If a prototype feels weak, someone proposes RAG. If it feels inconsistent, someone proposes fine-tuning. The named technique creates a sense of progress before the team has measured the failure.

Sometimes the highest-leverage fix is boring:

• Replace a vague instruction with a field-by-field contract.
• Show the model two or three representative examples in context.
• Normalize a date, currency, or identifier before the model sees it.
• Move current facts into a normal database query or typed API.
• Validate the output and return a clear repair request.
• Split one broad task into two narrow steps.
• Add a human review state instead of pretending uncertainty does not exist.
• Remove irrelevant context that makes the answer less precise.

These changes are not anti-AI. They are what make an AI feature legible. A model cannot compensate for a product that has not decided which source is authoritative, which fields are required, or who is allowed to approve the result.

The newest model may also make the baseline good enough. That does not mean the problem is solved forever; it means the team's current budget may be better spent on evaluation, source quality, and user experience than on training infrastructure. Recheck the baseline after meaningful model or prompt changes before assuming the old gap still exists.

Diagnose the failure before changing the model

When a B2B AI feature fails, save the input, the expected outcome, the retrieved context if any, the model output, the validation result, and the human correction. Then classify the failure. The classification is more useful than a general impression that the model “did not get it.”

This diagnostic method also gives you a better conversation with vendors or implementation partners. Instead of asking for “an AI trained on our data,” you can ask whether the proposed system will expose retrieval results, source versions, evaluation cases, validation failures, correction history, and permission decisions.

For complex or sensitive workflows, connect this article to the broader boundaries described in BishopTech's guide to AI-agent memory and retrieval and guide to model routing in production. Retrieval is not memory, and a retrieval choice is not the same as a model-routing choice. Keeping those concepts separate makes the architecture easier to test.

Evaluate the whole system, not the technique

An evaluation should answer whether the proposed change improves the job you care about. A high retrieval score does not prove that the answer is useful. A high answer score does not prove that the source was authorized. A valid JSON response does not prove that the category was correct.

Build an evaluation set from real work before you choose a more expensive adaptation path. Include ordinary cases, ambiguous cases, stale-source cases, missing-source cases, permission boundaries, and the cases that humans routinely correct. Keep a held-out set that the team does not use while changing prompts or training examples.

Evaluate retrieval separately

For each question, inspect whether the expected source was available, whether the right passage was retrieved, whether the source scope was correct, and whether the system could abstain. Measures such as context relevance and coverage can be useful, but they are not the whole answer. A relevant passage from the wrong customer is a failure even if it looks semantically perfect.

AWS now documents separate retrieve-only and retrieve-and-generate RAG evaluation jobs. Its metrics include context relevance and coverage for retrieval, then correctness, completeness, helpfulness, faithfulness, citation precision, and citation coverage for generated responses. This is a useful shape for your own test plan even if you do not use Bedrock: separate the search problem from the writing problem.

Evaluate behavior separately

For a fine-tuned or prompted behavior, test the exact contract. Check labels, required fields, refusal or escalation cases, edge cases, and the effect of unusual wording. Compare the baseline and the candidate on the same set. Look for regressions in nearby tasks, not only improvements on the target examples.

The May 2026 industrial RAG and fine-tuning study is a useful reminder that the choice is not only accuracy. Its authors evaluate answer quality and operational costs and report that open-source models can approach premium-model quality when enhanced with RAG in the studied settings. That result is bounded by the paper's datasets and methods; it should inform an experiment, not become a promise for your application.

Count human work and recovery

If a cheaper or more specialized path creates more corrections, retries, manual source checks, or support work, include those costs. If the system cannot explain why it produced an answer or cannot recover after a stale document, the operational price is higher than the token bill.

Write down the pass condition before the comparison. It might be “the assistant identifies the correct policy section and drafts a response with the source attached,” or “the extractor returns all required fields and sends uncertain cases to review.” Avoid vague goals such as “more intelligent” or “more human.” A named outcome creates a testable decision.

When hybrid is worth the complexity

RAG plus fine-tuning is not a compromise that automatically gives you the best of both worlds. It is two systems with two maintenance paths. Use it when you can show two independent needs.

A useful hybrid might look like this:

• RAG retrieves the current policy, product details, or customer record.
• A tuned model extracts the relevant fields into a stable contract.
• Application code validates the fields and checks permissions.
• A human reviews an external commitment or high-impact change.

Another hybrid might use fine-tuning to help a model read domain-specific retrieved documents, especially when the retrieval task is stable and the team has quality training examples. The RAFT research direction is an example of this kind of approach: it trains a model for an open-book setting where retrieved documents include useful and distracting passages. AWS points readers to this research when discussing combined RAG and fine-tuning.

But a paper result is not a production instruction. A hybrid design adds questions: which component owns freshness, which training examples can contain private data, how do you roll back a tuned model, how do you compare the base and tuned model when the retrieval index changes, and how do you keep one customer's data from becoming another customer's behavior? Answer those questions before treating hybrid as the default.

In a multi-tenant B2B product, keep the distinction especially clear. A shared fine-tuned model may capture general behavior or shared vocabulary. Tenant-specific facts and permissions should usually remain in a tenant-scoped retrieval or system-of-record path. Do not bake one customer's private information into a shared model merely because it is technically possible.

A practical thirty-day pilot

You do not need a grand platform decision to learn which path fits. Run a bounded pilot against one job with one owner, one source boundary, and one definition of done.

Days 1–5: define the job and baseline

Write the current workflow in plain language. Name the input, output, source of truth, human correction, and action boundary. Collect representative examples, including the cases that make people say the current process is annoying.

Build the simplest baseline that can answer the question. It may be one model with a clear prompt, a normal database query, or a deterministic workflow with one model step. Save the baseline outputs and corrections. If you skip this, you will not know whether the adaptation helped.

Days 6–12: test the knowledge path

If the task needs business facts, add the smallest approved retrieval path. Start with a source that has clear ownership and manageable permissions. Add metadata that identifies tenant, document, version, effective date, and access scope. Test missing documents, stale versions, duplicate documents, and no-match questions.

Inspect what was retrieved before you judge the final answer. If the right evidence is not present, tune ingestion, chunking, filters, query construction, or ranking. Do not ask the generation model to hallucinate its way around a missing source.

Days 13–19: test the behavior path

If the task needs stable behavior, improve the schema and examples first. Then test a small, controlled fine-tuning experiment only if the baseline still fails in a repeatable way and the team can maintain the data. Keep a held-out set and compare regressions.

Do not include current secrets, unnecessary personal data, or unreviewed customer content in a training file. Decide how examples are removed, how the model is versioned, who can start a training job, and where the resulting model can be used.

Days 20–30: compare end to end

Run the baseline and candidate paths on the same cases. Compare source correctness, output correctness, contract validity, latency, token or service cost, retries, reviewer effort, and recovery behavior. Segment the result by task type and risk. An average can hide the exact class of case the business most needs to get right.

Choose one of four outcomes:

1. Keep the baseline. The added layer did not create enough value.
2. Ship retrieval. The knowledge gap was real and the source path is controllable.
3. Test fine-tuning further. The behavior gap was real, the data is strong, and the contract is stable.
4. Use a hybrid with explicit boundaries. Retrieval and behavior each solved a different measured problem.

Write a stop condition too. Pause the rollout if source permissions are unclear, the team cannot reproduce failures, the candidate path raises the review burden, or the model's behavior improves on the demo cases while regressing on real work. A pilot is successful when it makes the next decision clearer, not when it produces the most elaborate diagram.

A current provider caveat

Model customization options are moving targets. A provider may change which models can be fine-tuned, which training methods are available, how data is retained, what regions are supported, or how a tuned model is deployed. An architecture that assumes a particular provider feature will remain forever is more fragile than it looks.

For example, OpenAI's current pricing page says that its fine-tuning platform is being wound down and describes limited availability for existing users. That is a provider-specific product notice, not a statement that fine-tuning is disappearing everywhere. It is still a useful reminder to verify the current capability, data policy, model lifecycle, and migration path before you make fine-tuning a permanent product dependency.

The portable part of your design should be the task contract, evaluation set, source model, authorization boundary, and recovery plan. Keep provider-specific configuration at the edge where possible. If a model or retrieval service changes, you want to rerun the same job and compare the result—not rediscover what “good” meant.

FAQ

Is RAG better than fine-tuning?

Neither is universally better. RAG is usually a better fit for changing, private, or source-traceable information. Fine-tuning is usually a better fit for a stable behavior, format, or narrow task with good examples. The right choice depends on the failure you can reproduce and the maintenance path your team can operate.

Can fine-tuning add our company's knowledge?

It can influence behavior on domain-specific examples, but it should not be treated as a live, authoritative knowledge base. If facts change, need citations, or differ by customer, use a controlled retrieval or system-of-record path. If you fine-tune, test whether the model learned the desired behavior and whether it remains correct when the source changes.

Do we need a vector database for RAG?

No. Retrieval can use keyword search, database filters, full-text search, semantic search, hybrid search, or a combination. Choose the smallest search system that finds the right source for your job and can enforce scope. A vector database is an implementation option, not the definition of retrieval.

Should we fine-tune before trying RAG?

Usually not when the problem is missing or changing knowledge. First make sure the source is available, correctly scoped, and retrievable. If the right evidence is present but the model still fails a stable behavior contract, then a fine-tuning experiment may be justified.

Does RAG prevent hallucinations?

No. RAG can give a model relevant evidence and a source trail, but it can still retrieve the wrong content, miss a needed passage, misunderstand the context, or produce a claim not supported by the source. Measure retrieval, grounding, abstention, and final answer quality separately.

When should we use both?

Use both when the workload has a current-knowledge problem and a separate repeatable-behavior problem. Keep those responsibilities explicit. Retrieval supplies the evidence, fine-tuning shapes the behavior, and application code still owns validation, authorization, side effects, and recovery.

The practical next step

Pick one repeated B2B workflow and collect the last few examples that humans corrected. For each one, write a single sentence describing the failure: missing source, wrong source, ignored source, invalid format, wrong classification, stale data, or unauthorized action. That list will usually tell you more than a generic debate about RAG versus fine-tuning.

If you need help turning that list into a bounded architecture, BishopTech can help scope the source boundary, task contract, evaluation set, and implementation path before the work expands. The starting point can be a retrieval pilot, a structured workflow, a fine-tuning feasibility test, or a clear decision to postpone.

See the custom software approach or explore automation systems if the next step is an implementation conversation. For a focused recommendation tied to your actual workflow, start a scoped BishopTech consultation.

Return to the My Mind research collection.

Sources and further reading

The links below are dated references used for the claims and framework in this article. Vendor documentation describes vendor capabilities and recommendations; the research paper is limited to its studied settings; public discussions are included as user-signal evidence, not as universal benchmarks or demand data.

1. AWS Prescriptive Guidance — Comparing Retrieval Augmented Generation and fine-tuning ↗ — current guidance accessed August 21, 2026.
2. Google Cloud — Fine-tuning LLMs and AI models ↗ — current guidance accessed August 21, 2026.
3. Google Cloud Documentation — Develop a generative AI application ↗ — current documentation accessed August 21, 2026.
4. Microsoft Learn — Augment LLMs with RAGs or Fine-Tuning ↗ — last updated January 30, 2026.
5. Amazon Bedrock — Evaluate the performance of RAG sources ↗ — current documentation accessed August 21, 2026.
6. Jakob Sturm et al. — Assessment of RAG and Fine-Tuning for Industrial Question-Answering-Applications ↗ — submitted May 10, 2026.
7. OpenAI API Reference — Vector Stores ↗ — current API reference accessed August 21, 2026.
8. OpenAI — API pricing and fine-tuning availability ↗ — current pricing page accessed August 21, 2026.
9. deepset Haystack Discussion #11697 — How are people currently debugging retrieval failures and RAG quality issues? ↗ — June 19, 2026, public practitioner signal.
10. mem0 Discussion #1102 — Learnings from building and running a RAG system in production ↗ — public production discussion with March and April 2026 replies.
11. r/Rag — ChatGPT Fine-Tuning vs RAG: Which Is Better? ↗ — July 28, 2026, public practitioner signal.
12. r/LocalLLaMA — Anyone still doing fine-tunes on consumer grade hardware? ↗ — June 27, 2026, public practitioner signal.
13. Tianjun Zhang et al. — RAFT: Adapting Language Model to Domain Specific RAG ↗ — submitted March 15, 2024; included for the hybrid-method research context.