David Schlangen : Home Page > minutes041207
- present: Michaela, Timo, David
from agenda, comments in [brackets]:
- Prosodie-Features noch nicht auf helios?
[ done ]
- Gold-Syntax, machen wir das noch? Aus penn treebank parses
berechnete features.
[ postponed; zuerst mal offline Experimente ]
- ASR-Ergebnisse, darauf parses & Syntax-Features
[ postponed; zuerst mal offline Experimente ]
folgende Skripte müssen geschrieben und Entscheidungen
getroffen werden:
- debug Penn & MSalign -> csv
[ --> David; dann mal alle drüberschauen ]
- classfile(s) (master) muß erzeugt werden;
- für jedes Wort:
- Abstand zu Turn-Ende in Worten & Sekunden
Enkapsuliert unsere Entscheidung darüber, was ein Turn ist. Kann
mehrere geben, für verschiedene Definitionen /
Quellen. (Handannotation vs. programmatisch.)
[ --> David; dann mal alle drüberschauen. Dokument mit genaueren
Beschreibungen der Experimente nach Datasets, Class feature,
etc.
Heute nette Terminologie gefunden, Unterschied zwischen
- decision point; wann mach System seine Entscheidung über Turn
Ende; und
- predicted end of turn; wo glaubt System ist der Turn zuende.
Bei einem Pausenthreshold von 300 ms folgt der DP also immer
(frühestens) 300ms nach dem PEOT; bei einer Vorhersage ist der
DP *vor* dem PEOT. (Und damit kann in die zu lernende Klasse die
Information über die Distanz DP und EOT einfließen.)
a) Reaktion, getriggert durch Pause:
<----- k ms ----------------| DP
PEOT <-- n ms -|
n ms = Pausen threshold; k ms = Größe des feature windows
b) Prädiktion
<--k ms--|<--n ms-|
DP PEOT
Zum Zeitpunkt DP wird vorhergesagt, dass das EOT zum Zeitpunkt
PEOT sein wird; n ms entfernt.
Trockenexperimente: mit Pausenschwelle spielen. Wenn Pause groß,
dann Recall von Turnenden niedrig (weil viele verpasst werden),
aber Precision gut (weil lange Pausen wirklich nur an Turnenden
auftreten). Wenn Pause kleiner wird, wird Recall besser, aber
Precision kleiner, weil viele Hesitations mitgefunden werden.
Also einfach f-score (y-Achse) gegen threshold (x-Achse)
plotten?
]
- Listen mit filenames, definieren verschiedene
Test-Sets. (Z.B. nur solche, für die vollständiger Parse
existiert, nur solche, für die Gold-Prosodie existiert, etc.)
[ nach Bedarf, sehen wir dann. Vielleicht Teil der
Verdengelungssuite ]
- Dialogakte aus Jurafsky-Annotation müssen Utterance-Segmentation
zugeordnet werden und entsprechend mit IDs versehen werden.
[ Aus Name in DA-Anno, e.g. "sw_0932_2610.utt" scheinen die
letzten 4 Ziffern den Penn-Treebank (und sonstigen)
SWBD-Konventionen zu entsprechen. Keine Ahnung was die ersten 4
sollen. ]
- Verdengelungsskript:
- Anforderung: nimmt Liste an Filenames, und produziert ARFF für
- WEKA, aus files
- mit Prosodie-Features,
- mit Syntax-Features,
- mit Dialog-Akten,
- mit Klassen
jeweils entweder per-Wort, oder per-Frame. Dabei berechnet es
aus dem Master-Classfile die tatsächlich zu lernende Klasse,
also entweder "wait / take" oder "wait n-msecs / take_now".
[ --> Michaela. Wichtig ist Reproduzierbarkeit. Da Verdengelung
(oder nachfolgender Filterungsschritt) bestimmt, was genau das
Experiment ist (welche Datenpunkte, welche zu lernenden
Klassen), sollte das genauestens reproduzierbar
sein. Vielleicht am einfachsten dann für jedes Experiment ein
eigenes Skript zu benutzen, das die entsprechenden
Berechnungen macht. ]
[ Zeug über Pausen / Stillen gelöscht, eher Quark. ]
- Entscheidung:
- was ist Trainingsset, was ist Development Set, was ist Testset?
[ Trainings: swbd2, developement: swbd3 (n-gramme & parser),
test: swbd4 ]
- Infrastruktur für Weka-Experimente.
Am Besten wäre natürlich, wenn die jeweils per Skript gesteuert
wären, zur leichteren Wiederholbarkeit /
Modifizierbarkeit. Andererseits will man natürlich vielleicht ein
bisschen mit dem GUI rumspielen. Vielleicht zuerst GUI, dann
eigentliche Experimente per Skript.
[ Timo hat makefiles dafür... Soll da dann auch direkt der Aufruf
des jeweils zu verwendenden Verdengelungsskriptes rein? ]
- Plan für Experimente:
[ --> David; erste Version ]
- sehr schön wäre natürlich, wenn wir es bis zum live-Modus
brächten, also einen Modus, der echte Verarbeitungszeiten &
-qualitäten mitberücksichtigt. (ASR -> parser -> feature
generator -> classifier)
[ postponed. Gar nicht so weit entfernt, zumindest für alles
ohne Parser. Für mit Parser stellt sich erst noch die Frage,
wie mit wechselnden Hypothesen umgegangen wird. ]
- Wichtig: Gemeinsames Log führen darüber, was versucht wurde mit
welchem Erfolg.
- Addendum: mindestens READMEs in Verzeichnis, die erklären, wie
genau die Features erzeugt wurden. Oder wrapper scripts, die (eine
lauffähige Installation der Tools vorausgesetzt) die Features
erzeugen. Reproduzierbarkeit!
- PPS:
- die zur Erzeugung der Features benutzte Version der Programme mit einem svn release tag versehen, damit man ggfs später genau diese Version reproduzieren kann!
das, 12/05/07 03:25 (GMT)
Keyword: inpro,
meeetings,
minutes,
nigh2.0Add a new page under this one
