my experiments with so called "truth"

A language model can get a training target from the same text it is reading. Move the text over by one token: each input position now has a next token to predict. No one has to write a separate answer for every prefix. The catch is that the model must not be allowed to peek at that answer. The text already contains a training target Consider the sentence “The kettle is on the stove.” As before, we will pretend each word is one token and leave out punctuation. A real tokenizer may split it differently. After “The”, the next token in this sentence is “kettle”. After “The kettle”, it is “is”. Each position gives us a prediction to compare with the token that actually follows. The input and target sequences are offset by one position. Word-sized tokens are a simplification for this example. This is why we can train a language model from ordinary text without manually writing an answer for every prefix. The text supplies the target. However, later tokens are present in the training s...

A language model can use a sentence you just typed without learning new weights from it. The prompt changes the calculation's input. During ordinary generation, the model's learned numbers stay fixed. To see how that works, give it the words “The kettle is on the” and follow one prediction. We will follow a model in the GPT family, short for Generative Pre-trained Transformer. It generates text using already-learned parameters: the numbers its calculations use. We will trace one prediction through that model, then see how repeating the step produces more text. The second article explains how training learns those numbers. Start with one prediction After “The kettle is on the”, “stove” is a possible continuation. So is “table”. The model assigns scores to the possible next tokens, which we can turn into probabilities. Choosing a token from those probabilities is a separate step. A token is a unit of text defined by a tokenizer. It might be a word, part of a word, or punctua...

Suppose you have a folder of notes from a side project. Somewhere in those notes is the reason you chose SQLite over Postgres. You remember discussing it, but you cannot remember which file contains the decision. You could search the folder yourself, read a few files, and put the answer together. What would it take to let a language model do those steps? The model can write a request to search. That request is still just output from the model; it has not searched a single file. Our application must run the search and send the results into another model call. Following that handoff is a useful way to understand an agent. For this example, watch what changes after each tool result: the model has new information for choosing its next action. Give the model a way to look For this example, we will design two tools: search_notes(query) Returns matching file names and short excerpts. read_note(path) Returns the contents of one file in the notes folder. A tool is a capability ...

In one sentence: With AWS Cloud Development Kit (CDK), we write a program that produces a CloudFormation template. CloudFormation reads that template and creates or updates the resources in AWS. Keep that split in mind: the CDK application describes the infrastructure; CloudFormation builds it. The CDK command-line tool connects the two. 1. The problem Say we need a network, a load balancer, a Postgres database and an application running in Amazon Elastic Container Service (ECS). We have three ways to describe the setup. Configure it in the AWS console. We can create the resources, but repeating the setup and reviewing changes means keeping track of the individual settings ourselves. Write a CloudFormation template by hand. The setup becomes a file we can review and reuse. As we add roles, security groups, logs and connections, that file grows. Write a program that produces the template. That is CDK. We get functions, loops and types, and the output is still a file CloudFor...

At some point, if you are working on managing  Jenkins  for your team, you will find yourself looking for a set of useful groovy scripts to control jenkins configuration for a large no of builds/jobs. Following are some mostly frequently needed ones Get all jobs that belong to a view  hudson.model.Hudson.instance.getView('my-view')?.items.each() { println it.fullDisplayName } Clear the build queue   import hudson.model.* def queue = Hudson.instance.queue println "Queue contains ${queue.items.length} items" queue.clear() println "Queue cleared" Disable jobs in a view  hudson.model.Hudson.instance.getView('1.1.x-tests')?.items.each() { println("JOB : "+it.name) it.disabled=true it.save() } Get all jobs that that define a TimerTrigger with the trigger spec  import hudson.model.* import hudson.triggers.* for(item in Hudson.instance.items) { for(trigger in item.triggers.values()) { if(trig...

Recently, to learn a test framework for Scala ( even for Java) I chose specs2 .  Its still difficult to move to SBT, largely due to the fact that I am yet to be comfortable using it. So, for the time being I will stick to maven. To configure the scala/java project edit the pom.xml to include <dependencies> <!-- specs2 version I used : 1.12.3--> <dependency> <groupid>org.specs2</groupid> <artifactid>specs2_${scala.version}</artifactid> <version>${specs2.version}</version> <scope>test</scope> </dependency> <dependency> <groupId>org.scala-lang</groupId> <artifactId>scala-library</artifactId> <version>${scala.version}</version> </dependency> </dependencies> <build> <sourceDirectory>src/main/scala...

I've been learning Scala recently, including through a Coursera course. I'm gradually moving from writing Java-like Scala toward thinking in terms of transformations on data. What I like so far is being able to express operations on collections without spelling out every intermediate step. Shorter code helps when it makes the flow easier to follow, but it does not automatically make a program easier to maintain. Recently, I came across Akka. It lets us organize concurrent work as actors that communicate through messages. Each actor handles one message at a time and can keep its own state. This gives us a way to separate responsibilities without having several workers directly update the same state. We still need to design how those actors coordinate. I tried a word-count program using Akka and Scala. A mapper splits sentences into words, a reducer combines their counts, and an aggregator maintains the totals. The useful part of this exercise is seeing how work moves between ...