O czym jest ten film
- Cerebras — duża firma produkująca układy do szybkiego wnioskowania AI — opisała na blogu firmową bazę wiedzy, którą autor uznaje za jedno z niewielu sensownych wdrożeń „drugiego mózgu”.
- Kluczowa różnica: żadnych efektownych grafów w Obsidianie ani „mózgu w słoju” — tylko niezawodny pipeline zbierania danych i wygodne odpytywanie.
- Fundamentem systemu jest RAG (retrieval augmented generation) — wstrzykiwanie właściwej informacji do promptu, zanim model odpowie.
- Dane wciągane są z wielu źródeł: Slack, wiki/Confluence, repozytoria kodu na GitHubie, dokumentacja techniczna, własne bazy danych.
- Surowe dane zamieniane są na embeddingi i wzbogacane metadanymi (kto, kiedy, dlaczego, jaki wątek).
- System waży informacje według źródła i świeżości — nowsze i pochodzące od ważniejszych osób znaczą więcej.
- Baza ma trzy warstwy: zbieranie danych, odpytywanie oraz (w dużej firmie) uwierzytelnianie i audyt.
- Autor buduje taki system na żywo, używając agenta kodującego (Claude Code), wklejając mu wpis z bloga i opisując swoje źródła danych.
- Test porównawczy: model z bazą wiedzy odpowiedział poprawnie na 17 z 20 pytań, model bez bazy — na 0.
- Przewaga tego podejścia nad „naiwnym RAG-iem” to właśnie wagi czasowe i jakość retrievalu, a nie sama liczba dokumentów.
Redakcyjne tłumaczenie
Dlaczego akurat ta baza wiedzy jest inna
To naprawdę ciekawa sprawa. Firma Cerebras zbudowała bazę wiedzy, która — jak sądzę — nie jest kompletną ściemą. Trudno mi to powiedzieć, bo do tej pory praktycznie każda odsłona „baz wiedzy”, „drugich mózgów” czy jak to zwał, była zwykłym przechwałkami bez pokrycia.
Cerebras to potężna firma sprzętowa z branży AI. Tworzy bardzo szybkie układy do wnioskowania, z których korzystają rozmaite miliardowe firmy, o których zapewne słyszeliście. I w całym tym obszernym poradniku — bo opublikowali na ten temat długi wpis na blogu — ani razu nie pokazali grafu z Obsidiana. Ani razu nie pokazali unoszącego się w tubie trójwymiarowego mózgu.
(Informacja dodatkowa: Cerebras Systems to producent gigantycznych procesorów WSE przeznaczonych do trenowania i wnioskowania modeli AI; Obsidian to popularna aplikacja do notatek, w której użytkownicy budują wizualne „drugie mózgi” w postaci grafów powiązań.)
Zamiast tego pokazali bardzo niezawodny i solidny pipeline wciągania danych, który pozwala praktycznie każdemu w firmie odpowiedzieć na dowolne pytanie o biznes i o to, co robili inni ludzie w organizacji. Wrzucili gigabajty danych tekstowych i graficznych z platform takich jak Slack — każdą rozmowę na Slacku, jaka kiedykolwiek odbyła się w organizacji — z wiki i Confluence, ze wszystkich repozytoriów kodu na GitHubie, z dokumentacji technicznej, a także z własnych baz danych. Całość tych danych „ugnietli” w przestrzeni embeddingów, którą można sobie wyobrazić po prostu jako zbiór pojęć, po których AI potrafi wyszukiwać.
Dzięki temu, gdy ktoś zapyta: „Hej, o czym to mówił Paul trzy dni temu? Chodziło chyba o embeddingi”, system potrafi wejść do treści Slacka — bez odpytywania API w locie — i zawsze wie, co się dzieje w firmie.
Chcę w tym filmie pokazać, czym to jest, a potem zbudować taki system razem z wami. Zbudowałem już jeden dla własnego biznesu i jest całkiem użyteczny — a to tylko mały zespół. Wyobrażam sobie, że przy tysiącach ludzi w organizacji coś takiego zaczyna się skalować i robi się naprawdę dobre.
Na YouiTubie jest oczywiście dużo szumu, bo każdy próbuje przepchnąć swój własny sposób robienia rzeczy. To nie jest mój sposób. To jest sposób tej dużej firmy — który akurat uważam za bardzo praktyczny i który nie polega na wizualizowaniu czegoś dziwacznego dla osób niezbyt technicznych.
Co to jest RAG i dlaczego jest fundamentem
Żeby naprawdę zrozumieć ten system, najpierw trzeba zrozumieć, czym jest retrieval augmented generation, powszechnie nazywane RAG. RAG jest kamieniem węgielnym w zasadzie całej tej dziedziny, więc warto krótkie przypomnienie.
RAG pozwala modelom odpowiadać na pytania o konkretny zbiór danych, a nie tylko w sensie ogólnym, na podstawie całej wiedzy. Gdybym wpisał do czatu z modelem AI „jak wysoki jest Nick?”, pewnie zapytałby: o kogo chodzi? Kto to Nick? To zależy — jeśli chodzi o Nicka Jonasa, to Nick Jonas ma tyle a tyle wzrostu. To bardzo ogólne pytanie, więc prawdopodobnie dostaniemy ogólną odpowiedź. A dzieje się tak dlatego, że model przechodzi po wszystkich swoich danych.
A teraz wyobraźcie sobie, że zamiast pytać wprost „jak wysoki jest Nick?”, najpierw wprowadzam do promptu zdanie „Nick ma 188 cm”, a dopiero potem pytam „jak wysoki jest Nick?”. Co powie model? To dość oczywiste. Podaliśmy mu informację tuż przed pytaniem, więc powie po prostu: Nick ma 188 cm. Nie wie nawet, o którego Nicka mi chodzi — po prostu ma informację bezpośrednio w prompcie.
Tym samym zredukowaliśmy całą zmienność modelu i sprawiliśmy, że odpowiedź jest hiperkonkretna — dokładnie taka, jakiej chcemy, za każdym razem. Na tym właśnie polega RAG: wzbogacamy generowanie tekstu przez AI, pobierając informację (np. „Nick ma 188 cm”) z jakiejś bazy danych.
Kluczowe jest to, że to nie jest zwykła baza danych. Zwykle ta informacja istnieje w języku, który duże modele językowe rozumieją intuicyjnie — w przestrzeni embeddingów. Trzeba zapamiętać, że cały RAG to po prostu system pozwalający umieścić informację przed zadaniem pytania.
Jak to przekłada się na bazę wiedzy firmy
Załóżmy, że chcecie zbudować bazę wiedzy odpowiadającą na wszystkie pytania o wasz biznes — na wszystko, co wydarzyło się w ostatnich 24 godzinach. Można zastosować to samo podejście. Gdybym zapytał swoją bazę „co Peter mówił na zeszłotygodniowej prelekcji?”, zwykły model rozsypałby się na mnóstwo odpowiedzi: kto to Peter? O jakiej prelekcji mówisz? Nie wiem nawet, który jest rok — jestem tylko korpusem tekstu.
Potrzebujemy więc sposobu, żeby wstrzyknąć informację. Realistycznie chcemy czegoś w rodzaju: „Peter Jackson wygłosił prelekcję w zeszłym tygodniu, w czwartek o 18:52. Omówił X, Y i Z”. Chcemy po prostu móc dokleić to przed prompt.
I dokładnie to robi system bazy wiedzy Cerebrasa — pozwala pobrać istotną informację z firmy i wstrzyknąć ją nad wasze pytanie. Dla modelu nie ma różnicy, czy zobaczył samo pytanie, czy pytanie plus tę doklejoną „pomoc”. To mocno zmienia jego odpowiedź, ale on sam nie wie, że mu podpowiedzieliśmy — traktuje to tak, jakby było częścią jego danych treningowych.
I dlatego jest to takie potężne. Pozwala każdemu w firmie odpowiedzieć na dowolne pytanie o cokolwiek, co się wydarzyło. Można też przechowywać rzeczy w rodzaju: oto zestaw problemów i oto rozwiązania, których użyliśmy. Gdy dołącza nowa osoba i próbuje naprawić jakiś kod, a coś nie działa, może zapytać bazę: „dlaczego to nie działa?”. A ona odpowie: „Pewnie nie wypychasz na produkcję tak, jak my to robimy w tej firmie — u nas jest to trochę inaczej niż w większości firm, zaraz ci pokażę”.
Anatomia bazy wiedzy
Bazę napisało trzech autorów wpisu — Isaac, Daniel i Mike — a obecnie system odpowiada na jakieś 15 000 pytań dziennie. Wpis jest długi i pełen fajnych wizualizacji, ale dla oszczędności czasu wyłuskam najważniejsze fragmenty.
Baza składa się z trzech głównych warstw:
Pierwsza to platforma zbierania i przechowywania danych wewnętrznych. Trzeba jakoś przenieść wiedzę spoza systemu do wewnątrz: wiedzę zawartą w rozmowach ludzi na Slacku, w SOP-ach firmy, w checklistach, procesach, mailach. Trzeba to wszystko wciągnąć i umieścić w bazie w odpowiedni sposób, żeby nie zrobiło się z tego śmietnisko.
(Informacja dodatkowa: SOP — Standard Operating Procedure — to spisana, powtarzalna procedura postępowania.)
Druga to platforma odpytywania danych. Skoro dane są już w „mózgu”, potrzebujemy sposobu, by je wyciągać. Przykład: „pobierz statystyki wydajności z ostatniego tygodnia dla platformy X, a potem zastosuj do nich to ujęcie, o którym Nick mówił na ostatnim firmowym seminarium”.
Trzecia to warstwa uwierzytelniania i autoryzacji z audytem i analityką — kto sięga po dane, po co i tak dalej. Cerebras działa w sprzęcie i współpracuje z miliardowymi firmami, więc tego potrzebuje. Ja jestem mały w porównaniu z nimi, więc tej warstwy nie buduję — dla nas liczą się przede wszystkim warstwy pierwsza i druga. Zakładam, że każdy w moim biznesie jest w porządku.
Źródła danych i czym jest embedding
Na samej górze mamy źródła danych, które są nieustannie wciągane.
- Slack — system skanuje wszystkie wiadomości ze wszystkich dostępnych przestrzeni roboczych i zamienia je w embeddingi. Jeśli używacie Discorda, robicie to samo na Discordzie; jeśli maila — na mailu. Chodzi po prostu o miejsce, gdzie ludzie rozmawiają.
- Wiki / Confluence — każda większa firma ma gdzieś składowaną wiedzę: checklisty, SOP-y, strony onboardingowe. To też ląduje w przestrzeni embeddingów.
- Repozytoria kodu — szczególnie ważne, jeśli jesteście firmą softwarową lub jej pokrewną.
- Dokumentacja techniczna (net listy, dokumenty PRM) — istotna głównie dla firm sprzętowych i softwarowych.
- Własne bazy danych — np. z KPI działu sprzedaży; te sformatowane dane też można zapisać jako embeddingi.
Czym jest embedding? Bierze surowe dane — powiedzmy zdanie „Nick uważa, że pingwiny są fajne” — i przepuszcza je przez duży model językowy (ChatGPT, Claude, model open source, cokolwiek). Zadajemy modelowi pytania: kto to Nick? Dlaczego to powiedział? O której? Gdzie? Kiedy? Na końcu nie mamy już naiwnego kawałka tekstu, lecz: „Nick uważa, że pingwiny są fajne”, godzina 17:32, temat: Nick Saraev, opis: Nick jest założycielem organizacji X, robi to i tamto.
Bierzemy więc rdzeń danych i dodajemy do niego metadane — dodatkowe informacje dookoła. To nie jest już tylko mała bryłka pośrodku; wiemy datę i godzinę wysłania, do kogo, skąd, kim jest ta osoba, dlaczego to istotne i o co Nickowi chodziło.
To podobne do działania aparatu cyfrowego. Robiąc zdjęcie, masz samo zdjęcie (rdzeń danych), ale też mnóstwo metadanych: kiedy zrobione, jaka paleta barw, a wiele aparatów zapisuje też pozycję GPS — co jest trochę przerażające. Nie przechowujemy więc samych danych, tylko dane wzbogacone o dodatkowe informacje i zapisane w formie zrozumiałej dla maszyny.
Wagi: źródło i świeżość
To ważne, bo — podobnie jak wasz mózg lepiej i mocniej zapamiętuje nowe rzeczy — ten system silniej „pamięta” nowe wpisy w bazie. Mamy źródło, mamy znaczniki czasu, wiemy więc, jak ważyć dane. Jeśli dane pochodzą od nisko postawionego pracownika sprzed trzech lat, zważymy je znacznie słabiej niż dane od Nicka — założyciela firmy — sprzed 30 sekund.
Gdy ktoś pyta o niedawne seminarium, system nie przechodzi po wszystkich seminariach jednakowo, jak zrobiłby naiwny model językowy, tylko preferuje najświeższe. Sprawdza świeżość, datę i trafność. W ten sposób powstaje zbiór „wspomnień” tego mózgu, uszeregowanych według daty, czasu i istotności.
Odpytywanie i struktura artefaktu
Trzeci krok to odpytywanie danych — przez MCP, interfejs webowy, agentów AI, czat. Proces działa w odwrotną stronę: zapytanie przechodzi przez embeddingi, a te reprezentują konkretną informację (np. wiadomość ze Slacka), którą wyciągamy, by uzyskać odpowiedź.
(Informacja dodatkowa: MCP — Model Context Protocol — to standard łączenia modeli AI z zewnętrznymi źródłami danych i narzędziami.)
Praktyczny przykład na wiadomości ze Slacka. W wątku wsparcia ktoś (Amaya) o 9:14 pisze: „Hej, przywracanie zawiesza się po wczytaniu manifestu na większym klastrze, ale małe uruchomienia działają”. Owen odpowiada: „Tak, odtwarzam to na 128 wątkach, ale log urywa się przed rozgrzaniem cache’u”.
System bierze cały wątek, dzieli go na okna czasowe — a wszystko dzieje się automatycznie — i tworzy z tego ustrukturyzowany artefakt. Model językowy zadaje pytania do treści i wyciąga metadane: pytanie („dlaczego przywracanie zawiesza się po wczytaniu manifestu?”), podsumowanie („duże przywracania urywają się przed rozgrzaniem cache’u”), a jeśli sprawa wymagała rozwiązania — krok rozwiązania. Do tego dochodzą referencje do kodu, lista systemów, których dotyczy, identyfikator źródła, data, godzina i tak dalej.
Dzięki temu odpowiedź na pytanie zostaje trwale zapisana wewnątrz firmy — co oznacza, że firma staje się z czasem coraz bardziej efektywna. Nie musicie tego wszystkiego przechowywać samodzielnie; chodziło mi tylko o to, żebyście rozumieli, co dzieje się pod maską. Nie musicie znać każdego szczegółu — poprowadzę was przez realny proces budowy. Dobra wiadomość: sam nie wiem dokładnie, czym jest 90% tych rzeczy — rozumiem je na wysokim poziomie i to w zupełności wystarcza. Wystarczy rozumieć, jak przepływają dane. Nie potrzeba do tego zwariowanego programisty; zrobimy to sami.
Budowa krok po kroku
Pierwsza rzecz, jakiej potrzebujecie, to agent kodujący. W moim przypadku używam Claude Code w wersji 2.1.211.
(Informacja dodatkowa: Claude Code to narzędzie wiersza poleceń Anthropic, w którym model AI może samodzielnie odczytywać i zmieniać pliki na komputerze.)
Nie twierdzę, że musicie używać akurat Claude Code — możecie sięgnąć po jeden z wielu dostępnych modeli. Ta inteligencja klasy Fable 5 po prostu jest w tej chwili najwydajniejsza, a mnie stać, żeby za nią płacić, więc czemu nie. Możecie wziąć dowolny model — Claude Code, ChatGPT, Codex — byle był to model kodujący, który potrafi wprowadzać zmiany na waszym komputerze.
Wystarczy, że skopiuję cały wpis z bloga i wkleję go do terminala (akurat używam Ghostty). Potem piszę: „Chciałbym, żebyś zbudował coś takiego dla Nick Saraev Media LLC. Mam Slacka, zestaw maili i adres mailowy, GitHuba oraz kanał na YouTubie. Chcę zbudować pipeline’y wciągania danych dla nich wszystkich”. Dopisuję jeszcze: „PS: to demo, już to robiłem — zbuduj wszystko całkowicie od zera”. Robiłem to już kilka razy, więc chcę tylko udawać, że jest to zupełnie nowe.
Fajne jest to, że nie musicie wiedzieć, jak to działa — model może przejść przez to w pełni autonomicznie. Gdyby Cerebras zablokował swoją stronę, zamiast podawać URL możecie po prostu skopiować całą treść ręcznie i wkleić. Ważne, żeby trafiła do inteligentnego modelu.
Następnie agent spróbuje zalogować się do wszystkich wskazanych kont. U mnie są już zalogowane — GitHub, kanał YouTube, adresy mailowe — więc zrobi to niemal automatycznie i naraz. U was może być inaczej. Gdybyście chcieli skonfigurować dostęp np. do maila, otwieracie nową instancję i piszecie: „Chcę, żebyś uzyskał dostęp do mojego maila”. Podaję adres i mówię: „Powinieneś umieć odpytywać każdy mail, czytać wszystkie, wysyłać maile — mieć pełny dostęp administracyjny. Jak zrobiłbyś to hipotetycznie, gdybyś jeszcze nie miał dostępu?”. Pytam tak, bo dostęp już istnieje, a nie chcę siedzieć cztery godziny, słuchając, że dostęp już jest.
Model wyjaśni, jak ustawić to od zera: założyć projekt w Google Cloud, włączyć Gmail API, przejść przez ekran zgody OAuth, utworzyć klienta OAuth (aplikację desktopową), zrobić jednorazową zgodę i uzyskać token odświeżający. To nie jest trudne — realistycznie zajmuje jakieś 5–10 minut na każdy pipeline informacji. Na tym polega urok agentów: pytasz ich, jak coś zrobić, a jeśli model jest wystarczająco mądry (u mnie Opus 4.8, ale może być Fable 5 czy GPT 5.6), dostajesz potrzebne poświadczenia, żeby zbudować pipeline.
(Informacja dodatkowa: OAuth to standard bezpiecznej autoryzacji, w którym aplikacja uzyskuje ograniczony dostęp do konta użytkownika bez poznawania jego hasła.)
Po lewej stronie agent w tym czasie buduje system. Ponieważ chcę zobaczyć, co się dzieje, używam komendy /btw — to funkcja specyficzna dla Claude Code — i proszę: „zwizualizuj system, który dla mnie budujesz, w ASCII”. Podczas gdy główny wątek pracuje, drugi wątek zadaje pytania. Diagram pokazuje dokładnie to, o czym mówiłem: Slacka, trzy konta Gmail, mojego GitHuba i kanał YouTube jako konektory (API, MCP itp.), które pompują dane. Dalej krok destylacji, gdzie każdy wątek przechodzi przez model (tu Haiku) i dostaje pytanie, podsumowanie, rozwiązanie i listę systemów. Potem wciąganie danych do pipeline’u / bazy — jednej tabeli w czymś, co wygląda jak PostgreSQL. Na dole konfiguracja retrievalu: wyszukiwanie pełnotekstowe (dopasowanie dokładnych tokenów) oraz embeddingi.
Test: z bazą wiedzy vs bez niej
Po zbudowaniu pokazuję artefakt: ten sam model dostał te same 20 pytań — raz z bazą wiedzy, raz bez. Wersja z bazą odpowiedziała poprawnie na 17 z 20 pytań; pozostałe trzy to uczciwe częściowe odpowiedzi lub odmowy („nie wiem, bo nie mam dowodów”). Wersja bez bazy odpowiedziała poprawnie na zero. To bardzo wysoka jakość. Można sobie wyobrazić, jak wdrożenie tego w dowolnej firmie znacząco poprawia i jakość, i szybkość odpowiedzi.
Przykład: „Która firma AI ostatnio zaproponowała płatną współpracę sponsorską dla podcastu Stacked?”. Prowadzę podcast Stacked z Jackiem Robertsem, ostatnio trochę urośliśmy — mamy jakieś 5600 subskrybentów, blisko 6 tysięcy. Natywnie nie dostalibyście odpowiedzi, ale my wiemy: to abacus.ai. Zaproponowali płatny sponsoring, promujący ich Chat LLM jako wszechstronnego super-asystenta AII. Kontakt przyszedł od konkretnej osoby. Czy przyjęliśmy? Absolutnie nie.
Inny przykład: „Do których repozytoriów na GitHubie NSM wypychał ostatnio zmiany?”. Mamy dokładną aktywność — to ja zastępowałem starą nazwę firmy nową. To akurat nie jest imponujące; każdy RAG by to zrobił. Imponujące jest to, że dane są wciągane całkowicie automatycznie i nie muszę nic z nimi robić — dzieje się to w tle, nie wymaga mojego zarządzania, a ja mogę zadać dowolne pytanie w dowolnym momencie.
Dlaczego to lepsze niż naiwny RAG
Czego nie da się dobrze zwizualizować, to o ile jest to lepsze od naiwnego RAG-u, który stosuje większość ludzi. My mamy datę i czas — czyli informację, ile minęło od powstania danych — oraz istotnie wyższą jakość retrievalu. Miałem w systemie tylko jakieś 640 dokumentów; firma taka jak Cerebras ma pewnie setki tysięcy. Tym, co odróżnia kiepską bazę wiedzy od dobrej, nie jest liczba dokumentów, lecz to, jak skutecznie potrafisz wyciągnąć te najlepsze i najbardziej trafne. I na to właśnie odpowiada ten rodzaj RAG-u.
Nie mówię, że musicie użyć akurat tego rozwiązania — jest wiele różnych RAG-ów i wiele podejść do baz wiedzy. Ale to zrobiła poważna firma. Oni nie robią czegoś takiego, jeśli to nie daje zwrotu z czasu i energii. A daje — także mnie: cała treść, którą tworzę i która trafia do biznesu, jest syndykowana, embedowana, wyciągana i wzbogacana. To obfite źródło szkoleniowe, które od razu wprowadza cały zespół w temat. Mogę je rozdać pstryknięciem palca i dać ludziom ten sam „mózg”, który sam długo budowałem.
Niestety nie wygląda to zbyt efektownie — nie mam wielkiego unoszącego się mózgu na środku ekranu. Ale to ten sam zasób, co w Obsidianie czy Graphify, tyle że prawdopodobnie o wyższym ROI — właśnie dzięki ważeniu częstotliwości i czasu.
Jak widać, mocno kibicuję Cerebrasowi — to świetna firma. To nie jest wpis sponsorowany, nie dostałem za to żadnych pieniędzy. Po prostu uważam, że to chyba najfajniejsze wdrożenie bazy wiedzy, jakie widziałem. Jeśli lubicie takie rzeczy, zajrzyjcie do Maker School — mojej dzień po dniu mapy rozliczalności, w której pokazuję, jak zdobyć pierwszego klienta na usługę AI lub automatyzacji (na przykład budowanie takich systemów RAG czy baz wiedzy za pieniądze) w ciągu 90 dni — albo zwracam pieniądze. Miłego dnia i subskrybujcie kanał.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Baza wiedzy oparta na RAG bije wizualne „drugie mózgi”
Na czym polega: Wartość systemu tworzy niezawodny pipeline wciągania danych i skuteczny retrieval, a nie efektowna wizualizacja typu graf w Obsidianie czy „mózg w słoju”.
Jak stosować: Zamiast inwestować czas w ładne mapy powiązań, skup się na tym, by dane z realnych źródeł (Slack, wiki, kod, maile) automatycznie trafiały do bazy odpytywalnej językiem naturalnym.
Na co uważać: Nie myl atrakcyjności wizualnej z użytecznością. System, który świetnie wygląda, ale słabo wyszukuje, jest bezwartościowy.
2.RAG to wstrzykiwanie kontekstu przed pytaniem
Na czym polega: RAG redukuje zmienność odpowiedzi modelu, doklejając właściwą informację do promptu, zanim model odpowie — dzięki temu odpowiedź jest hiperkonkretna.
Jak stosować: Projektując dowolne rozwiązanie AII dla firmy, myśl w kategoriach: „jaką informację muszę pobrać i wstrzyknąć, żeby model odpowiedział trafnie”. To fundament, nie detal.
Na co uważać: Jakość odpowiedzi jest tak dobra, jak trafność wstrzykniętego kontekstu. Zły retrieval = pewna, ale błędna odpowiedź.
3.Wzbogacaj dane metadanymi, nie zapisuj surowego tekstu
Na czym polega: Każdy fragment danych przechodzi przez model, który dodaje metadane: kto, kiedy, gdzie, dlaczego, w jakim wątku, jakich systemów dotyczy.
Jak stosować: Na etapie ingestii zbuduj krok „destylacji” — model generuje dla każdego fragmentu pytanie, podsumowanie i ewentualne rozwiązanie oraz identyfikatory źródła.
Na co uważać: Metadane generuje model, więc mogą zawierać błędy lub halucynacje. Przy wrażliwych zastosowaniach warto weryfikować kluczowe pola.
4.Waż informacje według źródła i świeżości
Na czym polega: Nowsze dane i dane od ważniejszych osób dostają wyższą wagę; przy pytaniach o „ostatnie” wydarzenia system preferuje najświeższe wpisy zamiast traktować wszystko jednakowo.
Jak stosować: Zapisuj znaczniki czasu i rangę źródła jako metadane i uwzględniaj je w rankingu retrievalu — to główna przewaga nad „naiwnym RAG-iem”.
Na co uważać: Zbyt agresywne ważenie świeżości może wypchnąć wciąż aktualną, ale starszą wiedzę. Dobierz wagi do charakteru danych.
5.Jakość retrievalu ważniejsza niż liczba dokumentów
Na czym polega: O sile bazy nie decyduje liczba dokumentów (autor miał ~640, Cerebras setki tysięcy), lecz zdolność wyciągnięcia najbardziej trafnych.
Jak stosować: Zainwestuj w hybrydowy retrieval — wyszukiwanie pełnotekstowe (dokładne tokeny) plus embeddingi — i testuj trafność na realnych pytaniach.
Na co uważać: Dokładanie kolejnych dokumentów bez poprawy retrievalu obniża jakość — więcej szumu, trudniej znaleźć sygnał.
6.Zbuduj system agentem kodującym, nie ręcznie
Na czym polega: Autor buduje cały pipeline, wklejając agentowi (Claude Code) wpis z bloga i opisując swoje źródła danych; agent działa w dużej mierze autonomicznie.
Jak stosować: Podaj agentowi dobry wzorzec (tu: wpis Cerebrasa), jasno opisz swoje źródła i pozwól mu zaproponować oraz zbudować pipeline’y. Do konfiguracji dostępu pytaj go wprost „jak byś to zrobił od zera”.
Na co uważać: Nie musisz rozumieć każdego szczegółu, ale musisz rozumieć przepływ danych — inaczej nie wychwycisz, gdy agent zbuduje coś błędnego.
7.Pipeline’y dostępu konfiguruje się w minuty, nie dni
Na czym polega: Podłączenie źródła (np. Gmail przez Google Cloud, Gmail API, OAuth, token odświeżający) to realnie 5–10 minut na pipeline, gdy prowadzi cię model.
Jak stosować: Traktuj każde źródło osobno i konfiguruj je po kolei, prosząc agenta o instrukcję krok po kroku dla dokładnie twojego stacku.
Na co uważać: Dostęp administracyjny do maila, GitHuba czy Slacka to poważne uprawnienia — pilnuj zakresu tokenów i tego, co agent robi z poświadczeniami.
8.Waliduj system testem porównawczym
Na czym polega: Autor zadał ten sam zestaw 20 pytań modelowi z bazą (17/20 trafnych) i bez (0/20), co jasno pokazuje wartość systemu.
Jak stosować: Zbuduj zestaw realnych pytań firmowych i regularnie porównuj odpowiedzi z bazą i bez — to twój wskaźnik jakości i argument wdrożeniowy.
Na co uważać: „Uczciwe odmowy” (model mówi „nie wiem”) są lepsze niż pewne błędy — projektuj system tak, by przyznawał się do braku dowodów.
9.Automatyczna, ciągła ingestia w tle to główna wartość
Na czym polega: Przewagą nad zwykłym RAG-iem nie jest samo pytanie i odpowiedź, lecz to, że dane wciągają się automatycznie, bez zarządzania ze strony właściciela.
Jak stosować: Zaprojektuj ingestię jako proces działający w tle (harmonogram, webhooki), żeby baza była zawsze aktualna bez ręcznej pracy.
Na co uważać: „Bez zarządzania” nie znaczy „bez nadzoru” — monitoruj, czy pipeline’y nie padły i czy nie wciągają śmieci lub danych wrażliwych.
10.W dużej organizacji dodaj warstwę uwierzytelniania i audytu
Na czym polega: Cerebras ma trzecią warstwę — kontrolę dostępu, autoryzację, audyt i analitykę; autor jako mały zespół ją pomija.
Jak stosować: Dla małego, zaufanego zespołu wystarczą warstwy zbierania i odpytywania. Skalując do wielu osób, dodaj kontrolę, kto sięga po jakie dane i dlaczego.
Na co uważać: Baza wiedzy agreguje całą wiedzę firmy w jednym miejscu — bez kontroli dostępu staje się pojedynczym punktem wycieku wrażliwych informacji.