torben/chemenu
1
1
Fork 0
Code Issues 26 Pull Requests Actions Packages Releases 32 Activity

Backlink-boosted Ranking in tools/chemenu/search/fuse.py #6

New Issue
Open
opened 2026-08-29 22:03:25 +00:00 by torben · 1 comment
torben commented 2026-08-29 22:03:25 +00:00
Owner
Copy Link
Copy Source

Abgezweigt von: #2 ("Personalization Plane: USER.md + SOUL.md ("Thoth") aus gbrain-Analyse übernehmen")
Session-Tag: perplexity-gbrain-personalization-2026-08-23

status/blocked auf #35, seit 2026-09-04. Backlink-Boost und semantisches Backend sind beide
Ranking-Signale und laufen beide durch dieselbe fuse.py. Wer #35 baut, hat die Messumgebung, an
der sich eine Gewichtungsformel überhaupt bewerten lässt; vorher ist jeder Faktor geraten. Das
Issue bleibt offen, weil das Signal plausibel ist — aber es ist nicht eigenständig bearbeitbar.

Kontext

gbrain gewichtet beim Retrieval Seiten mit mehr Backlinks höher ("a page found by two backends outranks a page found by one" ist bei uns schon per RRF gelöst – aber nur zwischen Suchbackends, nicht nach Backlink-Anzahl einer Seite).

tools/chemenu/search/fuse.py volltext geprüft: reciprocal_rank_fusion() implementiert reines RRF (RRF_K = 60) über die Ranglisten mehrerer Backends (lexikalisch/semantisch) und sortiert final nach (-score, title.lower()). Kein Signal aus der Anzahl eingehender Links (related:/entities:/concepts:-Referenzen anderer Seiten) fließt in den Score ein.

Vorschlag

Backlink-Anzahl als zusätzlichen, schwach gewichteten Fusionsfaktor einführen – nicht als weiteres RRF-Backend (das würde Rang-Gleichheit zwischen einer thematisch zentralen und einer nur zufällig hoch platzierten Seite erzeugen), sondern als Tie-Breaker oder kleiner additiver Bonus auf den bereits fusionierten Score.

Wichtig zur Risikobewertung (eigene Einschätzung, kein geprüfter Fakt): das ist der einzige der drei ausgelagerten Punkte, der bestehenden Kern-Suchcode verändert statt nur zu ergänzen – entsprechend sorgfältiger testen (tools/chemenu/tests/test_search.py existiert bereits).

Offene Fragen für die Umsetzung

  • Backlink-Zahl woher? kb/index.md/INDEX.md enthalten vermutlich schon aggregierte Referenzen – prüfen, ob das ohne zusätzlichen Scan verfügbar ist, oder ob kb_scan.py erweitert werden muss
  • Gewichtungsfaktor: fix oder konfigurierbar (config.py)?
  • Gilt das für alle Seitentypen gleich, oder sollten z. B. kb/sources/-Seiten (viele Backlinks per Konstruktion) anders behandelt werden als kb/concepts/?

Nächste Schritte

  • Zuerst #35. Ohne ein zweites Backend und einen Korpus, an dem Ranking überhaupt weh tut, gibt es nichts, wogegen eine Formel validiert werden könnte
  • Datenquelle für Backlink-Zähler klären (bestehender Index vs. neuer Scan)
  • Gewichtungsformel entwerfen und gegen test_search.py validieren
  • Vorher/Nachher-Vergleich an ein paar realen Suchanfragen, bevor Merge

Hinweis zu Pfaden

Alle tools/wiki_tools/…-Pfade in diesem Body sind am 2026-09-04 auf tools/chemenu/… nachgezogen
worden (Rename in 2.0.0, #3). Der Titel war bereits vorher korrigiert. Teilerledigung von #29.

**Abgezweigt von:** #2 ("Personalization Plane: USER.md + SOUL.md (\"Thoth\") aus gbrain-Analyse übernehmen") **Session-Tag:** `perplexity-gbrain-personalization-2026-08-23` **`status/blocked` auf #35, seit 2026-09-04.** Backlink-Boost und semantisches Backend sind beide Ranking-Signale und laufen beide durch dieselbe `fuse.py`. Wer #35 baut, hat die Messumgebung, an der sich eine Gewichtungsformel überhaupt bewerten lässt; vorher ist jeder Faktor geraten. Das Issue bleibt offen, weil das Signal plausibel ist — aber es ist nicht eigenständig bearbeitbar. ## Kontext gbrain gewichtet beim Retrieval Seiten mit mehr Backlinks höher ("a page found by two backends outranks a page found by one" ist bei uns schon per RRF gelöst – aber nur *zwischen Suchbackends*, nicht nach *Backlink-Anzahl einer Seite*). `tools/chemenu/search/fuse.py` volltext geprüft: `reciprocal_rank_fusion()` implementiert reines RRF (`RRF_K = 60`) über die Ranglisten mehrerer Backends (lexikalisch/semantisch) und sortiert final nach `(-score, title.lower())`. Kein Signal aus der Anzahl eingehender Links (`related:`/`entities:`/`concepts:`-Referenzen anderer Seiten) fließt in den Score ein. ## Vorschlag Backlink-Anzahl als zusätzlichen, schwach gewichteten Fusionsfaktor einführen – **nicht** als weiteres RRF-Backend (das würde Rang-Gleichheit zwischen einer thematisch zentralen und einer nur zufällig hoch platzierten Seite erzeugen), sondern als Tie-Breaker oder kleiner additiver Bonus auf den bereits fusionierten Score. **Wichtig zur Risikobewertung (eigene Einschätzung, kein geprüfter Fakt):** das ist der einzige der drei ausgelagerten Punkte, der bestehenden Kern-Suchcode verändert statt nur zu ergänzen – entsprechend sorgfältiger testen (`tools/chemenu/tests/test_search.py` existiert bereits). ## Offene Fragen für die Umsetzung - Backlink-Zahl woher? `kb/index.md`/`INDEX.md` enthalten vermutlich schon aggregierte Referenzen – prüfen, ob das ohne zusätzlichen Scan verfügbar ist, oder ob `kb_scan.py` erweitert werden muss - Gewichtungsfaktor: fix oder konfigurierbar (`config.py`)? - Gilt das für alle Seitentypen gleich, oder sollten z. B. `kb/sources/`-Seiten (viele Backlinks per Konstruktion) anders behandelt werden als `kb/concepts/`? ## Nächste Schritte - [ ] **Zuerst #35.** Ohne ein zweites Backend und einen Korpus, an dem Ranking überhaupt weh tut, gibt es nichts, wogegen eine Formel validiert werden könnte - [ ] Datenquelle für Backlink-Zähler klären (bestehender Index vs. neuer Scan) - [ ] Gewichtungsformel entwerfen und gegen `test_search.py` validieren - [ ] Vorher/Nachher-Vergleich an ein paar realen Suchanfragen, bevor Merge ## Hinweis zu Pfaden Alle `tools/wiki_tools/…`-Pfade in diesem Body sind am 2026-09-04 auf `tools/chemenu/…` nachgezogen worden (Rename in 2.0.0, #3). Der Titel war bereits vorher korrigiert. Teilerledigung von #29.
torben added the prio/waitingsize/M labels 2026-08-31 06:56:50 +00:00
torben changed title from Backlink-boosted Ranking in tools/wiki_tools/search/fuse.py to Backlink-boosted Ranking in tools/chemenu/search/fuse.py 2026-09-01 15:20:47 +00:00
torben added the area/kbkind/build labels 2026-09-02 21:25:06 +00:00
torben added the status/blocked label 2026-09-04 12:30:07 +00:00
torben commented 2026-09-04 12:33:56 +00:00
Author
Owner
Copy Link
Copy Source

Changelog: status/blocked gesetzt, an #35 (Triage-Sitzung 2026-09-04, Betreiberentscheidung).

Zur Debatte stand, ob das Issue als spekulativ zu schließen ist — es gibt kein gemessenes Ranking-Problem, nur die Analogie zu gbrain. Ergebnis: offen lassen, aber ehrlich labeln. Backlink-Boost und semantisches Backend sind beide Ranking-Signale durch dieselbe fuse.py; wer #35 baut, hat die Messumgebung, an der sich eine Gewichtungsformel überhaupt bewerten lässt. Vorher ist jeder Faktor geraten, und ein geratener Faktor in Kern-Suchcode ist genau das Risiko, das der Body selbst benennt.

Dazu im Body: ein erster „Nächster Schritt" (zuerst #35), und der Blocker-Absatz im Kopf.

Pfade tools/wiki_tools/… → tools/chemenu/… nachgezogen (Teilerledigung von #29). prio/waiting, kind/build, size/M, area/kb unverändert.

**Changelog:** `status/blocked` gesetzt, an **#35** (Triage-Sitzung 2026-09-04, Betreiberentscheidung). Zur Debatte stand, ob das Issue als spekulativ zu schließen ist — es gibt kein gemessenes Ranking-Problem, nur die Analogie zu gbrain. Ergebnis: offen lassen, aber ehrlich labeln. Backlink-Boost und semantisches Backend sind beide Ranking-Signale durch dieselbe `fuse.py`; wer #35 baut, hat die Messumgebung, an der sich eine Gewichtungsformel überhaupt bewerten lässt. Vorher ist jeder Faktor geraten, und ein geratener Faktor in Kern-Suchcode ist genau das Risiko, das der Body selbst benennt. Dazu im Body: ein erster „Nächster Schritt" (zuerst #35), und der Blocker-Absatz im Kopf. Pfade `tools/wiki_tools/…` → `tools/chemenu/…` nachgezogen (Teilerledigung von #29). `prio/waiting`, `kind/build`, `size/M`, `area/kb` unverändert.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/corpus
Betrifft Demo-/Testbett-Frage, Inhalt und Umfang von kb/
 area/distribution
Betrifft Auslieferung, Upgrade, Versionierung einer Instanz
 area/kb
Betrifft kb/-Schema, Contract, Confidence, Lint, Wissensbasis
 area/process
Betrifft den Entwicklungsprozess selbst, nicht den Stack als Artefakt
 area/workflow
Betrifft Git, Merge, Branching, Publish, PRs
 kind/build
Spezifiziert, wartet nur noch auf Umsetzungszeit
 kind/decision
Wartet auf eine Betreiberentscheidung
 kind/defect
Befund: Doku und Realitaet, oder zwei Dokus, widersprechen sich
 prio/blocking
Blockiert oder beschaedigt laufende Arbeit - als naechstes
 prio/planned
Traegt bald Zinsen - eingeplant
 prio/waiting
Sinnvoll, wartet auf einen Ausloeser
 size/L
Mehrere Sitzungen oder offene Designfragen vor dem ersten Commit
 size/M
Mehrere Dateien, Contract- oder Instruction-Aenderung, eigener Testaufwand
 size/S
Eine Sitzung, ein Publish, klar umrissener Schnitt
 status/blocked
Wartet auf ein anderes, noch offenes Issue - nicht eigenstaendig bearbeitbar
 status/incoming
Vom Menschen angelegte Anforderung, unvollständig, muss durch den Stack komplettiert werden.
 status/unconfirmed
Gemeldeter Verdacht, noch nicht gegen tatsaechliches Verhalten geprueft - size/prio vorlaeufig
No Label area/kb kind/build prio/waiting size/M status/blocked
Milestone
No items
No Milestone
Assignees
Clear assignees
torben
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: torben/chemenu#6
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?