docs: consolidate pages that were split for no reason

Ten merges and renames, all in one direction: fewer pages, each covering a whole
subject.

Table absorbs schema evolution and versioning. Vector search absorbs
multi-vector. Explain absorbs explain analyze. Reranking was seven pages -- an
overview and six rerankers of a few dozen lines each -- and is now one. The
vector index page absorbs quantization, which was only ever a parameter of it.

Indexing moves to Manage, where the other catalog objects are. The operational
half stays in Operate as one Indexing page, absorbing GPU indexing -- which was
filed in sophon despite importing lancedb's snippets and being mostly
open-source content with one Enterprise-badged section.

Performance was a single page aggregating tips for four unrelated operations,
which is hard to keep current. Each section now sits with the operation it is
about: ingestion tips on Insert, index tips on Indexing, compaction tips on
Compaction, query tips on Search.

Data Types leaves Concepts. The type reference belongs in the SQL reference,
which already described the same types from the query side; Table now carries a
short summary that points there. The multimodal material it had absorbed is its
own page again, since storing blobs is a task rather than a type definition.

Query becomes Semantic Search, Branches becomes Branch, and the Enterprise
Security page becomes Compliance.

Redirects cover every moved URL, and 30 files were repointed at the merged
anchors.
This commit is contained in:
Jack Ye
2026-09-14 00:57:26 -07:00
parent fe651ae003
commit 19f8f396ec
48 changed files with 2209 additions and 2293 deletions
@@ -32,7 +32,7 @@ vector databases are ill-equipped to handle.
4. "We need to A/B test a new chunking strategy, but we can't disrupt the production system or duplicate the entire dataset." Experimentation is vital for improvement, but it can't come at the cost of production stability or a massive infrastructure bill.
LanceDB's [zero-cost data evolution](/tables/schema) and [time-travel capabilities](https://docs.lancedb.com/tables/versioning) directly address these critical enterprise pain points, providing the foundation for a reliable, auditable, and production-ready RAG system.
LanceDB's [zero-cost data evolution](/management/table#schema) and [time-travel capabilities](https://docs.lancedb.com/management/table#versioning) directly address these critical enterprise pain points, providing the foundation for a reliable, auditable, and production-ready RAG system.
## Dataset: The U.S. Federal Register {#dataset-the-us-federal-register}
+1 -1
View File
@@ -35,7 +35,7 @@ are runnable in Colab; the rest are written up here.
| [Vector search](/search/vector-search) | Similarity search, distance metrics, and tuning it. |
| [Full-text search](/search/full-text-search) | Keyword search over text columns. |
| [Hybrid search](/search/hybrid-search) | Keyword and vector search combined. |
| [Multi-vector search](/search/multivector-search) | Several embeddings per document. |
| [Multi-vector search](/search/vector-search) | Several embeddings per document. |
| [Reranking](/reranking) | Reordering results to improve the top-k. |
| [Feature engineering](/feature-engineering) | Deriving columns and tables from data already stored. |
| [Materialized views](/management/materialized-view) | A table defined by a query, refreshed incrementally. |
@@ -4,7 +4,7 @@ sidebarTitle: "Multi-vector XTR"
description: "Represent a document with many vectors, and speed retrieval with ConteXtualized Token Retrieval."
---
Covers [multi-vector search](/search/multivector-search) enhanced by XTR
Covers [multi-vector search](/search/vector-search) enhanced by XTR
(ConteXtualized Token Retriever): representing complex data with several vectors
for more nuanced meaning, and using XTR to speed retrieval by prioritizing the
most important tokens.