As someone who has been working on this space for a while (not affiliated with govbase) this is really hard. Between eliminating the sycophancy that seems baked into LLMs and dealing with generalized hallucinations - it's freaking hard. I spent this weekend trying to figure out how to get my system to stop telling me the SAVE Act would be fine because it doesn't say what the process for if birth certificate doesn't match current id.
No, I haven't found a good solution yet - I'm going down a rabbit hole of basically crawling the entire federal register for referenced legislation and then adding in an adversarial agent to see if that can spot gaps.
Would be cool to see some logs on server load, it's one thing to claim "scale to thousands of requests per second" it's another to show the logs of a €4 VPS doing it. I don't doubt it, when I did a similar experiment with golang I never noticed any real issues (aside from a misconfiguration at the proxy requiring a min size on the SSE response) but it would still be neat to see the logs/active users.
Agreed! I have a WIP article in which I describe in the setup in more detail. I’ll also include load testing benchmarks as part of it. The key to reaching high scale is keeping things simple, and there’s really very little that the app is doing. Swoole and Redis are doing the heavy lifting, and they’re both heavily optimised for scale out-of-the-box.
Yes - there is a file watcher that should pickup modifications to the configuration file.
And you can persist indexes across restarts by mounting a volume to the `/data` directory (e.g., `-v $(pwd):/data`). Indexes are stored in a `.sourcebot` cache directory.
It’s also difficult to determine if someone is speeding from data.
For example the road I live off of according to the speed limit the car thinks goes from 40 to 65 to 25 to 65 to 40 in about a 4 mile span. Spoiler it does not. It is 40 the whole way. But according to the car I am either going 25 under, 15 over, or exactly the right speed.
(And the 65 section in the middle? Blind corner. Idk where it’s getting its data but it is very very wrong)
Iirc, though, I think I read something about this and they were more interested in average speed (regardless of posted speed), and the rate/frequency of acceleration/deceleration (especially deceleration).
The idea being that speed increases accident severity, regardless of posted speeds. Rapid deceleration is indicative of reacting late to something you should have seen and responded to earlier (eg following too closely and having to slam the brakes, not seeing someone merging, not slowing down for a yellow light, etc).
Basically that a safe driver would have a fairly smooth acceleration/deceleration profile because they're aware of what's happening around them and pre-plan accordingly. If someone wants to merge in, give them room and then back up enough that you can brake slowly if something happens.
I still don't want to be tracked, but their metrics seemed sane at first pass.
As someone in the Northeast US: Many of our highways were designed 80+ years ago, and do not have appropriate acceleration/deceleration lanes.
The terrible drivers are often those with the most timid inputs, especially with regards to acceleration. It is perfectly normal here to need to merge into heavy, 60mph+ traffic from a dead stop, or to need to quickly match speed and identify an appropriate merge spot to not wind up stuck at the end of a ramp.
And it's not like they sit there for 15 minutes waiting for some exceptionally large gap to match their acceleration habits - that would be very annoying to other drivers, but theoretically "safe". They enter in the same length gap as someone that actually uses their gas pedal - but rely on oncoming traffic to hit their brakes/evade, as they fail to get up to speed quickly enough for the small gap they've entered in.
-----
Hard braking is something with fewer reasons it should happen regularly - but I'm still reminded of the usual adage about metrics. Do you really want people to be mentally reluctant to hit their brakes as hard because of the insurance hit? That seems like a recipe for increasing decision time and accidents.
Maybe if the only thing you're reacting to is other vehicles or the road. The number of times I have to slam on my brakes on that particular road because of animals running into the road is way too high. And no, not always deer. I've come around curves and just had someone's dog sitting in the middle of the road on multiple occasions because for some reason people think it's totally safe to just let their dogs roam.
That indicates real increased risk, though, compared to someone who drives in places where animals are less likely to be in the road.
Insurers aren't trying to determine how good of a driver you are (conditional probability of you being in a collision given conditions). They're trying to determine how likely it is that you're going to be involved in a collision that results in a claim (unconditional probability of you being in a collision). If you frequently drive through deer infested forests, it seems reasonable that your insurer is going to expect more claims compared to someone who doesn't do that.
It's similar to how driving late at night results in higher premiums. You can be the same good driver at night and during the day, but if you're frequently driving at 3 a.m., you're a higher risk.
Your ECS API looks very similar to that of Bevy's, were you inspired at all by that?
From the little I can see of it, it looks like you don't allow writes to data and instead prefer to return a new thing based on a query? Based entirely on the below.
Yeah we are huge fans of Bevy, and heavily inspired by their API. Mutability is tricky in XLA / JAX's computation model. Its optimizations rely on a purely functional style of programming, and so we've tried to map that onto an ECS. In addition, there are some counterintuitive things about programming with JAX that try and discourage through our API. Like accidentally unrolling a loop by using `for` instead of `vmap`.
EDIT: One thing I forgot to add is that we actually use Bevy for our 3D viewer. IMO, its the perfect framework for developing 3d applications that aren't quite games. Most games engines make you carry around a ton of features you will never use, but Bevy is really good at being flexible, lightweight, and easy to use
No, I actually like that approach better than the traditional ECS approach. Though I assume it both adds and removes some complexity. In a traditional ECS approach you can depend on certain systems running in certain orders because you depend on them having run. Then you refactor, forget this dependency, and suddenly you have changed behaviors and you have no idea why until you remember this. If, as I assume, you have per step immutability that removes a whole class of bugs at the cost of a slight increase in complexity.
Yes and no, for text type stuff? Yes you're right. But I think in the vision space synthetic data will remain useful for a lot of things. I'm currently working on building a pipeline for personal projects to go from CAD models of environment to segmented training data. So far it looks almost as useful as real world data at a fraction of the cost of manual labeling.
No, I haven't found a good solution yet - I'm going down a rabbit hole of basically crawling the entire federal register for referenced legislation and then adding in an adversarial agent to see if that can spot gaps.