BERT(je) verdieping

Vandaag een aardige serie Youtube filmpjes gevonden die helpen om Bert beter te begrijpen. In deze serie van ChrisMcCormickAI wordt het gebruik van Bert op een heel duidelijke en zorgvuldige wijze toegelicht. Een van de zaken is de uitleg over de input voor Bert. Hoewel hij ergens aangeeft dat je kan kiezen voor een zins lengte van 256 blijkt dat niet uit mijn eerder model overzicht. Ik denk dat het daar over "Bert large" gaat.

De zinnen moeten worden voorzien van de juiste begin en eindtokens [CLS] en [SEP]. Daarnaast moet er in de 2e 128 bytes input aangegeven worden welke input 'echte tokens' zijn en welke 'paddings' [PAD]. Natuurlijk wil ik kijken of dat bij mijn input goed is gegaan.
Ik kijk eerst naar de NL 'vocab file':

[UNK]
[CLS]
[SEP]
[PAD]
[MASK]
!
"
&
'
(
)
De [CLS] en de [SEP] lijken op de juiste plaatst te staan Hoewel ik mij afvraag of afzonderlijke zinnen allemaal van deze codering voorzien moeten zijn.  Dat zie ik niet zo snel terug. Wel zijn er diverse [UNK] (code 0) die slaan op unknown. Tevens is het [PAD] (3) token niet goed uitgevoerd. De nullen op het eind zouden m.i. een drie moeten zijn. De 2e reeks moet aangeven waar de 'echte' tokens (incl [CLS], [SEP] en [UNK] staan (hoewel ik de laatste niet helemaal zeker weet). Dat is, zoals hieronder te zien is, ook niet het geval. De hele 2e reeks is altijd alleen van nullen voorzien. 

>>> train_x[0][100]
array([    1, 22795, 26385, 20076,     0,   113,   134, 15607, 12486,
          13, 12828, 22796, 18100, 29220, 25138, 16934, 16779,  8378,
       13903, 10537, 15305, 20076,  7862, 15607, 12365,    13, 15612,
       17064, 16203, 16204, 26054, 19377, 21877, 10537, 14294,  7862,
        7932, 13604, 20722, 27373, 16804, 14293, 29438,  9092, 11281,
       20732, 22065,    13, 20047,   123,   131,    13,  8431, 17707,
       22286,    13, 15557, 22055, 12918,    11, 15061, 24298, 20722,
       22538, 25138, 26576, 14912, 23917,     0,   132, 10343, 17811,
       15333, 23879,     2,     0,     0,     0,     0,     0,     0,
           0,     0,     0,     0,     0,     0,     0,     0,     0,
           0,     0,     0,     0,     0,     0,     0,     0,     0,
           0,     0,     0,     0,     0,     0,     0,     0,     0,
           0,     0,     0,     0,     0,     0,     0,     0,     0,
           0,     0,     0,     0,     0,     0,     0,     0,     0,
           0,     0])
>>> train_x[1][100]
array([0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
       0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])

Ik zie overigens dat de vocab file zowel hoofd- en kleine letters bevat. Ik heb mij blijkbaar eerder vergist en ben ervan uitgegaan dat het een 'uncased versie' betrof. Ik meen zelfs dat het moedel pas goed ging rekenen nadat ik de zinnen naar uncased heb omgezet. Gek genoeg lijken er maar een paar kleine letters in de vocab voor te komen:

...
W
Y
Z
`
b
d
v
w
z
«
»
–
‘
’
“
”
...
Wel weer als vervolg teken : ##a etc Daar word wel het hele alfabet afgedekt.



Formeel zou de [UNK] code niet (vaak) voor mogen komen. Elk woord zou normaliter in zijn 'woorddelen' moeten kunnen worden uitgedrukt. Desnoods in de afzonderlijke letters. Zo zou een onbekend woord, bijvoorbeeld "dirk",  worden opgesplitst in d, ##i, ##r, ##k. (Met de ## indien het een vervolg letter is.) Maar als ze niet ik de vocab voorkomen kan het uiteraard een probleem worden. Ook zijn niet alle 'leestekens' er zo te zien. Ik mis bijvoorbeeld het apenstaartje.

Maar goed, dat vraagt verder onderzoek. Eerst maar eens testen of een betere codering ook een beter resultaat oplevert.

Ik ben ook benieuwd wat er zou gebeuren als ik de hoofdletters in de vocab door kleine letters vervang. Een mooi experiment.