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
changed title from Backlink-boosted Ranking in tools/wiki_tools/search/fuse.py to Backlink-boosted Ranking in tools/chemenu/search/fuse.py2026-09-01 15:20:47 +00:00
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.
**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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Abgezweigt von: #2 ("Personalization Plane: USER.md + SOUL.md ("Thoth") aus gbrain-Analyse übernehmen")
Session-Tag:
perplexity-gbrain-personalization-2026-08-23status/blockedauf #35, seit 2026-09-04. Backlink-Boost und semantisches Backend sind beideRanking-Signale und laufen beide durch dieselbe
fuse.py. Wer #35 baut, hat die Messumgebung, ander 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.pyvolltext 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.pyexistiert bereits).Offene Fragen für die Umsetzung
kb/index.md/INDEX.mdenthalten vermutlich schon aggregierte Referenzen – prüfen, ob das ohne zusätzlichen Scan verfügbar ist, oder obkb_scan.pyerweitert werden mussconfig.py)?kb/sources/-Seiten (viele Backlinks per Konstruktion) anders behandelt werden alskb/concepts/?Nächste Schritte
test_search.pyvalidierenHinweis zu Pfaden
Alle
tools/wiki_tools/…-Pfade in diesem Body sind am 2026-09-04 auftools/chemenu/…nachgezogenworden (Rename in 2.0.0, #3). Der Titel war bereits vorher korrigiert. Teilerledigung von #29.
Backlink-boosted Ranking in tools/wiki_tools/search/fuse.pyto Backlink-boosted Ranking in tools/chemenu/search/fuse.pyChangelog:
status/blockedgesetzt, 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/kbunverändert.