VARNING: DETTA UTKASTS TILL POSTER SOM "FÖRSÄKRATS".

Det är troligt att mycket av det som är nedan inte kommer att fungera; Jag genererar dessa som hur-till för MIG och sedan göra alla steg och få provappen att fungera ... Du har varit smygande och sett dem! de kommer sannolikt att vara redo i mitten av december.

## Inledning

Spänn fast dig, för det här kommer att bli en lång serie!

Om du har följt tillsammans med denna blogg, vet du att jag är lite besatt av att hitta intressanta sätt att använda LLMs och AI i praktiska tillämpningar.

Jo, jag har ett nytt projekt som kombinerar min kärlek till bloggning, C# och AI: bygga en skrivassistent som hjälper mig att skriva nya blogginlägg med hjälp av mitt befintliga innehåll som kunskapsbas.

OBS: Detta är en del av mina experiment med AI (assisterad utformning) + min egen redigering.

• Samma röst, samma pragmatism, bara snabbare fingrar.
• Tänk på hur moderna juridiska metoder använder LLM:s som är utbildade i rättspraxis för att utarbeta uppgifter, förslag och kontrakt.
• De börjar inte från grunden - systemet refererar till relevanta prejudikat, föreslår språk baserat på framgångsrika tidigare dokument, och upprätthåller överensstämmelse med etablerade mönster.
• Det är precis vad vi bygger här, men för blogginnehåll.
• Målet är att skapa en AI-driven skrivassistent som:

Hjälper till med nya blogginlägg i min etablerade stilFöreslår relevant innehåll från tidigare artiklar till referensHittar liknande inlägg för att upprätthålla överensstämmelse

Skapar automatiskt interna länkar till relaterade artiklar

Agerar som "GitHub Copilot för din blogg"

• Denna serie kommer att omfatta byggandet av en komplettRetrieval Augmented Generation (RAG)
• **system i C# som körs på Windows.**Vi använder de senaste tillvägagångssätten och ramverken, och jag förklarar varje ny teknik när vi stöter på den.
• **Min hårdvaruinställning (och minimala specifikationer)**Min utvecklingsmaskin:

GPU**: NVIDIA RTX A4000 (16GB VRAM)**Maskiner och apparater för tillverkning av massa, papper eller papp, i.a.n.

: AMD Ryzen 9 9950X

• RAMBESTÄMMELSERNA: 96GB DDR5
  • Det här är min specifika fälla, men du
  • behöver inte den här hårdvaran
• **för att följa med.**Här är de minsta specifikationerna för olika komponenter:
  • GPU Acceleration (Rekommenderas, krävs ej)
• Lägsta: NVIDIA GPU med 8 GB VRAM (t.ex. RTX 3060, GTX 1070 Ti)

Kan köra 7B-parametermodeller med kvantisering

• Anständig inbäddning av genereringshastighetBekvämt
• **: 12GB+ VRAM (t.ex. RTX 3060 12GB, RTX 4060 Ti)**Kör större modeller eller högre kvalitet kvantifieringar
• Min inställning
  • : 16GB (A4000) - Kan köra 13B modeller bekvämt
  • Endast alternativ för processor
  • Lägsta

: Modern fyrkärnig processor

• Rekommenderad: 8+ kärnor (för rimlig inbäddning generering)
  • Allt fungerar på CPU-endast, bara långsammare:
• Inbäddning generering: ~5-10x långsammareLLM slutsats: 10-50x långsammare
  • Fortfarande helt användbart för en skrivassistent!
• RAM-kravLägsta

: 16 GB system RAM

• CPU-enbart slutledning för 7B-modellerBekvämt
• : 32GBBättre för större modeller på CPU

Min inställning

: 96GB - Overkill, 32GB är mycket

• FörvaringSSD
• : Rekommenderas för modellbelastningRymden
• : ~20GB för modeller och vektordatabasHur är det med Intel/AMD NPU:er?

**Moderna processorer inkluderar nu dedikerade AI acceleratorer:*Intel Core Ultra(Meteor Lake+) - Intel AI Boost (NPU)*AMD Ryzen AI

(serien 7040/8040) - XDNA NPU

• ✅ Great for: On-device inference, battery efficiency (laptops)
• ⚠️ Limited for our use: Immature .NET/ONNX Runtime support
• ❌ Not ready for: This project's primary path

AMD Ryzen AI Max

1. (Strix Point) - Upp till 50 TOPSViktigt: NPU är endast för slutledning!
2. Du inte "bygga" eller träna modeller på NPU:er - de är utformade för attkör
3. **Förskolade modeller på ett effektivt sätt.**Modeller utbildas på moln GPUs (eller arbetsstationer), sedan laddas ner och distribueras till NPUs för slutsatser.
4. **Nuvarande status för körmodeller på NPU:er (som skrivning):**Varför inte NPU för den här serien?
5. Programvaruekosystem: CUDA har 15 år av löptid, NPU stöd i .NET är ny

Förlaga till kompatibilitet

• : De flesta GGUF modeller mål CUDA/CPU, NPU-optimerade modeller är sällsyntaDokumentation: Begränsade resurser för NPU-utveckling i C#
• Prestanda
• : För närvarande långsammare än diskreta GPUs för vår arbetsbelastning
• Stöd för direktML

: Fortfarande experimentell för LLM inference

# Use DirectML execution provider (supports NPU)
dotnet add package Microsoft.ML.OnnxRuntime.DirectML

# In code:
var sessionOptions = new SessionOptions();
sessionOptions.AppendExecutionProvider("DML"); // DirectML
var session = new InferenceSession("model.onnx", sessionOptions);

**Kan du använda NPU:er för att dra slutsatser?**Ja, men jag vet inte.KräverDirektMLutförande leverantör i ONNX RuntimeModeller måste vara i ONNX-format (inte GGUF)

C# stöd är experimentelltPrestanda är för närvarande underwhelming vs. CUDA

Hur man försöker NPU inference (avancerade användare):

Framtida överväganden

1. : En gångONNX körtid
2. ochDirektML
3. **mogna sitt NPU-stöd (troligen 2024-2025), dessa kommer att bli livskraftiga alternativ för slutledning!**Nedre raden
4. **: Jag ska visa GPU-accelererad väg, men kommer att notera CPU-endast alternativ hela.**Du kan starta CPU-endast och uppgradera senare!
5. Vad vi byggerDet slutliga systemet kommer att ha flera komponenter:
6. Markering intag pipeline- Behandlar alla blogginlägg, delar dem intelligent, och genererar inbäddningar

Vektordatabas

- Lagrar inbäddningar och möjliggör semantisk sökning efter liknande innehåll

Windows klientprogram

• • En skrivbordsskrivarassistent UI med editor och förslag panel

• Integrering av LLM

• • Lokal GPU-accelererad slutsats för innehållsgenerering

• Citering och länkgenerering

• Auto-förslag interna länkar och referenser till relaterade inlägg

• Stilkonsistensgränssnitt

• • Lär mönster från befintliga inlägg för att upprätthålla röst och struktur

• Tänk på det som "GitHub Copilot möter Grammarly" men tränas specifikt på din blogg innehåll och stil.

• Varför "Lawyer GPT"?

• Moderna advokatbyråer använder LLM:s som utbildats på stora bibliotek av rättspraxis för att hjälpa till med att utarbeta juridiska dokument.

När du skriver en motion, systemet:

Hänvisningar till relevanta prejudikat och tidigare framgångsrika argument

Föreslår språkmönster som har fungerat tidigare

Upprätthåller överensstämmelse med rättsliga skrivstandarder

Bitkällor automatiskt

Det är vår modell.

När jag börjar skriva "Adding Entity Framework for...", bör systemet:Hitta mina tidigare EF-relaterade inlägg, Föreslå strukturella mönster jag använt förutErbjud relevanta kodsnuttar från tidigare artiklar

Skapa automatiskt länkar till relaterade inlägg

Behåll min skrivstil och tekniska djupTill skillnad från generiska AI skriva assistenter, vårt system är förankrad i faktiska tidigare innehåll, så det kommer inte att föreslå saker som är oförenliga med vad jag redan har skrivit.Översikt över serienSå här täcker vi de kommande veckorna:).

Del 1 (detta inlägg): Introduktion och arkitektur

Vi kommer att fastställa vad vi bygger och varför, plus att täcka de arkitektoniska besluten.

Del 2: GPU- inställning & CUDA i C#

Få Windows ställa in för GPU-accelererad AI arbetsbelastning, installeraCUDA, cuDNN Ordförande, och testa att C# faktiskt kan se och använda din GPU.Del 3: Förstå inbäddningar och vektordatabaserDjupdyk i vad inbäddningar faktiskt är, hur de möjliggör semantisk sökning, och välja rätt vektordatabas (spoiler: vi kommer förmodligen att använda

Qdrant Ordförande

ellerPgvector Ordförande, Del 4: Byggande av ledning för förtäringBehandling av markdown-filer, intelligenta bitningsstrategier (du kan inte bara dela på stycken!), och generera inbäddningar för allt vårt innehåll.

Del 5: Windows-klienten

Att välja rätt ram (

WPF-värde

Vegetabiliska fetter och oljor samt fraktioner av sådana fetter eller oljor, även raffinerade men inte kemiskt modifierade

, eller

HUVUDSAKLIG

?), bygga UI, och gör det faktiskt trevligt att använda.

Del 6: Lokal LLM-integration

1. Köra modeller lokalt med hjälp avONNX körtid
2. lama.cppbindningar eller andra metoder.
3. **Gör fullt bruk av den där A4000!**Del 7: Innehållsgenerering och snabbteknik
4. **Föra allt samman - semantisk sökning efter relevant innehåll, sammanhangsbaserad fönsterhantering, snabb ingenjörskonst för skrivhjälp och generera sammanhängande förslag.**Del 8: Avancerade funktioner och produktionsutveckling
5. **Automatisk länkning till relaterade inlägg, stil konsekvens kontroll, kod sippet förslag, och göra systemet faktiskt användbart för dagligt skrivande.**Varför RAG?

Innan vi dyker in i arkitektur, låt oss tala om varför RAG (Retrieval Augmented Generation) är rätt strategi här.

Problemet med finputsning

Du kanske tänker: "Varför inte bara finjustera en LLM på alla blogginlägg?" Det finns flera problem med det:

1. Kostnad och komplexitet
2. • Finjustering är dyrt (både i beräkning och ansträngning)
3. Tålamod
4. • Varje nytt blogginlägg innebär omskolning
5. Svart låda

• Svårt att förstå vad modellen "lärde"

• ✅ Always up-to-date (just re-index new posts as you write them)

• ✅ Grounded in your actual writing (maintains consistency)

• ✅ Traceable (know which past posts influenced suggestions)

• ✅ Efficient (no expensive retraining for every new post)

• ✅ Flexible (can swap out LLMs or adjust search strategies)

• ✅ Privacy-preserving (everything runs locally)

Hallucination

• Ingen garanti för att modellen inte hittar på.

graph TB
    A[Markdown Files] -->|Ingest| B[Chunking Service]
    B -->|Text Chunks| C[Embedding Model]
    C -->|Vectors| D[Vector Database]

    E[User Writing] -->|Current Draft| F[Windows Client]
    F -->|Embed Context| C
    C -->|Query Vector| D
    D -->|Similar Content| G[Context Builder]

    G -->|Relevant Past Articles| H[Prompt Engineer]
    H -->|Prompt + Context| I[Local LLM]
    I -->|Generated Suggestions| J[Link Generator]
    J -->|Suggestions + Citations| F

    F -->|Display| K[Editor with Suggestions]

    class C,I embedding
    class D,K output

    classDef embedding stroke:#333,stroke-width:4px
    classDef output stroke:#333,stroke-width:4px

Inga hänvisningar

• Kan inte lätt spåra svar tillbaka till källor

• Hur RAG Solves detta

• RAG kombinerar det bästa av båda världarna: kraften hos LLMs med precisionen i sökningen för att skapa sammanhangsmedveten innehållsgenerering.

• Flödet är:

• Användaren börjar skriva (t.ex., "Bygga ett REST API med ASP.NET Core...")

• System finner semantiskt liknande tidigare artiklar

System matar relevanta bitar i samband med LLMLLM genererar förslag/fortsättningar baserade på tidigare innehåll

System erbjuder förslag med referenser till källposter

Detta innebär följande:

Systemarkitektur

Låt mig dela upp nyckelkomponenterna som vi kommer att bygga:

• 1. Vad är det som händer?
• Markering intag pipeline

**Denna komponent:**Läser ner markeringsfiler från bloggkatalogen

• Extraherar metadata (titel, kategorier, datum, ordräkning)Intelligent biter innehållet (bevarande kodblock för återanvändning)
• Identifierar strukturella mönster (hur jag organiserar inlägg)
• Spåra källinformation för citeringsgenereringNyckelutmaning

: Chunking strategi spelar en enorm roll.

För liten och du förlorar sammanhang.

**För stor och du slösar bort LLM: s sammanhangsfönster.**Vi behöver bitar som är semantiskt meningsfulla - en fullständig tanke eller sektion, inte godtyckliga paragrafbrytningar.

• **Två.**Inbäddningsmodell
• **Inbäddningar är magin som gör semantiska sökningar.**En inbäddad modell tar text och omvandlar den till en högdimensionell vektor (array av siffror) som fångar semantisk mening.
• **Liknande begrepp hamnar "nära" i vektorrymden, även om de använder olika ord.**Till exempel:
• "Databasmigrering" och "uppdatering av DB-schemat" skulle ha liknande inbäddningar"Cat" och "kitten" skulle vara närmare än "cat" och "databas"

Teknologival

: Vi kommer förmodligen att använda antingen:

Meningsöversättare

modeller (kan köras via ONNX Runtime i C#)

• ✅ Mature, stable, lots of resources
• ✅ Native Windows performance
• ❌ Windows-only
• ❌ Looks dated unless you invest in UI libraries

OpenAI:s inbäddade modeller (via API)

• ✅ Cross-platform (XAML-based)
• ✅ Modern, actively developed
• ✅ Similar to WPF
• ❌ Smaller ecosystem

BGE-modeller

• ✅ Cross-platform
• ✅ Microsoft-backed
• ❌ Still maturing
• ❌ More mobile-focused

(den senaste öppna källkoden)**3. Vad är det som händer?Vektordatabas**Vektordatabasen lagrar inbäddningar och möjliggör snabb likhetssökning.**När du skriver om "Docker komponera", finner den K mest semantiskt liknande tidigare innehåll - inte bara nyckelord matchar, men konceptuellt relaterat material.**Teknologival

: Vi ska utvärdera:

Qdrant Ordförande

• • Modern, skriven i Rust, utmärkt C# klient, Docker-vänlig
• Pgvector Ordförande
• • Förlängning för PostgreSQL (vi använder redan Postgres!)
• Vävnad

- Ett annat stabilt alternativ med bra .NET-stöd:

Krossgryn

• • Populärt i Python land, mindre så i C#
• Jag lutar mot Qdrant för dess enkelhet och prestanda, eller Pgvector att hålla allt i Postgres.
• Fyra.
• Windows- klientName

Vi behöver en trevlig UI för att skriva med AI-hjälp.Tänk split-pane redaktör med förslag.

• Alternativ:WPF (Fönsterpresentationsstiftelsen))
• Vegetabiliska fetter och oljor samt fraktioner av sådana fetter eller oljor, även raffinerade men inte kemiskt modifierade
• MAUI (Multiplattforms-App-UI)
• Eftersom vi är Windows-fokuserade och jag vill ha något stabilt, Jag lutar mot

WPF med

• UI för det moderna arbetsgränssnittet (WPF)
• eller
• Vegetabiliska fetter och oljor samt fraktioner av sådana fetter eller oljor, även raffinerade men inte kemiskt modifierade

för den plattformsoberoende potentialen.**För att uppnå detta mål har kommissionen beslutat att inleda ett förfarande enligt artikel 108.2 i fördraget om Europeiska unionens funktionssätt (nedan kallat EUF-fördraget).**Lokal LLM-integration

Det är här A4000 GPU lyser.

Vi vill driva LLM lokalt för:

• Sekretess (inga data som skickas till API:er)
• Hastighet (lokala slutsatser är snabba)
• Kostnad (inga API-avgifter)
• Kontroll (vi väljer modellen)

Teknikalternativ

• ONNX körtid
• Konvertera modeller till ONNX format
• Utmärkt GPU-acceleration
• C# inbyggt stöd

Nedsidan: Inte alla modeller konvertera väl

lama.cpp

• bindningar
• C++ bibliotek med C# bindningar (
• LLamaSharp Ordförande
• Stöder CUDA
• Brett modellstöd (Llama, Mistral, etc.)

Mycket aktiv utveckling

TorchSharp Ordförande

PyTorch bindningar för .NET

1. Största möjliga flexibilitetSteeper inlärningskurva
2. Jag lutar motLLamaSharp Ordförande
3. **för sin mognad och användarvänlighet med populära modeller.**6. Vad är det som händer?
4. Kontextfönsterhantering och snabbteknikLLM har begränsade sammanhangsfönster (t.ex. 4K, 8K, 32K polletter).
5. **Vi måste:**Hämta det mest relevanta tidigare innehållet (överst K från vektorsökning)

Anpassa dem i sammanhangsfönstret med det aktuella utkastet

Strukturera uppmaningen till skrivhjälp

Lämna plats för de genererade förslagen

• **Det här är svårare än det låter.**Vi ska utforska strategier som:
• Dynamiskt K- urval baserat på vad du för närvarande skriverRe-rankning hämtas bitar efter relevans

Komprimerande sammanhang på ett intelligent sätt

• **Multi-shot uppmaning med exempel från tidigare inlägg7. Vad är det som händer?Länk- och citeringsgenerering**Varje bit behöver metadata:
• **Källfil/post**Position i det ursprungliga dokumentet
• PubliceringsdatumKategorier

Använda kodslippar

• **När LLM genererar förslag skapar vi automatiskt markeringslänkar till källposterna och identifierar återanvändbara kodmönster.Vad gör detta annorlunda?Det finns massor av RAG tutorials där ute, men denna serie kommer att vara olika:**C# Först

- De flesta RAG-exempel finns i Python.

• Vi är på full gång .NETFönster & GPU- Legenomsnittlig NVIDIA CUDA på Windows, inte Linux/WSLProduktionsklara**- Inte bara proof-of-concept, men faktiskt användbar kod**Områdesspecifik

- Optimerad för bloggskrivarhjälp, inte generisk innehållsgenerering

• Djupa förklaringar- Vi ska faktiskt förklara "varför" bakom beslut
• **Teknologier vi använder**Här är teknikstacken jag planerar:
• Kärnramar.NET 9 Ordförande

(senast vid tidpunkten för skrivandet)

• Detta beslut träder i kraft den tjugonde dagen efter det att det har offentliggjorts i Europeiska unionens officiella tidning.- Moderna språkfunktionerAI/ML-bibliotek
• **ONNX körtid**eller

LLamaSharp Ordförande

• LLM-slutsats

Microsoft.ML

• - Möjligt för vissa uppgifterDomstolsövergångar via ONNX
• - InbäddningarVektordatabas
• Qdrant Ordförandeeller
• Pgvector Ordförande- Fastställs senare

Rambestämmelser för användargränssnittet

• WPF-värdedär
• Modernt arbets- och utvecklingsprogrameller
• Vegetabiliska fetter och oljor samt fraktioner av sådana fetter eller oljor, även raffinerade men inte kemiskt modifierade- Modern skrivbordsgränssnitt

Verktyg för stöd

• Markdig Ordförande- Använder den redan för nedräkning.
• Docka- För körning av Qdrant eller andra tjänster
• Entitetsramar- Om vi använder pgvector
• GPU-stackCUDA

12.x Ordförande

• **(senast vid tidpunkten för skrivandet)**cuDNN Ordförande
• - Djupt lärande primitivaPrestandaöverväganden
• **Olika hårdvaruinställningar kommer att ha olika funktioner:**Med 8 GB VRAM (minimum)
• Förlaga storlek: 7B parametermodeller med Q4 kvantisering

Bearbetning av tillverkningssatser

: Bearbetning i mindre partier

1. Minneshantering
2. : Noggrann VRAM-övervakning krävs
3. Fungerar bra för
4. : Skriva assistent, inbädda generation
5. Med 12 GB+ VRAM (komfortabel)
6. Förlaga storlek

: 7B med högre kvalitetskvantisering (Q5/Q6)

Bearbetning av tillverkningssatser

: Större partier för snabbare genomströmning**Kan också köra**: Några 13B modeller med aggressiv kvantisering

• Med 16GB+ VRAM (Min inställning)
• Förlaga storlek
• : 7B-13B parametermodeller bekvämt
• Bearbetning av tillverkningssatser
• : Fullständiga partier, minimala begränsningar

Snabba slutsatser

: Del II svarstider

Huvudbyggnad

• : Kan experimentera med olika modellerEndast processor (Fallback)
• Allt fungerar., bara långsammare
• Inbäddningar: 5-10x långsammare än GPU
• LLM:s slutsats: 10-50x långsammare än GPU
• Fortfarande användbar: För en skrivassistent med tålamod!

Utvecklingsstrategi

Vi bygger detta stegvis:

Börja med enklaste komponenter (markdown-avläsning, kapning)

Lägg till inbäddningsgenerering (kan börja med API-baserad innan du går lokalt)

Få vektorsökning att fungera

Bygg grundläggande användargränssnitt

Integrera LLM

• Polska och optimeraVarje del kommer att kunna sättas in och testas på egen hand.
• Inga stora integrationsmardrömmar.
• Vad är nästa?
• Till
• Del 2: GPU- inställning & CUDA i C#
• , vi får hand-på med GPU-inställningen:
• Installera CUDA och cuDNN på Windows
• Skapande av en utvecklingsmiljö

Skriva ett enkelt C#-program för att verifiera GPU-åtkomst

Köra en grundläggande slutledningstest med ONNX Runtime

• Benchmarking våra A4000 för att förstå vad vi kan göra
• Detta kan verka grundläggande, men att få GPU stacken rätt är avgörande.
• Jag har slösat timmar felsökning problem som kom ner till version missmatchningar eller saknas DLLer.
• Varför detta är viktigt
• Förutom att bara vara ett coolt projekt, denna strategi har verkliga tillämpningar:

Teknisk dokumentation- Bibehålla konsekvent stil över stora doc uppsättningar!