Merge pull request #1973 from abdonpijpelink/update-images

Update two images in the docs

qdrant-landing/content/documentation/concepts/hybrid-queries.md

@@ -213,11 +213,11 @@ For all decay functions, there are these parameters available
 | `x`        | N/A     | The value to decay                                                                                                                                                                                |
 | `target`   | 0.0     | The value at which the decay will be at its peak. For distances it is usually set at 0.0, but can be set to any value.                                                                            |
 | `scale`    | 1.0     | The value at which the decay function will be equal to `midpoint`. This is in terms of `x` units, for example, if `x` is in meters, `scale` of 5000 means 5km. Must be a non-zero positive number |
-| `midpoint` | 0.5     | Output is `midpoint` when `x` equals `scale`. Must be in the range (0.0, 1.0), exclusive                                                                                                          |
+| `midpoint` | 0.5     | Output is `midpoint` when `x` equals `target` ± `scale`. Must be in the range (0.0, 1.0), exclusive                                                                                                          |
 
-The formulas for each decay function are as follows:
+![Decay functions.](/docs/decay-function.png)
 
-<iframe src="https://www.desmos.com/calculator/idv5hknwb1?embed" width="600" height="400" style="border: 1px solid #ccc" frameborder=0 class="mx-auto d-block"></iframe>
+The [formulas for each decay function](https://www.desmos.com/calculator/idv5hknwb1) are as follows:
 
 <br>
     

qdrant-landing/content/documentation/guides/distributed_deployment.md

@@ -1088,9 +1088,11 @@ Before responding to the client, the peer handling the request dispatches all op
 - reads are using a partial fan-out strategy to optimize latency and availability
 - writes are executed in parallel on all active sharded replicas
 
-![Embeddings](/docs/concurrent-operations-replicas.png)
+By default, concurrent updates on one point can result in an inconsistent state. For example, if two clients simultaneously update the same point in a collection with three replicas per shard. On some replicas, the point may reflect the update from one client, while on other replicas, the point may reflect the update from the other client.
 
-However, in some cases, it is necessary to ensure additional guarantees during possible hardware instabilities, mass concurrent updates of same documents, etc.
+![Two clients updating the same point at the same time.](/docs/concurrent-operations-replicas.png)
+
+In some cases, it is necessary to ensure additional guarantees during possible hardware instabilities, mass concurrent updates of same documents, etc.
 
 Qdrant provides a few options to control consistency guarantees: