RAG: pridobivanje podakov iz spomina– pridobivanje pravega konteksta

Apr 23, 2026 | RAG & SLM

VIR

• https://machinelearningmastery.com/ai-agent-memory-explained-in-3-levels-of-difficulty/

BISTVO

• Članek izhaja iz osnovnega dejstva, da je veliki jezikovni model brez trajnega notranjega stanja, zato vsaka API-zahteva začne “od začetka”, kar je dovolj za enkratne naloge, ne pa za več fazne agente.

• Avtorica zato definira problem spomina kot problem, kako stateless sistemu dati občutek trajnega, poizvedljivega znanja o preteklosti, da lahko sledi odločitvam, preferencam, neuspelim poskusom in zbranim dejstvom.

• V drugi ravni članka razloži delovni oziroma in-context spomin, kjer model v trenutnem kontekstnem oknu vidi zgodovino pogovora, rezultate orodij, sistemski poziv in relevantne dokumente.

• Ker kontekstno okno ni neskončno in z dolžino vhodov rasteta strošek ter latenca, članek predstavi zunanji spomin, kjer agent relevantne informacije prikliče iz ločenega sistema šele takrat, ko jih potrebuje.

• Tretja raven članka pokaže, da v praksi ni dovolj samo hraniti podatke, ampak je treba odločiti tudi, kaj shraniti, kdaj zapisati, kako priklicati pravo informacijo, kako obravnavati zastaranje in kako uskladiti več agentov, ki pišejo v isti spominski sistem.

DEJSTVA

• Članek z naslovom “AI Agent Memory Explained in 3 Levels of Difficulty” je napisala Bala Priya C in je bil objavljen 22. aprila 2026 v kategoriji Artificial Intelligence.

• Avtorica članek razdeli na 3 ravni: razumevanje problema spomina, vrste agentnega spomina in arhitekturo spomina pri produkcijski skali.

• Pri delovnem spominu navede, da trenutni modeli podpirajo približno od 128K do 1M tokenov konteksta, vendar stroški in latenca naraščajo z dolžino vhodnega besedila.

• Med glavne tipe agentnega spomina izrecno uvrsti epizodični spomin za dogodke in izide, semantični spomin za dejstva in preference ter proceduralni spomin za uspešne strategije, vzorce delovanja in znane načine odpovedi.

• Za vrednotenje kakovosti spomina predlaga 4 metrike: retrieval recall, retrieval precision, faithfulness in staleness rate, ker lahko sistem napačen priklic izvede tiho in nato iz njega sklepa povsem verjeten, vendar napačen odgovor.

CITATI

• “Every request starts from scratch.” Ta kratek stavek povzema jedrni problem stateless agenta, ki brez dodatnega mehanizma ne ohrani nobene operativne kontinuitete med klici.

• “The memory problem is the problem of giving an inherently stateless system the ability to behave as if it has persistent, queryable knowledge about the past.” To je osrednja definicija članka in najbolj natančen opis, kaj avtorica sploh razume pod agentnim spominom.

• “Memory has to be selective.” Ta stavek poudari, da dobro zasnovan sistem ne zapisuje vsega, ampak samo tisto, kar vpliva na prihodnje vedenje agenta.

• “Memories become stale.” S tem avtorica opozori, da je dolgoročni spomin lahko tudi škodljiv, če agent priklicuje zastarele preference, spremenjene entitete ali opuščene tehnične podatke.

• “Agent memory functions like a stack.” Zaključna metafora članka poveže delovni spomin za trenutno stanje in zunanji priklic za zgodovino ter dejstva v enoten praktični model delovanja.

5 Tehnik za optimiziranje Long-Context RAG

Apr 19, 2026 | RAG & SLM

• Povzetek: članek razloži, da veliki kontekstni okviri pri sodobnih LLM-jih ne odpravijo potrebe po RAG, ampak spremenijo optimizacijo: glavni težavi postaneta izguba pozornosti znotraj dolgega prompta in visoki stroški obdelave.

VIR

• https://machinelearningmastery.com/5-techniques-for-efficient-long-context-rag/

BISTVO

• Članek predstavi 5 tehnik za učinkovitejši long-context RAG: reranking, context caching, dinamično chunkanje z metapodatki, hibridno iskanje in query expansion.

• Osrednja teza je, da milijonski context window še ne pomeni boljše natančnosti, ker model pogosto slabše obravnava informacije na sredini zelo dolgega vhoda.

• Avtor posebej izpostavi problem “Lost in the Middle”, kjer model daje večjo težo začetku in koncu prompta kot sredini.

• Za zmanjšanje stroškov članek priporoča ponovno uporabo že naloženega konteksta prek context caching, namesto da se isti veliki dokument obdeluje pri vsakem vprašanju znova.

• Praktično priporočilo članka je, da sistem ne sme samo dodajati več konteksta, ampak mora aktivno izbirati, razvrščati in umeščati najbolj relevantne informacije.

DEJSTVA

• Članek je objavil Shittu Olumide na MachineLearningMastery dne 15. aprila 2026.

• Klasični starejši kontekstni okviri LLM-jev so po članku tipično obsegali približno 4.000 do 32.000 tokenov.

• Kot primer novih modelov z zelo velikim kontekstom članek navede Gemini Pro in Claude Opus z okni 1 milijon tokenov ali več.

• Pri rerankingu avtor predlaga, da sistem najprej pridobi več kandidatov, na primer top 20, nato pa izbere top 5 za končni prompt.

• Pri inteligentnem chunkanju članek priporoča segmente velikosti približno 500 do 1000 tokenov z dodanimi metapodatki, kot so vir, naslov razdelka, številka strani in povzetki.

CITATI

• “The emergence of million-token context windows does not eliminate the need for retrieval-augmented generation—it reshapes it.”

• “The goal is not simply to provide more context, but to ensure the model consistently focuses on the most relevant information.”

• “Information buried in the middle is significantly more likely to be ignored or misinterpreted.”

• “Long contexts introduce latency and cost overhead.”

• “Hybrid search combines semantic and keyword-based retrieval.”

RAG sistem (lokalni LLM) za 1 TB dokumentov

Mar 27, 2026 | RAG & SLM

VIR: https://en.andros.dev/blog/aa31d744/from-zero-to-a-rag-system-successes-and-failures/

BISTVO (5 ključnih točk)

• Avtor je moral zgraditi interni RAG‑chat za inženirje, ki lokalno uporablja LLM in odgovarja na vprašanja o skoraj desetletju projektne dokumentacije (~1 TB), z velikim poudarkom na OrcaFlex datotekah.

• Prvotni pristop (LlamaIndex + JSON + “kar vse poberi iz Azure folderja”) je sesul RAM in bil neobvladljiv; rešil ga je agresiven filtrirni pipeline po ekstenzijah in tipih datotek ter konverzija v plain text.

• Ključni preklop je bil na ChromaDB kot namensko vektorsko bazo (nad SQLite), z batch obdelavo ~150 datotek naenkrat, checkpointi in možnostjo varnega ponovnega zagona brez izgube napredka.

• Zaradi šibke lokalne GPU je najel VM z NVIDIA RTX 4000 SFF Ada (20 GB VRAM); indeksiranje 451 GB dokumentov je trajalo 2–3 tedne in ustvarilo ~738.000 vektorjev ter 54 GB indeks.

• Končna arhitektura: lokalni LLM prek Ollama (llama3.2:3b), embeddings z nomic‑embed‑text, ChromaDB (HNSW), LlamaIndex kot RAG orkestrator, Flask API + Gunicorn, Streamlit UI, Docker Compose, GPU pospešek in dokumenti servirani direktno iz Azure Blob Storage prek SAS tokenov.

  

DEJSTVA (številke, imena, tehnologije)

• Izvorni podatkovni set: približno 1 TB projektov in tehnične dokumentacije; po filtriranju je indeksiral 451 GB dokumentov.

• Po končanem indeksiranju je imel 738.470 vektorjev in približno 54 GB vektorskega indeksa v ChromaDB (nad SQLite).

• Batch pipeline je obdeloval približno 150 datotek na iteracijo, z eksplicitnimi klici garbage collectorja med batchi.

• Najeta GPU mašina: VM z NVIDIA RTX 4000 SFF Ada (20 GB VRAM), strošek najema pri Hetznerju je bil 184 € za obdobje indeksiranja.

• Tehnološki sklad: Ollama + llama3.2:3b (LLM), nomic‑embed‑text (embeddings), ChromaDB (HNSW), LlamaIndex (RAG), Flask + Gunicorn (API), Streamlit (web UI), Docker Compose (orkestracija), Azure Blob Storage (451 GB dokumentov).

CITATI (ključni poudarki v izvirnem jeziku)

• “A few months ago I was tasked with creating an internal tool for the company’s engineers: a Chat that used a local LLM.”

• “LlamaIndex ended up overflowing my laptop’s RAM within minutes, choking my OS until everything froze.”

• “After many trials and errors, and reading more about it, I decided to make the leap to a dedicated vector database: ChromaDB.”

• “After several weeks, between 2 and 3, the indexing process finished without failures. 738,470 vectors, 54GB of index in ChromaDB, and a RAG system ready to answer questions.”

• “My humble advice, if you’re considering building something similar: spend time building the best possible data. If the source is not relevant enough, the LLM won’t be able to generate good answers.”

Vektorske baze vs RAG , ko potrebuješ natančne relacije, večstopenjsko sklepanja in razložljivost agentovega spomina.

Mar 25, 2026 | RAG & SLM

VIR
https://machinelearningmastery.com/vector-databases-vs-graph-rag-for-agent-memory-when-to-use-which/

BISTVO

• Članek razloži, kako vektorske baze in grafni RAG služita kot arhitekturi dolgoročnega spomina za AI agente in kdaj je smiselno uporabiti katerega.

• Vektorske baze predstavljajo podatke kot vektorje v visoko-dimenzionalnem prostoru in so odlične za semantično iskanje po ne-strukturiranem besedilu (pogovori, dokumentacija, koda).

• Grafni RAG kombinira znanostne grafe in LLM ter modelira svet kot entitete (vozlišča) in relacije (povezave), kar omogoča natančno, večskokovno iskanje in razložljivost.

• Vektorske baze so enostavnejše za uvedbo, a slabše pri kompleksnih relacijah in natančnih poizvedbah; grafni RAG je dražji in kompleksnejši, a boljši za strukturirane podatke in natančne povezave.

• Avtor predlaga hibridno arhitekturo: vektorji za začetno semantično iskanje, nato grafni sprehod za natančen kontekst okoli najdenih entitet.

DEJSTVA

• Članek je objavil Matthew Mayo 5. marca 2026 na portalu MachineLearningMastery v kategoriji “Artificial Intelligence”.

• Vektorske baze uporabljajo vdelave (embeddings) kot goste vektorje realnih števil, kjer razdalja odraža semantično podobnost.

• V grafnem RAG so entitete (npr. oseba, podjetje, tehnologija) predstavljene kot vozlišča, relacije (npr. »dela pri«, »uporablja«) pa kot usmerjene ali neusmerjene povezave.

• Tipični use-case za vektorske baze so pogovorni dnevniki, splošna dokumentacija in široke baze znanja iz surovega besedila.

• Tipični use-case za grafni RAG so finančni zapisi, odvisnosti kode, kompleksni pravni dokumenti, organizacijske strukture in odobritvene verige.

7 majhnih jezikovnih modelov

Mar 25, 2026 | RAG & SLM

VIR

• Top 7 Small Language Models You Can Run on a Laptop

BISTVO

• Članek opisuje 7 SLM modelov, ki delujejo na potrošniški strojni opremi in so razvrščeni po primernosti za konkretne use-case scenarije, ne po benchmarkih.

• Glavne osi izbire so: dolgi kontekst (Phi‑3.5 Mini), splošna vsestranskost (Llama 3.2 3B), ekstremna učinkovitost za rob/telefon (Llama 3.2 1B), večja moč ob še sprejemljivi velikosti (Ministral 3 8B, Gemma 2 9B) ter specializacija za kodo (Qwen 2.5 7B) in prototipiranje (SmolLM2 1.7B).

• Avtor poudari, da se posamezne uteži, kontekstni limiti in izdaje modelov hitro spreminjajo, zato priporoča, da bralec konkretne variante preveri na model cardih oz. straneh v Ollami.

• Vsi opisani modeli so na voljo za lokalni prenos prek Hugging Face ali Ollama, pri čemer morata uporabnik za nekatere družine (Llama, Gemma) sprejeti licenčne pogoje in se včasih avtenticirati.

• Zaključna poanta: vstopni prag za lokalni pogon AI je nizek; izberite eno družino modelov glede na svoj primer uporabe, jo preizkusite na lastnih podatkih in nato iterirajte.

DEJSTVA

• Phi‑3.5 Mini (Microsoft) ima približno 3,8B parametrov, v 4‑bit kvantizaciji potrebuje približno 6–10 GB RAM, v 16‑bit natančnosti pa približno 16 GB RAM.

• Llama 3.2 3B (Meta) podpira vsaj 8 jezikov (angleščina, nemščina, francoščina, italijanščina, portugalščina, hindijščina, španščina, tajščina), v 4‑bit načinu potrebuje približno 6 GB RAM.

• Llama 3.2 1B lahko v 4‑bit kvantizaciji deluje v približno 2–4 GB RAM in je primerna tudi za višji razred pametnih telefonov in IoT naprave.

• Ministral 3 8B (Mistral AI) cilja na robne namestitve; v 4‑bit kvantizaciji potrebuje približno 10 GB RAM, v 16‑bit pa okrog 20 GB RAM, priporočeno je vsaj 16 GB RAM.

• Gemma 2 9B (Google) v 4‑bit kvantizaciji potrebuje približno 12 GB RAM, v 16‑bit okoli 24 GB RAM, priporočilo je 16+ GB RAM za resnejšo uporabo.

CITATI

• »Powerful AI now runs on consumer hardware. The models covered here work on standard laptops and deliver production-grade results for specialized tasks.«

• »Microsoft’s Phi-3.5 Mini is a top choice for developers building retrieval-augmented generation (RAG) systems on local hardware.«

• »Meta’s Llama 3.2 3B is the all-rounder. It handles general instruction-following well, fine-tunes easily, and runs fast enough for interactive applications.«

• »Alibaba’s Qwen 2.5 7B dominates coding and mathematical reasoning benchmarks.«

• »Hugging Face’s SmolLM2 is one of the smallest models here, designed for rapid experimentation and learning.«

SLM (mali jezikovni modeli) pokrijejo ~80% produkcijskih primerov z do 95% nižjimi stroški kot veliki modeli (LLM )

Mar 25, 2026 | RAG & SLM

VIR: https://machinelearningmastery.com/introduction-to-small-language-models-the-complete-guide-for-2026/

BISTVO:

• Majhni jezikovni modeli (SLM, do ~10B parametrov) zadoščajo za večino tipičnih produkcijskih nalog (chatboti, support, dokumenti) pri bistveno nižjih stroških in latencah.

• Ključne prednosti SLM-ov so nižji stroški (lokalni GPU namesto API), manjša latenca (50–200 ms lokalno) in boljša zasebnost (on‑prem, brez pošiljanja podatkov v oblak).

• Sodobni SLM-i (Phi-3 Mini, Llama 3.2 3B, Mistral 7B) z dobro dodelavo dosegajo zmogljivost, primerljivo z bistveno večjimi modeli na ozko usmerjenih domenah.

• Priporočeni pristop v praksi je hibrid: SLM rešuje ~80% ponavljajočih se, predvidljivih poizvedb, zahtevnih ~20% se preusmeri na velik LLM prek “router” vzorca.

• Za začetek avtor priporoča: lokalni preizkus (Ollama + Llama/Phi), identifikacijo ponovljivih use‑caseov, fine‑tuning na 500–1000 primerih in lokalno/on‑prem namestitev.

• Zasebnost: Regulirani sektorji (zdravstvo, finance, pravni sektor) ne smejo pošiljati občutljivih podatkov zunanjim API-jem.
  SLM-i omogočajo tem organizacijam uporabo AI-ja ob hkratnem ohranjanju podatkov na lastnih strežnikih. Brez klicev zunanjih API-jev podatki ne zapustijo vaše infrastrukture.

• LLM so zasnovani za širino in nepredvidljivost, medtem ko so SLM zgrajeni za globino in ponavljanje. Če vaša naloga zahteva obravnavo kakršnegakoli vprašanja o kateri koli temi, potrebujete široko znanje LLM. Vendar pa, če rešujete isti tip problema na tisoče krat, bo SLM, ki je fino prilagojen za to specifično področje, hitrejši, cenejši in pogosto bolj natančen.

DEJSTVA:

• Članek je objavljen 24. februarja 2026, avtor je Vinod Chugani na portalu Machine Learning Mastery.

• SLM je definiran kot model z manj kot 10 milijardami parametrov, tipično med 1B in 7B.

• Phi‑3 Mini ima približno 3,8B parametrov, Llama 3.2 3B ima 3B parametrov, Mistral 7B pa 7B parametrov.

• Kvantizacija 7B modela iz 16‑bit (≈14 GB) v 4‑bit zmanjša pomnilniški odtis na približno 3,5 GB, ob ohranitvi ~95% kvalitete.

• Veliki modeli, kot je GPT‑4, imajo več kot 1 bilijon parametrov, Claude Opus ima stotine milijard parametrov, Llama 3.1 70B se še vedno šteje kot “velik”.

Kako SLM-ji Dosežejo Svojo Prednost 

SLM-ji niso zgolj »majhni LLM-ji«. Uporabljajo specifične tehnike za zagotavljanje visoke zmogljivosti pri nizkem številu parametrov.

Distilacija Znanja:
trenira manjše »študente« modele, da posnemajo večje »učiteljske« modele. Študent se nauči ponoviti izhod učitelja, ne da bi potreboval enako veliko arhitekturo. Microsoftova serija Phi-3 je bila stisnjena iz veliko večjih modelov, pri čemer je ohranila več kot 90 % zmogljivosti pri 5 % velikosti.

Visokokakovostni Trening:
Podatki so pomembnejši za SLM-je kot sama količina podatkov. Medtem ko so LLM-ji trenirani na bilijonih tokenov z interneta, SLM-ji koristijo kurirane, visokokakovostne podatkovne zbirke. Phi-3 je bil treniran na »učbenik kakovostnih« sintetičnih podatkih, skrbno filtriranih za odstranitev šuma in odvečnosti.

Kvantizacija stisne uteži modela iz 16-bitnih ali 32-bitnih plavajočih vejic v 4-bitne ali 8-bitne cela števila. Model s 7 milijardami parametrov v 16-bitni natančnosti zahteva 14 GB pomnilnika. Kvantiziran na 4-bitni način, se prilega v 3,5 GB (dovolj majhen za zagon na prenosniku). Sodobne kvantizacijske tehnike, kot je GGUF, ohranijo več kot 95 % kakovosti modela ob doseganju 75 % zmanjšanja velikosti.

Arhitekturne Optimizacije, kot je redka pozornost, zmanjšujejo računsko obremenitev. Namesto da bi vsak token pozornosti namenil vsakemu drugemu tokenu, modeli uporabljajo tehnike kot so pozornost z drsnim oknom ali skupinska pozornost po poizvedbah, da osredotočijo izračune tam, kjer so najbolj pomembni.