Oksana astral303

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

The Conspiracy Against High Temperature Sampling

Or: Why Your LLM Outputs Are Boring and Whose Fault It Really Is

There's a quiet war being waged in the machine learning inference space, and most of you don't even know you're losing it. Every day, millions of people interact with large language models through sanitized, corporatized interfaces that offer them a single "creativity" slider at best. Often they get nothing at all. Meanwhile, a small cabal of researchers and hobbyists has been pushing the boundaries of what's actually possible with modern sampling techniques. Yes, this includes the much maligned "coomer" community.

We live in a time of revealed conspiracies. The Epstein files have shown us what happens when powerful institutions coordinate to suppress information and protect their interests. Flight logs that sat in plain sight for years. Connections that "serious people" dismissed as paranoid speculation until the documents dropped. The pattern is always the same! Information asymme

Here are my attempts to script an IntelliJ-based IDE using javax.script.* API (ex-JSR-223).

The list of available scripting languages and engines:

Groovy - built-in, via Groovy jars and <app>/lib/groovy-jsr223-xxx.jar
JavaScript (Nashorn) - built-in, via Java Runtime <app>/jbr/... (deprecated and will be removed soon)
JavaScript (GraalJS) - https://plugins.jetbrains.com/plugin/12548-intellij-scripting-javascript
JPython - https://plugins.jetbrains.com/plugin/12471-intellij-scripting-python
JRuby - https://plugins.jetbrains.com/plugin/12549-intellij-scripting-ruby
Clojure - https://plugins.jetbrains.com/plugin/12469-intellij-scripting-clojure

	1. Setup a project

	2. Add groovy SDK support:
	https://www.bonusbits.com/wiki/HowTo:Add_Groovy_SDK_to_IntelliJ_IDEA

	3. Download http://(yourjenkinsurl)/job/(yourpipelinejob)/pipeline-syntax/gdsl
	- this will give you the .gdsl file - download this to the src folder of your project.

	4. Finally follow this step - right click on the src folder -> Mark directory as -> Sources Root

	__author__ = 'acp'

	import re
	import fileinput
	import operator
	import sys

	objectschanged={}

	def create_object_list(line2,mapofObjects,instance):

	import java.util.List;
	import java.util.concurrent.TimeUnit;

	import rx.Observable;
	import rx.Subscriber;
	import rx.schedulers.Schedulers;

	public class DebounceBuffer {

	public static void main(String args[]) {

	function map() {
	emit(1, {
	sum: this.value, // the field you want stats for
	min: this.value,
	max: this.value,
	count: 1,
	diff: 0
	});
	}

	So you've cloned somebody's repo from github, but now you want to fork it and contribute back. Never fear!

	Technically, when you fork "origin" should be your fork and "upstream" should be the project you forked; however, if you're willing to break this convention then it's easy.

	* Off the top of my head *

	1. Fork their repo on Github
	2. In your local, add a new remote to your fork; then fetch it, and push your changes up to it

	git remote add my-fork git@github...my-fork.git