Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Impact of carriage return ('\n'), multiple carriage return and multiple spaces dut to PDF parsing #751

Open
Snikch63200 opened this issue Dec 5, 2024 · 2 comments
Labels
bug Something isn't working

Comments

@Snikch63200
Copy link

Snikch63200 commented Dec 5, 2024

Hello,

I noticed PDF parsing leads to multiple carriage returns and multiples spaces (sometimes huge) inside citations.

Request to litellm:
litellm.acompletion(api_base='http://192.168.1.15:11434', model='ollama/dolphin-mixtral:8x7b', api_type='ollama', stream=False, caching=False, cache=True, mirostat=0, mirostat_eta=0.1, mirostat_tau=5.0, num_ctx=32768, repeat_last_n=64, repeat_penalty=1.1, temperature=0.7, seed=0, tfs_z=1, num_predict=1000000, max_tokens=1000000, top_k=40, top_p=0.9, min_p=0.0, messages=[{'role': 'system', 'content': 'Provide a summary of the relevant information that could help answer the question based on the excerpt. Respond with the following JSON format:\n\n{\n "summary": "...",\n "relevance_score": "..."\n}\n\nwhere summary is relevant information from the text - Environs 100 mots. words. relevance_score is an integer 1-10 for the relevance of summary to the question.\n'}, {'role': 'user', 'content': "Extrait de Aiguillon (47) - A Grand Jean.pdf pages 105-106: File Aiguillon (47) - A Grand Jean.pdf\n\n----\n\nue qui a disparu.\n De probables fils de bronze visibles sur la radiographie (fig. 84) entourant la\n poignée et soudés à elle, rappellent une technique ornementale bien connue\n sur les exemplaires d’épées du même type à Montréal-du-Gers (Gers),\n Cabreret (Lot), Monteils (Aveyron) et Cazals (Le Frau, Tarn- et-Garonne).\n Il semble d’après Mohen et Pajot que ce type d’épée à soie effilée, par\n opposition aux soies plates aquitaniennes, soit plutôt de type Languedocien.\n Ces épées à antenne sont datées en général de la fin du premier âge du Fer\n soit vers 575-550 av. J.-C.\n\n\n\n\n\nFig. 84 Radiographie de la soie de Iso 212 (St 71, Incinération 10), poignard à antennes106 Inrap · Rapport d’opération Aiguillon - A Grand Jean\n\n\n 3.5. Chronologie de la nécropole\n\n\n Les indices chronologiques fournis par l’analyse du mobilier céramique\n et métallique se rapportent à une fourchette de dates entre 650 et 450 av.\n J.-C., soit l’ensemble du premier âge du Fer (fig. 85). Les dix tombes à\n incinération étudiées se répartissent, semble t-il, sur deux à trois phases,\n pendant les deux siècles d’occupation funéraire.\n La sépulture la plus ancienne est l’incinération 3, elle est seule dans ce cas,\n viennent ensuite quatre tombes pour la phase moyenne du premier âge du\n Fer : Incinération 2, 4, 8 et 9 (bien que la datation de l’incinération 9 soit\n un peu large) ; suivies dans la phase finale de cinq tombes : Incinérations 6,\n 10, 5, 7 et 1. La recherche d’une organisation chronologique des tombes ne\n semble pas pertinente au regard de l’effectif assez faible (fig. 86).\n\n\n\n Inci. 6 Inci. 10 Inci. 5 Inci. 7 Inci. 1 Inci. 2 Inci. 4 Inci. 8 Inci. 9 Inci. 3\n St 57 St 71 St 52 St 61 St 37 St 33 St 40 St 62 St 69 St 47\n 300\n\n 350\n\n 400\n\n 450\n\n J.-C. 500 phase finale\n av Fer 550\n phase moyenne du\n 600 âge\nFig. 85 Tableau chronologique de synthèse Ier\n 650\n phase ancienne\n 700\n\n 750\n\n\n\n\n 3.6. Organisation spatiale des tombes et typologie des\n structures funéraires\n\n\n 3.6.1. Architecture des tombes et taphonomie\n\n Les urnes reposent dans une fosse aux contours non délimitables car le\n sédiment encaissant se confond avec le remplissage. Le fond de la fosse est\n a priori plat si l’on en juge d’après la disposition des vases. Aucun élément\n périphérique de signalisation, comme des galets ou trous de poteau, n’a\n été observé au cours de la fouille ; cependant l’existence d’un tumulus ou\n d’une modeste éminence de terre n’est pas à exclure. De même que la trace\n éventuelle de bûchers funéraires n’a pu ê\n\n----\n\nQuestion: Quels sont exemples connus d'inhumations de squelettes d'enfants ou d'immatures à l'intérieur de récipients en céramique (dolia, amphores, bassines, terrines), datés du Haut Empire, dont la datation est fiable. Répondez en Français.\n\n"}], client=None, timeout=60.0, metadata={'model_group': 'ollama/dolphin-mixtral:8x7b', 'model_group_size': 1, 'deployment': 'ollama/dolphin-mixtral:8x7b', 'model_info': {'id': 'c81d5d9631f274cb4f071153083eb90c3787bf37e4c00875a09b80f19006fc40', 'db_model': False}, 'api_base': 'http://192.168.1.15:11434', 'caching_groups': None}, model_info={'id': 'c81d5d9631f274cb4f071153083eb90c3787bf37e4c00875a09b80f19006fc40', 'db_model': False}, max_retries=0)

I wonder if it affects LLM global comprehension of the citation and so PaperQA efficiency.

Best regards.

Copy link

dosubot bot commented Dec 5, 2024

The PaperQA codebase does not explicitly mention handling or preprocessing steps for carriage returns and multiple spaces in text extracted from PDFs. The PDF parsing library used, pymupdf, extracts text using the get_text method with sort=True, which helps maintain text order but does not specifically address spacing or formatting issues [1].

For citations, the codebase includes functions like strip_citations and get_citenames to handle and preprocess citations using regular expressions, ensuring they are correctly identified and extracted [2][3]. However, there is no specific mention of handling irregular spacing or carriage returns in these functions.

If these formatting issues are affecting the LLM's comprehension, you might consider implementing additional preprocessing steps to normalize whitespace and remove unnecessary carriage returns before the text is processed by the LLM.

To continue talking to Dosu, mention @dosu.

@dosubot dosubot bot added the bug Something isn't working label Dec 5, 2024
@jamesbraza
Copy link
Collaborator

Hi @Snikch63200 yep thanks for sharing.

Yeah the parsing layer needs work, we need to better support tabular data (#667 (comment)), scientific notation/non-ASCII chars (#744), and also other modalities like images.

Open to contributions here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants