자동 전사에서 자신만만한 거짓말을 잡아냅니다.
Whisper는 30초간의 침묵 구간에서 다음과 같은 결과를 만들어 냅니다:
"시청해 주셔서 감사합니다. 제 채널 구독 부탁드립니다."
신뢰도: 0.88. 오류도, 경고도 없습니다. 다운스트림 시스템은 이를 사실로 받아들입니다.
이 프로젝트는 그런 경우와, ASR 파이프라인이 조용히 쓰레기를 만들어 내는 다른 여섯 가지 방식을 잡아냅니다.
git clone https://github.com/Guillain-RDCDE/Trusted-Transcription.git
cd Trusted-Transcription
pip install pydantic click jiwer
PYTHONPATH=src python -m trusted_transcription.cli detect corpus/sample/silence_hallucination.json --format table출력:
SEG SEVERITY DETECTOR REASON
--------------------------------------------------------------------------------
2 critical silence_hallucination Known phantom phrase: 'Thank you for watching...'
4 critical repetition_loop N-gram 'nous avons constate' repeated 3x in 8 segments
6 critical temporal_drift Timestamp stall: segments 5 and 6 share [55.30-55.30]
Total: 3 flags세 가지 환각이 잡혔습니다. API 호출 0회. 정상 샘플에서 오탐 0건:
PYTHONPATH=src python -m trusted_transcription.cli detect corpus/sample/clean_transcript.json --format table
# No hallucinations detected.Related MCP server: this-needs-a-call
Audio -> Whisper -> [7 detectors] -> [LLM repair] -> [scoring] -> Trusted transcript탐지는 결정적입니다. 플래그가 발생하기 전에는 LLM이 개입하지 않습니다. 7가지 탐지기는 정규 표현식, 산술 연산, 통계로만 동작합니다. 실행 시간은 0.06초이고, 비용이 들지 않으며, 스스로 환각을 일으키지 않습니다.
수정에는 제약이 있습니다. LLM(Claude)은 구조화된 출력만 허용되고, 신뢰도 임계값은 0.7이며, "I don't touch this."라고 말할 수 있는 명시적 권한이 있습니다. 제약 없는 수정은 23%의 확률로 상황을 더 악화시킵니다 (ADR 0004에 해당 실험이 기록되어 있습니다).
LLM이 해결하지 못하는 중요한 플래그에는 사람이 개입합니다. 전사 결과의 ~70%는 무인으로 통과되고, 나머지는 정확한 세그먼트가 강조 표시된 채 검토로 보내집니다.
탐지기 | 탐지 대상 | 방식 |
| 같은 문구가 5~50회 반복 | 슬라이딩 윈도우 내 n-gram 빈도 |
| 침묵 구간에서 "시청해 주셔서 감사합니다" | 알려진 환각 패턴 + 단어/초 비율 |
| 시스템 프롬프트가 출력으로 누출됨 | 명령 마커 패턴 매칭 |
| 타임스탬프가 겹치거나, 거꾸로 가거나, 멈춤 | 연속 세그먼트 간 쌍별 산술 비교 |
| 문맥과 무관한 일관된 텍스트 | 이웃 어휘와의 Jaccard 거리 |
| 프랑스어 전사가 영어로 바뀜 | 언어 태그 + 기능어 마커 |
| 섹션이 조용히 누락됨 | 커버리지 비율 + 분당 단어 수 |
일곱 번 모드가 가자 위험합니다. 다른 모든 환각은 눈에 보이든 쓰레기를 만듭어 내지만, 이 모드는 아무것도 만듭어 내지 않습니다. 그리고 그 '아무것도 없음'은 올바르게 보입니다.
증상과 원인을 담은 전체 카탈로그: docs/failure-modes.md
PYTHONPATH=src python -m trusted_transcription.mcp_serverstdio를 통해 5개의 도구가 노출됩니다: transcribe, detect_hallucinations, repair, score, estimate_cost. 모든 MCP 호환 에이전트가 파이프라인을 구동할 수 있습니다.
Claude Code 설정:
{"mcpServers": {"trusted-transcription": {"command": "tt-mcp"}}}PYTHONPATH=src python -m trusted_transcription.cli cost 60
# Whisper API: $0.3600
# LLM repair: $0.0360
# Total: $0.3960
# Per hour: $0.40왜 파인튜닝 대신 두 모델인가? 인간의 개입은 어디에 남아 있나? 왜 확률론적 방법보단 결정적 방법을 먼저 사용하는가?
0001 — 직렬 연결된 두 모델 (LoRA 파인튜닝을 시도했지만 포기함)
pip install pytest
PYTHONPATH=src python -m pytest tests/ -v
# 13 passed in 0.06sAPI 호출도, 오디오 파일도 없습니다. 합성 전사본에 대한 순수 로직입니다.
이것은 프로덕션 법률 등급 전사 플랫트폼에서 추출한 범용 품질 계층입니다. 이 플랫트폼은 잘못된 단어 하나가 법적 책임으로 이어질 수 있는 공식 받아쓰기를 처러합니다. Whisper + Claude 파이프라인은 9대 서버 팝에서 약 70% 무인 운영되며 일일 과금이 이루어집니다.
플랫폼 코드는 NDA에 포함되어 있습니다. 기법, 탐지기, 아키텍처 결정은 여기에 공개합니다. 막다른 길도 마찬가지입니다. 그것들은 ADR에 기록되어 있으며, 프로덕션 주장이 신뢰할 수 있는 이유이기도 합니다.
MIT — Guillain d'Erceville — guillain@poulpe.us — GitHub — LinkedIn
Run all hallucination detectors on a transcript. Returns a list of flags with severity, detector name, and evidence. Detectors: repetition_loop, silence_hallucination, prompt_echo, temporal_drift, phantom_subtitle, language_switch, completeness.
| Name | Required | Description | Default |
|---|---|---|---|
| transcript_json | Yes | JSON string of a TranscriptResult |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the return shape and enumerates the detectors, which is useful. However, it does not state whether this operation mutates anything, requires prior transcription, or has any side effects or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, with the main action and output in the first sentence and an exhaustive but relevant detector list in the second. Every part earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description explains both input context and output fields. It does not elaborate on what 'TranscriptResult' is or what each detector checks, but the sibling tool transcribe and the detector names supply enough context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the single parameter is already described as 'JSON string of a TranscriptResult'. The description adds no further parameter-level detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Run all hallucination detectors') on a specific resource ('a transcript') and clearly describes the output (flags with severity, detector name, evidence). The detector list differentiates it from siblings like transcribe, repair, score, and estimate_cost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Run all hallucination detectors on a transcript' makes the intended use case clear: after transcription, when hallucination detection is needed. It does not explicitly name alternatives or exclusions, but the sibling names make the context obvious enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate processing cost for a given audio duration. Returns breakdown: Whisper API cost, LLM repair cost (if needed), total.
| Name | Required | Description | Default |
|---|---|---|---|
| audio_duration_minutes | Yes | Duration of audio in minutes | |
| expected_hallucination_rate | No | Expected fraction of segments needing repair (0-1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It explains that the tool estimates cost and returns a breakdown, implying a read-only calculation. However, it does not explicitly state that no actual transcription/repair occurs, nor does it disclose pricing assumptions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The action and resource are front-loaded, and the return breakdown is stated concisely. Every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with two parameters and no output schema, the description is largely complete: it names the input and explicitly lists return components. A small gap is the absence of any statement about side effects or calculation basis, but this does not hinder correct calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context by naming 'LLM repair cost (if needed)', which hints at how expected_hallucination_rate factors in, but it does not substantially extend the parameter meaning already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('estimate'), a specific resource ('processing cost'), and the input ('audio duration'), then states the output breakdown. This clearly distinguishes it from the processing-oriented siblings transcribe, detect_hallucinations, repair, and score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is for estimating cost before processing, with no mention of alternatives or exclusions. Context is strong enough for an agent to select it when a cost estimate is needed, but it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the LLM repair loop on flagged segments. The LLM can delete fabricated segments, replace them, or decline to touch them. Returns structured repair actions with confidence and reasoning.
| Name | Required | Description | Default |
|---|---|---|---|
| transcript_json | Yes | JSON string of a TranscriptResult with flags |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It openly states that the LLM can delete fabricated segments, replace them, or decline to touch them, and that it returns structured repair actions with confidence and reasoning. This gives the agent a solid picture of the tool's autonomy and output without relying on annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences that front-load the primary action, then add behavioral detail and output shape. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description adequately explains the input context (flagged segments), the behavior (delete/replace/decline), and the output shape (structured actions with confidence and reasoning). Slightly more detail about whether actions are applied directly or returned as suggestions would be helpful, but it is not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents 'transcript_json' as a JSON string of a TranscriptResult with flags. The description adds workflow context but does not elaborate on the parameter itself, so it neither harms nor significantly improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Run the LLM repair loop') and a clear resource ('flagged segments'), while also enumerating the possible actions the LLM can take (delete, replace, or decline). This clearly differentiates 'repair' from siblings like 'detect_hallucinations' or 'score', which operate at earlier or different stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'on flagged segments' provides clear context that this tool is intended for transcripts that have already been flagged, presumably by 'detect_hallucinations'. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute quality metrics: WER, CER, hallucination rate, words per minute. If a reference transcription is provided, computes accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| reference_text | No | Reference transcription to score against (optional) | |
| transcript_json | Yes | JSON string of a TranscriptResult |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses what metrics are computed and the conditional behavior around reference text, but it does not mention whether the tool mutates anything, what it returns, or how it handles missing reference text beyond omitting accuracy. For a pure computation tool this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The metrics are listed up front, and the conditional behavior is stated second. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter computation tool with fully documented schema, the description is nearly complete. The only notable gap is that it does not describe the output shape or explicitly differentiate from detect_hallucinations, but this is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents transcript_json and reference_text. The description adds the metric names and the role of reference_text in computing accuracy, but it does not add material detail about parameter formats or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Compute'), a clear resource (transcript quality), and enumerates the exact metrics: WER, CER, hallucination rate, words per minute. This distinguishes it from siblings like transcribe and estimate_cost, and the conditional accuracy clause adds further precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool to score transcript quality metrics. However, it does not explicitly state when to prefer this over detect_hallucinations, which also overlaps with 'hallucination rate', nor does it mention any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe an audio file using Whisper. Returns segments with timestamps, text, and confidence scores.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | ISO 639-1 language code | fr |
| audio_path | Yes | Path to the audio file (wav, mp3, m4a, flac) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure and does a solid job by stating not only the action but the exact return payload: 'segments with timestamps, text, and confidence scores.' It also names the underlying engine, Whisper, which helps set expectations. It does not detail limitations or prerequisites, but the described behavior is concrete and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence that front-loads the core purpose and follows with the output structure. There is no wasted phrasing or redundant information, and every word contributes to an agent's understanding of what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only two parameters, no output schema, and no annotations, the description covers the essential elements: what it does, how it does it, and what it returns. It could add guidance about how this step fits with sibling tools like detect_hallucinations or repair, but that omission does not prevent correct use of the tool itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters, audio_path and language. The description adds no extra meaning about either parameter, such as default language behavior or audio format handling. The baseline score of 3 is appropriate because the schema does the heavy lifting and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair, 'Transcribe an audio file using Whisper', and clearly distinguishes this tool from sibling tools like detect_hallucinations, repair, score, and estimate_cost, which operate on transcription results rather than producing them. It is immediately obvious what this tool does and how it differs from others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: whenever an audio file needs to be transcribed. It names the input type and the model used, providing clear context. It does not explicitly discuss when not to use it or compare to alternatives, but the sibling names suggest downstream processing rather than competing transcription options, so the basic usage context is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool maps to a distinct stage in the transcription workflow: transcribe, detect hallucinations, repair, score, and estimate cost. There is no functional overlap or ambiguity about which tool to select.
Most tools follow a verb_noun pattern (detect_hallucinations, estimate_cost), while transcribe, repair, and score are single verbs. The naming is still consistent in style and domain, with no mixed casing or confusing variations.
Five tools is well-scoped for an audio transcription quality pipeline. Each tool serves a clear purpose and the set is neither bloated nor thin.
The toolset covers the full core pipeline: transcription, hallucination detection, LLM-based repair, quality scoring, and cost estimation. A minor gap is the lack of separate transcript retrieval or manual editing tools, but repair covers corrections reasonably.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Transcribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
Transcribe audio & video: diarization, timed SRT/VTT, podcasts, paste-a-link, whole-feed batch.
Transcribe audio and video into speaker-labelled transcripts, subtitles, clips, and cited Q&A.
Transform video, audio and images, and generate media from prompts. FFmpeg, captions, models.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Guillain-RDCDE/Trusted-Transcription'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
