Skip to main content
← Back to blog
9 min readSystems & Infra

Deleting 1.37% Wasn't the Whole Fix—Pruning and Hierarchical Titles Cut Collision Groups by 96.1%

I expected this to be a conventional knowledge-base cleanup: find duplicates, remove obsolete notes, and make the database smaller. Once the audit started, the real problem turned out not to be volume. It was that even a successful search result was often hard to identify.

Across three research namespaces, many sections from different documents shared flat titles such as “Analysis,” “Implementation,” “Conclusion,” or the same feature name. Full-text search could find the words, but the result title had lost its parent chapter and source context. Search was technically working while becoming harder to trust.

A small deletion count, a large signal improvement

Here is the measured result across those three namespaces:

MetricBeforeAfterChange
Indexed rows9,8069,672-134 (-1.37%)
Duplicate-title collision groups773-96.1%
File-sync rows with hierarchical paths08,766Context became visible

“Collision group” has a precise definition here: within each namespace, group file-sync rows by exact title and count only groups where COUNT(*) > 1. The 77 groups were distributed 17, 9, and 51 across the three namespaces; after rebuilding, the counts were 0, 1, and 2.

The 134 removed rows consisted of 69 precisely classified degenerate sections and 65 sections generated from byte-identical duplicate sources. Four hand-written entries were also retired in a separate, non-research namespace; they are not part of the three-namespace table or its 134-row delta. Each was removed only after proving that a successor fully preserved its useful content, provenance remained traceable, and the pre-deletion version was recoverable.

By storage volume, this was barely a cleanup. By result ambiguity, it was a substantial repair.

The core change: make titles carry their path

We did not rewrite the knowledge itself. We changed file-sync section titles so they retained parent context. A flat title such as:

Error handling

could become:

deployment.md § Deployment › Startup checks › Error handling

The keyword is still present. The full body is still searchable. But the result can now answer, “Error handling for which part of the system?” A direct post-deployment measurement found 8,766 file-sync rows with this form of hierarchical address.

Fewer title collisions do not, by themselves, mean harder search. The structure adds context without replacing the original terms, but the added parent terms can change ranking. A broad query for a parent topic may still retrieve several child sections, so a fixed benchmark is needed to separate preserved recall from ranking side effects.

Same-query comparisons, before and after

“The results look cleaner” was not an acceptable test, so we kept a pre-change snapshot and repeated the same queries:

  • M2_2_3: 17 hits became 15. The two removed results had ranked third and fourth and contained only degenerate sections; useful content remained.
  • 啟動器設計討論: 200 hits became 135. The missing 65 were exactly the duplicate file-sync sections, and the top five were no longer polluted by an inner duplicate proposal.
  • playbooks: 15 hits remained 15, the top-five order was unchanged, and titles gained their chapter paths.

These three post-hoc queries illustrate junk removal, source deduplication, and preserved recall for one stable case, but they are not a complete search benchmark. A separate, preselected set of ten system queries produced top-five overlaps of 5/5 for five queries, 3/5 for four, and 2/5 for one. Hierarchical titles can promote sibling sections from the same file, so the change improves result identification but is neither free nor guaranteed to preserve every rank. For the three queries whose hit counts and top-five outputs were archived, we observed no loss of useful full-text recall.

Agreement between two AIs was not a vote

Codex performed the inventory, dry runs, implementation, deployment, and validation. Claude then reviewed the work independently in read-only mode through ai-cli. Both models had to accept the same evidence rules:

  1. Duplicate sources required byte-level proof; matching names were insufficient.
  2. File-synced rows could not be deleted directly from the index; the source selection or splitting rule had to be corrected and synchronized again.
  3. Short did not mean worthless. Only precisely defined shapes—empty fences, horizontal rules, placeholders, standalone dates, and similar degenerate sections—could be filtered.
  4. A hand-written entry could be retired only when a successor fully preserved its useful content and version history could restore the original.
  5. Anything without complete evidence stayed on hold.

At the deployment gate, Claude independently reran 86 tests and 44 subtests before returning FINAL APPROVE; that was separate from the publication review of this article. The value was not that two models said yes. The value was that both had to reason from hashes, manifests, counterexamples, backups, and query results that another reviewer could reproduce.

What I am deliberately not calling complete

The structural rebuild and full-text search have passed validation, but fresh embeddings are still rebuilding in the background. The system reports search_degraded=true while vector coverage is incomplete, so this article claims an improvement only for structure and FTS. It does not present semantic or hybrid ranking as fully accepted.

Separating those gates matters. A responsive service and working keyword search do not prove that semantic ranking has converged. At the same time, a long-running embedding job should not erase the evidence for structural improvements that have already passed their own tests.

Five principles worth keeping

  1. Measure addressability, not only volume. A 1.37% reduction in rows can produce a much larger improvement in result clarity.
  2. Collision groups measure result ambiguity better than total row count. Moving from 77 exact-title groups to 3 directly shows improved identification; search experience still needs a fixed query benchmark.
  3. Pruning needs provenance and recovery points. Without sources, hashes, manifests, and backups, deletion is merely an irreversible guess.
  4. AI consensus needs shared evidence, not majority voting. An independent second review is valuable only when it can challenge the same artifacts.
  5. Structural and semantic acceptance are different gates. Keeping them separate prevents “partially complete” from becoming “fully successful.”

The counterintuitive lesson is that good knowledge-base pruning is not about remembering less. It is about making every retained piece easier to find, identify, and trust.