add: more stuff

This commit is contained in:
2026-05-07 23:43:04 -07:00
parent 4fa8ab3d16
commit 1044741636
4 changed files with 83 additions and 23 deletions
+6 -6
View File
@@ -41,12 +41,12 @@
"state": {
"type": "markdown",
"state": {
"file": "Simple Flux.md",
"file": "infra.md",
"mode": "source",
"source": false
},
"icon": "lucide-file",
"title": "Simple Flux"
"title": "infra"
}
}
],
@@ -142,12 +142,12 @@
"state": {
"type": "outgoing-link",
"state": {
"file": "Simple Flux.md",
"file": "infra.md",
"linksCollapsed": false,
"unlinkedCollapsed": true
},
"icon": "links-going-out",
"title": "Outgoing links from Simple Flux"
"title": "Outgoing links from infra"
}
},
{
@@ -214,15 +214,15 @@
},
"active": "a0cc81e9a0ac6335",
"lastOpenFiles": [
"learning ai.md",
"valheim.md",
"infra.md",
"README.md",
"learning ai.md",
"Simple Flux.md",
"Games.md",
"thoughts.md",
"rikidown.md",
"skubelb.md",
"valheim.md",
"Learning AI.md"
]
}
+5 -2
View File
@@ -2,9 +2,12 @@
This is powered by rikidown (see below); some previous text alluded a different software I was considering that ultimately got dropped because it was not using propert Markdown format. This seems to be working much better.
[infra.md](infra.md)
## Projects
[Valheim](valheim.md)
[rikidown.md](rikidown.md) describes the wiki software that was written to support this wobsite. In essence, this is the most basic version of a git-based wiki that uses Markdown to render it's content that I could make.
[[skubelb]] is a simple kubernetes load balancer/proxy tool; the intended use case is to provide ingress from a free-tier GCP VM to hosts that live at dynamic IPs. Originally, this was used to expose a GKE instance hosted on spot VMs to the internet, and deal with the constantly changing IPs.
[skubelb](skubelb.md) is a simple kubernetes load balancer/proxy tool; the intended use case is to provide ingress from a free-tier GCP VM to hosts that live at dynamic IPs. Originally, this was used to expose a GKE instance hosted on spot VMs to the internet, and deal with the constantly changing IPs.
[infra.md](infra.md)
+1 -7
View File
@@ -2,11 +2,9 @@ I acquired a used server for a very reasonable cost; it has 80x3.0ghz ARM cores,
If you are interested in hosting anything, please reach out :). If I you don't know how to reach out, you probably aren't invited to reach out.
I also have 5pi5, a Raspberry Pi 5 (16 GiB) that I use to host smaller applications.
Learnings:
- [[Simple Flux]]
- [Simple Flux](Simple%20Flux.md)
## Configuration
@@ -21,7 +19,3 @@ As a bonus, those silly AI tools are *very* helpful when you are tipsy. You can
and it will do the thing. It did pretty good, overall.
The Git repo for my FluxCD configuration is not public because I'm not confident that I've correctly removed all private keys from it (notably, the keys to access the kubernetes dashboard). In principle it should still be fine because access to the k3s control plane is restricted to my local network, but all the same... I don't trust you.
# Projects
[Valheim](valheim.md)
+71 -8
View File
@@ -1,13 +1,76 @@
AI has been a huge word lately; let me try and figure out what it is.
If you see anything wrong (not incomplete, but actually wrong), let me know :).
## Large language model (LLM)
LLM models are tensor networks that get 'activated' with an activation matrix, resulting in an output matrix.
There are multiple layers of matrices in most models.
## The basics of the LLM
The "open models" available online are still largely closed-source; the matrices are basically binary blocs that describe weights given to each tensor.
## Retrieval-augment generative AI (RAG)
Basically, before sending the prompt to the LLM, the client does a search to find additional context. There are lots of tools for doing this, but the most popular seem to be from the AI community, and work by converting the user input to a 'vector' of NLP tokens, using a specialized 'vector database' to find other 'chunks' of related inputs, then add those to the message before sending it to the LLM
## Tool calling
A super powerful capability, from what I can tell, it is generally implemented by telling the LLM how to structure its output to make tool calls, then attempting to parse the LLMs output to detect tool calls, run the tools, and append the result to the message going into the LLM.
This is the flow; understand this, and you understand 90% of the important bits:
1. Input text is tokenized (converted to words in the language understood by the model)
2. The tokenized input text is 'multiplied' with the layers in the model; each layer feeding into the next
3. The final output of the last layer is de-tokenized back into text
The model is trained to predict text. The training data might look something like:
```
<|turn>system
You are a helpful hacker named Acid Burn.<turn|>
<|turn>user
How do I use `ls` to sort files by size?<turn|>
<|turn>model
You can use `ls -lt`<turn|>
```
When the model is used, it is given this part of the message:
```
<|turn>system
You are a helpful hacker named Acid Burn.<turn|>
<|turn>user
How do I use `ls` to sort files by size?<turn|>
<|turn>model
```
It looks at all the samples it has, and autocompletes the remaining bits.
### Training
Training involves initializing all the layers of the model to random values, then feeding through
sample data that is used to adjust those random values. Over time, the random decreases, and you
end up with a large set of numbers that can be used for something useful.
## Everything is context
There are really 3 ways to get better results from a LLM; you change the architecture, you change
the training dataset, or you change what is given when asking it to autocomplete some text. For
the vast majority of people, changing the architecture is not possible (this is a multi-million
dollar endevour), as is training a model from scratch.
However, there are techniques called 'fine tuning' that let you adjust some layers in the model
to achieve changes in behavior. One of the most common ones is 'LO-rank Adaption' (LoRA). You
feed it in the sample data (see above), and target some more sensitive layers to change the way
it operates. This will let you achieve some changes, but actually training it to use new data is
very difficult.
The most practical, and common approach, is to change the text we are asking the model to
autocomplete. This can come in many forms, but I see there as being N primary ways:
1. Add more data to the request. This can include copy-pasting stuff, using 'retrieval augmentation'
to pull related information from dataset (or from a search engine)
2. Allow loading more context as requested by the model; this can include tool-calling
Everything is one of these 2 techniques. The vast majority of systems that are being advertised are
effectively just storing context (or summarized context), adding it to your prompt, and stripping it out
from the LLMs response.
## Monkey's with typewriters
LLMs can't code. But, they can predict what code might look like. One huge advantage computer science,
and many sciences have is that there is a correct answer. If we give the LLM samples where we test
it's output (by, for example, calling `make test` with a tool), it can make many attempts.
If you are asking about something similar to what it's seen in the past, it will likely figure it out.
If you are asking about something novel, it will make a guess. If it can test that guess, it might arrive
at a correct answer.
Put enough monkey's in front of type writers, and you eventually get Shakespeare.