|
| 1 | +# Varient Length supported RNN Design |
| 2 | +For the learning of variable length sequences, the existing mainstream frameworks such as tensorflow, pytorch, caffe2, mxnet and so on all use padding. |
| 3 | + |
| 4 | +Different-length sequences in a mini-batch will be padded with zeros and transformed to same length. |
| 5 | + |
| 6 | +The existing RNN implementations of the PaddlePaddle is `RecurrentLayerGroup`, |
| 7 | +which supports the variable length sequences without padding. |
| 8 | +This doc will design fluid's RNN based on this idea. |
| 9 | + |
| 10 | +## Multi-layer sequence data format `LODTensor` |
| 11 | +At present, Paddle stores data in one mini-batch in one-dimensional array. |
| 12 | + |
| 13 | +`Argument.sequenceStartPositions` is used to store information for each sentence. |
| 14 | + |
| 15 | +In Paddle, `Argument.subSequenceStartPositions` is used to store 2 levels of sequence information, while higher dimensional sequences can not be supported. |
| 16 | + |
| 17 | +In order to support the storage of `N-level` sequences, we define sequence information as the following data structure. |
| 18 | + |
| 19 | + |
| 20 | +```c++ |
| 21 | +std::shared_ptr<std::vector<std::vector<int>>> lod_start_pos_; |
| 22 | +``` |
| 23 | + |
| 24 | +Or more clearly defined here |
| 25 | + |
| 26 | +```c++ |
| 27 | +typedef std::vector<int> level_t; |
| 28 | +std::vector<level_t> lod_start_pos; |
| 29 | +``` |
| 30 | +Each `level_t` here stores a level of offset information consistent with paddle's current practice. |
| 31 | + |
| 32 | +In order to transmit sequence information more transparently, we have introduced a new tensor called `LODTensor`[1]. |
| 33 | +Its tensor-related interfaces all inherit directly from `Tensor`, but it also adds serial-related interfaces. |
| 34 | +Thus, when working with a `LODTensor`, ordinary `Op` is used directly as `Tensor`. |
| 35 | +The `Op` of the operation sequence will additionally operate the relevant interface of the `LODTensor` variable-length sequence operation. |
| 36 | + |
| 37 | +The definition of `LODTensor` is as follows: |
| 38 | + |
| 39 | + |
| 40 | +```c++ |
| 41 | +class LODTensor : public Tensor { |
| 42 | +public: |
| 43 | + size_t Levels() const { return seq_start_positions_.size(); } |
| 44 | + size_t Elements(int level = 0) const { |
| 45 | + return seq_start_positions_[level].size(); |
| 46 | + } |
| 47 | + // slice of level[elem_begin: elem_end] |
| 48 | + // NOTE low performance in slice seq_start_positions_. |
| 49 | + // TODO should call Tensor's Slice. |
| 50 | + LODTensor LODSlice(int level, int elem_begin, int elem_end) const; |
| 51 | + |
| 52 | + // slice with tensor's data shared with this. |
| 53 | + LODTensor LODSliceShared(int level, int elem_begin, int elem_end) const; |
| 54 | + |
| 55 | + // copy other's lod_start_pos_, to share LOD info. |
| 56 | + // NOTE the LOD info sould not be changed. |
| 57 | + void ShareConstLODFrom(const LODTensor &other) { |
| 58 | + lod_start_pos_ = other.lod_start_pos_; |
| 59 | + } |
| 60 | + // copy other's lod_start_pos_'s content, free to mutate. |
| 61 | + void ShareMutableLODFrom(const LODTensor &other) { |
| 62 | + lod_start_pos_ = std::make_shared < |
| 63 | + std::vector<std::vector<int>>(other.lod_start_pos_.begin(), |
| 64 | + other.lod_start_pos_.end()); |
| 65 | + } |
| 66 | + |
| 67 | +private: |
| 68 | + std::shared_ptr<std::vector<std::vector<int>>> lod_start_pos_; |
| 69 | +}; |
| 70 | +``` |
| 71 | +Among them, `lod_start_pos_` uses `shared_ptr` to reduce the cost of storage and replication. |
| 72 | +`LODTensor` can be thought as an extension of `Tensor`, which is almost completely compatible with the original `Tensor`. |
| 73 | +
|
| 74 | +## How to support the framework |
| 75 | +### Replace `Tensor` with `LoDTensor` |
| 76 | +To implement the passing of `LODTensor`, most `Tensor` in the framework need to be replaced with `LODTensor`. |
| 77 | +Simple implementation, directly **replace all previous `Tensor` with `LODTensor`** , where you can directly modify the `Tensor` interface created in `pybind.cc`. |
| 78 | +
|
| 79 | +In addition, the user may need to perceive the existence of a sequence (such as the sequence of the visualization needs to parse the output sequence in the model), so some of the serial operation APIs also need to be exposed to the python layer. |
| 80 | +
|
| 81 | +### Transmit `lod_start_pos` along with the Op call chain |
| 82 | +`lod_start_pos` is passed along with the Op call chain |
| 83 | +The framework needs to support the following features to implement the transmit of `lod_start_pos`: |
| 84 | +
|
| 85 | +1. Implement the transfer as `shared_ptr` |
| 86 | + - Do not modify the contents of `lod_start_pos` as a consumer |
| 87 | + - Modify producer of `lod_start_pos` as producer |
| 88 | + - Conventions consumer only needs to copy `shared_ptr` passed over |
| 89 | + - producer needs to create its own independent memory to store its own independent modifications and expose `shared_ptr` to subsequent consumer |
| 90 | + - Since the transfer process is implemented by copying `shared_ptr`, the framework only needs to pass `lod_start_pos` once. |
| 91 | +
|
| 92 | +2. Op is transparent enough not to sense `lod_start_pos` |
| 93 | +3. Producer Op that needs to modify `lod_start_pos` can update its `lod_start_pos` data when `Run` |
| 94 | +
|
| 95 | +## sorted by length |
| 96 | +After sorting by length, the batch size from the forward time step will naturally decrement, and you can directly plug it into Net to do the batch calculation. |
| 97 | +
|
| 98 | +For example, the original input: |
| 99 | +
|
| 100 | +``` |
| 101 | +origin: |
| 102 | +xxxx |
| 103 | +xx |
| 104 | +xxx |
| 105 | + |
| 106 | +-> sorted: |
| 107 | +xxxx |
| 108 | +xxx |
| 109 | +xx |
| 110 | +``` |
| 111 | +
|
| 112 | +After `SegmentInputs`, there will be 4 time steps, the input of each time step is as follows (vertical arrangement) |
| 113 | +
|
| 114 | +``` |
| 115 | +0 1 2 3 |
| 116 | +x x x x |
| 117 | +x x x |
| 118 | +x x |
| 119 | +``` |
| 120 | +
|
| 121 | +In order to track the changes before and after sorting, use here |
| 122 | +
|
| 123 | +```c++ |
| 124 | +struct SortedSeqItem { |
| 125 | + void *start{nullptr}; |
| 126 | + void *end{nullptr}; |
| 127 | +}; |
| 128 | +
|
| 129 | +std::vector<SortedSeqItem> sorted_seqs; |
| 130 | +``` |
| 131 | +To track the position of the sequence after sorting, and add a new interface |
| 132 | + |
| 133 | +```c++ |
| 134 | +std::vector<SortedSeqItem> SortBySeqLen(const LODTensor& tensor); |
| 135 | +``` |
| 136 | +Due to the sequence of input sequences, the following existing interfaces need to be modified: |
| 137 | +
|
| 138 | +- InitMemories, memory needs to be rearranged according to `sorted_seqs` |
| 139 | +- SetmentInputs |
| 140 | +- ConcatOutputs |
| 141 | +
|
| 142 | +In addition, because `sorted_seqs` needs to be multiplexed with `RecurrentGradientOp`, it will become a new output of `RecurrentOp`. |
| 143 | +It is passed in as an input to `RecurrentGradientOp`. |
| 144 | +
|
| 145 | +## InitMemories |
| 146 | +Due to the sequence change, the order of the elements on the `boot_memories` batch also needs to be rearranged accordingly. |
| 147 | +
|
| 148 | +## SegmentInputs |
| 149 | +
|
| 150 | +`SegmentInputs` relies on the information of `sorted_seqs` to cut the original sequence from the horizontal to the input of each step in the sorted sequence order. |
| 151 | +
|
| 152 | +the transition is as follows: |
| 153 | +``` |
| 154 | +origin: |
| 155 | +xxxx |
| 156 | +xx |
| 157 | +xxx |
| 158 | + |
| 159 | + | |
| 160 | + | |
| 161 | + \ / |
| 162 | + ! |
| 163 | +0 1 2 3 |
| 164 | +x x x x |
| 165 | +x x x |
| 166 | +x x |
| 167 | +``` |
| 168 | +## ConcatOutputs |
| 169 | +`ConcatOutputs` needs |
| 170 | +
|
| 171 | +- Restore the output of each time step back to the original input sequence order (to prevent the order of Infer phase from being upset) |
| 172 | +- Concat each sequence as a regular mini-batch representation |
| 173 | +
|
| 174 | +## references |
| 175 | +1. [Level of details](https://en.wikipedia.org/wiki/Level_of_detail) |
0 commit comments