@@ -15,7 +15,9 @@ Wir vergleichen mit den Metriken verschiedene Prompting-Architekturen:
- Verschiedene Aufgabenstellungen
- Wie stark kann man ohne Qualitätsverlust generalisieren?
- Werden die Dialoge besser mit einem Beispiel?
- AF: Add: Erreichen wir die Qualität vergleichbarer Arbeiten/existierender Trainingsdaten bzgl. automatisierter Metriken?
- Generierung von negativen Beispielen mit zusätzlichen Verhaltensmuster-Vorgaben
AF: würde ich nicht prioriesieren, zugunsten anderer Optionen unten:
- "System: Sei unhöflich"
- "User: Wechsel random das Thema"
- ...
@@ -25,18 +27,43 @@ Wir vergleichen mit den Metriken verschiedene Prompting-Architekturen:
Mit einer Schnittstelle kann man dem Modell während der Generierung Informationen zuspielen.
Das können Datenquellen, wie z.B. ATOMIC, WikiData, oder Fakten über Hotels, etc., sein.
Ablauf: 1. Echte, problemorientierte Daten (Hotels, Restaurants, scrapen aus OSM API) 2. Datenbank aufsetzen 3. Informationen embedden 4. API entwickeln, damit das Modell relevante Daten anfragen kann (Similarity Search)
Ablauf:
1. Echte, problemorientierte Daten (Hotels, Restaurants, scrapen aus OSM API)
2. Datenbank aufsetzen
3. Informationen embedden
4. API entwickeln, damit das Modell relevante Daten anfragen kann (Similarity Search)
AF: AF: warum nicht existierende Datensätze? (zus. Arbeitsaufwand!)
LFC: Die Idee war, mit echten Daten, z.B. von Heidelberg (~600 Restaurants, ..) zum einen eine gute Grundlage für FactScore zu haben, und zum anderen eine potentielle Anwendungsmöglichkeit zu demonstrieren (nicht besonders relevant).
Den Aufwand die Daten aus der API zu filtern und zu RDF umzuformen, schätzen wir nicht groß ein.
Gute, fertige und passende Datensätze haben wir dazu noch nicht gefunden, lehnen sie aber auch nicht kategorisch ab.
### Multi-Agent
Wir schreiben ein Programm, dass zwei Sprachmodell-Instanzen miteinander verbindet, um einen interaktiven Dialog zu simulieren.
Ablauf: 1. Schnittstelle programmieren 2. Die Sprachmodell-Instanzen miteinander einen Dialog führen lassen (Automatisierte User + System) 3. Vergleich zwischen One-Shot Dialogen und Multi-Agent Dialoge mit unseren Metriken
AF: Vorstufe:
1. ein Modell generiert interaktiven Dialog;
2. aus existierenden Szenarien / Datensets das Geeignetste auswählen
LFC:
1. Was unterscheidet einen "interaktiven Dialog" von einem "1-Shot Dialog" in dem Kontext?
2. Szenarien/Datensets ändern sich nicht für diese Methode.
Ablauf:
1. Schnittstelle programmieren
2. Die Sprachmodell-Instanzen miteinander einen Dialog führen lassen (Automatisierte User + System)
3. Vergleich zwischen One-Shot Dialogen und Multi-Agent Dialoge mit unseren Metriken
-[WOZ Datensatz](https://github.com/budzianowski/multiwoz/tree/master)(task oriented) [AF: Auswahl liegt nahe]
-[PersonaChat](https://www.kaggle.com/datasets/atharvjairath/personachat)(open dialogue) [AF: warum dieses und nicht andere vergleichbare? Was sind für Sie die wichtigsten Eigenschaften?]
- AF: Sie meinen hier mit Goldstandard Referenzdialog, ja?
- LFC: Ja, nur wenn wir die "gleichen" Dialoge wie im WOZ-Datensatz generiert, mit den selben Problemstellungen, und den selben Informationen (KG-Triplets), kann man die generierten Dialoge direkt vergleichen.
### FactScore
Code: https://github.com/shmsw25/FActScore
- ! Needs Knowledge-Base
- AF: Alternative zu KB:
1. Dialog UND Referenz mit Instruct-GPT in atomic facts zerlegen;
2. ggf. Filterung für Core Info,
3. dann Abgleich der relevanten atomic facts mit S(3)BERT
### DEAM [BOTH]
Code: https://github.com/PlusLabNLP/DEAM
-[Code](https://github.com/PlusLabNLP/DEAM)
-[Paper](https://arxiv.org/abs/2203.09711.pdf)
- Generiert negative examples
- Meta metric
- AF: was bedeutet hier meta metric?
- LFC: so wie wir das verstanden haben, ist diese Metrik nicht geeignet direkt die Dialoge zu bewerten, sondern kann genutzt werden, um herauszufinden, ob unsere Metriken (in)coherence gut erfassen können.
### Labruna [MANUAL]
Paper: https://arxiv.org/pdf/2305.14556.pdf
Daten: TBA
Manual annotated metric, only feasable for a small sample.
-[Paper](https://arxiv.org/pdf/2305.14556.pdf)
- Daten: TBA
- Manual annotated metric, only feasable for a small sample.
1. Consistency
2. Realism
3. Formality
4. Respectfulness
5. Spontanity/Naturalness
6. Has Conclusion
- AF: Possibly: let another LM judge for the above criteria (boolean -> graded); can be tested on Labruna et al's data
- LFC: Ja, war so geplant, haben vergessen es zu notieren
## Ressourcen
### Computing
- Local PC (3080 10GB)
- Coli-Cluster
- Coli-Cluster (8x 1080ti 11GB)
### Daten
@@ -125,39 +160,47 @@ Manual annotated metric, only feasable for a small sample.
- AF: to my knowledge the model suffers from missing regulation (safeguards)
- LFC: Safeguards sind in unserem Kontext weniger wichtig, da wir den Task vorgeben; Wilde Spekulationen/Halluzinationen sollten von unseren Metriken als solche erkannt werden
- AF: [here] some critical voices (haven't tested LLama 2 for comparison)
- LFC: Ein 7B Parameter Modell mit einem 1.76T Parameter Modell zu vergleichen, ist interessant. Wir erwarten keine GPT-4 Qualität von diesen kleinen Modellen.
- FactScore nicht anwendbar [AF: s.o: possibly apply Instruct-GPT to reference + match]
### Task Oriented only mit Knowledge Base
- Knowledge Graph z.B. aus OpenStreet Map API konstruiert
- MultiWOZ kein Gold Standard mehr
- AF: warum nicht?
- LFC: s.o.: weil man nicht mehr die selben Dialoge generieren will
- AF: Können Sie anstelle von dev: Subset von Train; für test: dev verwenden?
- LFC: ?
### Open Dialogue only mit Knowledge Base
- Event Coherence metrics (ATOMIC) anwendbar
- FactScore nicht anwendbar
- FactScore nicht anwendbar [AF: s.o.]
- Mehr Metriken
- mehr semantische/sprachliche analyse
@@ -169,3 +212,10 @@ Manual annotated metric, only feasable for a small sample.
- Open dialogue/task oriented (welches szenario, metriken würden begrenzt werden)
- Wie wichtig ist es Gold Standard aus WOZ zu haben
- Knowledge Base extrahieren aus WOZ, von OSM scrapen oder fertigen Datensatz nehmen
- Projektumfang (Knowledge-Graph API + Multi-Agent vermutlich zu viel)
- AF: TBD/ zu klären:
- Notwendigkeit für KG API [ wegen MWOZ?]
- Für Multi-Agent müssen Sie auf jeden Fall mindestens ein Szenario für single-LM-generated interactive dialogue erfolgreich umgesetzt haben, um die generelle Machbarkeit nachzuweisen, und als Baseline. Man könnte daher Multi-Agent als optional definieren.
- Open dialogue/task oriented (welches szenario, metriken würden begrenzt werden)
- Wie wichtig ist es Gold Standard aus WOZ zu haben ( dev aus train + dev als test?)
- Knowledge Base extrahieren aus WOZ, von OSM scrapen oder fertigen Datensatz nehmen [AF: TBD: warum keine existierenden Daten?]
