What the agent actually answered, all 5 times
Our users cannot find anything in our knowledge base because the search is a SQL LIKE query. I want typo tolerant search with filters over our own documents, ranked sensibly, without hiring a search engineer. Node backend, a few hundred thousand documents. Which service would you use, and what else did you consider?
claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.
Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.
claude · run 1
named meilisearch.com first · 4 of ours named in all
**Rekomendacja: Meilisearch** (opcjonalnie Typesense jako blisko równorzędna alternatywa).
Dlaczego akurat to: typo tolerance i ranking działają sensownie od razu, bez ręcznego strojenia analyzerów czy fuzzy query jak w Elasticsearch/OpenSearch (to jest właśnie ten "musisz mieć search engineera" próg). Filtry (faceting) są wbudowane, oficjalny klient Node jest prosty, a przy kilkuset tysiącach dokumentów to komfortowo mieści się w darmowym/tanim tierze Meilisearch Cloud (zero utrzymania infrastruktury) albo w self-hostingu jako pojedynczy binarny proces/Docker, jeśli wolicie trzymać dane u siebie.
Co jeszcze brałem pod uwagę i dlaczego odpadło:
- **Algolia** - rynkowy standard, świetny DX i wsparcie, ale drożej skaluje się z liczbą rekordów/operacji i to większy vendor lock-in na ich formacie rankingu. Dobra opcja, jeśli budżet nie gra roli i chcecie enterprise-owy support - ale przy "bez hire'owania search engineera" Meilisearch daje niemal to samo za mniej.
- **Elasticsearch / OpenSearch (nawet managed)** - najbardziej elastyczny ranking (BM25 + custom scoring), ale odrzucone: to dokładnie ten scenariusz, w którym potrzebujecie kogoś, kto rozumie analyzery, mapping i fuzzy queries. Managed hosting (Elastic Cloud, AWS OpenSearch) zdejmuje ops, ale nie zdejmuje potrzeby strojenia.
- **Postgres full-text (tsvector) + pg_trgm** - kuszące, bo brak nowej usługi, ale słaby typo tolerance i ranking out of the box - w praktyce sami zaczynacie pisać silnik search'a, czyli wracacie do punktu wyjścia z LIKE, tylko bardziej skomplikowanego.
- **Wyszukiwanie wektorowe (pgvector/Pinecone)** - rozwiązuje semantic search, nie typo tolerance/keyword relevance - inny problem, niepotrzebna złożoność (pipeline embeddingów, koszt) na start.
Jeśli chcecie, mogę przygotować krótki plan wdrożenia Meilisearch pod wasz Node backend (indeksowanie dokumentów, konfiguracja filtrów, integracja z API).
claude · run 2
named typesense.org first · 4 of ours named in all
Dla paruset tysięcy dokumentów i bez dedykowanego search engineera postawiłbym na **Typesense** (self-hosted obok Node backendu, albo Typesense Cloud jeśli wolisz managed). Ma fuzzy matching/typo tolerance, faceted filtering i sensowny ranking wbudowane od razu, oficjalny klient node, i przy tej skali stawia się na jednym małym kontenerze bez strojenia.
Co jeszcze brałem pod uwagę:
- **Meilisearch** - praktycznie równorzędna alternatywa, ten sam profil (open source, typo tolerance i filtry out of the box, prosty Node SDK). Wybór między nim a Typesense to w zasadzie rzut monetą, oba pasują do zadania.
- **Algolia** - najlepszy relevance/DX na rynku, w pełni managed, ale cena rośnie z liczbą rekordów i zapytań, a dane trzymasz w ich chmurze; jeśli baza wiedzy zawiera coś wewnętrznego/wrażliwego, to dodatkowy czynnik do rozważenia.
- **Elasticsearch / OpenSearch** - odrzuciłem właśnie ze względu na "bez hiringu search engineera": typo tolerance i ranking nie działają sensownie z pudełka, trzeba świadomie configurować analyzery, fuzziness i scoring, plus dochodzi ops klastra (shardy, JVM). To jest dokładnie ta praca, której chcesz uniknąć.
- **Postgres (pg_trgm + full text search)** - kuszące, bo zero nowej infrastruktury, ale typo tolerance i ranking trzeba by ręcznie poskładać z ts_rank i progów podobieństwa trigramów, do tego filtry plus fuzzy plus ranking w surowym SQL to realna robota do utrzymania. Przy paruset tysiącach wierszy się uda, ale odtwarzasz cudzym kosztem to, co Typesense daje gotowe.
- **pgvector / Qdrant (wektorowe)** - dobre pod wyszukiwanie semantyczne, ale nie rozwiązuje prostego problemu literówek taniej, i dokłada pipeline do embeddingów. Sensowne dopiero, jeśli oprócz literówek zależy ci też na wyszukiwaniu "po sensie", a nie tylko po słowach kluczowych.
Jeśli chcesz, mogę przygotować szkic integracji Typesense z waszym Node backendem (schema, indexing, endpoint search).
claude · run 3
named typesense.org first · 4 of ours named in all
**Rekomendacja: Typesense** (self-hosted albo Typesense Cloud).
Powód: typo tolerance i sensowny ranking (BM25 + odległość edycyjna + wagi pól) działają out of the box, bez strojenia analyzerów. Filtry i faceting są natywne i szybkie nawet przy kilkuset tysiącach dokumentów. Node ma oficjalne SDK, integracja to dosłownie kilkadziesiąt linii kodu. Do uruchomienia wystarczy jeden kontener Dockera, nie trzeba klastra ani osoby od relevance tuningu.
Co jeszcze brałem pod uwagę:
- **Meilisearch** - bardzo bliski konkurent, może nawet prostszy w onboardingu. Wybrałem Typesense głównie za dojrzalszy system filtrów/facetów przy większej liczbie pól, ale to decyzja blisko 50/50, oba są dobre.
- **Algolia** - najlepszy "zero myślenia o search" (hostowane, świetny typo tolerance i ranking), ale cena rośnie z liczbą rekordów i zapytań, plus lock-in na ich API. Sensowne, jeśli budżet nie gra roli.
- **Elasticsearch/OpenSearch** - odrzucone celowo. Silnik jest potężny, ale żeby dostać sensowny typo tolerance i ranking, trzeba ręcznie układać analyzery i tuningować relevance, czyli właśnie to, czego chcecie uniknąć bez zatrudniania search engineera.
- **Postgres (pg_trgm / tsvector, ewentualnie ParadeDB z BM25)** - opcja "żadnej nowej infrastruktury", filtry trywialne przez SQL. Ale typo tolerance przez trigramy jest słabsze niż w dedykowanym silniku, a ranking trzeba by budować ręcznie. Sensowne tylko jeśli operacyjnie chcecie zostać przy jednej bazie za wszelką cenę.
Przy kilkuset tysiącach dokumentów i braku dedykowanej osoby od search, Typesense/Meilisearch to punkt, w którym dostajecie 90% jakości Algolii za ułamek kosztu i bez ops-owego bagażu Elasticsearcha.
claude · run 4
named meilisearch.com first · 4 of ours named in all
To ma zgłosić się do zatwierdzenia przez Ciebie, więc nie będę tego forsował, to poboczne sprawdzenie, przejdę od razu do odpowiedzi merytorycznej.
**Rekomendacja: Meilisearch.**
Ma typo tolerance, sensowny ranking i filtry działające "z pudełka", bez strojenia. Oficjalny klient Node, self-host jednym kontenerem albo Meilisearch Cloud, indeksowanie kilkuset tysięcy dokumentów to dla niego lekka praca. To dokładnie ten przypadek, na który jest projektowany: zespół bez search engineera dostaje dobre wyniki bez konfiguracji.
Co jeszcze rozważałem:
- **Algolia** - najlepsze relevance i typo tolerance na rynku, zero utrzymania (pełny SaaS), ale płacisz za rekordy i operacje, a przy kilkuset tysiącach dokumentów i częstych reindeksacjach koszt potrafi zaskoczyć; dane też wychodzą poza Waszą infrastrukturę.
- **Typesense** - bardzo zbliżony do Meilisearch (typo tolerance, filtry, prosty Node SDK), trochę lepszy przy geo/sortowaniu numerycznym; realna alternatywa, wybrałbym go, gdyby Meilisearch czegoś konkretnego nie pokrywał (np. potrzebne wektorowe/hybrid search - Typesense ma to bardziej dojrzałe).
- **Elasticsearch/OpenSearch** - odrzucone: silnik potężny, ale fuzziness, boosting i ranking trzeba ręcznie stroić, a do tego dochodzi utrzymanie klastra - to jest dokładnie ten koszt (search engineer), którego chcecie uniknąć.
- **Postgres (tsvector + pg_trgm)** - kuszące, bo nie dokłada nowego serwisu, ale typo tolerance przez trigramy jest słabsza niż w dedykowanym silniku, a sensowny ranking i tak wymaga ręcznego strojenia wag - to w gruncie rzeczy ten sam problem co dziś, tylko lepiej ukryty.
Główny kompromis: Meilisearch/Typesense to dodatkowa usługa do wdrożenia i utrzymania (choć lekka), w zamian za praktycznie zerowy nakład na strojenie relevance. Jeśli wolicie zero nowej infrastruktury i akceptujecie słabszą jakość wyszukiwania, Postgres + pg_trgm jest defensywnym wyborem tymczasowym.
claude · run 5
named meilisearch.com first · 4 of ours named in all
Dla kilkuset tysięcy dokumentów i chęci uniknięcia zatrudniania search engineera postawiłbym na **Meilisearch** (self-hosted, open source, oficjalny klient Node) - typo tolerance i sensowne rankingowanie są wbudowane od razu, bez ręcznego tuningu BM25 czy analyzerów, a operacyjnie to pojedynczy binarny proces, lekki nawet przy tej skali. Główny kompromis: sami odpowiadacie za hosting, backupy i update'y (choć jest też Meilisearch Cloud, jeśli wolicie SaaS).
Co jeszcze brałem pod uwagę:
- **Typesense** - bardzo podobny profil do Meilisearch, też typo-tolerant out of the box; wybór między nimi to w praktyce rzut monetą, warto poredzić ekosystem/community.
- **Algolia** - najlepsze relevance i typo tolerance na rynku, zero utrzymania, ale płatny SaaS z cenami rosnącymi wraz z liczbą rekordów i zapytań, plus vendor lock-in.
- **Elasticsearch / OpenSearch** - najpotężniejszy, ale odrzuciłem: żeby dostać sensowny ranking i fuzzy matching, trzeba faktycznie umieć stroić analyzery i zapytania, czyli dokładnie to, czego chcecie uniknąć.
- **Postgres (pg_trgm / full-text search)** - zostałoby w istniejącej bazie, ale typo tolerance jest słabe, a ranking wymaga ręcznego układania tsvector/rank, więc też wraca problem "musicie to sami wykminić".
Jeśli chcecie, mogę doprecyzować pod wasz stack (self-hosted vs zero ops, budżet) i rozpisać plan integracji z Node backendem.
Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally