docs: fix typos across articles and building blocks

docs/articles/movie_recommendation_using_vectordb.md

@@ -267,7 +267,7 @@ torch.save(model.state_dict(), 'trained_model.pth')
 
 ## Implementing our movie RecSys
 
-To complete our movie recommendation system, we next set up our system so that users can input a movie title as a query. After this, our system retrieves Doc2Vec embeddings from our vector database, then uses similarity metrics such as cosine similarity or determines smallest Euclidian distances - to identify and recommend 'n' number of movies whose embeddings closely resemble those of the user's query movie, based on its genre/s.
+To complete our movie recommendation system, we next set up our system so that users can input a movie title as a query. After this, our system retrieves Doc2Vec embeddings from our vector database, then uses similarity metrics such as cosine similarity or determines smallest Euclidean distances - to identify and recommend 'n' number of movies whose embeddings closely resemble those of the user's query movie, based on its genre/s.
 
 ### Setting up our vector DB
 

docs/articles/multi-attribute-semantic-search.md

@@ -7,7 +7,7 @@
 There are two common approaches to multi-attribute vector search. Both start by separately embedding each attribute of a data object. The main difference between these two approaches is in how our embeddings are *stored* and *searched*.
 
 1. the *naive* approach - store each attribute vector in separate vector stores (one per attribute), perform a separate search for each attribute, combine search results, and post-process (e.g., weight) as required.
-2. the *Superlinked* approach - concatenate and store all attribute vectors in the same vector store (using Superlinked's built-in funtionality), which allows us to *search just once*, with attendant efficiency gains. Superlinked's `spaces` *also* let us weight each attribute at query time to surface more relevant results, with no post-processing.
+2. the *Superlinked* approach - concatenate and store all attribute vectors in the same vector store (using Superlinked's built-in functionality), which allows us to *search just once*, with attendant efficiency gains. Superlinked's `spaces` *also* let us weight each attribute at query time to surface more relevant results, with no post-processing.
 
 ![Two approaches to multi-attribute vector search](../assets/use_cases/multi-attribute-semantic-search/graphics.png)
 

docs/articles/retrieval_augmented_generation_eval_qdrant_ragas.md

@@ -251,7 +251,7 @@ EVAL_SIZE = 10
 RETRIEVAL_SIZE_3 = 3
 
 ## The dataset used to evaluate RAG using RAGAS
-## Note this is the dataset needed for evaluation hence has to be recreated everytime changes to RAG config is made
+## Note: this is the dataset needed for evaluation, so it must be recreated every time changes to the RAG config are made
 rag_eval_dataset_512_3 = create_eval_dataset(qdrant_qna_dataset,EVAL_SIZE,RETRIEVAL_SIZE_3)
 # The dataset is then exported as a CSV file, with a filename that includes details of the experiment for easy identification, such as the chunk size along with retrieval window used in this case  
 rag_response_dataset_512_3 = Dataset.from_dict(rag_eval_dataset_512_3)

docs/articles/scaling_rag_for_production.md

@@ -290,7 +290,7 @@ Now that our chunks are embedded, we need to **store** them somewhere. For the s
 from qdrant_client import QdrantClient
 from qdrant_client.http.models import Distance, VectorParams
 
-# Initalizing a local client in-memory
+# Initializing a local client in-memory
 client = QdrantClient(":memory:")
 
 client.recreate_collection(
@@ -313,7 +313,7 @@ from qdrant_client.models import PointStruct
 def store_results(df, collection_name="documents", client=client):
 	  # Defining our data structure
     points = [
-        # PointStruct is the data classs used in Qdrant
+        # PointStruct is the data class used in Qdrant
         PointStruct(
             id=hash(path),  # Unique ID for each point
             vector=embedding,

docs/articles/superlinked_langchain_retriever.md

@@ -188,7 +188,7 @@ These filters restrict the search space to specific filing types (e.g., 10-K, 8-
 .limit(sl.Param("limit"))
 ```
 This clause tells Superlinked which fields to return in the results. This minimizes unnecessary payload and keeps downstream processing efficient by including only the necessary metadata and report content. The limit clause limits the number of retrieved documents.
-Here is the complete query with defualt values for query parameters:
+Here is the complete query with default values for query parameters:
 
 ```python
 superlinked_query = (

docs/building_blocks/vector_compute/embedding_models.md

@@ -40,7 +40,7 @@ However, pre-trained models have performed better than custom models on others 
 
 Let’s look at some examples:
 
-[Llama-2](https://ai.meta.com/llama/), developed by Meta, is a set of LLMs pre-trained on a publically available corpus of data, with variants trained on 7B, 13B, 34B and 70B parameters. Llama-2 achieves highly impressive results on language tasks, but [as a decoder model](https://magazine.sebastianraschka.com/p/understanding-encoder-and-decoder) it is not well suited to vector embeddings.
+[Llama-2](https://ai.meta.com/llama/), developed by Meta, is a set of LLMs pre-trained on a publicly available corpus of data, with variants trained on 7B, 13B, 34B and 70B parameters. Llama-2 achieves highly impressive results on language tasks, but [as a decoder model](https://magazine.sebastianraschka.com/p/understanding-encoder-and-decoder) it is not well suited to vector embeddings.
 
 Another example is OpenAI, which leverages ELMo and GPT for unsupervised pre-training to create robust general linguistic representations. Read how [OpenAI has improved language understanding with unsupervised learning](https://openai.com/blog/language-unsupervised/).
 

docs/tools/vdb_table/README.md

@@ -37,7 +37,7 @@ Thanks for your interest in contributing to [vdbs.superlinked.com](https://vdbs.
 
 We use [discussions](https://github.com/superlinked/VectorHub/discussions/categories/vdb-comparison) as our way to have conversations about each vendor. Please find the relevant discussion and add to the conversation.
 
-Kindly review the following sections before you submit your issue or initial pull request, and use the approriate issues/PR template. In addition, check for existing open issues and pull requests to ensure that someone else has not already corrected the information.
+Kindly review the following sections before you submit your issue or initial pull request, and use the appropriate issues/PR template. In addition, check for existing open issues and pull requests to ensure that someone else has not already corrected the information.
 
 If you need any help, feel free to tag [@AruneshSingh](https://github.com/AruneshSingh) in your discussions/issues/PRs.