Türkçe altyazı Turkish subtitles
0:00 LLM'ler, yani büyük dil modelleri hakkında temel bir gerçek var: Zaman içinde donmuş durumdalar. Eğitim kesim tarihine kadar dünyamız hakkında her şeyi bilirler, ancak 5 dakika önce ne olduğunu kesinlikle bilmezler. Ayrıca sizin özel verilerinizi, iç wiki'lerinizi ya da veri tabanınızı bilmezler. Eğer bir LLM'in bu bilgileri bilmesini istiyorsak, bağlam enjeksiyonu sorununu çözmemiz gerekir. Doğru veriyi doğru zamanda modele nasıl getiririz? Bu konuda iki birbirinden farklı yaklaşım vardır. İlk yaklaşım, mühendislik yaklaşımı olarak adlandırabiliriz: RAG, retrieval augmented generation. There's a fundamental truth about LLMs, large language models. They are frozen in time. They know everything about our world up until their training cutoff date and absolutely 0:16 Burada bir LLM ve kullanıcıdan gelen bir giriş istemi var. Önceden, bu LLM'e vermek istediğimiz bazı belgeleri alıyoruz; bunlar PDF'ler, kod dosyaları ya da bütün kitaplar olabilir ve onları parçalara bölüyoruz. Bu parçalar bir embedding modeline gönderilir, model bu parçaları vektörlere dönüştürür ve bu vektörler özel bir vektör veritabanında saklanır. Kullanıcı bir soru sorduğunda, model en ilgili parçaları bulmak için semantik arama yapar ve bunları bağlam penceresine ekler. Böylece bağlam penceresi kullanıcı istemini ve vektör veritabanından aldığımız tüm parçaları içerir. Bu yöntem çalışır, ancak bir şeye dayanır: retrieval mantığınızın vektör veritabanında doğru bilgiyi bulmuş olması umuduna. nothing about what happened 5 minutes ago. Nor do they know anything about your private data, your internal wikis, your proprietary codebase. And if we do want an LLM to know any of that stuff, well, we have to solve the problem of context injection. How do we get the right data into the 0:36 İkinci yaklaşım biraz daha kaba kuvvetli bir yöntemdir ve buna uzun bağlam denir. Bu gerçekten modelin doğal çözümüdür çünkü burada veritabanını ve embedding modelini atlayabilirsiniz. Tek yapmanız gereken belgelerinizi doğrudan bağlam penceresine koymak ve modelin attention mekanizmasının cevabı bulması için işi halletmesine izin vermektir. Uzun bir süre boyunca bu tür kaba kuvvetli yöntem pek bir seçenek değildi çünkü bağlam pencereleri çok küçüktü. Erken LLM'lerin bağlam penceresi sadece yaklaşık 4K token tutabiliyordu. Oraya bir roman sığdıramazdınız, kurumsal bilgi tabanını bile. Temelde RAG kullanmanız gerekiyordu. Ancak günümüz modellerinin bağlam pencereleri çok daha büyük. Bazıları bir milyondan fazla token tutabiliyor; bu da yaklaşık 700,000 kelime demek. Bu kapasiteyle Lord of the Rings serisini ve hâlâ The Hobbit için yer bırakabilirsiniz. model at the right time? And there have been two very different ways to handle this. Now, the first is really what we can think of as the engineering approach. It's RAG, retrieval augmented generation. 0:52 Bu büyük kapasite artışı, mimarimiz hakkında zor bir soru sormamıza neden oluyor. Tüm belgelerimizi modelin bağlam penceresine koyabilirsek, embedding modelleri ve vektör veri depolarının ek yüküne gerçekten ihtiyacımız var mı? RAG gereksiz bir karmaşıklık katmanı mı haline geliyor? Eğer ihtiyacımız olan tüm veriyi bağlam penceresine sığdırabileceğimizi kabul edersek, bu kararın temel nedeni tek bir kelime: sadelik. Şimdi bağlam penceresini doğrudan doldurmanın üç nedeni var. So here we've got an LLM and we've also got an input prompt from the user. Now ahead of time we take some of the documents that we want to give to this LLM. So these are documents that could be 1:09 Birinci neden, altyapıyı sadeleştirmektir. Üretim ortamındaki bir RAG sistemi oldukça ağırdır; sabit boyutlu, kayar pencere ya da özyinelemeli bir chunking stratejisi gerekir. Veriyi kodlamak için bir embedding modeline, saklamak için bir vektör veritabanına, sonuçları sıralamak için bir rerankere ve tüm vektörleri kaynak verinizle senkronize tutmaya ihtiyacınız vardır. Bu birçok hareketli parçayı ve hataya açık noktaları içerir. Uzun bağlam ise "yığın yok" yaklaşımını sunar: veritabanını, embeddingleri ve retrieval mantığını kaldırırsınız. Mimari sadece veriyi alıp modele göndermekle sadeleşir. PDFs or code files or entire books and we chunk them. We break them up into smaller chunks and we pass them through to an embedding model and the embedding model takes those chunks and it 1:27 İkinci neden, retrieval şans oyunudur. RAG burada kritik bir başarısızlık noktası yaratır: retrieval adımı. Kullanıcı soru sorduğunda, RAG verinin matematiksel temsillerine (vektörlere) bakar ve en yakın eşleşmeyi bulmaya çalışır; bu semantik aramadır. Ancak semantik arama olasılıklıdır ve çeşitli nedenlerle ilgili belgeyi bulamayabilir. Bu duruma "sessiz başarısızlık" denir; cevap veride mevcutken LLM onu görmez çünkü retrieval doğru sonuçları döndürmemiştir. Uzun bağlamda ise retrieval adımı yoktur; model her şeyi görür. turns them into vectors and those vectors are then stored in a dedicated vector database. Now when a user asks a question, it performs a semantic search to retrieve the most relevant chunks 1:47 Üçüncü neden, "bütün kitap problemi" olarak adlandırabiliriz. RAG temelde mevcut olanı geri getirmek için tasarlanmıştır; sorgunuzla veritabanınızdaki belirli bir metin parçacığı arasında semantik eşleşme bulmaya dayanır. Ancak cevap veritabanında olmayan bir yerdeyse ne olur? Örneğin, ürün gereksinimleri ve sürüm notları ayrı belgelerde saklanıyor ve son sürümde hangi güvenlik gereksinimlerinin eksik olduğunu soruyoruz. RAG, "güvenlik" ve "gereksinimler" içeren parçaları arar, gereksinim belgesinden ve sürüm notlarından snippet'ler getirir, ancak aralarındaki boşluğu bulamaz. RAG modeli sadece birkaç izole snapshot ile gösterir, bu yüzden model eksik parçaları göremez. Uzun bağlam ise tüm gereksinim belgesini ve sürüm notlarını bağlam penceresine dökerek tam karşılaştırmayı yapar. RAG ölmüş mü? Vektör veritabanı 2024'te ihtiyaç duyduğumuz şeylerin müzesine mi? Pek de değil; uzun bağlam sadelikte öne çıkarken, RAG hâlâ bir yeri var ve bunu destekleyen üç neden daha var. and then inject them into the context window. So now the context window has the user prompt, but it also has all of these chunks that we have taken from the vector database and together this 2:03 Birinci neden, metni yeniden okuma problemidir. Uzun bağlam büyük bir hesaplama verimsizliği yaratır. Örneğin 500 sayfalık bir kılavuzu tokenlara dönüştürmek yaklaşık 250k token demektir ve her kullanıcı sorgusunda bu belgeyi prompta koymanız gerekir; modelin bu kılavuzu her seferinde işlemesi gerekir. RAG da aynı belgeyi işler, ancak bu işlem maliyetini sadece indeksleme zamanında öder. Prompt caching statik verilerde bir kısmını azaltabilir, ancak içerik sıkça değişen dinamik veri akışlarında her istekte tam maliyeti ödersiniz. forms the context window. Now this works but it does rely on something. It relies on the hope that your retrieval logic actually found the right information in the vector database. Now the the second approach is really a bit more of a brute force approach and that one is called 2:23 İkinci neden, samanlıkta iğne problemidir. Bağlam penceresinde veri varsa modelin onu kullanacağı varsayımı vardır, ancak araştırmalar bunun aksi olduğunu gösteriyor. Bağlam penceresi büyüdükçe (örneğin 500,000 token), modelin attention mekanizması seyrelebilir. 2,000 sayfalık bir belgenin ortasındaki tek bir paragraf hakkında spesifik soru sorarsanız, model genellikle onu bulamaz veya çevresindeki metinden detaylar hayal eder. RAG ise modele daha az gürültü verir; sadece en ilgili beş parçayı getirerek samanlığı kaldırır ve modeli sadece iğnelere odaklar. Model sinyale, gürültüye değil, odaklanır. long context. Now this is really the model native solution because you skip the database here and you skip the embedding model. All you do is you take your documents and you just well you put them 2:38 Üçüncü neden, sonsuz veri seti problemidir. Milyonlarca tokenluk bir bağlam penceresi harika görünse de, kurumsal veri ölçeğinde bu sadece bir damla su demektir; bir veri gölü terabaytlarca ya da petabaytlarca ölçülür. Her şeyi saklayan sonsuz bir veri seti istiyorsanız, LLM bağlam penceresine sığacak bilgiye filtrelemek için bir retrieval katmanına ihtiyacınız vardır. straight into the context window and then you let the model's attention mechanism actually do the heavy lifting of finding the answer. Now for a long time this kind of brute force method wasn't really much of an option because initially context windows were tiny. Early LLMs had context windows 2:58 Peki bu bizi nereye götürüyor? Eğer probleminiz sınırlı bir veri seti içeriyor ve belirli bir hukuki sözleşmeyi analiz etmek ya da bir kitabı özetlemek gibi karmaşık küresel akıl yürütme gerektiriyorsa, uzun bağlam en iyi yoldur; yığını sadeleştirir ve akıl yürütmeyi iyileştirir. Ancak kurumsal bilgi gibi sonsuz veri setlerinde geziniyorsanız, vektör veritabanı hâlazır tek geçerli depodur. Peki ya siz? Uzun bağlam takımı mı, RAG takımı mı, yoksa ikisinin bir karışımı mı? Yorumlarda bana bildirin. that could maybe store what like 4K of tokens. You couldn't fit a novel in there, let alone a corporate knowledge base. You basically had to use RAG. But today's models have much larger context 3:14 Windows. Bazılarının bir milyonun üzerinde tokeni var, biliyorsunuz. Bunu perspektif içine koyacak olursak, bir milyon token yaklaşık 700.000 kelimeye eşittir ve tüm Yüzüklerin Efendisi serisini prompta sığdırıp hâlâ The Hobbit için yer kalır. windows. Some of them have, you know, a million tokens plus. And to put that into perspective, a million tokens is roughly 700,000 words. and you could fit the entire Lord of the Rings series into 3:29 Bu büyük kapasite artışı, mimarimiz hakkında zor bir soru sormamıza neden oluyor. Çünkü tüm belgelerimizi modelin bağlam penceresine doğrudan komutlayabilirsek, gerçekten gömme modelleri ve vektör veri depolarının ek yüküne ihtiyacımız var mı? RAG gereksiz bir karmaşıklık katmanı mı oluyor? the prompt and still have room for The Hobbit. So, this massive jump in capacity forces us to ask a difficult question about our architecture. Because if we can simply command A, command C, command V, 3:43 Eğer ihtiyacımız olan tüm veriyi bağlam penceresine sığdırabileceğimizi kabul edersek, bunu yapma argümanı temelde tek bir kelimeye indirgenir: sadelik. Ve size bağlam penceresini doğrudan doldurmanın neden doğru bir yol olabileceğine dair üç neden vereyim. all of our documentation into the models context window, do we really need the overhead of embedding models and vector data stores? Is RAG becoming an unnecessary complexity layer? Well, 3:56 Birinci neden, altyapıyı çökertmek. Bir üretim RAG sistemi oldukça ağırdır. Sabit boyutlu, kayan pencere ya da özyinelemeli bir parçalama stratejisine ihtiyacınız var. Siz karar verirsiniz. if we accept that we can fit whatever data we need into the context window, then the argument for doing so basically boils down to one word, simplicity. And let me give you three reasons why 4:11 Veriyi kodlamak için bir embedding modeline ihtiyacınız var. Bunu depolamak için bir vektör veritabanına ihtiyacınız var. Sonuçları sıralamak için bir reranker'a ihtiyacınız var. Tüm vektörleri kaynak verinizle senkronize tutmanız gerekir. stuffing the context window directly may indeed be the way to go. And reason number one is collapsing the infrastructure. A production RAG system. Well, it is quite heavy. You need a a chunking strategy 4:27 Temelde birçok hareketli parça ve kırılma noktası vardır. Uzun bağlam, basitçe 'yığın yok' dediğimiz şeyi sunar. which is like fixed size maybe or sliding window or recursive. You decide. You're going to need a embedding model to encode the data. You need a a vector database to store it. You're going to need a reranker to sort the results. you need to keep all the vectors in sync with your source 4:45 Veritabanını kaldırırsınız, embeddingleri kaldırırsınız, retrieval mantığını kaldırırsınız. Mimariniz sadece veriyi alıp modele göndermekle sadeleşir. data. It's basically a lot of moving parts, a lot of places for things to break. And long context offers what we might call well just simply the uh the no stack stack. You remove the database, you 5:01 Bu birinci neden. İkinci neden, retrieval loterisi. remove the embeddings, you remove the retrieval logic. The architecture simplifies down to getting the data and just well sending it to the model. So that's reason number one. Reason number two is the 5:15 Şimdi, RAG burada kritik bir başarısızlık noktası tanıtır: retrieval adımı. Bir kullanıcı soru sorduğunda, RAG verinin matematiksel temsillerine bakar ve bunlar vektörlerde depolanır. retrieval lottery. Now, RAG introduces a critical point of failure here, the retrieval step itself, because when a user asks a question, RAG looks at mathematical representations of the data, which are 5:30 Vektörler temelde bir dizi içinde çok uzun bir sayı serisidir. En yakın eşleşmeyi bulmaya çalışır; bu semantik aramadır. stored in vectors. And vectors are basically just like a really long series of numbers in an array. And it tries to find the closest match. That's semantic search. But semantic search is probabilistic and for all manner of reasons, the retrieval might fail to find the 5:49 Ancak semantik arama olasılıksaldır ve çeşitli nedenlerle retrieval ilgili belgeyi bulamayabilir. Bunun bir adı vardır: sessiz başarısızlık. relevant document. And we actually have a name for this. It's called silent failure. The answer, well, it existed in the data, but the LLM never saw it because the retrieval step didn't return the right results. With long context, there is no retrieval step. The model gets to see everything. 6:08 Cevap veride vardı, ancak LLM onu hiç görmedi çünkü retrieval adımı doğru sonuçları döndürmedi. Uzun bağlamda retrieval adımı yoktur; model her şeyi görür. Now, reason number three that is well, I think we're going to call this the whole book problem. A RAG is fundamentally designed to retrieve what exists. It relies on finding a semantic 6:21 Şimdi, üçüncü neden; bunu 'tam kitap sorunu' olarak adlandıracağız. match between your query and a specific snippet of text in your database. But what if the answer lies in what's not in the database? So, so let's say you have a set of product requirements stored 6:35 Bir RAG temelde mevcut olanı geri getirmek için tasarlanmıştır. Sorgunuz ile veritabanınızdaki belirli bir metin parçacığı arasında semantik eşleşme bulmaya dayanır. as a document and you've also got a set of release notes stored as a document and then we ask which security requirements were omitted from the final release. Now using RAG when you query for omitted 6:50 Peki cevap veritabanında olmayan bir şeydeyse? Diyelim ki ürün gereksinimlerini bir belge olarak saklıyorsunuz ve aynı zamanda sürüm notlarını başka bir belge olarak saklıyorsunuz. Sonra, final sürümden hangi güvenlik gereksinimlerinin eksik olduğunu soruyoruz. security requirements the vector search looks for chunks discussing well security and requirements. It retrieves snippets from the requirements doc. It retrieves snippets from the release notes, but it cannot retrieve the gap between them. And because RAG only shows the model a few isolated 7:09 RAG kullanarak eksik güvenlik gereksinimlerini sorguladığınızda, vektör araması güvenlik ve gereksinimler hakkında parçalar arar. Gereksinim belgesinden snippetler, sürüm notlarından snippetler alır, ancak aralarındaki boşluğu geri getiremez. snapshots, the model never sees the full picture required to spot the missing pieces. The model really needs both of these documents in full to perform the comparison, which is exactly what 7:22 Ve çünkü RAG modele sadece birkaç izole snapshot gösterir, model eksik parçaları tespit etmek için gereken tam resmi hiç görmez. Modelin karşılaştırma yapabilmesi için her iki belgeyi de tamamen görmesi gerekir; uzun bağlam tam olarak bunu yapar, tüm gereksinim belgesini ve tüm sürüm notlarını bağlam penceresine döker. long context does by dumping the whole book, the full requirements doc and the full release notes into the context window. So, is RAG dead? Is the vector database destined for the museum of things 7:35 Peki, RAG öldü mü? Vektör veritabanı 2024'te ihtiyacımız olan şeylerin müzesine mi gidiyor? Pek sayılmaz, çünkü uzun bağlam sadelikte kazanırken RAG hâlâ bir yeri var. Ve bunu destekleyecek üç başka nedenim daha var. we needed in 2024? Well, not quite because while long context wins on simplicity, RAG still has a place. And I got another three reasons to support that. So, reason number one is the rereading text. 7:53 Şimdi, birinci neden yeniden okuma metni. Now, long context creates a massive compute inefficiency. So, if we take a manual, let's say this is like a a 500 page manual, and we've got to turn this into tokens. Well, that's something like 8:08 Uzun bağlam büyük bir hesaplama verimsizliği yaratır. Diyelim ki 500 sayfalık bir kılavuzu tokenlara dönüştürmemiz gerekiyor; bu yaklaşık 250.000 token eder. 250k of tokens. And we need to do that every time we make a user query and we put this document in the prompt. You're basically requiring the model to process that manual every time. Now, RAG also 8:23 Bu kılavuzu işlemek zorunda, ancak işlem maliyetini yalnızca indeksleme sırasında bir kez öder; statik veriler için prompt önbellekleme bu maliyeti kısmen dengeleyebilir, fakat içeriği sık sık değişen dinamik veri akışları için her istekte tam vergiyi ödemek zorundasın. İkinci neden iğne bulmacası problemidir. has to process that manual, but it only pays that processing cost once at indexing time. Now, prompt caching that can partially offset some of this for static data, but for dynamic data streams where content changes frequently, you are stuck paying the full tax on every request. Reason number two 8:45 Veri bağlam penceresinde ise modelin muhtemelen kullanacağına dair sezgisel bir varsayım vardır, ancak araştırmalar bunun aksine olduğunu gösteriyor. is the needle in the haystack problem. Now, there's a an intuitive assumption that if data is in the context window, the model's probably going to use it, but research suggests otherwise. 9:00 Bağlam penceresiyle başlayıp büyümeye devam edip şimdi 500.000 token civarına ulaştığımızda, modelin dikkat mekanizması biraz seyrelir; örneğin 2.000 sayfalık bir belgenin ortasındaki tek bir paragraf hakkında spesifik bir soru sorarsanız, model genellikle onu bulamaz ya da çevredeki metinden detaylar hayal eder. Because as we start with a context window and then it grows and it continues to grow and now we're at like 500,000 tokens, well, the model's attention mechanism can get a bit diluted. If you ask a 9:14 Ancak RAG ile modele daha az gürültü veriyoruz; sadece en üst beş ilgili parçayı getirerek, RAG saman yığınına iğneyi sunar ve modeli sadece iğnelere odaklanmaya zorlar, sinyale değil gürültüye. specific question about a single paragraph that's buried in, let's say, the middle of a 2,000 page document, well, the model often fails to retrieve it or it hallucinates details from the surrounding text. But with RAG, we're giving the model less noise. So by retrieving, say only the top five 9:35 Ve üçüncü neden, sonsuz veri kümesidir; milyonlarca tokenlık bir bağlam penceresi kulağa hoş geliyor, ancak kurumsal veri ölçeğinde sadece bir damla su demektir; yani terabaytlarca ya da hatta petabaytlarca ölçülen bir kurumsal veri gölü. relevant chunks, RAG has removed the haystack and presents the model with just the needles. It forces the model to focus on the signal and not the noise. And then reason number three, 9:49 Dolayısıyla her şeyi depolayan sonsuz bir veri kümesi istiyorsanız, bilgiyi LLM bağlam penceresine sığacak şekilde filtreleyen bir retrieval katmanına ihtiyacınız var. well that is the infinite data set. Now a context window of millions of tokens sounds great but in the scheme of enterprise data that's really just a drop in the bucket. I mean an enterprise data lake 10:05 Peki bu bizi nereye götürüyor? Eğer probleminiz sınırlı bir veri kümesini içeriyor ve belirli bir hukuki sözleşmeyi analiz etmek ya da bir kitabı özetlemek gibi karmaşık küresel akıl yürütme gerektiriyorsa, uzun bağlam en iyi yol gibi görünüyor; bu yığını basitleştirir ve akıl yürütmeyi geliştirir. that's probably measured in terabytes or or maybe even petabytes. So if you want an infinite data set that stores everything, you really do need to have a retrieval layer to filter information down 10:19 Ancak kurumsal bilgi'nin sonsuz veri kümesini keşfediyorsanız, vektör veritabanı tek geçerli depodur. Peki ya siz? Uzun bağlam ekibi misiniz, RAG ekibi mi yoksa ikisinin bir karışımı mı? Yorumlarda bana bildirin. to something that fits into the LLM context window. So where does this leave us? Well, if your problem involves a bounded data set and requires complex global reasoning like analyzing a specific legal contract or summarizing a book, I think long context is the way to go. It simplifies 10:38 yığın ve bu mantığı geliştirir. Ancak kurumsal bilginin sonsuz veri setinde dolaşıyorsanız, vektör veritabanı verileriniz için tek geçerli depodur. Ama nasıl the stack and it improves the reasoning. But if you're navigating the infinite data set of enterprise knowledge, the vector database remains the only viable warehouse for your data. But how 10:51 siz nasılsınız? Uzun bağlam takımısınız, RAG takımı mısınız, yoksa ikisinin bir karışımı mı? Yorumlarda bana söyleyin. about you? Are you team long context, team RAG, maybe a bit of both? Let me know in the comments. Altyazı bilgisayarımda üretildi ve videoyla ilerler; bir satıra tıklayın, o ana atlasın. Subtitles generated on my computer; they follow the video — click a line to jump there.
LLM'ler eğitim tarihine kadar olan bilgiyi bilir ancak güncel ve özel verileri öğrenmek için doğru bağlamı zamanında enjekte etmemiz gerekir; bu sorunu çözmenin bir yolu RAG (retrieval augmented generation) yöntemidir. LLMs know information up to their training cutoff, but we must inject the correct context in a timely manner to learn current and specific data; one solution to this problem is the Retrieval-Augmented Generation (RAG) method.
Bu video youtube.com üzerinde yayımlandı; buradaki oynatıcı YouTube’undur. Türkçe özet ve altyazı AiPulse için hazırlanmıştır. This video is published on youtube.com ; the player here is YouTube’s. The Turkish summary and subtitles are prepared for AiPulse .
YouTube’da izle Watch on YouTube AI Kritik → AI Critique →