
Warum ich den Chunk in meinem RAG-System auf 1500 Tokens gesetzt habe
Die Migration auf bge-m3 brachte ein 8192 Tokens Limit. Dennoch habe ich das Chunk-Limit bewusst auf 1500 Tokens gesetzt, um die semantische Schärfe zu bewahren.

Die Migration auf bge-m3 brachte ein 8192 Tokens Limit. Dennoch habe ich das Chunk-Limit bewusst auf 1500 Tokens gesetzt, um die semantische Schärfe zu bewahren.

Ich hatte die Textaufteilung bereits eingebaut und sah trotzdem weiter den Kontextfehler. Erst als ich den Tokenrahmen und die Spezialtoken mitgedacht habe, wurde die Ursache sichtbar.

Ich wollte den Weg von der Extension bis zur Speicherung sichtbar machen. Mit Bull Board und Dozzle habe ich Queue Status und Container Logs direkt im Browser und kann Fehler jetzt viel schneller einordnen.

Der Frontend Container war gebaut, lief und war trotzdem unhealthy. Die Ursache war eine kleine Alpine Falle: BusyBox Wget suchte localhost zuerst über IPv6 und nginx lauschte nur auf IPv4.

Ein TypeError im Browser nach einem Backend-Refactoring. Die Ursache ist kein Bug im Code, sondern ein veralteter Typ im Frontend, der die neue API-Response-Shape nicht kannte.

Instagram nutzt im Feed article-Tags, im Kanal-Grid nicht. ancestor traversal löst falsche PostIds, eine Promise-Map verhindert doppelte Backend-Requests.