diff --git a/tutorials/component-yaml-spec.md b/tutorials/component-yaml-spec.md
index a6c6db74..cadc96ba 100644
--- a/tutorials/component-yaml-spec.md
+++ b/tutorials/component-yaml-spec.md
@@ -6,7 +6,12 @@ Essentially, GNES requires two types of YAML config:
- [GNES-compose YAML](gnes-compose-yaml-spec.md)
- Component-wise YAML
-
+
+
+ 
+
+
+
All other YAML files, including the docker-compose YAML config and Kubernetes config generated from the [GNES Board](https://board.gnes.ai) or `gnes compose` command are not a part of this tutorial. Interested readers are welcome to read their [YAML specification](https://docs.docker.com/compose/compose-file/) respectively.
@@ -241,10 +246,22 @@ You can find a lot of examples in the [unittest](../tests/yaml)
For many real-world applications, a single encoder is often not enough. For example, the output of a `BertEncoder` is 768-dimensional. One may want to append it with some dimensional reduction or quantization models. Of course one can spawn every encoder as an independent container and then connect them together via GNES Board/`gnes compose`. But if you don't need them to be elastic, why bother? This is where `PipelineEncoder` can be very useful: it stacks multiple `BaseEncoder` together, simplifying data-flow in all runtimes (i.e. training, indexing and querying).
#### PipelineEncoder in the training runtime
-
+
+
+
+ 
+
+
+
#### PipelineEncoder in the indexing and querying runtimes
-
+
+
+
+
+ 
+
+
To define a `PipelineEncoder`, you just need to sort the encoders in the right order and put them in a list under the `component` field. Let's look at the following example:
diff --git a/tutorials/gnes-compose-yaml-spec.md b/tutorials/gnes-compose-yaml-spec.md
index 036727c4..f7a9c44f 100644
--- a/tutorials/gnes-compose-yaml-spec.md
+++ b/tutorials/gnes-compose-yaml-spec.md
@@ -102,7 +102,7 @@ services:
- 
+ 
|
@@ -136,7 +136,7 @@ which results a topology like the following:
- 
+
|