自動文字起こしに潜む自信に満ちた嘘を検出します。
Whisperは30秒の無音に対してこれを生成します:
「ご視聴ありがとうございました。チャンネル登録をお願いします。」
信頼度: 0.88。エラーも警告もありません。後段のシステムはそれを事実として取り込みます。
このプロジェクトは、そのようなケースと、ASRパイプラインが静かにゴミを出力する他の6つの方法を検出します。
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 flags3つの幻覚を検出。API呼び出しはゼロ。クリーンなサンプルに対する誤検知もゼロ:
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、そして「この箇所には触れません」と明示的に言う許可が与えられます。制約なしの修復は23%の確率で状況を悪化させます（ADR 0004にその実験が記録されています）。
人間は、LLMが解決できない重大なフラグについてはループに留まります。 約70%の文字起こしは無人で通過し、残りは該当セグメントを正確にハイライトした上でレビューに回されます。
検出器 | 検出対象 | 仕組み |
| 同じフレーズが5〜50回 | スライディングウインドウ上のN-graム頻度 |
| 無音時の「ご視聴ありがとうございます」 | 既知の幻覚パターン + 1秒あたりの単語数比 |
| システムプロンプトが出力に漏れる | 命令マーカーのパターンマッチング |
| タイムスタンプの重複、逆転、停止 | 連続セグメントのペアごとの算術演算 |
| 文脈と無関係な一貫性のあるテキスト | 隣接する語彙とのジャカード距離 |
| フランス語の文字起こしが英語に変わる | 言語タグ + 機能語マーカー |
| セクションが静かに欠落する | カバレッジ率 + 1分あたりの単語数 |
モード7が最も危険です。他の幻覚はすべて目に見えるゴミを生成します。しかしこれは何も生成しません — そして、何もないことは正しく見えるのです。
症状と原因の完全な一覧: docs/failure-modes.md
PYTHONPATH=src python -m trusted_transcription.mcp_serverstdioで公開される5つのツール: transcribe, detect_hallucinations, repair, score, estmate_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なぜファインチューニングではなく2つのモデルを使うのか？人間はどこに留まるのか？なぜ確率的アプローチより先に決定的アプローチなのか？
0001 — 直列の2つのモデル（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
