翻訳待ち：Show HN: TekMyra – context compression that refuses numbers it can't defend

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

Uh oh! There was an error while loading. Please reload this page. Notifications You must be signed in to change notification settings Fork 0 Star 0 BranchesTags Open more actions menu Latest commit History 2 Commits 2 Commits Folders and files NameName Last commit message Last commit date benchmarks/fixtures benchmarks/fixtures configs configs contracts contracts scripts scripts tekmyra tekmyra tests tests .gitignore .gitignore ARCHITECTURE.md ARCHITECTURE.md CITATION.cff CITATION.cff CONTRIBUTING.md CONTRIBUTING.md LICENSE LICENSE MANIFEST.in MANIFEST.in NOTICE NOTICE README.md README.md SECURITY.md SECURITY.md constraints-reproduce.txt constraints-reproduce.txt pyproject.toml pyproject.toml Repository files navigation TekMyra is a compressor that refuses rather than guesses. TekMyra compresses context for language models and then checks its own work. Before anything is emitted, a verifier confirms that every protected span (an account number, a citation, a file path, a monetary amount, a policy identifier) is represented exactly once in the output: as verbatim text, as an approved typed redaction marker, or as a token that resolves to the original. If that check fails, the compressor retries on a safer route. If the retry fails too, it raises and emits nothing. That is the whole idea. A compressor that silently drops a dollar figure is worse than no compressor, because the output still looks fine. The rest follows from it. A deterministic safety gate assigns a risk tier; a learned router proposes a route and may raise the risk tier but never lower it; a lossy route proposed at elevated risk is overridden to a reversible one. Protected spans get a disposition (preserve, redact, anchorize, or human-review) that tightens monotonically with risk and never loosens. What you get, honestly This is an open core, not the whole product. It is the compression and verification path: routing, the codecs, the learned selector, protected-span detection, the safety merge, and the verifier. 55 modules, six benchmark corpora, the configuration and contracts they need, the test suite, and the scripts that let you check our claims instead of believing them. What is deliberately not here, and why, is at the bottom of this file. Each absence is a design decision and is documented as one. Install From PyPI (Python 3.11+; the distribution is tekmyra-core, the import name is tekmyra): pip install tekmyra-core Or from source, which is what the rest of this page assumes: git clone https://github.com/laconiq-ai/tekmyra.git cd tekmyra pip install -e '.[dev]' # the library plus pytest, to run the suite below If you do not want the test dependencies, pip install -e . installs the library alone. Core dependencies are click, numpy, pydantic, scikit-learn, scipy, tiktoken and pyyaml. tiktoken is a core dependency, not an extra: the token-reduction figures are unobtainable without it, and a bare install that printed WITHHELD instead of a number is the defect that forced this decision. Optional extras: [transformer] for the transformer compressor path, [baselines] for comparison baselines. Neither is needed to reproduce anything below. You need a model, and here is how to get one Trained model artifacts are not in this repository and never will be. They are the commercial half. The reference artifact bundle is published as a release asset on this repository's Releases page, tekmyra-reference-artifacts.tar.gz, with its SHA-256 printed in the release notes. Download it, check the digest before extracting, and unpack it at the root of your clone: curl -L -O https://github.com/laconiq-ai/tekmyra/releases/latest/download/tekmyra-reference-artifacts.tar.gz shasum -a 256 tekmyra-reference-artifacts.tar.gz # compare against the release notes tar xzf tekmyra-reference-artifacts.tar.gz # unpacks .cache/compressor/1.0.0 and .cache/router/1.0.0 The digest is published beside the asset rather than pinned in this file, so that a reader checks the artifact they actually downloaded against the record for that release rather than against a constant that a later release would silently falsify. What you cannot do, stated rather than left to be discovered: you cannot retrain these artifacts from this repository. The training corpus and the trainer are deliberately not published, under the same rule that keeps trained artifacts closed. The bundle is verifiable as a receipt (compare its digest) and is not reproducible from source. No tool in this payload claims otherwise. The artifact directories are resolved in this order, and a failure prints every location it tried: $TEKMYRA_ARTIFACT_ROOT/.cache/... if that variable is set .cache/... under your working directory .cache/... beside the installed package Without a model, the benchmark refuses to give you a number. That is not a bug, and it is worth seeing; it is the same instinct as the verifier: Error: Learned router artifact did not load — refusing to produce a benchmark number. artifact_dir='/.cache/router/1.0.0' exists=False backend='none'. could not resolve '.cache/router/1.0.0'; searched, in order: absent /.cache/router/1.0.0 Set $TEKMYRA_ARTIFACT_ROOT to the directory holding .cache/ if your artifacts live elsewhere. Re-run with --allow-rules-only to record an explicitly rules-only run; such a run cannot emit a headline compression ratio. If you have not downloaded the model yet, that is almost certainly the cause, and it is the expected state of a fresh clone: the trained artifact is a separate release asset, not part of this repository. See 'You need a model' in the README for the fetch procedure. To measure what this build can produce without one, re-run with --allow-rules-only - that records an explicitly rules-only run and cannot emit a headline compression ratio. (That transcript is pasted from a real run in a fresh clone, where the working directory and the editable install are the same place, so the search has one candidate; run from anywhere else and the list grows to every location tried.) Take the escape hatch it offers and you get a run that is honest about what it is: the headline is withheld (not zero, not one, withheld), token reduction is 0.00%, and 68 of 68 locked spans are still preserved across 28 reached fixtures. The safety machinery works without a model. The compression does not. Numbers Every figure names its corpus, its denominator, its basis, and which execution path produced it. Figures on different bases are not comparable and are not put in one table. With the reference artifact bundle, on the corpora in this repository, via the joblib/scikit-learn path (no onnxruntime installed): corpus fixtures mean size headline ratio tokens locked spans synthetic 301 (28 reached of 28 eligible, 0 refused) 250 chars 0.7409 +25.86% 68/68 long_context_v1 40 (26 reached of 40 eligible, 14 refused) 23,644 chars 0.2929 +48.44% corpus / +70.40% on the prose route 704/704 Headline ratio is the share of content kept, averaged over fixtures the compressor reached. Tokens is corpus-wide token reduction with refusals in the denominator: a refusal saves nothing and is counted as saving nothing, because a build that refuses more would otherwise score better for refusing. One more thing both rows share, which the benchmark prints beside every number and this table must therefore say too: routing is blind, and some labels name a codec that does not exist. 20 of synthetic's 28 eligible fixtures are labelled route_intent=summarizer and 20 of long_context_v1's 40 are labelled extractive_keypoint_compressor (both declared but never built), so routing blind sends them to prose_token_compressor instead. An improvement on those fixtures means "compressed with a different codec than the labels specify", not "compressed what the labels intended"; both are true of these numbers and only one is what a reader assumes. The report's routing_caveat field carries this per-corpus, derived from the fixtures at run time. The 14 refusals on long_context_v1 are the headline of that row, not a footnote to it, and they are refusals, not abstentions. Both words appear in this project and they are different outcomes, so here is what was measured, on both builds at the same commit with the anchor store as the only variable: Abstentions are zero in both builds. An abstention is a fixture that completes untouched. None did. The 14 are refusals, and they exist only in this build. The commercial build completes all 40. The refused fixtures are the same 14 either way, and the 26 this build completes are exactly a subset of the commercial build's 40. They fail three checks at once (locked_spans_preserved, facts_preserved, anchors_resolvable), not the anchor check alone. This build cannot resolve anchors (see What is deliberately absent), so spans the commercial build recovers are unrecoverable here, and verification refuses rather than shipping the loss. They are not "routed to" reversible_retrieval_mode. That is where they LAND after their first route fails verification; the router sent them to legal_security_safe_mode (6) and governance_safe_compression (8). Routing is identical in both builds (same routes, same ratios on every shared fixture), so the anchor store changes what survives verification, never where anything was sent. This build is not worse at compressing. It reaches the compressor on exactly the same 26 fixtures and produces the identical 0.2929. It refuses 14 that the commercial build completes, for a stated reason, and counts them as saving nothing. A system that compresses 26 of 40 and refuses 14 rather than ship an unverifiable result is making a different promise from one that compresses all 40; that difference is what the open/closed seam costs, stated rather than smoothed. Locked spans: name the build before quoting the ratio. Both builds report 1.000, over different denominators: 704/704 here, 1785/1785 commercial. The gap is the 1,081 spans belonging to the 14 refused fixtures, which leave this build's count with the fixtures. Span detection is identical across both builds on every shared fixture. The public-corpus figure and what this repository can reproduce Our public-corpus baseline is 62.1458% effective byte reduction over 138 fixtures (2,708,761 → 1,025,379 bytes) with 6 refusals (4.35% of fixtures, 3.55% of bytes), refusals contributing zero saving; the on-accepted diagnostic is 64.4356%. Measured at commit 14c63bc on benchmarks/fixtures/public_{domain,code,diff,json}_v1. Those four corpora ship in this repository. A clean clone can verify that their fixture bytes match the committed baseline and that every third-party source is covered by NOTICE: python -m pytest tests/test_public_corpus_notice.py That does not reproduce the 62.1458% rate. Reproducing it also requires the trained artifacts, which the reference bundle supplies as the versioned .cache/compressor/1.0.0 and .cache/router/1.0.0 directories the code loads; a clean checkout has neither and measures a no-op prose compressor. With the bundle unpacked, run: python -m pytest tests/test_public_corpus_ratchet.py The rate is on a byte basis and is not comparable to the ratio and token figures above. The evidence artifact, tests/baselines/public_corpus_baseline.json, carries the figure, its denominators, the corpus file counts and the sha256 digest of each corpus. Which of those digests you can check here is worth stating precisely, because the baseline is the record of a measurement taken in the private tree. The digests for the four public_* corpora and synthetic match this repository's bytes and you can recompute them (the algorithm is tests/measurement_provenance.py::_corpus_digest). Three entries describe the private measuring tree and will NOT match what you have: benchmark [truncated for AI cost control]