Tämä sarja näyttää, miten RAG syntyi, miten se toimii konepellin alla ja miten tuotantojärjestelmiä rakennetaan. Semanttisesta hausta tekoälyyn perustuvaksi Q&A:ksi, jossa on lainauksia – kaikki joissa on toimivia C#-koodiesimerkkejä.
Sarjan navigaatio: Tämä on Reggion (Retroval-Augmented Generation) -sarjan 1 osa:
RAG (Retrieval-Augmented Generation) kehitettiin tekemään tekoälystä älykkäämpi, jotta LLM:t saisivat käyttöönsä tietoja, joita he eivät ole kouluttaneet. Mutta tässä on mielenkiintoista: teknologia avaa mahdollisuuksia paljon pidemmälle kuin tekoälyn chatbotit. Se mahdollistaa semanttisen haun nettisivuilta, sisältösuosituksista, kirjoitusavusta ja tiedonhallinnasta.
Kaksoisluonne: RAG voi auttaa asiakkaita (parempi haku, tarkat vastaukset lainausmerkeillä) tai käyttää heitä hyväkseen (manipulatiiviset suositukset, negatiivisen arvostelun hautaaminen, ylennyksen paljastaminen). Ero ei ole teknologiassa – sen tarkoitus. Semanttinen haku, joka auttaa käyttäjiä löytämään sen, mitä he todellisuudessa tarvitsevat? Hieno. Se, joka priorisoi sen, mikä tekee sinusta eniten rahaa, kun vaikutat hyödylliseltä? Se on synkkä kuvioalue, ja siksi sen ymmärtäminen, miten tämä toimii, on tärkeää.
Tässä totuus RAG:stä: Se kuulostaa pelottavalta. Vektori upottaa muuntautumismalleja, KV-kätköjä? Mutta kuten kaikki muukin ohjelmistossa, kyse on vain sen toiminnan ymmärtämisestä. Sinun ei tarvitse tuntea muuntajien arkkitehtuurien takana olevaa matematiikkaa sen enempää kuin sinun tarvitsee ymmärtää kokoonpanoa kirjoittaaksesi C#:n.
RAG kolmessa vaiheessa:
Loppu on toteutusta koskevia yksityiskohtia.
Tämä sarja näyttää, miten RAG-järjestelmät rakennetaan toimivalla C#-koodilla. Ei käsien heiluttelua. Ei olettamuksia. Vain kappaleet ja niiden sopivuus yhteen.
Mitä opitte tässä sarjassa:
Näytän myöhemmin myös, miten kokonaisia RAG-järjestelmiä rakennetaan, mukaan lukien:
Hakijasukupolvi: Etsi merkityksellisiä tietoja ja käytä niitä.
flowchart LR
A[User Question] --> B[Retrieve Relevant Info]
B --> C[Retrieved Documents/Context]
C --> D[Generate Response]
A --> D
D --> E[Grounded, Accurate Answer]
style B stroke:#f9f,stroke-width:2px
style D stroke:#bbf,stroke-width:2px
Ilman aluetukia: Käyttäjä kysyy → LLM-arvauksia muistista → saattaa hallusinoida
RAG:n kanssa: Käyttäjä kysyy → Etsi relevantteja dokumentteja → LLM-vastauksia käyttämällä näitä dokumentteja → ground in reality
// Without RAG: Hope the LLM knows
var answer = await llm.GenerateAsync("How do I deploy Docker?");
// Risk: Might make up outdated or wrong steps
// With RAG: Give it the docs
var relevantDocs = await vectorSearch.FindSimilar("How do I deploy Docker?");
var context = string.Join("\n", relevantDocs.Select(d => d.Text));
var answer = await llm.GenerateAsync($"Context: {context}\n\nQuestion: How do I deploy Docker?");
// Result: Answer based on YOUR actual Docker deployment docs
Avainymmärrys: Erillinen tietovarasto (haku) päättelystä (LLM). Päivitä dokumentit, haku pysyy nykyisellään. Uudelleenkoulutusta ei tarvita.
RAG perustuu vuosikymmeniä kestäneeseen haku- ja NLP-tutkimukseen. Historian ymmärtäminen auttaa ymmärtämään, miksi RAG on suunniteltu sellaiseksi kuin se on - ja millaisia ongelmia se ratkaisee.
Avainsanahaku:
Ongelma: Nämä sopivat yhteen hahmot, ei merkitys. Etsi "kontti orkestraatio" ja et löydä "Docker Swarmia", jos nuo tarkat sanat eivät tule näkyviin. He voivat käsitellä kirjoitusvirheitä, mutta eivät semantiikkaa.
Watson (IBM, 2011):
Lukemismallit:
Transformers (2017): "Huomio on kaikki mitä tarvitset"
BERT (2018):
GPT-2/3 (2019-2020):
Ankkurivektorin kuvaukset:
BART (Facebook AI, lokakuu 2019):
M2M-100 (Facebook AI, lokakuu 2020):
Oikean maailman esimerkki: Minun Neural Machine Translation Tool BARTia käytetään varakäännösmallina silloin, kun peruspalveluja ei ole saatavilla, mikä osoittaa, kuinka näistä muuntajapohjaisista malleista tuli käytännön rakennuspalikoita tuotantojärjestelmille.
Seminaalipaperi "Hakijasukupolvea osaamisintensiivisille NLP-tehtäville"Patrick Lewis et al. (Facebook AI Research) esitteli virallisesti RAG:n, joka perustuu suoraan BART:iin:
Se, mitä he yhdistivät:
Tulokset: RAG-järjestelmät ylittivät paljon suuremmat mallit osaamisvaltaisissa tehtävissä ja olivat samalla tehokkaampia ja ajan tasalla. Osaamispohjaa voisi päivittää ilman mallin uudelleenarviointia.
ChatGPT, GPT-4 ja Claude tekivät RAGista olennaisen:
Tänään (2024-2025): RAG on tarkkuutta ja auditifioitavuutta tarvitsevien tuotannon tekoälyjärjestelmien tosiasiallinen standardi. Jokainen suuri tekoälyyritys tarjoaa RAG-työkaluja.
Ennen kuin sukellamme syvälle teknisiin yksityiskohtiin (joita käsittelemme osassa 2), ymmärretään korkeatasoista työnkulkua.
RAG-järjestelmät toimivat kolmessa eri vaiheessa:
flowchart LR
A[Your Documents] --> B[Split into Chunks]
B --> C[Generate Embeddings]
C --> D[Store in Vector DB]
style C stroke:#f9f,stroke-width:2px
style D stroke:#bbf,stroke-width:2px
Mitä tapahtuu:
Avainkäsite: Samanlaiset merkitykset tuottavat samanlaisia vektoreja, joten "Docker container" ja "containerization platform" päätyvät lähelle toisiaan vektoriavaruudessa.
flowchart LR
A[User Question] --> B[Generate Query Embedding]
B --> C[Search Vector DB]
C --> D[Top K Most Similar Chunks]
style B stroke:#f9f,stroke-width:2px
style C stroke:#bbf,stroke-width:2px
Mitä tapahtuu:
Miksi se toimii: "Miten otan kontit käyttöön?" (query) on semanttisesti samanlainen kuin Dockerin sijoittamisesta kertovat kappaleet, vaikka sanat eroavatkin toisistaan.
flowchart TB
A[User Question] --> B[Build Prompt]
C[Retrieved Context] --> B
B --> D[LLM]
D --> E[Generated Answer with Citations]
style B stroke:#f9f,stroke-width:2px
style D stroke:#bbf,stroke-width:2px
Mitä tapahtuu:
Taikuus: LLM ei voi hallusinoida asioita, jotka eivät ole yhteydessä. Se voi vain syntetisoida ja selittää, mitä on tarjolla.
Jäljitetään kysely järjestelmän kautta:
Käyttäjä kysyy: "Miten käytän Docker Composea?"
Vaihe 1 - Nouto:
Query embedding: [0.234, -0.891, 0.567, ...]
Search vector DB for similar embeddings...
Retrieved chunks:
1. "Docker Compose is a tool for defining multi-container applications..." (similarity: 0.92)
2. "To use Docker Compose, create a docker-compose.yml file..." (similarity: 0.87)
3. "The docker-compose up command starts all services..." (similarity: 0.83)
Vaihe 2 - Sukupolvi:
Prompt to LLM:
"Context:
[1] Docker Compose is a tool for defining multi-container applications...
[2] To use Docker Compose, create a docker-compose.yml file...
[3] The docker-compose up command starts all services...
Question: How do I use Docker Compose?
Answer (use the context above):"
LLM Response:
"To use Docker Compose [1], start by creating a docker-compose.yml file [2] that
defines your services. Then run 'docker-compose up' to start all services [3]..."
Tulos: Tarkka vastaus implisiittisillä viittauksilla asiakirjoihinne.
Se, milloin RAG:tä (ja milloin ei) käytetään, edellyttää sen vertaamista vaihtoehtoihin.
TARKOITUS LAAJENTUMISEKSI |--------|-----|-------------| | Tietopäivityksiä Välitön (päivität vain tietopohjan) Vaatii uudelleenkoulutusta | Kustannukset Alhainen (varastointi + upotus) Korkea (koulutusaika GPU) | Tarkkuus Maaperällä olevat lähteet voivat hallusinoida | Räätälöinti Rajoitettu haku Deep-malliin sopeutumiseen | Selittävyys Korkea (voin mainita lähteet) Alhainen (musta laatikko) | Paras Osaamisintensiiviset tehtävät Tyyliin/muotoon sopeutuminen
Milloin Fine-Tuningia käytetään:
Milloin RAG:tä käytetään:
Voitko yhdistää molemmat? Hienostunut tyyliin, RAG faktoihin.
Modernit LLM:t ylpeilevät valtavilla kontekstiikkunoilla (GPT-4: 128K, Claude: 200K). Miksei vain kaada kaikkia asiakirjoja kontekstiin?
Pitkän kontekstin ongelmat:
Kun pitkässä kontekstissa on järkeä:
Kun RAG:ssä on järkeä:
Parhaita käytäntöjä: Käytä RAG:tä valitaksesi olennaisimman sisällön, ja käytä sen jälkeen pitkää kontekstia kyseiselle alaryhmälle.
Harvasanainen yllytys (esimerkkinä nopeassa) on yksinkertainen lähtökohta.
Esimerkki:
Examples:
Q: What is Docker?
A: Docker is a containerization platform...
Q: How does Kubernetes work?
A: Kubernetes orchestrates containers...
Q: What is my new question?
A: [LLM generates answer]
Rajoitukset:
Aluekehitys:
Voit ajatella RAG:tä "automatisoituna muutaman laukauksen ärsykkeenä mittakaavassa".
Voit yhdistää RAG:n perinteiseen täystekstihakuun Reciprocal Rank Fusion (RRF) -sovelluksella.
Miksi hybridi?
public async Task<List<SearchResult>> HybridSearchAsync(string query)
{
// Run both searches in parallel
var semanticTask = SemanticSearchAsync(query, limit: 20);
var keywordTask = KeywordSearchAsync(query, limit: 20);
await Task.WhenAll(semanticTask, keywordTask);
var semanticResults = await semanticTask;
var keywordResults = await keywordTask;
// Combine using Reciprocal Rank Fusion
return ApplyRRF(semanticResults, keywordResults);
}
private List<SearchResult> ApplyRRF(
List<SearchResult> list1,
List<SearchResult> list2,
int k = 60)
{
var scores = new Dictionary<string, double>();
// Score from first list
for (int i = 0; i < list1.Count; i++)
{
var id = list1[i].Id;
scores[id] = scores.GetValueOrDefault(id, 0) + 1.0 / (k + i + 1);
}
// Score from second list
for (int i = 0; i < list2.Count; i++)
{
var id = list2[i].Id;
scores[id] = scores.GetValueOrDefault(id, 0) + 1.0 / (k + i + 1);
}
// Merge and sort by combined score
var allResults = list1.Concat(list2)
.GroupBy(r => r.Id)
.Select(g => g.First())
.OrderByDescending(r => scores[r.Id])
.ToList();
return allResults;
}
Nyt kun ymmärrät, mikä RAG on, mistä se on peräisin ja miten sitä verrataan vaihtoehtoihin, niin miksi sillä on merkitystä:
1. tekoälyn demokratisointi
2. Käytännöllinen tarkkuus
3. Aina ajan tasalla
4. Yksityisyys ja valvonta
5. Kustannus-hyötysuhde
6. Monipuoliset sovellukset
Olemme jäljittäneet RAG:n evoluution:
Osa 1: Tärkeimmät näkemykset:
Kolmivaiheinen henkinen malli:
Kaikki muu on optimointia.
Ymmärrät nyt mitä RAG on, miksi sillä on merkitystä, ja jossa Mutta miten se oikeasti toimii konepellin alla?
Sisään **Osa 2: Arkkitehtuuri ja sisätilat**Sukellamme syvälle teknisiin yksityiskohtiin:
Täydellinen RAG-putki:
LLM-sisätilat:
Tekniset syväsukellukset:
Jatka osaan 2: Arkkitehtuuri ja sisätilat →
Osan 2 jälkeen olet valmis 3. osaan, jossa rakennamme todellisia järjestelmiä, ratkaisemme yhteisiä haasteita ja tutkimme kehittyneitä tekniikoita, kuten HyDE:tä, monivalintaista RAG:tä ja kontekstimaista pakkausta.
Peruskirjat:
Lue lisää:
Seuraava tässä sarjassa:
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.