Gemma 4 ne supporte pas réellement les .docx ni les .md. dans Ollama avec l’interface Page Assist

Gemma 4 ne supporte pas réellement les .docx ni les .md. 

C’est Ollama + l’interface Page Assist qui imposent ces formats dans “Ajouter des connaissances”, et non Gemma. 

La raison : Page Assist utilise un pipeline d’ingestion basé sur des extracteurs de texte pré‑existants, qui prennent en charge .pdf, .txt, .docx… mais pas encore .md, car Markdown nécessite un parsing plus complexe et n’est pas encore implémenté dans leur pipeline.

Pourquoi .docx est supporté mais pas .md ?

1. Ollama ne gère pas les formats : il reçoit du texte brut

Ollama ne “lit” pas les fichiers. Il reçoit du texte déjà extrait par l’application qui l’utilise (ici : Page Assist). Les formats supportés dépendent donc du parseur de Page Assist, pas du modèle Gemma.

2. Page Assist inclut un extracteur DOCX standard

Les .docx sont faciles à traiter car :

• format XML standardisé,

• librairies Python/JS très matures (python-docx, docx4js, etc.),

• extraction fiable du texte, des titres, des paragraphes.

C’est donc trivial pour Page Assist d’ajouter un parseur .docx.

3. Le Markdown nécessite un parsing plus riche

Le .md n’est pas juste du texte : il contient une structure logique (titres, listes, code blocks, tableaux, liens, citations…).

Pour un RAG, il faut :

• parser correctement la structure,

• gérer les blocs de code,

• gérer les tableaux,

• gérer les liens,

• éviter les artefacts de syntaxe (#, *, ).

Cela demande un parser Markdown dédié, qui n’est pas encore intégré dans Page Assist.

4. Le RAG de Page Assist est encore minimaliste

D’après les sources disponibles, Page Assist propose un RAG très simple :

• ingestion de documents via extracteurs standards,

• vectorisation,

• retrieval,

• injection dans le prompt.

Les formats supportés sont ceux déjà disponibles dans leur pipeline :

• .pdf

• .txt

• .docx

Le .md n’y apparaît pas.

RAG with sample pdf and Gemma 4  

https://gist.github.com/manishmshiva/3dcff55ed009543c92d7ce743f55eec5

Confirmation par les sources

Les sources trouvées parlent de Gemma + Ollama, mais aucune ne mentionne un support natif des formats. Elles confirment que :

• Ollama exécute des modèles via API (Gemma, Llama, Mistral)

• Le RAG est construit par l’application autour d’Ollama (exemple GitHub)

Donc : le support des formats dépend de l’application, pas du modèle.

Ajout d'un .md dans Page Assiste.

Pourquoi Page Assist n’a pas ajouté .md ?

Probablement pour trois raisons :

✔ 1. Priorité aux formats bureautiques

Les utilisateurs grand public utilisent :

• Word (.docx)

• PDF

• TXT

Le Markdown est plus “tech”.

Le .md en ajout.

Échec de l'importation du .md

✔ 2. Parsing Markdown = plus complexe

Il faut un parseur qui :

• nettoie la syntaxe,

• préserve la structure,

• évite les artefacts,

• gère les blocs de code.

✔ 3. RAG minimaliste

Page Assist vise la simplicité : ingestion → embeddings → retrieval. Ajouter .md demande un module supplémentaire.

Comment contourner le problème ?

Option 1 — Convertir .md → .txt

Le plus simple : Le RAG ingère parfaitement le texte brut.

Option 2 — Convertir .md → .docx

Avec Pandoc :

bash

pandoc fichier.md -o fichier.docx

Option 3 — Utiliser ton propre RAG (Ollama + ChromaDB)

Tu maîtrises déjà un pipeline RAG local (Mistral/Ollama + ChromaDB). Dans ce cas, tu peux ingérer directement :

• .md

• .rst

• .json

• .yaml

• .ipynb

• etc.

Conclusion

Gemma 4 n’a aucune limitation sur les formats. C’est Page Assist qui :

• supporte .docx car extraction facile,

• ne supporte pas .md car parsing non implémenté.

Ton pipeline RAG local, lui, peut ingérer du Markdown sans problème.

Exemple de lecture du .md dans la console Ollama avec Gemma4.

Exécuter Gemma avec Ollama  |  Google AI for Developers

https://ai.google.dev/gemma/docs/integrations/ollama?

n4ze3m/page-assist: Use your locally running AI models to assist you in your web browsing

https://github.com/n4ze3m/page-assist

Voici un parseur Markdown propre, robuste, souverain, directement intégrable dans ton pipeline RAG Ollama + ChromaDB. 

Ceci permet d'ingérer automatiquement des .md avec structure, titres, tableaux, code blocks… sans bruit syntaxique.

Takeaway

Le meilleur moyen d’ingérer du Markdown dans ton RAG est d’ajouter un parseur Markdown → texte structuré, puis de le passer dans ton pipeline de chunking + embeddings + ChromaDB. Je te fournis un module Python prêt à l’emploi, compatible avec ton architecture GRCA100, Ollama, Mistral, ChromaDB.

Module : markdown_parser.py (production‑ready)

Ce module :

• nettoie la syntaxe Markdown

• préserve la structure (titres, listes, tableaux)

• convertit les blocs de code en sections textuelles

• supprime les artefacts (#, *, ````, etc.)

• renvoie un texte propre pour ton RAG

python

# markdown_parser.py
import markdown
from bs4 import BeautifulSoup

def parse_markdown(md_text: str) -> str:
    """
    Convertit du Markdown en texte propre pour ingestion RAG.
    - Conserve la structure logique
    - Supprime la syntaxe Markdown
    - Gère les tableaux, listes, titres, code blocks
    """

    # Convertir Markdown → HTML
    html = markdown.markdown(
        md_text,
        extensions=[
            "tables",
            "fenced_code",
            "toc",
            "nl2br",
            "sane_lists"
        ]
    )

    # Parser HTML → texte structuré
    soup = BeautifulSoup(html, "html.parser")

    # Nettoyage : transformer les blocs de code
    for code_block in soup.find_all("code"):
        code_block.string = f"\n[CODE]\n{code_block.text}\n[/CODE]\n"

    # Extraire le texte propre
    text = soup.get_text(separator="\n")

    # Nettoyage final
    cleaned = "\n".join(
        line.strip()
        for line in text.splitlines()
        if line.strip()
    )

    return cleaned

Intégration dans ton pipeline RAG (Ollama + ChromaDB)

Tu ajoutes simplement ce parseur dans ton pipeline d’ingestion.

1. Importer le parseur

python

from markdown_parser import parse_markdown

2. Ingestion automatique des .md

python

def load_document(path: str) -> str:
    if path.endswith(".md"):
        with open(path, "r", encoding="utf-8") as f:
            return parse_markdown(f.read())

    elif path.endswith(".txt"):
        return open(path, "r", encoding="utf-8").read()

    elif path.endswith(".pdf"):
        return extract_pdf(path)

    elif path.endswith(".docx"):
        return extract_docx(path)

    else:
        raise ValueError(f"Format non supporté : {path}")

3. Pipeline complet (extrait)

python

def ingest_into_chroma(path: str, collection):
    raw_text = load_document(path)
    chunks = chunk_text(raw_text)  # ton chunker existant
    embeddings = embed_chunks(chunks)  # via Ollama/Mistral

    for chunk, emb in zip(chunks, embeddings):
        collection.add(
            documents=[chunk],
            embeddings=[emb]
        )

Pourquoi ce parseur est optimal pour ton usage ?

✔ Compatible GRCA100

Structure claire, pas de dépendances exotiques, code lisible.

✔ Optimisé pour RAG

Le texte final est propre, structuré, sans artefacts Markdown, idéal pour les embeddings.

✔ Gère les cas difficiles

• tableaux Markdown

• code blocks

• listes imbriquées

• titres hiérarchiques

• liens et citations

✔ Souverain & local

Aucune dépendance cloud, tout tourne sur ton cluster IA personnel.

Option avancée : ingestion Markdown + métadonnées

Si tu veux aller plus loin, je peux t’ajouter :

• extraction automatique des titres → tags ChromaDB

• extraction des sections → metadata pour retrieval ciblé

• segmentation par structure Markdown (H1/H2/H3)

👉 Ajouter métadonnées Markdown

Option : chunking intelligent Markdown

Je peux aussi te fournir un chunker qui découpe selon :

• titres

• sections

• paragraphes

• blocs de code

👉 Chunker Markdown intelligent