ubutler

The six solid objects discovered on Forrest Beach, to the north of Townsville, are thought to be space debris, and the Australian Space Agency (ASA) is now trying to determine where they came from. The BBC has approached the agency for comment.

Off-topic but this is the first time I’m learning we (Australia) have a space agency :O

Sounds nice except that these are 1 very small scale model, 1 reranker, and 1 embedding model that are far from frontier LLM level.

We've tried to take a first-principles approach to our end goal of 'legal superintelligence' that has involved identifying the areas of our domain most in need of improvement and releasing models that raise the bar on quality in those areas.

We've been around for a couple months now and ended up starting with retrieval and enrichment. The models we've released to tackle those problems have indeed been smaller in size than their competitors, yet they still rank ahead on open-source benchmarks.

Them being so small also helps with their accessibility — as I mention in our post, our models can be deployed on ordinary hardware, not a supercomputer.

Next on our roadmap is reasoning and research, which will require more infrastructure to support, but again, we aim to be judged by performance at the time of release.

As much as I agree with the message, this reads like marketing copy trying to make a big deal out of a tiny model being hosted privately.

The point of this point is really just to reaffirm our commitment to sovereignty and accessibility and contrast our approach with that of major AI labs. It _is_ possible to commercialize LLMs while still keeping them accessible. A customer using a self-hosted deployment today does not need to worry about our models no longer being available tomorrow. We think that's a good thing. And moving forward, we want to keep that option available for anything we do, instead of trying to pull up the ladder while we're ahead.

Our models can be deployed on premises as well, though that is more of a bespoke offering at the moment. We've also been fortunate enough to have trained most of our models on our own private infrastructure. Your question raises a broader question, though, about sovereign risk attached to cloud services in general. For some, particularly governments, sensitivity is so high that certain workloads must run fully on their own hardware. I don't see that changing for now, and, in fact, in certain jurisdictions, the trend is turning against cloud services.

ChatGPT already does this, albeit in limited circumstances, through the use of its sandbox environment. Asking GPT in thinking mode to, for example, count the number of “l”s in a long text may see it run a Python script to do so.

There’s a massive issue with extrapolating to more complex tasks, however, where either you run the risk of prompt injection via granting your agent access to the internet or, more commonly, an exponential degradation in coherence over long contexts.

This is called a lexical innovation ;). https://en.wikipedia.org/wiki/Lexical_innovation.

We'd argue it makes a lot of sense to appropriate 'graphitization' as a term for a model designed to transform data into knowledge graphs.

Also, you really want to tell people how to access it and what it costs. Or put up a "call for quote" if your market is large Enterprise budgets.

Our pricing page can be found in our documentation here: https://docs.isaacus.com/pricing/prices. We're planning on making it more visible on our website; thanks for the feedback!

FWIW we're planning on releasing a self-hostable version on AWS Marketplace quite soon followed by one on the Azure Marketplace. In both cases, deployments live entirely in your tenancy, are fully air-gapped (ie, they can't access the internet), and your usage is unmetered.

We do already have a government-facing client using one of our self-hosted deployments given the privacy and security concerns the legal industry tends to have (rightfully in our view) around AI.

Weirdly, the blog announcement completely omits the actual new context window size which is 400,000: https://platform.openai.com/docs/models/gpt-5.2

As @lopuhin points out, they already claimed that context window for previous iterations of GPT-5.

The funny thing is though, I'm on the business plan, and none of their models, not GPT-5, GPT-5.1, GPT-5.2, GPT-5.2 Extended Thinking, GPT-5.2 Pro, etc., can really handle inputs beyond ~50k tokens.

I know because, when working with a really long Python file (>5k LoCs), it often claims there is a bug because, somewhere close to the end of the file, it cuts off and reads as '...'.

Gemini 3 Pro, by contrast, can genuinely handle long contexts.

Here's a copy of the only known recording of a prank call to the Queen: https://www.youtube.com/watch?v=-YFFhc3XZDw

After having read the article in its entirety, I’m still not sure what Cybersyn is…

Personally, I like it. However, I like being able to comment and upvote more. At the same time, I'd be reluctant to say the least to hand over my login credentials. It could be quite cool to see this turned into a FOSS RES-style browser extension. Or maybe even a commercial product. I already paid for the HACK app.

We were unfortunately disappointed to discover that, yes, Voyage, Cohere, and Jina all train on the data of their API customers by default.

Voyage's terms say:

you grant Voyage AI (and its successors and assigns) a worldwide, irrevocable, perpetual, royalty-free, fully paid-up, right and license to use, copy, reproduce, distribute, prepare derivative works of, display and perform the Customer Content: ... (iii) to train, improve, and otherwise further develop the Service (such as by training the artificial intelligence models we use).

Cohere's terms say:

YOU GRANT US A ... RIGHT TO ... USE ... ANY DATA ... TO ... IMPROVE AND ENHANCE THE COHERE SOLUTION AND OUR OTHER OFFERINGS AND BENCHMARK THE FOREGOING, INCLUDING BY SHARING API DATA AND FINETUNING DATA WITH THIRD PARTIES ...

Jina's terms say:

Jina AI shall, subject to applicable mandatory data protection requirements, be entitled to retain data uploaded to the Jina AI Systems or otherwise provided by the Customer or collected by Jina AI in the course of providing the Services and to use such data in anonymized/pseudonymized format for its business purposes including to improve its artificial intelligence applications.

In my experience, maintaining a very popular software library, supporting open source, and blogging have absolutely all contributed to my success, and, additionally, as someone who is now a founder seeking like-minded, highly skilled engineers, those are key signals for an attractive hire.

I can understand though, perhaps in a work environment where management is unlikely to be able to retain high skilled talent, you may want 'low-profile' workers that aren't going to have as many competitors chasing after them...

Further to @dust42, BERT is an encoder, GPT is a decoder, and T5 is an encoder-decoder.

Encoder-decoders are not in vogue.

Encoders are favored for classification, extraction (eg, NER and extractive QA) and information retrieval.

Decoders are favored for text generation, summarization and translation.

Recent research (see, eg, the Ettin paper: https://arxiv.org/html/2507.11412v1 ) seems to confirm the previous understanding that encoders are indeed better for “encoder task” and vice-versa.

Fundamentally, both are transformers and so an encoder could be turned into a decoder or a decoder could be turned into an encoder.

The design difference comes down to bidirectional (ie, all tokens can attend to all other tokens) versus autoregressive attention (ie, the current token can only attend to the previous tokens).

Actually it reflects the idea of Unicode code points correctly. They are meant to represent graphs, not semantics.

Why do we then have lots of invisible characters that are intended essentially as semantic markers (eg, zero-width space)?

Hey HN,

Over the past couple months, we, a team of Aussie legal and AI experts, have been working on building a new type of legal AI company — a company that, instead of trying to automate legal jobs, is trying to automate legal tasks.

We want to make lawyers’ lives easier, not replace them.

We’ve been laser-focused on building small and efficient yet still highly accurate, specialized models for some of the most time-consuming and mundane legal tasks lawyers have to perform. Stuff like running through a thousand contracts just to locate any clauses that would allow you to get out early.

We just finished training our first set of models, focused on document and clause classification, probably the most common problem we see come up. Our benchmarks show our models to be far more accurate and almost more efficient than their closest general-purpose competitors.

Today, we’re making those models publicly available via the Isaacus API, the world’s first legal AI API.

Our models don’t require any finetuning because they’re zero-shot classifiers — you give them a description of what you’re looking for (for example, “This is a confidentiality clause.”) and they pop out a classification score.

Because our models are so small, which they have to be to be able to process reams of legal data at scale, they can sometimes be a bit sensitive to prompts. To help with that, however, we’ve preoptimized an entire library of prompts, including what we call, universal templates, which let you plug in your own arbitrary descriptions of what you’ve looking for.

We’ve made our prompt library available via the Isaacus Query Language or IQL. Another world first — it’s a brand-new AI query language designed specifically for using AI models to analyze documents.

You can invoke query templates using the format “{IS <query_template_name>}”. You can also chain queries together using Boolean and mathematical operators, like so: “{This is a confidentiality clause.} AND {IS unilateral clause}”.

We think our API is pretty neat and we hope you will too.

This is just the beginning for us — over the course of this year, we’re planning on releasing text extraction and embedding models as well as a second generation of our Kanon legal foundational model.

Below are some links for your convenience.

- Quickstart guide: https://docs.isaacus.com/quickstart

- Announcement: https://isaacus.com/blog/the-worlds-first-legal-ai-api

- Docs: https://docs.isaacus.com/home

- Sign up: https://platform.isaacus.com/accounts/signup/

- LinkedIn: https://www.linkedin.com/company/isaacus/

- Email: hello@isaacus.com

Kagi Professional is $10/m and comes with unlimited searches.

+1 It’s almost as indispensable as tqdm for a data scientist at least.

MessagePack can encode rows as well and then you just need to manage linking the keys during deserialization. In fact, it can encode arbitrary binary without needing base64 like JSON.

Although MessagePack is definitely not a drop-in replacement for JSON, it is certainly extremely useful.

Unlike JSON, you can’t just open a MessagePack file in Notepad or vim and have it make sense. It’s often not human readable. So using MessagePack to store config files probably isn’t a good idea if you or your users will ever need to read them for debugging purposes.

But as a format for something like IPC or high-performance, low-latency communication in general, MessagePack brings serious improvements over JSON.

I recently had to build an inference server that needed to be able to communicate with an API server with minimal latency.

I started with gRPC and protobuf since it’s what everyone recommends, yet after a lot of benchmarking, I found a way faster method to be serving MessagePack over HTTP with a Litestar Python server (it’s much faster than FastAPI), using msgspec for super fast MessagePack encoding and ormsgpack for super fast decoding.

Not sure how this beat protobuf and gRPC but it did. Perhaps the Python implementation is just slow. It was still faster than JSON over HTTP, however.

Nice. You can do the same in Python like so and surprisingly it only takes a couple seconds to a minute to get the print out, no need for importing any special libraries (just `sys` to enable printing large numbers).

```python

import sys sys.set_int_max_str_digits(0) # Allows for printing very large numbers.

x = (2 * 136_279_841) - 1

print(x)

```

I had already started using Kagi to create bangs that run searches like “site:reddit.com %s” but glad to see this made even easier!

Simhash is an extremely fast and simple algorithm for detecting near duplicate text at scale which makes it particularly useful for deduplicating AI training datasets.

Is it “this couple reign” or “this couple reigns”? The former just feels wrong despite it being the title.

* without already labelled training data (assuming you're referring to causal LLMs).

If you have labelled training data (or semi-labelled), BERT takes the cake, both in terms of accuracy and efficiency. In fact, you can have luck with getting a CLM to generate noisy labels and then training BERT/RoBERTa on that to get a robust strong classifier.

I misinterpreted the title as Apple approving development of iOS apps on PC. That would’ve been an exciting development.

and indeed, much of what used to be fertile farmland in that part of the world is now desert from over-farming

Do you have a source for this?

Probably because the title of the article uses 402,000,000 Mbps and I think there’s a rule(?) on HN about not misrepresenting titles or rewording them too much, though I’d wager 402 Tbps is fair alteration.

Although worth noting that more recent techniques (eg, Transformers) need stop words for context.

There are two reasons I can think of why someone might reuse a tokeniser:

1. They want to continue pretraining a model instead of starting from scratch. But actually people might not know that you can pretty easily reuse model weights even when training with a new tokeniser (I’ve got a blog post on how to do that: https://umarbutler.com/how-to-reuse-model-weights-when-train... ).

2. Because it’s convenient for end users. Tokenising and chunking really large corpora can take a long time and it’s nice that I can use the GPT2 tokeniser and then train a bunch of different models on that data without having to retokenise everything.