docs: clean up prose flagged by the shared Vale rules (#4596)

The existing docs have 254 findings from our shared Vale rules.
Contributors would otherwise inherit these when editing the same lines.

Clean up the prose across 80 pages: correct product names and a repeated
word, simplify a few phrases, and replace dashes with punctuation that
fits each sentence. The pinned Vale scan now reports zero findings, with
no suppressions.

docs/web/tutorials/agents/agentic-rag.mdx

@@ -4,8 +4,8 @@ sidebarTitle: "Agentic RAG"
 description: "Several agents collaborating to retrieve and answer."
 ---
 
-Builds a RAG system where multiple agents collaborate -- retrieving
-information, checking it, and generating answers -- rather than a single
+Builds a RAG system where multiple agents collaborate (retrieving
+information, checking it, and generating answers) rather than a single
 retrieve-then-generate pass.
 
 <Note>

docs/web/tutorials/agents/contextual-rag.mdx

@@ -6,7 +6,7 @@ description: "Prepend LLM-generated context to each chunk before embedding it."
 
 Addresses the "lost in the middle" problem in retrieval. An LLM generates a
 succinct piece of context for each document chunk, which is prepended to the
-chunk before embedding -- so a chunk carries enough surrounding meaning to be
+chunk before embedding, so a chunk carries enough surrounding meaning to be
 retrieved for the right queries.
 
 <Note>

docs/web/tutorials/agents/hyde.mdx

@@ -4,8 +4,8 @@ sidebarTitle: "HyDE"
 description: "Generate a hypothetical answer, then retrieve documents similar to it."
 ---
 
-An LLM writes a hypothetical document answering the query, and that document --
-not the query -- is embedded and used for retrieval. It works because a
+An LLM writes a hypothetical document answering the query, and that document,
+not the query, is embedded and used for retrieval. It works because a
 plausible answer sits nearer the real answers in embedding space than a question
 does.
 

docs/web/tutorials/agents/matryoshka-embeddings.mdx

@@ -5,7 +5,7 @@ description: "Nested, variable-size embeddings with LanceDB and LlamaIndex."
 ---
 
 A RAG pipeline built on Matryoshka embeddings with LlamaIndex. The embeddings
-nest, so one model serves several dimensionalities -- store the full vector and
+nest, so one model serves several dimensionalities: store the full vector and
 retrieve with a truncated one when the cheaper comparison is good enough.
 
 <Note>

docs/web/tutorials/agents/nvidia-rag-blueprint/index.mdx

@@ -150,7 +150,7 @@ This example is meant to prove more than a trivial vector lookup.
 - the adapter supports `RRFReranker`, `MRRReranker`, and `CrossEncoderReranker`
 - the default example uses `MRRReranker`, not a plain weighted linear combination
 
-That matters for NVIDIA partner workloads because product names, storage platforms, and technical
+Hybrid retrieval is important for NVIDIA partner workloads because product names, storage platforms, and technical
 jargon often need exact lexical matching as well as semantic retrieval.
 
 ## How this can be extended {#how-this-can-be-extended}

docs/web/tutorials/agents/time-travel-rag/index.mdx

@@ -11,7 +11,7 @@ All the scripts and code for this tutorial are available in the
 
 ## Use case: Financial services regulatory knowledge base {#use-case-financial-services-regulatory-knowledge-base}
 
-Imagine you're a major investment bank. Your team is tasked with building a critical Retrieval-Augmented Generation (RAG) system. This system must provide instant, accurate answers to compliance officers about ever-changing financial regulations. A wrong or out-of-date answer isn't just an inconvenience—it could lead to multi-million dollar fines, reputational damage, and regulatory audits.
+Imagine you're a major investment bank. Your team is tasked with building a critical Retrieval-Augmented Generation (RAG) system. This system must provide instant, accurate answers to compliance officers about ever-changing financial regulations. A wrong or out-of-date answer isn't just an inconvenience: it could lead to multi-million dollar fines, reputational damage, and regulatory audits.
 
 Your knowledge base is a living entity, constantly evolving with:
 

docs/web/tutorials/search/multivector-needle-in-a-haystack.mdx

@@ -53,7 +53,7 @@ A bi-encoder maps an entire piece of content (a query, a document page) to a *si
 
 ### Multi-vector (Late-Interaction) Models {#multi-vector-late-interaction-models}
 
-Multi-vector models, pioneered by ColBERT, take a different approach. Instead of one vector per page, they generate a *set of vectors* for each page—one for every token (or image patch).
+Multi-vector models, pioneered by ColBERT, take a different approach. Instead of one vector per page, they generate a *set of vectors* for each page: one for every token (or image patch).
 
 *   **Mechanism (MaxSim):** The search process is more sophisticated. For each token in the query, the system finds the most similar token on the page. These maximum similarity scores are then summed up to get the final relevance score. This "late-interaction" preserves fine-grained, token-level details.
 *   **The Models:** We used several vision-language models adapted for this architecture, including `ColPali`, `ColQwen2`, and `ColSmol`. While their underlying transformer backbones differ, they all share the ColBERT philosophy of representing documents as a bag of contextualized token embeddings.

docs/web/tutorials/search/ner-search.mdx

@@ -4,8 +4,8 @@ sidebarTitle: "NER Search"
 description: "Extract named entities and embed them to sharpen retrieval."
 ---
 
-Uses Named Entity Recognition to power vector search. Extracting entities --
-people, places, organizations -- and embedding them alongside the text improves
+Uses Named Entity Recognition to power vector search. Extracting entities
+(people, places, organizations) and embedding them alongside the text improves
 accuracy when queries are about specific things rather than general topics.
 
 <Note>

docs/web/tutorials/search/video-search.mdx

@@ -6,7 +6,7 @@ description: "Embed video with V-JEPA and search it by similarity."
 
 Builds a video search application on V-JEPA (Video Joint Embedding Predictive
 Architecture). Generates vector embeddings for video content and uses
-[vector search](/search/vector-search) to find visually similar clips -- a
+[vector search](/search/vector-search) to find visually similar clips: a
 multimodal case where the searchable column is not text.
 
 <Note>