WAARSCHUWING: Deze zijn ontwerp-Posts die 'onthuld'.
Het is waarschijnlijk veel van wat hieronder zal niet werken; IK genereren deze als how-to voor MIJ en dan doen alle stappen en krijg de sample app werken...Je bent stiekem en ze gezien! ze zullen waarschijnlijk klaar zijn medio december.
## Inleiding
Doe je gordel om, want dit wordt een lange serie.
Als je deze blog hebt gevolgd, weet je dat ik een beetje geobsedeerd ben door het vinden van interessante manieren om LLM's en AI te gebruiken in praktische toepassingen.
Ik heb een nieuw project dat mijn liefde voor bloggen, C# en AI combineert: het bouwen van een schrijfassistent die me helpt nieuwe blogberichten op te stellen met behulp van mijn bestaande content als kennisbasis.
OPMERKING: Dit maakt deel uit van mijn experimenten met AI (ondersteund opstellen) + mijn eigen bewerking.
Denk aan hoe moderne juridische praktijken gebruik maken van LLM's getraind in jurisprudentie om slips, moties en contracten op te stellen.
Ze beginnen niet vanaf nul - het systeem verwijst naar relevante precedenten, stelt taal voor gebaseerd op succesvolle documenten uit het verleden, en handhaaft consistentie met gevestigde patronen.
Dat is precies wat we hier bouwen, maar voor blog inhoud.
Het doel is om een AI-aangedreven schrijfassistent te creëren die:
Auto-genereert interne links naar gerelateerde artikelen
Handelt als "GitHub Copilot voor uw blog"
Deze serie zal betrekking hebben op het bouwen van een compleetRetrieval Augmented Generation (RAG)
**systeem in C# dat draait op Windows.**We gebruiken de nieuwste benaderingen en kaders, en ik zal elke nieuwe technologie uitleggen als we het tegenkomen.
**My Hardware Setup (en Minimum Specificaties)**Mijn Development Machine:
GPU**: NVIDIA RTX A4000 (16GB VRAM)**CPU
: AMD Ryzen 9 9950X
RAM: 96GB DDR5
Dit is mijn specifieke setup, maar jij
heb deze hardware niet nodig
**om mee te volgen.**Hier zijn de minimale specificaties voor verschillende componenten:
Nog steeds volledig bruikbaar voor een schrijfassistent!
RAM-vereistenMinimum
: 16GB systeem RAM
CPU-only gevolgtrekking voor 7B modellenComfortabel
: 32GBBeter voor grotere modellen op CPU
Mijn setup
: 96GB - Overkill, 32GB is genoeg
OpslagSSD
: Aanbevolen voor modelbelastingRuimte
: ~20GB voor modellen en vectordatabaseHoe zit het met Intel/AMD NPU's?
**Moderne CPU's bevatten nu speciale AI-versnellers:*Intel Core Ultra(Meteor Lake+) - Intel AI Boost (NPU)*AMD Ryzen AI
(7040/8040 series) - 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
(Strix Point) - Tot 50 TOPSBelangrijk: NPU's zijn alleen voor gevolggeving!
Je "bouwt" of traint geen modellen op NPU's - ze zijn ontworpen omuitvoeren
**Efficiënt voorgetrainde modellen.**Modellen worden getraind op cloud GPU's (of werkstations), vervolgens gedownload en geïmplementeerd naar NPU's voor gevolgtrekkingen.
**Huidige status voor draaiende modellen op NPU's (als van schrijven):**Waarom niet NPU's voor deze serie?
Software-ecosysteem: CUDA heeft 15+ jaar looptijd, NPU ondersteuning in .NET is opkomende
Modelcompatibiliteit
: De meeste GGUF modellen doel CUDA/CPU, NPU-geoptimaliseerde modellen zijn zeldzaamDocumentatie: Beperkte middelen voor NPU ontwikkeling in C#
Prestaties
: Momenteel langzamer dan discrete GPU's voor onze werklast
DirectML-ondersteuning
: Nog experimenteel voor LLM-inferentie
# 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);
**Kun je NPU's gebruiken als gevolg?**Ja, maar:VereistDirectMLuitvoerder in ONNX RuntimeModellen moeten in ONNX-formaat zijn (geen GGUF)
C# ondersteuning is experimenteelPerformance is momenteel onderbenut vs. CUDA
Hoe NPU-inferentie te proberen (geavanceerde gebruikers):
Toekomstige overweging
: EenmaalONNX-runtime
enDirectML
**volwassen hun NPU ondersteuning (waarschijnlijk 2024-2025), deze zal levensvatbare alternatieven voor gevolgtrekkingen worden!**Onderaan
**: Ik zal het GPU-versnelde pad laten zien, maar zal overal CPU-only alternatieven opmerken.**U kunt alleen CPU starten en later upgraden!
Wat we aan het bouwen zijnHet uiteindelijke systeem zal verschillende componenten hebben:
Afbakening Ingestie Pijplijn- Processeert alle blog berichten, brokken ze intelligent, en genereert inbeddingen
Vectordatabase
- slaat inbeddingen op en maakt semantisch zoeken naar soortgelijke inhoud mogelijk
Toepassing van Windows-client
Een bureaublad schrijven assistent UI met editor en suggestie paneel
LLM-integratie
Lokale GPU-versnelde gevolgtrekking voor het genereren van inhoud
Citaat & koppelingsgeneratie
Auto-sugges interne links en verwijzingen naar gerelateerde posten
Style Consistency Engine
Leert patronen van bestaande berichten om spraak en structuur te behouden
Zie het als "GitHub Copilot ontmoet Grammarly" maar getraind specifiek op de inhoud en stijl van uw blog.
Waarom 'advocaat GPT'?
Moderne advocatenkantoren gebruiken LLM's die getraind zijn in uitgebreide jurisprudentie-bibliotheken om juridische documenten te helpen opstellen.
Bij het schrijven van een motie, het systeem:
Verwijzingen naar relevante precedenten en eerdere succesvolle argumenten
Stelt taalpatronen voor die eerder gewerkt hebben
Handhaaft consistentie met wettelijke schrijfstandaarden
Windows instellen voor GPU-versnelde AI workloads, installerenCUDA, cuDNN, en het testen dat C# daadwerkelijk kan zien en gebruiken van uw GPU.Deel 3: Inbeddingen en vectordatabases begrijpenDiepe duik in wat inbeddingen eigenlijk zijn, hoe ze semantisch zoeken mogelijk maken, en het kiezen van de juiste vector database (spoiler: we zullen waarschijnlijk gebruiken
ofpgvector, Deel 4: Bouwen van de Ingestie PijpleidingHet verwerken van markdown-bestanden, intelligente brokstrategieën (je kunt niet zomaar splitsen op alinea's!), en het genereren van inbeddingen voor al onze inhoud.
?), het bouwen van de UI, en waardoor het eigenlijk aangenaam om te gebruiken.
Deel 6: Lokale LLM-integratie
Lokaal draaien van modellen met behulp vanONNX-runtime
lama.cppbindingen, of andere benaderingen.
**Gebruik makend van die A4000!**Deel 7: Content Generation & Prompt Engineering
**Alles bij elkaar brengen - semantisch zoeken naar relevante inhoud, context window management, prompt engineering voor het schrijven van hulp, en het genereren van coherente suggesties.**Deel 8: Geavanceerde kenmerken en productie-implementatie
**Auto-linken naar gerelateerde berichten, stijl consistentie controleren, code knipsel suggesties, en het maken van het systeem eigenlijk nuttig voor het dagelijks schrijven.**Waarom RAG?
Voordat we in architectuur duiken, laten we het hebben over waarom RAG (Retrieval Augmented Generation) hier de juiste aanpak is.
Het probleem met Fine-Tuning
Je zou kunnen denken: "Waarom niet gewoon fine-tune een LLM op alle blog posts?" Er zijn verschillende problemen met dat:
Kosten & complexiteit
Fine-tuning is duur (zowel in berekening als inspanning)
Stabiliteit
Elke nieuwe blogpost betekent omscholing
Zwarte doos
Moeilijk te begrijpen wat het model "geleerd"
✅ 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)
Hallucinaties
Geen garantie dat het model niets verzint.
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
Geen verwijzingen
Kan niet gemakkelijk antwoorden terug te traceren naar bronnen
Hoe RAG dit oplost
RAG combineert het beste van beide werelden: de kracht van LLM's met de precisie van zoeken om context-bewuste contentgeneratie te creëren.
De stroom is:
Gebruiker begint te schrijven (bijv., "Een REST API bouwen met ASP.NET Core...)
Systeem vindt semantisch vergelijkbare artikelen uit het verleden
Systeem voert relevante brokken als context naar de LLMLLM genereert suggesties/voortzettingen op basis van eerdere inhoud
Systeem biedt suggesties met verwijzingen naar bronposten
Dit betekent:
Systeemarchitectuur
Laat me de belangrijkste onderdelen die we gaan bouwen op een rijtje zetten:
Afbakening Ingestie Pijplijn
**Deze component:**Leest markdown-bestanden uit de blogmap
**Te groot en je verspilt het contextvenster van de LLM.**We hebben stukken nodig die semantisch betekenisvol zijn - een complete gedachte of sectie, geen willekeurige paragraaf breekt.
(state-of-the-art open source)**3.Vectordatabase**De vectordatabase slaat inbeddingen op en maakt een snelle zoektocht naar gelijkenis mogelijk.**Wanneer je schrijft over "Docker compone" vindt het de K meest semantisch vergelijkbare inhoud uit het verleden - niet alleen trefwoord komt overeen, maar conceptueel gerelateerd materiaal.**Technologiekeuze
: We zullen evalueren:
Qdrant
Modern, geschreven in Rust, uitstekende C# client, Docker-vriendelijk
pgvector
Extensie voor PostgreSQL (we gebruiken Postgres al!)
Weaviate
- Een andere solide optie met goede .NET ondersteuning:
## Inleiding
