The implementation learns to play Battleship in about 2000 steps, pretty neat!
67 karma · joined May 6, 2014
The implementation learns to play Battleship in about 2000 steps, pretty neat!
Then, you want to parition the document into chunks. Late chunking pairs really well with semantic chunking because it can use late chunking's improved sentence embeddings to find semantically more cohesive chunks. In fact, you can cast this as a binary integer programming problem and find the ‘best’ chunks this way. See RAGLite [1] for an implementation of both techniques including the formulation of semantic chunking as an optimization problem.
Finally, you have a sequence of document chunks, each represented as a multi-vector sequence of sentence embeddings. You could choose to pool these sentence embeddings into a single embedding vector per chunk. Or, you could leave the multi-vector chunk embeddings as-is and apply a more advanced querying technique like ColBERT's MaxSim [2].
[1] https://github.com/superlinear-ai/raglite
[2] https://huggingface.co/blog/fsommers/document-similarity-col...
The benefit is that each sentence’s embedding is informed by all of the other sentences in the context. So when a sentence refers to “The company” for example, the sentence embedding will have captured which company that is based on the other sentences in the context.
This technique is called ‘late chunking’ [1], and is based on another technique called ‘late interaction’ [2].
And you can combine late chunking (to pool token embeddings) with semantic chunking (to partition the document) for even better retrieval results. For an example implementation that applies both techniques, check out RAGLite [3].
[1] https://weaviate.io/blog/late-chunking
[2] https://jina.ai/news/what-is-colbert-and-late-interaction-an...
1. Declare numbers as numbers in the configuration language. E.g. "decimal(1e1000)".
2. Parse declared numbers with a lossless format like Python's decimal.Decimal.
3. Let users decide at their own risk if they want to convert to a lossy format like float.
These are some of the problems with utility I took away from your comment:
1. Short term utility maximisation does not necessarily align with long term utility maximisation. 2. The utility is difficult to define because we don't know what can contribute to it and how much those components would contribute. 3. The utility, even if defined, can only be partially observed.
While these are certainly valid and interesting observations, that doesn't mean there isn't a latent utility that describes your lifetime's value. If you live a thousand lives and had access to a device to measure the (latent) utility, surely you could it to rank lives as more meaningful or valuable than others.
Looking at it this way, the problems you raise could be seen as opportunities: how should we align short term utility with long term utility? How can we find out which utility components there are and how much they would contribute? And how can we make the utility observable, so that it can be maximised?
Interestingly, attempting to maximise the utility may itself lower the utility as a result of spending time on the maximisation task and the dehumanisation of life as a result of its formalisation.
That's a very inefficient way to run your CI, with conda and pip alike.
Instead, you could build your environment once in a Docker image and use that as your build image.
Saves a lot of time on your builds, guarantees reproducibility, and will work even when package servers are unavailable.
I wonder why they didn't have just one median function and control its behaviour with keyword arguments instead of creating 4 different median functions.