Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
12 KiB
Semantic Ranker and Reranking Models
Last updated: 2026-06-19 Status: GA (core), Preview (query rewrite, prerelease models) Category: RAG Architecture & Semantic Search Type: reference Source: https://learn.microsoft.com/azure/search/hybrid-search-overview
Innhold
- Introduksjon
- Kjernekomponenter
- Reranking-tilnærminger
- Arkitekturmønstre
- Beslutningsveiledning
- Integrasjon med Microsoft-stakken
- Offentlig sektor (Norge)
- Kostnad og lisensiering
- For arkitekten
- Kilder og verifisering
Introduksjon
Semantic Ranker er en premium-funksjon i Azure AI Search som bruker Microsofts språkforståelsesmodeller (opprinnelig fra Bing) til å forbedre søkerelevans gjennom L2 (Level 2) reranking. Den opererer oppå de initielle BM25- eller RRF-rangerte resultatene, og rerangerer de topp 50 basert på dyp semantisk forståelse av innholdet.
Semantic Ranker er ikke et generativt AI-system — den ekstraherer eksisterende tekst fra dokumenter. Den produserer semantiske captions (relevante passasjer), semantiske answers (direkte svar på spørsmål), og en @search.rerankerScore fra 0.0 til 4.0 som indikerer semantisk relevans. Dette gjør den ideell for kunnskapsbaser, dokumentportaler og RAG-scenarioer der høy relevans er kritisk.
Funksjonen er GA for kjernefunksjonalitet, med preview-features som query rewrite (utvider spørsmål til opptil 10 varianter) og mulighet for å opt-in til prerelease-modeller.
Kjernekomponenter
Trestegs-prosessen
-
Input og summarisering
- Tar topp 50 resultater fra initial ranking (BM25 eller RRF)
- Assembler opptil 2000 tokens per dokument fra konfigurerte felt
- Token-allokering: title (128), keywords (128), content (resten)
- Fra november 2024: summary strings opptil 2048 tokens (tidligere 256)
-
Scoring
- Evaluerer semantisk relevans med språkmodeller
- Tildeler
@search.rerankerScore(0.0–4.0 skala)
-
Output-generering
- Returnerer re-scorede resultater i synkende rekkefølge
- Ekstraherer verbatim captions og answers
- Gir både plain text og highlighted versjoner
Reranker Score-skala
| Score | Betydning |
|---|---|
| 4.0 | Svært relevant, komplett svar |
| 3.0 | Relevant men mangler noen detaljer |
| 2.0 | Noe relevant, delvis svar |
| 1.0 | Relatert men minimalt svar |
| 0.0 | Irrelevant |
Tommelregel: Bruk score 3.0+ som høy-konfidensresultater i RAG-systemer.
Semantic Configuration
{
"semantic": {
"defaultConfiguration": "my-semantic-config",
"configurations": [
{
"name": "my-semantic-config",
"prioritizedFields": {
"titleField": { "fieldName": "Title" },
"prioritizedContentFields": [
{ "fieldName": "Description" },
{ "fieldName": "Content" }
],
"prioritizedKeywordsFields": [
{ "fieldName": "Tags" },
{ "fieldName": "Category" }
]
}
}
]
}
}
Feltkrav:
- Må være
searchableogretrievable - Må være strings (
Edm.StringellerCollection(Edm.String)) - Title: maks 25 ord anbefalt
- Content: lengre, deskriptiv tekst (prioritert rekkefølge)
- Keywords: tagger, kategorier (prioritert rekkefølge)
Reranking-tilnærminger
1. Azure AI Search Semantic Ranker (innebygd)
| Egenskap | Detalj |
|---|---|
| Type | Proprietary Microsoft-modell (fra Bing) |
| Integrasjon | Innebygd i Azure AI Search |
| Kapasitet | ~10 samtidige queries per replika |
| Aktivering | queryType=semantic i spørring |
| Multilingual | Ja |
results = search_client.search(
query_type='semantic',
semantic_configuration_name='my-semantic-config',
search_text="historic hotel walk to restaurants",
select='HotelName,Description',
query_caption='extractive',
query_answer='extractive'
)
for result in results:
print(f"Reranker Score: {result['@search.reranker_score']}")
captions = result["@search.captions"]
if captions:
print(f"Caption: {captions[0].highlights}")
2. Cross-Encoder Reranking (custom)
For scenarier der du trenger full kontroll over reranking-logikk:
from sentence_transformers import CrossEncoder
model = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-6-v2')
pairs = [(query, doc["content"]) for doc in initial_results]
scores = model.predict(pairs)
# Re-sort basert på cross-encoder scores
reranked = sorted(
zip(initial_results, scores),
key=lambda x: x[1],
reverse=True
)
Fordeler: Full kontroll, open-source modeller, kan fintunes for domene Ulemper: Ekstra infrastruktur, høyere latency, vedlikeholdskostnad
3. LLM-basert reranking
Bruk en LLM for å vurdere og rangere søkeresultater:
Fordeler: Fleksibel, kontekstuell forståelse Ulemper: Høy token-kostnad, uforutsigbar latency
4. List-wise Ranking (RRF)
Automatisk i hybrid queries — Reciprocal Rank Fusion kombinerer rankings fra multiple queries uten eksplisitt reranking-steg.
Arkitekturmønstre
Mønster 1: Semantic Ranking for RAG
Flyt: Query → Hybrid search → RRF (L1) → Semantic Ranker (L2, topp 50) → Topp-k kontekst → LLM
Fordeler:
- Best mulig relevans for RAG-kontekst
- Semantiske captions gir bedre kontekst enn hele dokumenter
- Reduserer hallusinering gjennom høy-kvalitets grounding
Ulemper:
- Ekstra latency (~50–200ms)
- Krever S1-tier
- Kun topp 50 rerankes
Mønster 2: Multi-layer Ranking
Flyt: Query → BM25+Vector → RRF (L1) → Semantic Ranker (L2) → Custom reranker (L3)
Brukes når standard semantic ranking ikke er tilstrekkelig for domenet, f.eks. medisinsk, juridisk, eller teknisk dokumentasjon.
Mønster 3: Agentic Retrieval med L3
Flyt: Query → LLM query planning → Subqueries → Parallel retrieval → Semantic ranking → LLM-assistert L3 ranking
Preview-funksjon (2025) som integrerer iterativ søk med semantic ranking.
Beslutningsveiledning
Når bruke semantic ranking
| Scenario | Semantic Ranker? | Begrunnelse |
|---|---|---|
| Enterprise kunnskapsbase | Ja | Høy relevans for varierte spørsmål |
| RAG-grounding | Ja | Bedre kontekst = mindre hallusinering |
| E-commerce produktsøk | Vurder | Kan hjelpe for beskrivende søk, men ikke for SKU-oppslag |
| Logg-analyse | Nei | Strukturert data, ikke deskriptiv tekst |
| Høy-volum API (>10K qps) | Vurder | Kapasitetsbegrensning per replika |
| Utvikling/testing | Ja (gratis tier) | 1000 requests/mnd gratis |
Vanlige feil
- Glemme å sette
k=50for vector queries — Semantic ranker jobber med topp 50 fra L1 - Feil felt i semantic configuration — Korte, kodelignende felt gir dårlige resultater
- Forvente generative svar — Semantic ranker ekstraherer verbatim, den genererer ikke
- Ignorere
@search.rerankerScore— Bruk den for filtrering og konfidensgrenseverdier
Røde flagg
CapacityOverloadedfeil → For mange samtidige queries per replika- Lave reranker scores (<1.0) på relevante dokumenter → Sjekk semantic configuration feltvalg
- Uventede answers → Sjekk at content-felt er tilstrekkelig deskriptive
Integrasjon med Microsoft-stakken
| Tjeneste | Integrasjon |
|---|---|
| Azure OpenAI | RAG med semantic-ranked kontekst for bedre svar |
| Microsoft Foundry | Evaluering av semantic ranking-kvalitet via built-in evaluators |
| Copilot Studio | Automatisk bruk av semantic ranking i grounding |
| Azure Cosmos DB | Semantic Reranker (separat produkt, lignende konsept) |
| Databricks | Vector Search med reranking-integrasjon |
Offentlig sektor (Norge)
Relevans
- Semantic ranker er multilingual — fungerer med norsk tekst uten ekstra konfigurasjon
- Ideell for offentlige kunnskapsbaser der brukere stiller spørsmål i naturlig språk
- Captions og answers kan brukes direkte i brukergrensesnitt for raskere saksbehandling
Tilgjengelighet
- Tilgjengelig i Norway East og Norway West regioner
- All prosessering skjer i valgt region (datasuverenitet)
- Ingen data sendes ut av regionen for reranking
Compliance
- GDPR-kompatibel
- Schrems II-kompatibel (EU Data Boundary)
- Ingen tredjepartsleverandører involvert i reranking-prosessen
Kostnad og lisensiering
Prismodell
| Plan | Detaljer |
|---|---|
| Gratis | 1000 semantic ranker-requests/måned, alle tier (inkl. Free) |
| Standard | Pay-as-you-go etter gratis kvote, per 1000 requests |
Faktureringsregler
- Belastes:
queryType=semanticOG søkestreng er ikke tom - Belastes IKKE:
search=*(tom query), selv medqueryType=semantic - Overgang fra gratis til betalt skjer sømløst (ingen varsling)
Kostnadsoptimering
- Bruk gratis tier for utvikling og testing
- Vurder om alle queries trenger semantic ranking, eller kun de med lav BM25-relevans
- Batch queries med lignende emner for bedre cache-utnyttelse
For arkitekten
Spørsmål å stille kunden
- Hvilken type innhold skal søkes — deskriptivt, strukturert, eller blandet?
- Stiller brukerne naturlige spørsmål eller bruker de nøkkelord?
- Hva er akseptabel latency for søkeresultater?
- Hvor mange samtidige søk forventes?
- Er multilingual support nødvendig?
- Finnes det et budsjett for semantic ranking utover gratis tier?
- Har dere allerede S1-tier, eller krever dette en oppgradering?
Fallgruver
- Semantic ranker er IKKE en erstatning for god indeksdesign — dårlige felt gir dårlige resultater
- Summary string-lengden (2048 tokens) betyr at svært lange dokumenter kan miste kontekst
- Semantiske answers returneres kun når modellen er 70% konfident — ikke forvent svar på alle queries
Anbefalinger per modenhetsnivå
| Nivå | Anbefaling |
|---|---|
| Starter | Aktiver semantic ranker med default config, bruk gratis tier |
| Intermediær | Optimer semantic configuration-felt, implementer score-basert filtrering |
| Avansert | Kombinér med custom cross-encoder, A/B-test reranking-strategier, opt-in til prerelease-modeller |
Kilder og verifisering
Verified (MCP-research)
- Semantic ranking in Azure AI Search
- Configure semantic ranker
- Add semantic ranking to queries
- Enable or disable semantic ranker
- Relevance in Azure AI Search
- Hybrid search overview
Baseline (modellkunnskap)
- Cross-encoder-eksempler basert på Sentence Transformers-dokumentasjon
- Offentlig sektor-anbefalinger basert på norsk kontekst
Semantic Ranker i Hybrid Search (oppdatert 2026-06-19)
Semantic ranker (L2 reranking) fungerer optimalt i hybrid search-kontekst:
- Aksepterer opp til 50 resultater fra RRF-merger som input
- Bruker maskinlesningsforståelse (MRC) for å re-ranke basert på semantisk relevans
@search.rerankerScoreerstatter@search.scoresom primær rankingmetrikk- Valgfritt:
captions(ekstraktiv) oganswers(ekstraktiv) fra verbatim tekst
Konfigurasjon:
{
"queryType": "semantic",
"semanticConfiguration": "min-konfig",
"captions": "extractive",
"answers": "extractive"
}
Viktig: Sett k=50 i vectorQueries — semantic ranker trenger tilstrekkelig input. Pre-filtre som er for strenge kan redusere antall input-dokumenter og svekke reranking-kvaliteten.