Samenvatting
In de geëxtraheerde tekst staan reeksen U+FFFD (het replacement character, �) waar de PDF-extractie glyphs niet naar Unicode kon herleiden. Dat kost twee dingen tegelijk:
- Zichtbaar: de tekens verschijnen letterlijk in de zoekfragmenten, bijvoorbeeld
jaarlijkse grondprijzenbrief.� Er wordt.
- Zwaarder: tekst die niet gedecodeerd is, is geen tekst meer en dus niet doorzoekbaar. Een kop die als
# ������� is opgeslagen, is met geen enkele zoekterm te vinden.
Bewijs
document:notubiz:gemeente:best:17217270, gemeten op de markdown zoals die in object storage staat:
|
|
| lengte |
85.164 tekens |
U+FFFD |
3.969 tekens in 550 aaneengesloten reeksen |
| aandeel |
4,7% van het document |
| langste reeks |
140 tekens achter elkaar |
Koppen die daardoor verdwenen zijn:
# �������
# 1. Inzet van het grondbeleid voor Best�
### 1.1 Aanleiding voor actualisatie�
### 1.2 Grondbeleid als instrument voor gemeentelijke regie�
De eerste kop is volledig weg. Bij de andere drie is de tekst bruikbaar maar hangt er een niet-decodeerbaar teken aan.
Het zit al in de extractie, niet in de API. Bovenstaande telling komt uit de markdown in object storage, dus vóór indexering en vóór de zoekrespons. Dit staat los van de dubbele HTML-escaping uit #213, die in de responslaag zat en inmiddels opgelost is.
Omvang
Steekproef van 144 zoekresultaten over zes uiteenlopende termen: 3 fragmenten (2%) bevatten zichtbaar U+FFFD. Dat is een ondergrens voor het echte probleem — een fragment laat maar een paar regels zien, en tekst die volledig onleesbaar is geworden komt juist níét als zoekresultaat naar boven.
Hoeveel documenten in totaal geraakt zijn is hiermee niet vastgesteld. Dat is met de huidige index ook niet direct te meten: de tokenizer gooit deze tekens weg, dus je kunt er niet op zoeken.
Vermoedelijke oorzaak
Niet onderzocht. Het patroon — hele reeksen achter elkaar, en losse tekens aan het eind van verder correcte koppen — wijst op een PDF met een ingesloten subset-font zonder (volledige) ToUnicode-mapping. De extractor kan de glyph dan wel tekenen maar niet benoemen, en levert U+FFFD.
Twee dingen om mee te beginnen:
- Nagaan of
pymupdf4llm hier opties voor heeft, of dat de transmutation-route op dezelfde documenten beter scoort. Beide paden bestaan al in src/documents/text.ts.
- Overwegen om OCR in te zetten wanneer een pagina boven een drempel aan niet-decodeerbare tekens uitkomt. De tekst staat wel degelijk in de PDF; alleen de mapping ontbreekt.
Er bestaat al een kwaliteitsscore op de extractie (extraction_quality_score / extraction_quality_status in derived_content). De vraag of U+FFFD-dichtheid daarin meetelt is niet nagekeken; als dat niet zo is, is dat waarschijnlijk de goedkoopste plek om dit zichtbaar te maken.
Herkomst
Opgemerkt in een zoekfragment tijdens het testen van een andere wijziging, en daarna nagemeten op de opgeslagen markdown.
Samenvatting
In de geëxtraheerde tekst staan reeksen
U+FFFD(het replacement character,�) waar de PDF-extractie glyphs niet naar Unicode kon herleiden. Dat kost twee dingen tegelijk:jaarlijkse grondprijzenbrief.� Er wordt.# �������is opgeslagen, is met geen enkele zoekterm te vinden.Bewijs
document:notubiz:gemeente:best:17217270, gemeten op de markdown zoals die in object storage staat:U+FFFDKoppen die daardoor verdwenen zijn:
De eerste kop is volledig weg. Bij de andere drie is de tekst bruikbaar maar hangt er een niet-decodeerbaar teken aan.
Het zit al in de extractie, niet in de API. Bovenstaande telling komt uit de markdown in object storage, dus vóór indexering en vóór de zoekrespons. Dit staat los van de dubbele HTML-escaping uit #213, die in de responslaag zat en inmiddels opgelost is.
Omvang
Steekproef van 144 zoekresultaten over zes uiteenlopende termen: 3 fragmenten (2%) bevatten zichtbaar
U+FFFD. Dat is een ondergrens voor het echte probleem — een fragment laat maar een paar regels zien, en tekst die volledig onleesbaar is geworden komt juist níét als zoekresultaat naar boven.Hoeveel documenten in totaal geraakt zijn is hiermee niet vastgesteld. Dat is met de huidige index ook niet direct te meten: de tokenizer gooit deze tekens weg, dus je kunt er niet op zoeken.
Vermoedelijke oorzaak
Niet onderzocht. Het patroon — hele reeksen achter elkaar, en losse tekens aan het eind van verder correcte koppen — wijst op een PDF met een ingesloten subset-font zonder (volledige)
ToUnicode-mapping. De extractor kan de glyph dan wel tekenen maar niet benoemen, en levertU+FFFD.Twee dingen om mee te beginnen:
pymupdf4llmhier opties voor heeft, of dat de transmutation-route op dezelfde documenten beter scoort. Beide paden bestaan al insrc/documents/text.ts.Er bestaat al een kwaliteitsscore op de extractie (
extraction_quality_score/extraction_quality_statusinderived_content). De vraag ofU+FFFD-dichtheid daarin meetelt is niet nagekeken; als dat niet zo is, is dat waarschijnlijk de goedkoopste plek om dit zichtbaar te maken.Herkomst
Opgemerkt in een zoekfragment tijdens het testen van een andere wijziging, en daarna nagemeten op de opgeslagen markdown.