Poradnik OpenClaw: baza wektorowa i lokalne embeddingi na LM Studio. Po co, po co nie, i jak to zrobić krok po kroku

Wstęp: OpenClaw pamięta, ale musi cię rozumieć

W poprzedniej części serii pokazałem najważniejsze komendy OpenClaw i to, jak przełączać modele, restartować bramę i podłączać kanały. Dziś schodzimy poziom niżej, do bardzo konkretnego i moim zdaniem często niedocenianego mechanizmu: pamięci i wyszukiwania semantycznego.

OpenClaw nie jest statycznym botem czekającym na polecenie. Kiedy z nim rozmawiasz, czyta plik pamięci, przypomina sobie wcześniejsze ustalenia, projekty, decyzje i preferencje. Pytanie brzmi: jak robi to skutecznie, skoro notatki zmieniają się, a zapytania rzadko pokrywają się słowo w słowo z treścią notatek?

Odpowiedź to search hybrydowy: klasyczne wyszukiwanie po słowach kluczowych połączone z wyszukiwaniem wektorowym. A wektory, czyli matematyczne odwzorowanie znaczenia, mogą pochodzić albo z chmury, albo z lokalnego serwera LM Studio. W tym poradniku pokażę po kolei, dlaczego warto postawić na lokalne embeddingi i jak to skonfigurować na własnym sprzęcie.

Zanim przejdziemy dalej, zróbmy prosty test intuicji. Załóżmy, że pół roku temu zapisałeś w notatkach zdanie: „produkcyjna brama chodzi na porcie 8080 i wraca sama po awarii”. Dziś pytasz asystenta: „co się dzieje z serwisem, gdy padnie?”. Zwykła wyszukiwarka po słowach nie złapie związku, bo nie ma wspólnych fraz. Wektor zrozumie, że „brama”, „serwis” i „padnie” to bliskie znaczeniowo rzeczywistości. To właśnie ta różnica robi z notatnika system pamięci, a nie tylko magazyn plików.

1. Czym właściwie jest wyszukiwanie wektorowe

Zanim przejdziemy do konfiguracji, warto zrozumieć, co rozumiemy przez „bazę wektorową” w kontekście OpenClaw. Nie jest to osobna aplikacja, którą trzeba instalować obok. To funkcja wbudowana w silnik pamięci, którą można włączyć lub zostawić wyłączoną.

Mechanizm wygląda tak:

OpenClaw czyta pliki pamięci, czyli `MEMORY.md` i wszystko w katalogu `memory/`.
Dzieli ich treść na kawałki (domyślnie chunki po 400 tokenów z nakładką 80 tokenów).
Każdy kawałek zamienia w wektor, czyli listę liczb opisujących znaczenie tekstu.
Przy zapytaniu robi to samo z Twoim pytaniem.
Porównuje odległość między wektorem zapytania a wektorami notatek i zwraca te najbliższe znaczeniowo.

Kluczowa przewaga nad zwykłym wyszukiwaniem po frazach: możesz zapytać „jak zmienić model głównego agenta”, a system znajdzie notatkę napisaną jako „ustawienia domyślnego modelu bramy”, nawet jeśli nie ma ani jednego wspólnego słowa. To tłumaczy, dlaczego wektory są tak cenne dla pamięci asystenta.

Pokażę to na realnym przykładzie z życia. W mojej konfiguracji jedna z notatek mówi: „localemu embedderowi podaj baseUrl przez /v1/ i klucz lm-studio”. Gdy zadaję pytanie „jak przełączyć wektory na lokalną maszynę?”, system nie szuka słowa „embedder”. Szuka podobieństwa znaczeniowego i trafia dokładnie w tę notatkę. Bez wektorów dostałbym pustkę albo przypadkowy fragment.

Search hybrydowy – najlepszy z obu światów

OpenClaw nie opiera się wyłącznie na wektorach. Uruchamia dwa tory równolegle:

tor wektorowy, który łapie znaczenie i synonimy,
tor BM25 (pełnotekstowy indeks FTS5), który łapie dokładne terminy, identyfikatory, kody błędów i klucze konfiguracji.

Oba wyniki są łączone z wagami. To ważne, bo gdy szukasz na przykład konkretnego błędu w konfiguracji, dopasowanie po dokładnym stringu bywa cenniejsze niż podobieństwo znaczeniowe. Hybryda daje jedno i drugie.

2. Dlaczego warto trzymać embeddingi lokalnie

Teraz do sedna. Skąd brać wektory? Domyślnie OpenClaw używa embeddingów OpenAI. To oznacza, że kawałki Twoich notatek są wysyłane na serwery OpenAI, żeby tam zostały zamienione w wektory. Działa to dobrze, ale ma dwie konsekwencje, które dla wielu użytkowników są istotne.

Prywatność

Treść pamięci, czasem bardzo osobista, opuszcza Twoją maszynę. Jeśli zależy Ci na pełnej kontroli nad danymi, to temat do poważnego rozważenia. Lokalne LM Studio liczy wektory na Twoim sprzęcie, a notatki nie opuszczają sieci lokalnej. Dla firm objętych RODO to rozwiązanie potrafi być niemal koniecznością.

Ważny niuans: same embeddingi to tylko jedna warstwa. Pełna prywatność wymaga też lokalnego modelu jako głównego agenta, bo to on czyta wstrzyknięte fragmenty pamięci podczas odpowiadania. O tym szerzej pod koniec artykułu.

Koszt i niezależność

Lokalne embeddingi to zero opłat za tokeny. Nie ma limitu zapytań, nie ma zależności od awarii zewnętrznego API i nie ma problemu, gdy ktoś kiedyś zmieni cennik lub politykę.

Elastyczność sprzętu

Do embeddingów nie potrzeba potężnego GPU. Modele embeddingowe są małe i szybkie, dobrze radzą sobie nawet na typowym PC czy stacji roboczej. W praktyce lokalny serwer embeddingów potrafi być nawet szybszy niż sieciowe wywołanie, zwłaszcza przy dużej liczbie notatek.

3. Co wiedzieć o architekturze

Zanim zaczniesz, przyda się jasność struktury. OpenClaw ma wbudowany silnik pamięci (ang. builtin memory engine) oparty na SQLite. Nie dodajesz żadnego osobnego pluginu do baz wektorowych dla tego mechanizmu. To, co robisz, to tylko podmiana dostawcy embeddingów.

Gdzie fizycznie trafiają dane:

indeks pamięci siedzi w per-agentowej bazie SQLite, domyślnie pod ścieżką `~/.openclaw/agents//agent/openclaw-agent.sqlite`,
wektory trzymane są w tej samej bazie, opcjonalnie przez rozszerzenie sqlite-vec; gdy się nie załaduje, OpenClaw automatycznie przechodzi na liczenie podobieństwa kosinusowego w procesie,
pełnotekstowy indeks FTS5 również mieszka w tej bazie,
obok pojawiają się pliki WAL i SHM, odpowiadające za spójność transakcji.

Uwaga na pułapkę: plik `~/.openclaw/state/openclaw.sqlite` to stan bramy (crony, zadania, autoryzacje), a nie indeks pamięci. Łatwo je pomylić, gdyż oba są plikami SQLite.

4. Konfiguracja krok po kroku

Przechodzimy do praktyki. Zakładam, że masz uruchomione LM Studio na maszynie w swojej sieci i że model embeddingowy jest już załadowany (np. `text-embedding-nomic-embed-text-v1.5`).

Krok 1: Dodaj wpis w pliku hosts

Zamiast wpisywać surowe IP w configu i skryptach, dodaj czytelną nazwę hosta. To ułatwi życie, gdy w przyszłości zmienisz maszynę na inną z tej samej klasy adresów.

W pliku `/etc/hosts` dodaj linię:

192.168.1.24 gemma4

Sprawdź, czy działa:

getent hosts gemma4

Jeśli odpowiedź zawiera poprawny adres, masz alias gotowy. Od tej pory zmiana maszyny to edycja jednej linii w tym pliku, bez ruszania configu i skryptów.

Krok 2: Wskaż provider embeddingów na LM Studio

Otwórz plik konfiguracyjny `~/.openclaw/openclaw.json` i w sekcji agenta ustaw provider embeddingów na `openai-compatible`, bo LM Studio wystawia kompatybilny endpoint `/v1/embeddings`.

Fragment konfiguracji:

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "openai-compatible",
        model: "text-embedding-nomic-embed-text-v1.5",
        remote: {
          baseUrl: "http://gemma4:1234/v1/",
          apiKey: "lm-studio"
        }
      }
    }
  }
}

Pole `apiKey` może zawierać dowolną wartość, LM Studio i tak jej nie weryfikuje, ale struktura wymaga klucza dla providerów OpenAI-kompatybilnych.

Zanim wpiszesz to po raz pierwszy, warto się upewnić, że lokalny serwer faktycznie wystawia model embeddingowy. Szybki test z wiersza poleceń:

curl -s http://gemma4:1234/v1/models

Odpowiedź powinna zawierać listę załadowanych modeli, a wśród nich na przykład `text-embedding-nomic-embed-text-v1.5`. Jeśli widzisz go na liście, możesz bezpiecznie przejść dalej. Jeśli nie, załaduj model w interfejsie LM Studio zanim cokolwiek skonfigurujesz. To oszczędza chwilę frustracji przy pierwszym diagnozowaniu.

Krok 3: Zrestartuj bramę

Po każdej zmianie konfiguracji:

openclaw gateway restart

Albo przez systemd:

systemctl --user restart openclaw-gateway

Krok 4: Sprawdź status i zbuduj indeks

Upewnij się, że provider i wektory są wykrywane:

openclaw memory status
openclaw memory status --deep

Komenda z flagą `–deep` rozdziela informację o magazynie wektorów od informacji o providerze, co bardzo pomaga w diagnozie. Jeśli indeks jest pusty albo budowany był na starym providerze, przebuduj go:

openclaw memory index --force

Krok 5: Przetestuj działanie

Po przebudowie zapytaj asystenta o coś, co w notatkach jest sformułowane inaczej niż w zapytaniu. Jeśli wyszukiwanie semantyczne działa, dostaniesz trafienie mimo braku wspólnych słów. To najlepszy dowód, że wektory liczone lokalnie robią robotę.

5. Typowe pułapki i ich rozwiązania

Brak wyników albo tylko dopasowania po słowach kluczowych

To znak, że provider embeddingów nie jest wykryty. Sprawdź `openclaw memory status –deep` i upewnij się, że sekcja Embeddings jest sprawna. Jeśli widzisz tylko tory keyword, to znaczy, że wektory nie są liczone.

Local embeddings timeout

Provider lokalny domyślnie używa dłuższego czasu oczekiwania na batch, ale na wolniejszym hoście i tak może się przydać podniesienie limitu. Szukaj ustawienia `memorySearch.sync.embeddingBatchTimeoutSeconds` w dokumentacji i zwiększ je, potem przebuduj indeks.

sqlite-vec się nie ładuje

Nic strasznego. OpenClaw automatycznie przechodzi na kosinusowe podobieństwo liczone w procesie. Działa, tylko przy bardzo dużej bazie może być wolniejsze.

Reindeks po zmianie providera

Zmiana modelu lub providera automatycznie wymusza przebudowę. Jeśli czujesz, że coś jest nieaktualne, po prostu odpal `openclaw memory index –force`.

6. Realny przykład z życia: dlaczego to zmienia komfort pracy

Czas na konkret, bo teoria fajnie brzmi, ale dopiero w praktyce widać różnicę. Wyobraź małego blogera technicznego, który od roku prowadzi notatki o swojej sieci: adresy, hasła do paneli, schematy konfiguracji, a nawet zapisane preferencje rozmów z agentem.

Pewnego niedzielnego wieczoru zmienia router i muszą przepiąć pół tuzina usług. Zamiast przeklinać się przez folder z notatkami, pyta agenta: „gdzie mam to samo, co wcześniej przy zmianie starego pudełka?”. Domyślnie (bez wektorów) agent łapie tylko dokładne słowa i może nie trafić na właściwy fragment, bo notatka opisuje zupełnie inny sprzęt. Z wektorami rozumie intencję: szuka procedury „zmiany routera”, nie konkretnego modelu urządzenia. Minuta zamiast kwadransa grzebania w plikach.

Drugi przykład, tym razem o prywatności w praktyce. Freelancer prowadzący audyty bezpieczeństwa trzyma w pamięci wrażliwe ustalenia z klientami. Dopóki embeddingi liczy chmura, fragmenty tych notatek wychodzą poza jego maszynę przy każdym indeksowaniu. Po przełączeniu na LM Studio wektory powstają lokalnie, a on odzyskuje kontrolę: cała pętla pamięci zostaje w jego sieci. Dla kogoś, kto ma w umowach klauzule o poufności, to nie luksus, tylko warunek pracy.

Ostatni, mniej oczywisty przykład: oszczędność. Hobbysta, który przez rok gromadzi dziesiątki plików notatek, potrafi przy każdym przebudowie indeksu wysłać sporo tokenów do chmury. Lokalny embedder robi to samo za darmo i bez limitów, niezależnie od tego, ile razy tniemy i wektoryzujemy historię.

7. Analiza z różnych perspektyw

Perspektywa prywatności

Z punktu widzenia użytkownika dbającego o dane, lokalne embeddingi to duży krok w stronę samowystarczalności. Notatki nie opuszczają sieci, co ma znaczenie w kontekście RODO i polityk zero trust. Pamiętaj jednak, że pełna izolacja wymaga także lokalnego modelu głównego agenta, bo to on czyta wstrzyknięte fragmenty pamięci podczas odpowiadania. Rozdziel to jasno: lokalne wektory zatrzymują tekst w domu, ale sam agent nadal może komunikować się z chmurą.

Perspektywa biznesowa

Firma z wieloma agentami i historią notatek zyskuje na szybkości i koszcie. Brak opłat za embeddingi i brak zewnętrznego API jako pojedynczego punktu awarii to argumenty, które trudno pobić. Zespół devów, który ma wspólnego agenta z bazą wiedzy, dostaje natychmiastowe odpowiedzi konsultacyjne bez martwienia się o limity providera.

Perspektywa techniczna

Hybrydowy search łączący wektory z BM25 to poprawne inżyniersko podejście. Nie wybierasz między jakością semantyczną a precyzją dokładnych stringów, masz obie. W połączeniu z opcjonalnym czasowym zanikaniem wag (temporal decay) i mechanizmem różnorodności wyników (MMR) da się dobrze wystroić jakość odpowiedzi na dużej historii. Zauważ, że to ten sam mechanizm co w wielkich systemach RAG: cały czas mówimy o sprawdzonym pomyśle, tyle że na mniejszą, prywatną skalę.

8. Przyszłość lokalnej pamięci

Z mojej perspektywy badacza AI dzielenie pracy między lokalne i chmurowe modele to nie moda, lecz trwały trend. Lokalne embeddingi to pierwszy, bezpieczny krok na tej drodze. W dalszej perspektywie całe asystentowe pętle pamięci, przypominania i podsumowywania będą działać na sprzęcie użytkownika, a chmura zostanie tylko tam, gdzie realnie potrzeba jej mocy.

Spekulując, do końca dekady zobaczymy asystentów, którzy trzymają całą prywatną pamięć lokalnie, a na zewnątrz wysyłają wyłącznie zagregowane, anonimizowane zapytania, jeśli w ogóle. Dla entuzjastów otwartych narzędzi to dobra wiadomość: pełna kontrola nad własnym asystentem jest dziś osiągalna, a jednym z głównych elementów tej układanki jest właśnie lokalna baza wektorowa.

Podsumowanie

Baza wektorowa w OpenClaw to nie osobny program, lecz wbudowany mechanizm wyszukiwania semantycznego oparty na SQLite i hybrydowym łączeniu wektorów z pełnotekstowym indeksem. Domyślnie wektory liczy OpenAI, ale przestawienie na lokalne LM Studio jest proste i przynosi realne korzyści: prywatność, zerowy koszt i większą niezależność od chmury.

Konfiguracja sprowadza się do pięciu kroków: dodanie aliasu w `hosts`, ustawienie providera `openai-compatible` na lokalne LM Studio, restart bramy, sprawdzenie statusu i przebudowa indeksu. W efekcie Twój asystent rozumie znaczenie notatek, a dane zostają w Twojej sieci.

Jeśli coś nie działa, diagnoza zaczyna się od `openclaw memory status –deep`. A gdy chcesz iść dalej w stronę pełnej prywatności, kolejnym krokiem jest lokalny model jako główny agent. O tym opowiem w następnej części serii.