Which is the correct bbox ocr level for LiLT? block level or word level?
This is regarding the lilt model belowhuggingface.coLiLTWe’re on a journey to advance and democratize artificial intelligence through open source and open science.github.com/jpWang/LiLTWord or segment position embeddings?opened06:39PM - 21 Nov 22 UTCclosed08:40AM - 24 Nov 22 UTCNielsRoggeHi @jpWang,

I had a question related to LiLT; namely whether or not you're le…veraging bounding boxes per word or per segment when fine-tuning on FUNSD. The LayoutLMv3 authors saw a great boost in performance when employing the same bounding box coordinates for a set of words that make up a "segment", like an address on an invoice. They use the OCR engine to identify segments in a document, and then give the same bounding box coordinates to all the words that make up that segment (an idea which was introduced in [StructuralLM](https://arxiv.org/abs/2105.11210)).

LayoutLMv1 and v2 both use "word position embeddings," which means that each individual word has its own bounding box coordinates. 

Does LiLT achieve 88% F1 on FUNSD with word position embeddings? Looking at [this file](https://github.com/jpWang/LiLT/blob/main/LiLTfinetune/data/datasets/funsd.py), it seems word position embeddings are used.In the above link, author of LILT has mentioned that the model is pretrained on “segment-level box”.Questionwhich kind of ocr is assumed byLiltModel? word token level or “segment-level box”?How to ensure the same  “segment-level box” or word level ocr is applied for finetuning and inference?Any pointers on implement the correct ocr level using pytesseract?