Concept Fable

Weaviate

Conclusion first:Weaviate is an open-source vector database that combines vector search, structured filtering, keyword search (BM25), and schema-based object storage. Its core design philosophy is 'vectorize everything': each data object can simultaneously have vectors, structured attributes, and keyword inverted indexes, and queries can use them in a weighted hybrid manner. Weaviate supports GraphQL and RESTful APIs, automatic vectorization (through integrated embedding models), multi-tenancy, modular extensions (such as summarizer, QA, NER, etc.), and a native implementation of hybrid search. In enterprise RAG scenarios, Weaviate is suitable for unified retrieval platforms that require schema management, hybrid search, and multimodal data (text, images, etc.). Its GraphQL interface is especially friendly to applications with complex query logic.

Weaviate · Open-source vector database

Read the story first. There is no rush to give a definition here; let the question grow on its own first.

Fable

The pharmacy manager puts efficacy, prescriptions and contraindications on the same medicine drawer

The old pharmacy had three independent retrieval systems: one for searching by medicine name, one by symptom, and one by formula. The shopkeeper said managing them separately was clearest, and the dispensing pharmacists were used to it too. Until one emergency prescription came in: 'Find formulas with effects close to Mahuang Tang, but exclude medicines containing ephedra, suitable for children over three, and covered by medical insurance.' The pharmacist first checked the formula cabinet, then the medicine-name cabinet for ingredients, then the symptom cabinet for contraindications, and then manually cross-referenced three stacks of paper.

The young apprentice wrote a lookup table and stuck it on the wall, listing the path 'Mahuang Tang → similar formula → reduce ephedra → add age → add medical insurance'. Two weeks later the table was covered with exceptions and arrows, more dizzying than looking it up directly.

Someone proposed merging the three complete sets of apparatus into one large general ledger cabinet, writing all attributes on the same row. After the merge, queries were indeed simpler, but a new problem appeared: some prescriptions were textual descriptions, some were numerical indicators, and some were herbal compatibility diagrams; cramming them all into fixed columns quickly caused field explosion.

The newly arrived director of compounding changed the approach. He treated each prescription as an independent object, with several things attached to it at the same time: a set of description ciphertext for similarity matching, a set of structured attributes for precise filtering, a set of keywords for literal search, and also space reserved for custom question-answer pairs and summaries.

At query time, the pharmacy can call all three methods at once: use text descriptions to find the formula with the closest effects, use structured fields to filter out contraindications and age, and use keywords to lock onto terms like 'strengthen the spleen' and 'remove dampness'. The three signals are weighted and fused, returning results in one pass.

He also defined classes on the data mechanism: each class pre-declared attribute types and indexing methods. The 'formula' class had a herb list, efficacy vector, and contraindication conditions; the 'herb' class had a nature-flavor-meridian vector, price, and inventory. Different classes could reference each other.

Later the pharmacy also connected external data sources: the medical insurance catalog, epidemic bulletins, and new drug approval announcements. Each data source connected through the same data mechanism, and prescription objects automatically inherited the new information.

The old proprietor finally admitted: a prescription is not a patchwork of independent fields; it is a complete object with structure and semantics that can be retrieved from multiple angles at once.

Reveal

This story is about: Weaviate

Weaviate is an open-source vector database that combines vector search, structured filtering, keyword search (BM25), and schema-based object storage. Its core design philosophy is 'vectorize everything': each data object can simultaneously have vectors, structured attributes, and keyword inverted indexes, and queries can use them in a weighted hybrid manner. Weaviate supports GraphQL and RESTful APIs, automatic vectorization (through integrated embedding models), multi-tenancy, modular extensions (such as summarizer, QA, NER, etc.), and a native implementation of hybrid search. In enterprise RAG scenarios, Weaviate is suitable for unified retrieval platforms that require schema management, hybrid search, and multimodal data (text, images, etc.). Its GraphQL interface is especially friendly to applications with complex query logic.

What matters is that it is not just a term, but a structural problem that repeatedly appears in real AI / Agent systems. Understanding it lets you judge when to add a model, when to change a process, and when to add governance.

Metaphor mapping

Three independent retrieval systems: vector store, SQL database and search engine kept separate, with queries assembled at the application layer
A lookup path posted on the wall: hardcoded logic in the application layer orchestrating multiple data sources, fragile and hard to maintain
Field explosion: cramming all attributes into a flat table, ignoring that different data types need different indexing strategies
Independent objects carry three types of information: Weaviate's data model, with vectors + attributes + keyword indexes coexisting
Describe ciphertext: vector embedding, used for semantic similarity
Structured fields: scalar attributes for precise filtering (numbers, dates, booleans, strings, etc.)
Weighted fusion of three signals: rank fusion in hybrid search, keyword + vector mixed scoring
Class definitions and property types: Weaviate schema, pre-declaring data structures and indexing strategies

Andy Ren Xu's judgment

The practical value of this concept is that it helps you break "AI features that look smart" into deliverable, verifiable, and governable units of work.

vector databasehybrid searchGraphQLsemantic searchRAG