ja, aber wenn es das einmal für alle entity typen macht dauert das ja dann doch ne weile.
18 * 30 min
Achso, du möchtest es nochmal tunen? In dem Fall würde ich empfehlen, nur die entities abzuspeichern. Das müsste doch den corpus sogar kleiner machen. Also dass processed_documents_store direkt auf die spacy ents zeigt, dann kann der rest während der Ausführung garbage collected werden, dann müsste es recht wenig speicherplatz brauchen, und du kannst trotzdem noch alles machen?
Ich hatte das was du mir geschickt hattest bei mir mit implementiert.
So
Und wollte einfach nochmal alle Werte im vergleich sehen.
Aber ja und dann halt schauen das ich gute Kombinationen finde oder so.
Ich wollte erst processed_documents_store beim entity zählen mit erstellen damit es nur einmal nlp(i.get(“text”)) aussführt, da das scheinbar so lange brauch. Aber da kommt das mit Kernel absturz. Deswegen hatte ich den nlp aufruf jetzt auch in der Hilfsfunktion was halt jedes Indexing/Erstellen der manipulierten Texte so lange dauern lässt
hast du den falschen Link geschickt? Kann da nichts mit processed_documents_store finden.
Aber ja, das was ich geschrieben habe mit nur die entities direkt speichern sollte ja auf jeden Fall klappen.
Ich wollte erst processed_documents_store beim entity zählen mit erstellen damit es nur einmal nlp(i.get(“text”)) aussführt, da das scheinbar so lange brauch. Aber da kommt das mit Kernel absturz. Deswegen hatte ich den nlp aufruf jetzt auch in der Hilfsfunktion was halt jedes Indexing/Erstellen der manipulierten Texte so lange dauern lässt
Ich bin mir nicht sicher, ob wir über das gleiche reden.
Ich hab es so verstanden, dass du anstelle von nlp(i.get("text")) im processed_documents_store abzuspeichern, du dort nlp(i.get("text")).ents abspeichern könntest. Das sollte das Problem doch lösen, oder?
Weil so deutlich weniger Speicherplatz verbraucht werden sollte.
Mhhh also dann habe ich doch aber nur noch die Entity Typen nicht mehr den Text dahinter oder?
Wenn ich nur noch die Typen habe kann ich den Text doch nicht mehr so manipulieren dass nur noch der Text mit Entity Label “ORG” oder so übrig bleibt
Den Text hast du noch, der ist ja für eine entity ent in ent.text gespeichert, sieh das Colab Notebook.
Und in ent.label_ hast du den Typen, also ist alles da, was du brauchst?
ah ok, ich versuchs
KeyError: ‘L02-1310’
# entity Recognition
# Process all documents with spacy.
nlp = spacy.load("en_core_web_sm")
# count entitys
# Erstelle ein Dictionary {}
EntityTypeDict = dict()
#store all processed documents for easy random access
processed_documents_store = {}
# gehe über alle abstracts mit spacy und ließ deren Entitäten
for i in pt_dataset.get_corpus_iter():
doc = nlp(i.get("text"))
processed_documents_store[i.get("docno")] = doc.ents
print(doc.ents)
for ent in doc.ents:
#print("entity:")
#print(ent.text, ent.start_char, ent.end_char, ent.label_)
# wenn der Entity Type bereits im Dictionary ist dann ...
if ent.label_ in EntityTypeDict:
EntityTypeDict[ent.label_] += 1
# falls nicht füge den Entity Typen in den Dictionary mit Initial 1 vorkommen
else:
EntityTypeDict[ent.label_] = 1
break
print(EntityTypeDict)
ausgabe von doc.ents ist (Context Vector Models, two, IDF)
Dann gebe ich das weiter (nur zur Testausgabe code verändert)
ret = []
for i in pt_dataset.get_corpus_iter():
text = ""
print(processed_documents_store[i.get("docno")])
for ent in processed_documents_store[i.get("docno")]:
if str(ent.label_) in ["ORG"]:
text += " " + ent.text
if len(text) > 0:
ret += [{"docno": i["docno"], "text": text}]
print( ret )
hier ist processed_documents_store[i.get(“docno”)] auch wieder (Context Vector Models, two, IDF); jedoch habe ich diesen key error
Ok, der Kernel würde trotzdem abstürzen
Ok, es stürzt jetzt mit dem KeyError: ‘L02-1310’ ab?
Das problem scheint mir zu sein, dass processed_documents_store bestimmt nur einen einzelnen Eintrag enthält? Weil beim hinzufügen ein break im code steht, deswegen würde ich vermuten, dass es nur einen Eintrag in processed_documents_store einfügt, und dann kann er später die Dokumente nicht finden, weil sie nicht eingefügt worden.
Viele Grüße,
maik
Ja war der Fall, aber ich hatte es auch mal ohne break durchlaufen lassen und dann war wieder Kernel absturz auch wenn ich nur doc.ents darin speicher
Hast du währenddessen mit htop geschaut, woran es liegen könnte? ist es der Speicher
Ne, also wo schreibe ich das denn hin?
Einfach während es läuft htop aufmachen (in der konsole htop tippen), und beobachten, wie sich der speicher verhält.
ok mach ich mal
mhhh oder auch nicht, ist jetzt schon nach 7000 Dokumenten abgestürzt hatte noch freien Platz
aber es kommt auf jedenfall davon
processed_documents_store = {}
processed_documents_store[i.get('docno')] = nlp(i.get("text")).ents
Projekt
(Stemming und Ausgabe eines Dokuments nicht ausgeführt)
Ok, also die CPU Auslastung sieht gut aus, die Memory auslastung sieht auch gut aus?
Lässt du es bei dir lokal oder im Codespace laufen?
(Im link oben kann ich keine processed_documents_store finden)
lasse es im codespace laufen
oh muss ich das erst commiten damit man das da sieht
Ja, also Memory war nicht voll
Ok, was ist dein Ziel gerade? Möchtest du herausfinden, wie deine Retrieval Pipeline aussehen soll? Dafür könntest du auch die einschränkung auf die qrels machen, und die gesamte pipeline über alles lassen wir dann nur in TIRA laufen, da können wir dem ganzen mehr ram und CPUs geben, da ist es auch kein problem wenn es langsam läuft. Wäre das nicht das einfachste?