slowlp
← Blog
Lesson 2026.07.19 · 12 min read

Index and keywords came out worse than I expected

Splitting vertical classification from cross filters, then capping counts all the way into merge

Lesson

The screen felt wrong. Shelf classify (index) and tags both there, overlapping as if they did the same job. More docs, more split bins, more chips, and the wiki list never felt cleaned. Around then I said: 「지금 화면이 보기 좀 불편한데 index와 태그가 있는데 뭔가 구성을 좀 잘할순 없을까」.

I thought it was UI layout. It was a lower layer. When classify is off, wiki seating goes off with it.

If classify is wrong, the wiki is wrong

In myWiki, L1 is shelf row one. Which bin a doc sits in. L2 is a finer bin inside. Keywords are chips that cross those bins. I did not write that cleanly from day one. In use the roles mixed.

Open a project space and one product split into many bins. slowloop, SlowLoop, slowloop lab, SlowLoop Lab, slowloop-lab. Spelling variants, five shelf bins. 「지금 프로젝트 인덱스 보면 같은 의미가 많은데 slowloop 관련되서 이런거 하나로 통합 안되나」. Fair. hermes and hansaiam bundled into one bin cleanly, but a shaky brand name and AI opened a new bin.

「이거 AI가 인덱스 만드는거 아니야?」. Yes. People are not hand-building a folder tree. Each doc gets a bin, the system draws it. Fragments are quality, not a crash bug. Weak synonym→canonical rules and bins split by spelling. Add synonym rules to the prompt, re-run classify, five bins become one. Keep brand names out of hardcode; patterns only. That direction landed then too.

Funnier mistakes too. Space name leaking in as an L1 prefix. Space is already the root; put the name on the path again and the shelf folds twice. Interest spaces mixed with product axes. Single-product spaces reusing the product name as L1. Axes blurred enough that I had to ask 「l1 이 1차 인덱스 맞아?」.

Bad classify makes wiki placement bad. Summarize and reflect follow bins. Wrong shelf map means wrong seats for everything piled on it. Same lesson as fixing the second-side classify. If find-and-seat structure breaks, polishing body quality does not show up in the feel.

Tags work when few; around a thousand they fail

Keyword chips are fine with few docs. Dozens, press a chip, browse related. Near a thousand docs the story changes. Too many chips, near-duplicates, filters that still feel messy. Not “collect related docs.” More “pick one chip from a sea.”

At first I treated shelf classify and tags almost as one layer. Sometimes the bin name became a tag again. Vertical classification and cross filter stacked on one line. Shelf already has “slowloop-lab,” chip has it again. Filter and the keyword list looks unchanged. 「1차인덱스별로 태크 관리는 안하고있나? 필터걸면 키워드가 안바뀌고 그대로네」. What I wanted: pick a shelf bin, chips narrow to docs inside. Without split roles, that does not show. Classify is seat. Keyword is a cross signal. Copy the same word into both and the screen doubles dirty.

So I split the jobs.

Classify is vertical. One doc, one bin. L1/L2 two levels by default; if only one arrives, correct into a bin. Pick one L1 axis by space character. Multi-app space → product name. Single product → module/layer. Interest space → life/interest area. Do not mix axes. Do not re-inject the space name into the path. Implementation detail goes to L2 or keywords. L1 is one axis only.

Keywords are cross filters. Chips that gather the same topic · series · family across shelf bins. Do not clone bin names onto chips. Series numbers and version shards collapse to a group rep. One chip is one group. “Sits in this bin” is classify. “Gather this family” is keyword.

I put the split into generation rules too. If too few docs wear a group, do not keep the chip. Space-wide keyword budget: target about thirty, hard near forty. Over hard, keep by frequency, drop the rest. Integer caps versus 「한도를 정수가 아니고 비율로 할까 현재 인덱스에 포함된 전체 문서 갯수로 해가지고」 as a share of total pages, we talked both. In the end keywords got a per-space ceiling, merge got a per-bin page budget. Numbers differ. Premise is the same: do not grow forever.

The cap that stopped keyword flood went into merge too

Role split was not enough. Keywords still want to grow. AI loves inventing new words per doc. Count limits finally locked it some. Harder to invent new chips, forced reuse of existing vocabulary, screen less noisy. Prefer attach to an existing chip over inventing a group every time.

Same sense went into document merge. Continues from sticky merge. After a summarize batch, cluster drafts by title·summary, promote only confirmed ones to the shelf. Too many shards and the wiki is a thin card wall. Waiting for people to hit merge forever is heavy. So bind once at batch end.

Scope was the problem. Scan the whole space at once and keyword overlap alone can glue unrelated notes. “Both AI,” “both life.” Weak commonality should not merge. Minecraft and a prayer note in one doc, product name stuck to unrelated life memo. Prompt-only “be careful” is weak against that.

So merge was caged inside L2, the shelf bin. Only candidates inside the same L1/L2. Cross-bin merge rejected in code. Per-bin page budgets too. Soft/hard from space doc count and bin count; high-pressure bins first. One bin too large → split that bin across requests, never mix other bins’ docs. Merge-strength hints are secondary. Page budget and bin boundary are the body.

Effect was better than expected. Not perfect. The old “totally different topics on one card” accidents dropped. Better than scanning the whole space on keyword stickiness alone. Same bin, similar title·summary → candidate. Different bin → never on the list.

Fencing a model that does not get the body

Why caps work: the merge model does not get full bodies. It gets id, title, summary, which bin. Tokens and cost. Same proper noun in title and summary and “merge” can be right. Same titles, different contexts also exist. Without bodies, keyword overlap can get sticky. Smart model, thin input, no judgment material.

Then classify is the fence. “Merge only inside this bin” cuts whole-space keyword sticker mistakes. Vertical classification seats first; cross signals only work inside. Keyword caps stop chip flood; shelf caps stop over-merge. Same count-constraint idea on another layer. Narrowing the candidate set by bin is more stable than “merge carefully” in a prompt.

Not done. Synonym rules need more work. L1 axes by space character still wobble in real use. Filter UX still awkward. One sense is clear: classify has to be right for the wiki to live. Not decoration for a pretty taxonomy. The floor that makes later merge, query, and organize behave as expected.

It started as “the screen is uncomfortable,” and ended as splitting what bins and chips do, then caging how many are allowed as numbers. Without that cage the model glues unrelated notes on title·summary overlap alone. With it, not perfect, but merges that leak off the shelf drop.

myWiki series 6 / 7 View all →
Recently added — this is a middle part of the series, not the latest in the story. Read on with “Next”.
COMMENTS