Pipeline oceny sygnałów: deterministyczna triażacja wiedzy

Większość zarządzania wiedzą opiera się na intuicji. Zapisujesz notatkę, bo „wydaje się ważna”. Sześć miesięcy później masz 7000 notatek i nie wiesz, które z nich mają znaczenie. Zbudowałem deterministyczny pipeline oceny, który mi to mówi.

System to 733 wiersze Python. Ocenia każdy przychodzący sygnał w czterech ważonych wymiarach, oblicza wynik złożony i kieruje sygnał do jednego z 12 folderów domenowych, skrzynki odbiorczej do ręcznego przeglądu lub do kosza. Żadnego ręcznego tagowania. Żadnego „przejrzę później”, które nigdy nie następuje. Decyduje algorytm.

TL;DR

Ważony wynik złożony (trafność 35%, wykonalność 30%, głębia 20%, autorytet 15%) generuje ocenę od 0,0 do 1,0 dla każdego sygnału. Routing wykorzystuje trzy progi: >= 0,55 automatycznie zapisuje do folderu domenowego, >= 0,30 kolejkuje do ręcznego przeglądu, < 0,30 po cichu pomija. Przetworzono ponad 7700 notatek w ciągu 14 miesięcy, przy czym Development (2837) i Design (1709) dominują w rozkładzie. Najciekawsza wada: wymiar głębi mierzy bogactwo metadanych, a nie jakość treści, więc dobrze otagowany tweet ze zdjęciem kwiatu uzyskuje wynik 0,85.

Problem z intuicją

Używam Obsidian jako bazy wiedzy. Sygnały napływają z kanałów RSS, zakładek Twittera, gwiazdek GitHub, newsletterów i ręcznego przechwytywania. Przed pipelinem każdy sygnał trafiał do jednego folderu skrzynki odbiorczej. W ciągu dwóch miesięcy nagromadził się inbox z ponad 400 nieprzetworzonych notatek.

Standardowa rada („przeglądaj co tydzień, taguj na bieżąco, stosuj system folderów”) zakłada, że przegląd faktycznie się odbywa. Nie odbywa się. Skrzynki odbiorcze stają się jednokierunkowe: elementy wchodzą, ale nigdy nie wychodzą. Wiedza, którą przechwyciłeś, jest funkcjonalnie identyczna z wiedzą, której nigdy nie przechwyciłeś. Clay Shirky ujął problem precyzyjnie: „To nie jest przeładowanie informacją. To awaria filtra.”⁸

Potrzebowałem systemu, który potrafi ocenić ponad 7700 notatek szybciej niż jestem w stanie je przeczytać, stosując kryteria zdefiniowane raz i stosowane jednolicie. Nie silnika rekomendacji. Algorytmu oceny.

Wynik złożony

Formuła oceny to ważona kombinacja liniowa czterech wymiarów — standardowe podejście w wielokryterialnej analizie decyzyjnej (MCDA):⁹

composite = (
    relevance     * 0.35 +
    actionability * 0.30 +
    depth         * 0.20 +
    authority     * 0.15
)

Każdy wymiar generuje liczbę zmiennoprzecinkową od 0,0 do 1,0. Formuła zaokrągla wynik złożony do trzech miejsc po przecinku. Wagi odzwierciedlają celowy porządek priorytetów: co jest dla mnie istotne (trafność) przeważa nad co mogę wykorzystać (wykonalność), co przeważa nad jak bogate są metadane (głębia), co przeważa nad jak wiarygodne jest źródło (autorytet).¹

Cztery wymiary

Trafność (35%): dopasowanie do zainteresowań

Trafność korzysta z ręcznie kurowanego słownika słów kluczowych z ponad 40 wpisami, każdy oceniany od 0,15 (nft) do 1,0 (claude code, swiftui). Ocena łączy najlepsze dopasowanie ze średnią wszystkich dopasowań:

# 60% best match, 40% average of all matches
return min(1.0, best_score * 0.6 + avg_score * 0.4)

Elementy bez dopasowań otrzymują bazowy wynik 0,25, a nie 0,0. System penalizuje nieznany temat łagodniej niż temat nieistotny. Wartość bazowa jest najczęściej dostosowywanym parametrem: zbyt wysoka — a nieistotne treści zalewają skrzynkę odbiorczą, zbyt niska — a naprawdę nowe zainteresowania są odfiltrowywane, zanim je zobaczę.²

Wykonalność (30%): potencjał edukacyjny

Wykonalność dopasowuje do 22 słów kluczowych zorientowanych na działanie: tutorial, guide, how-to, build, github.com. Adresy URL otrzymują specjalne traktowanie:

if "github.com" in url:
    hits += 2  # Repositories are inherently actionable
if "/docs" in url or "/tutorial" in url:
    hits += 1

Ocena opiera się na funkcji skokowej, nie liniowej: 0 trafień → 0,10, 1 trafienie → 0,40, 2 trafienia → 0,60, 3+ trafień → min(1.0, 0.70 + hits * 0.05). Funkcja skokowa nagradza obecność sygnałów wykonalności bardziej niż ich liczbę. Jeden link do tutorialu jest wart więcej niż różnica między trzema a czterema słowami kluczowymi.³

Głębia (20%): bogactwo metadanych

Głębia jest czysto strukturalna. Mierzy obecność i długość pól, a nie jakość treści:

Głębia to wymiar, któremu ufam najmniej. Tweet ze zdjęciem nemofili z pełnym opisem i czterema tagami uzyskuje głębię 0,85. Bogate metadane, nieistotna treść: ładne zdjęcie kwiatów. Głębia zastępuje pojęcie „źródło dostarczyło ustrukturyzowane dane”, co koreluje z jakością, ale jej nie gwarantuje.⁴

Autorytet (15%): wiarygodność źródła

Autorytet zaczyna od bazowego wyniku 0,40 i jest dostosowywany według typu źródła:

if source in ("twitter", "x"):        score = 0.50
elif source in ("blog", "newsletter"): score = 0.60
elif source in ("github", "docs"):     score = 0.70

Lista dozwolonych domen nadpisuje wynik w górę (nigdy w dół): github.com, anthropic.com, apple.com, arxiv.org, docs.python.org i inne ustawiają autorytet na co najmniej 0,75. Lista dozwolonych kodyfikuje ocenę, że te źródła domyślnie zasługują na wyższy poziom zaufania.

Routing progowy

Trzy przedziały routingu określają, co dzieje się z każdym ocenionym sygnałem:

THRESHOLD_AUTO_WRITE = 0.55   # → domain folder
THRESHOLD_INBOX      = 0.30   # → 00-Inbox (manual review)
# Below 0.30 → silently skipped

Pipeline zapisuje sygnały z wynikiem >= 0,55 bezpośrednio do jednego z 12 folderów domenowych, wnioskowanych z dopasowania tagów i tytułów. Sygnały ze średniego zakresu (0,30-0,55) trafiają do skrzynki odbiorczej do ręcznego przeglądu. Wszystko poniżej 0,30 nigdy nie trafia do skarbca.

Zakres 0,30-0,55 to „strefa niejednoznaczności”, w której system ma najmniejszą pewność. Opcjonalna flaga --llm-triage wysyła te sygnały do Claude w celu ewaluacji, co może skorygować wynik złożony o maksymalnie ±0,20, potencjalnie przesuwając sygnał powyżej progu automatycznego zapisu. Claude widzi tylko niejednoznaczne sygnały, nigdy te z wysokim ani niskim wynikiem. Wydawanie tokenów API na sygnały, które deterministyczny scorer już obsłużył, byłoby marnotrawstwem.⁵

Wnioskowanie domeny wykorzystuje system głosowania. Każdy tag mapuje się na domenę, każde słowo kluczowe w tytule dodaje głos. Domena z największą liczbą głosów wygrywa. Remisy rozstrzygane są kolejnością w słowniku (de facto arbitralnie). Domyślny fallback: „Inspiration”.

Wyniki

Po przetworzeniu ponad 7700 notatek w ciągu 14 miesięcy:

Rozkład odzwierciedla rzeczywistość. Konsumuję więcej treści związanych z programowaniem i projektowaniem niż czegokolwiek innego. Elementy w skrzynce odbiorczej (420) reprezentują strefę niejednoznaczności — sygnały, których algorytm nie potrafił pewnie przypisać automatycznie.⁶

Co algorytm ocenił błędnie

Pułapka głębi

Tweet ze zdjęciem nemofili uzyskał wynik composite 0.36, relevance 0.25, actionability 0.10, depth 0.85, authority 0.50. Trafił do skrzynki odbiorczej, ponieważ głębia (0,85) i autorytet (0,50) skompensowały niemal zerową trafność i wykonalność. Bogate metadane, nieistotna treść: ładne zdjęcie kwiatów.

Ten przykład ilustruje fundamentalne ograniczenie oceny opartej na proxy metadanych. Głębia mierzy „źródło dostarczyło ustrukturyzowane dane”, a nie „treść jest wartościowa”. Twitter dostarcza pełne opisy i tagi do każdego tweeta. Dobrze otagowany tweet o śniadaniu uzyskuje głębię 0,85. Badania z zakresu wyszukiwania informacji nazywają to napięcie kompromisem precyzja/pełność: optymalizacja pod kątem pełności (wychwycenia wszystkiego, co istotne) nieuchronnie dopuszcza fałszywie pozytywne wyniki.¹⁰

Poprawka, którą rozważyłem i odrzuciłem: Zmniejszenie wagi głębi z 0,20 do 0,10 zredukowałoby fałszywie pozytywne wyniki z dobrze otagowanych nieistotnych treści, ale jednocześnie penalizowałoby naprawdę głębokie treści ze źródeł o skąpych metadanych. Obecna waga to kompromis.

Problem bazowego wyniku trafności

Bazowy wynik 0,25 dla zerowego dopasowania trafności oznacza, że każdy dobrze ustrukturyzowany sygnał z rozsądnego źródła uzyskuje co najmniej 0,30 i trafia do skrzynki odbiorczej. Wartość bazowa tworzy dolną granicę fałszywie pozytywnych wyników: skrzynka odbiorcza gromadzi sygnały, które są dobrze otagowane i pochodzą z rozsądnych źródeł, ale nie mają nic wspólnego z moimi zainteresowaniami.

Faktyczna poprawka: Okresowy przegląd skrzynki odbiorczej pozostaje konieczny. Pipeline redukuje powierzchnię przeglądu z 7700 elementów do 420 (redukcja o ~95%), ale nie jest w stanie wyeliminować ręcznego przeglądu dla strefy niejednoznaczności.

Uwagi implementacyjne

Pipeline działa jako narzędzie CLI. Dane wejściowe to tablica JSON sygnałów (z RSS, Twitter API lub ręcznego wprowadzenia). Dane wyjściowe to pliki markdown kompatybilne z Obsidian, zapisywane do folderów domenowych.

python triage.py --input signals.json --vault ~/obsidian-signals/
python triage.py --input signals.json --vault ~/obsidian-signals/ --llm-triage
python triage.py --input signals.json --min-score 0.60  # Stricter routing

Wstępne filtrowanie uruchamia się przed oceną: deduplikacja URL względem istniejących notatek w skarbcu, filtrowanie pustych treści oraz lista zablokowanych źródeł szumu. Zduplikowane notatki i spamerskie źródła nigdy nie docierają do etapu oceny.

Funkcje oceniające są czyste: bez efektów ubocznych, bez wywołań API, bez dostępu do systemu plików. Każda funkcja przyjmuje słownik sygnału i zwraca słownik wyników. Czyste podejście sprawia, że są testowalne w izolacji i komponowalne z etapem triażu LLM, który uruchamia się tylko na niejednoznacznym podzbiorze.⁷

Kluczowe wnioski

Dla inżynierów budujących systemy triażu:

• Deterministyczna ocena przewyższa ręczną kurację na dużą skalę. 7700 notatek w 14 miesięcy. Ręczna triażacja wymagałaby ponad 50 godzin przeglądu. Pipeline przetworzył je w minuty ze współczynnikiem routingu ~95% (tylko 5,5% wymagało ręcznego przeglądu).

• Proxy metadanych mają znane tryby awarii. Głębia mierzy strukturę, nie jakość. Autorytet mierzy źródło, nie trafność. Oba proxy działają w skali zagregowanej, ale generują przewidywalne fałszywie pozytywne wyniki na poziomie pojedynczego sygnału. Uznanie trybów awarii jest uczciwsze niż twierdzenie, że algorytm „działa”.

Dla praktyków zarządzania wiedzą:

• Ważone wyniki złożone ujawniają rzeczywiste priorytety. Wagi 35/30/20/15 nie są arbitralne. Kodyfikują konkretną ocenę: trafność ma większe znaczenie niż wykonalność, która ma większe znaczenie niż bogactwo metadanych, które ma większe znaczenie niż wiarygodność źródła. Jawne i konfigurowalne wagi to różnica między systemem a nawykiem.

• Strefa niejednoznaczności jest nieredukowalna. Sygnały między 0,30 a 0,55 są naprawdę niejednoznaczne: deterministyczny scorer nie jest w stanie ich rozstrzygnąć. Triaż LLM pomaga, ale nie eliminuje tej strefy. Ręczny przegląd niejednoznacznego podzbioru pozostaje konieczny.

Ujmę ten artykuł jako problem inżynieryjny, a nie poradę produktywnościową. Ocena złożona ma zastosowanie w każdej dziedzinie, gdzie elementy wymagają deterministycznego routingu: zgłoszenia wsparcia, moderacja treści, kwalifikacja leadów, wykrywanie anomalii. Moje konkretne wagi i progi kodyfikują osobiste priorytety, ale architektura jest uniwersalna. Więcej o tym, jak akumulowana wiedza tworzy nieliniową wartość, można przeczytać w Mental Compound Interest. OODA Loop for Prompt Engineering eksploruje pokrewny wzorzec: ustrukturyzowaną obserwację jako alternatywę dla intuicji. Każdy komponent pipeline’u (ocena, routing, triaż) jest niezależnie użyteczny i kumuluje się z pozostałymi, podążając za wzorcem compounding engineering.