Skip to content

[Bug]: Default prompt biases document types towards English although existing Paperless document types are provided #257

Description

@hammaschlach

Summary

Default prompt prefers English document types over existing Paperless document types

Steps to reproduce

Describe the bug

While testing Zettelrobbe with a German Paperless installation and Ollama (Gemma 3 1B), I noticed that document types are often returned in English although matching German document types already exist in Paperless.

Environment

  • Paperless-ngx
  • Ollama
  • gemma3:1b
  • German documents

Example

My existing Paperless document types include:

  • Rechnung
  • Vertrag
  • Kontoauszug
  • Bescheid
  • Rezept
  • Zeugnis

The system prompt correctly injects these existing document types.

However, the prompt later contains this JSON example:

"document_type": "Invoice/Contract/..."

When analysing a simple German invoice, the model returned:

{
  "document_type": "Invoice/Contract/"
}

instead of using the already existing document type:

{
  "document_type": "Rechnung"
}

Why I think this happens

The JSON example seems to have a stronger influence on the model than the injected list of existing document types.

Although the prompt also states:

The Tags, Title and Document_Type MUST be in the language that is used in the document.

the example still encourages English output.

Suggested improvement

Replace

"document_type": "Invoice/Contract/..."

with something language-neutral, for example

"document_type": "<existing document type>"

or otherwise avoid English examples in the prompt.

This should improve multilingual installations without changing any application logic.

Additional observation

The correspondent extraction also tends to return the complete company address instead of just the company name.

Example:

IXXX GmbH • XXXstr. 30 • D-10969 Berlin

instead of simply

IXXX GmbH

I'm not sure whether this is intentional, but it also seems to be influenced by the current prompt.

Expected behavior

When existing Paperless document types are available and the document language is German, the AI should reuse the existing document type.

Example:

Existing Paperless document types:

  • Rechnung
  • Vertrag
  • Kontoauszug

Expected result for a German invoice:

{
  "document_type": "Rechnung"
}

The prompt should not bias the model towards English document types.

Actual behavior

The current default prompt injects the existing Paperless document types correctly, but later contains this JSON example:

"document_type": "Invoice/Contract/..."

When analysing a German invoice with Ollama (Gemma 3 1B), the model returned:

{
  "document_type": "Invoice/Contract/"
}

instead of using the existing Paperless document type "Rechnung".

The prompt also states that the document type should be in the same language as the document, so this seems contradictory.

Additionally, correspondent extraction sometimes returns the full postal address instead of only the company name.

Relevant logs

No application errors were observed.

The issue is reproducible with a default installation.

The generated prompt contains:

"document_type": "Invoice/Contract/..."

while existing Paperless document types already include German values such as "Rechnung" and "Vertrag".

The model then returns:

{
  "document_type": "Invoice/Contract/"
}

instead of reusing the existing Paperless document type.

Browser console / stack trace (if applicable)

Zettelrobbe version

v2026.07.04

Zettelrobbe commit

No response

Paperless-ngx version

No response

Deployment type

Docker Compose

Host OS

Linux

Host OS version

No response

Browser (if UI related)

No response

Configuration notes

No response

Pre-submission checklist

  • I searched existing issues and did not find a duplicate.
  • I removed or masked secrets/tokens from logs and screenshots.

Additional context

Image

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions