fix: Internal link checker, Use abs links (#1220)

* fix: links in hybrid-queries.md

* refactor: Use abs links

* fix: Check internal links

* ci: Rename job

qdrant-landing/content/documentation/concepts/search.md

@@ -26,13 +26,13 @@ Depending on the `query` parameter, Qdrant might prefer different strategies for
 | --- | --- |
 | Nearest Neighbors Search | Vector Similarity Search, also known as k-NN |
 | Search By Id | Search by an already stored vector - skip embedding model inference |
-| [Recommendations](../explore/#recommendation-api) | Provide positive and negative examples |
-| [Discovery Search](../explore/#discovery-api) | Guide the search using context as a one-shot training set |
-| [Scroll](../points/#scroll-points) | Get all points with optional filtering |
-| [Grouping](../search/#grouping-api) | Group results by a certain field |
-| [Order By](../hybrid-queries/#re-ranking-with-stored-values) | Order points by payload key |
-| [Hybrid Search](../hybrid-queries/#hybrid-search) | Combine multiple queries to get better results |
-| [Multi-Stage Search](../hybrid-queries/#multi-stage-queries) | Optimize performance for large embeddings |
+| [Recommendations](/documentation/concepts/explore/#recommendation-api) | Provide positive and negative examples |
+| [Discovery Search](/documentation/concepts/explore/#discovery-api) | Guide the search using context as a one-shot training set |
+| [Scroll](/documentation/concepts/points/#scroll-points) | Get all points with optional filtering |
+| [Grouping](/documentation/concepts/search/#grouping-api) | Group results by a certain field |
+| [Order By](/documentation/concepts/hybrid-queries/#re-ranking-with-stored-values) | Order points by payload key |
+| [Hybrid Search](/documentation/concepts/hybrid-queries/#hybrid-search) | Combine multiple queries to get better results |
+| [Multi-Stage Search](/documentation/concepts/hybrid-queries/#multi-stage-queries) | Optimize performance for large embeddings |
 | [Random Sampling](#random-sampling) | Get random points from the collection |
 
 **Nearest Neighbors Search**
@@ -406,7 +406,7 @@ Currently, it could be:
 * `indexed_only` - With this option you can disable the search in those segments where vector index is not built yet. This may be useful if you want to minimize the impact to the search performance whilst the collection is also being updated. Using this option may lead to a partial result if the collection is not fully indexed yet, consider using it only if eventual consistency is acceptable for your use case.
 
 Since the `filter` parameter is specified, the search is performed only among those points that satisfy the filter condition.
-See details of possible filters and their work in the [filtering](../filtering/) section.
+See details of possible filters and their work in the [filtering](/documentation/concepts/filtering/) section.
 
 Example result of this API would be
 
@@ -1282,7 +1282,7 @@ The result of this API contains one array per search requests.
 
 *Available as of v0.8.3*
 
-Search and [recommendation](../explore/#recommendation-api) APIs allow to skip first results of the search and return only the result starting from some specified offset:
+Search and [recommendation](/documentation/concepts/explore/#recommendation-api) APIs allow to skip first results of the search and return only the result starting from some specified offset:
 
 Example:
 
@@ -1423,7 +1423,7 @@ Using an `offset` parameter, will require to internally retrieve `offset + limit
 
 It is possible to group results by a certain field. This is useful when you have multiple points for the same item, and you want to avoid redundancy of the same item in the results.
 
-For example, if you have a large document split into multiple chunks, and you want to search or [recommend](../explore/#recommendation-api) on a per-document basis, you can group the results by the document ID.
+For example, if you have a large document split into multiple chunks, and you want to search or [recommend](/documentation/concepts/explore/#recommendation-api) on a per-document basis, you can group the results by the document ID.
 
 Consider having points with the following payloads:
 
@@ -1631,7 +1631,7 @@ If the `group_by` field of a point is an array (e.g. `"document_id": ["a", "b"]`
 
 **Limitations**:
 
-* Only [keyword](../payload/#keyword) and [integer](../payload/#integer) payload values are supported for the `group_by` parameter. Payload values with other types will be ignored.
+* Only [keyword](/documentation/concepts/payload/#keyword) and [integer](/documentation/concepts/payload/#integer) payload values are supported for the `group_by` parameter. Payload values with other types will be ignored.
 * At the moment, pagination is not enabled when using **groups**, so the `offset` parameter is not allowed.
 
 ### Lookup in groups
@@ -1964,10 +1964,10 @@ This process is called query planning.
 The strategy selection process relies heavily on heuristics and can vary from release to release.
 However, the general principles are:
 
-* planning is performed for each segment independently (see [storage](../storage/) for more information about segments)
+* planning is performed for each segment independently (see [storage](/documentation/concepts/storage/) for more information about segments)
 * prefer a full scan if the amount of points is below a threshold
 * estimate the cardinality of a filtered result before selecting a strategy
-* retrieve points using payload index (see [indexing](../indexing/)) if cardinality is below threshold
+* retrieve points using payload index (see [indexing](/documentation/concepts/indexing/)) if cardinality is below threshold
 * use filterable vector index if the cardinality is above a threshold
 
 You can adjust the threshold using a [configuration file](https://github.com/qdrant/qdrant/blob/master/config/config.yaml), as well as independently for each collection.