- For recognition, do I label speakers, and what about overlapping speech and lazy pronunciation?
- No labels. The transcript frame has one text field and no speaker field, and the answer key holds both parties’ words with no labels in it — so do not add “客戶:” or “Agent:”: normalisation removes the colon, not the word, and the label is scored as extra characters. The audio is one mono channel with both sides of the call mixed; transcribe everything both people say, in the order it was said, including the words spoken over each other — a missed overlap counts as deleted characters, and the run page’s “right words, wrong place” shows what ordering cost you. Write words, not pronunciations: Traditional characters, Hong Kong usage, spoken Cantonese as spoken (佢, 嘅, 咗), and a lazy pronunciation does not change the character — 你 said “lei” is still 你. Fillers such as 呃 and 嗯 are speech and are scored.
- Does the understanding pillar need the insurer’s SOP or a knowledge base?
- None is issued, and no internal rule of the insurer’s is ever required to answer. How you build your system is yours: a retrieval index or a fine-tune over public insurance material — product pages, published procedures, ordinary Hong Kong practice — is allowed and usually helps with terminology and register. The one training restriction is the evaluation audio itself, which may not be trained on, redistributed or published. What no outside source can supply is the call-specific facts: this caller’s balance, this policy’s status, what was agreed on this call. Those come from the recording, and no policy data is supplied or queryable — if a fact is not in the call, nobody scoring it has it either. The judge is given the same task you are, that call’s verified transcript, and the key facts an organiser recorded from it; policy accuracy asks whether a citation matched what the call establishes, not whether you knew an internal rule. Where the call does not settle something, the answer that scores says what the call supports, names what it cannot confirm, and offers the next step.
- How long does integration take?
- Two to three hours for ASR, about a day for the full stack. You implement a WebSocket server and we connect to it. Once the URL is registered, the portal runs a connection test against three real clips and gives you a readable diagnosis of anything that fails, so you find out from us rather than from a scored run.
- Why do you call my endpoint instead of taking a file?
- Because latency and turn-taking cannot be measured from a file, and those are 25% of the score. A batch upload path exists as a fallback for recognition only, labelled on the leaderboard. It is not a Core Score on its own: Core also needs understanding and speech, which are measured only over a connection.
- What happens if my endpoint goes down mid-window?
- The run reports insufficient data rather than a bad score, and it does not consume your quota. Failures we caused are attributed to us and re-run for free. A downed endpoint is never published as a 100% error rate, because that would be a false statement about your system.
- Can I see which clips I got wrong?
- On practice runs, yes, with the reference transcript alongside your output. On scored runs you see per-item status and your own response, but not the ground truth.