Merge pull request #3544 from vespa-engine/kkraune-patch-1

fix IDs and typos

en/phased-ranking.html

@@ -48,7 +48,7 @@
 
 
 
-<h2 id="first-phase-ranking">First-phase ranking on content nodes</h2>
+<h2 id="first-phase-ranking-on-content-nodes">First-phase ranking on content nodes</h2>
 <p>
   Normally, you will always start by having one ranking expression
   that is evaluated on the content nodes.  This is configured in
@@ -67,7 +67,7 @@ <h2 id="first-phase-ranking">First-phase ranking on content nodes</h2>
 
 
 
-<h2 id="two-phase-ranking-content-nodes">Two-phase ranking on content nodes</h2>
+<h2 id="two-phase-ranking-on-content-nodes">Two-phase ranking on content nodes</h2>
 <p>
   While some use cases only require one (simple) first-phase
   ranking expression, for more advanced use cases it's possible to
@@ -111,9 +111,9 @@ <h2 id="two-phase-ranking-content-nodes">Two-phase ranking on content nodes</h2>
 </p>
 
 
-<h2 id="global-phase">Using a global-phase expression</h2>
+<h2 id="using-a-global-phase-expression">Using a global-phase expression</h2>
 <p>
-  Using a rank expressions configured as a
+  Using a rank expression configured as a
   <a href="reference/schema-reference.html#globalphase-rank">global-phase</a>
   in the <code>rank-profile</code> section of a schema, you can add
   a ranking phase that will run in the stateless container after
@@ -208,7 +208,7 @@ <h2 id="global-phase">Using a global-phase expression</h2>
 </pre>
 <p>
   In the above example, the <em>my_expensive_function</em> will be evaluated on the content nodes
-  for the 50 top ranking documents from the first-phase so that the global-phase does not need to re-evaluate.
+  for the 50 top-ranking documents from the first-phase so that the global-phase does not need to re-evaluate.
 </p>
 
 
@@ -232,10 +232,10 @@ <h2 id="cross-hit-normalization-including-reciprocal-rank-fusion">Cross-hit norm
   reranks (see <a href="#globalphase-rerank-count">configuration</a> above).
   This means that first, the input (<em>my_function_or_feature</em>)
   is computed or extracted from each hit that global-phase will
-  rerank; then the normalization step is applied; afterwards when
-  computing the actual global-phase expression the normalized output
+  rerank; then the normalization step is applied; afterwards, when
+  computing the actual global-phase expression, the normalized output
   is used.
-  As an example, assume some text fields with bm25 enabled, an onnx
+  As an example, assume some text fields with bm25 enabled, an ONNX
   model (from the <a href="#myapp-with-global-model">example</a> in
   the previous section), and a "popularity" numeric attribute:
 </p>
@@ -256,7 +256,7 @@ <h2 id="cross-hit-normalization-including-reciprocal-rank-fusion">Cross-hit norm
     }
 </pre>
 <p>
-  The <code>normalize_linear</code> normalizer takes a single argument which must be
+  The <code>normalize_linear</code> normalizer takes a single argument, which must be
   a rank-feature or the name of a function.  It computes the maximum and minimum
   values of that input and scales linearly to the range [0, 1], basically using
   the formula <code>output = (input - min) / (max - min)</code>
@@ -265,9 +265,9 @@ <h2 id="cross-hit-normalization-including-reciprocal-rank-fusion">Cross-hit norm
   The <code>reciprocal_rank</code> normalizer takes one or two arguments; the first
   must be a rank-feature or the name of a function, while the second (if present)
   must be a numerical constant, called <code>k</code> with default value 60.0.
-  It sorts the input values and finds their <em>rank</em> (so highest score gets
+  It sorts the input values and finds their <em>rank</em> (so the highest score gets
   rank 1, next highest 2, and so on). The output from reciprocal_rank is computed
-  with the formula <code> output = 1.0 / (k + rank) </code> so note that even the best
+  with the formula <code> output = 1.0 / (k + rank) </code>, so note that even the best
   input only gets <code>1.0 / 61 = 0.016393</code> as output with the default k.
 </p>
 <p>
@@ -302,9 +302,9 @@ <h2 id="stateless-re-ranking">Stateless re-ranking</h2>
   The number of <em>hits</em> is limited by the query api
   <a href="reference/query-api-reference.html#hits">hits</a> parameter and
   <a href="reference/query-api-reference.html#queryprofile">maxHits</a> setting.
-  The hits available for container level re-ranking are the global top ranking hits
-  after content nodes have retrieved and ranked the hits
-  and global top ranking hits have been found by merging the responses from the content nodes.
+  The hits available for container-level re-ranking are the global top-ranking hits
+  after content nodes have retrieved and ranked the hits,
+  and global top-ranking hits have been found by merging the responses from the content nodes.
 </p>
 
 
@@ -320,7 +320,7 @@ <h2 id="top-k-query-operators">Top-K Query Operators</h2>
 </p>
 <p>
   The <a href="nearest-neighbor-search.html">nearest neighbor search</a> operator is also a top-k 
-  retrieval operator and the two operators can be combined in the same query.
+  retrieval operator, and the two operators can be combined in the same query.
 </p>
 
 
@@ -329,9 +329,9 @@ <h2 id="choosing-phased-ranking-functions">Choosing phased ranking functions</h2
 <p>
 A good quality ranking expression will for most applications consume too much CPU
 to be runnable on all retrieved or matched documents within the latency budget/SLA.
-The application ranking function should hence in most cases be a second phase function.
-The task then becomes to find a first phase function,
-which correlates sufficiently well with the second phase function.
+The application ranking function should hence in most cases be a second-phase function.
+The task then becomes to find a first-phase function,
+which correlates sufficiently well with the second-phase function.
 </p>
 
 
@@ -469,7 +469,7 @@ <h2 id="rank-phase-statistics">Rank phase statistics</h2>
 
 <h3 id="usage">Usage</h3>
 <p>
-  The framework is flexible in use, the normal use case is:
+  The framework is flexible in use; the normal use case is:
 </p>
 <ol>
   <li>
@@ -507,7 +507,7 @@ <h3 id="usage">Usage</h3>
 </p>
 <pre>
 field match_count type long {
-    indexing: 7 | to_long | attribute | summary   # Initialized to 7 for a new document. Default is 0.
+    indexing: 7 | to_long | attribute | summary   # Initialized to 7 for a new document. The default is 0.
     attribute: mutable
 }
 </pre>