Is RAG the right tool for this? My understanding was that RAG uses vector similarity to compare queries (the extracted string) versus the search corpus (the PDF file) using vector similarities. The use case you describe is verification, which sounds like it would be better done with an exhaustive search via string comparison isntead of vector similarities.
The thing with cooking meth is that you don't have to be comfortable putting it in your body. You just have to be comfortable selling it to someone else who will put it in their body! Unfortunately, for many meth producers/dealers that bar is not very high.
"verifying" signatures is an inherently insecure practice anyway. It's trivial to copy a signature any many people (like me) have poor writing that varies each time anyway. It's more about showing intent than verification.
Out of curiousity: are you Irish? These patterns match some of my relatives, particularly ending sentences with "filler" words and the "th" pronounciation. I never thought about these as things that need fixing since they are just part of an accent (not suggesting you shouldn't change them if you feel like you'd prefer a different speech pattern).
I got reasonable offers from 2/3 companies I went on-site with from Triblebyte. I found that their stable of companies had too many tiny startups with questionable (read: boring/dumb) product ideas. I wanted a company with 100-300 employees so not many of their partners met my criteria. I found their recruiting partner that works with you kind of annoying... I didn't appreciate them texting me/"checking in" all the time. It's bad enough to deal with the company recruiters doing this, I don't need another cook in the kitchen. Overall, I didn't think it was a waste of time but I don't think I'd use it again now that I know that they mostly represent smaller companies with advertising/fintech aspirations.
sitting on the floor requires a pretty high degree of hip and hamstring flexibility to avoid rounding the pelvis under and introducing poor posture. You might be better off taking breaks to focus on improving hip mobility and work up to a sitting desk option as a longer term goal.
Small counterpoint: many people who buy instruments want to buy the actual instrument they try out. Quality in guitars (and other instruments) is wide enough that one might play well, while another of the same model plays like a worse, cheaper instrument. Buying a guitar untested/online (even the same model you tried in store) has a large amount of risk that decreases with the instrument price, but not always and not as quickly as you might expect.
I don't know enough about Benford's law to draw conclusions, but is N=O(1000) a large enough sample size to expect it to apply? My intuition suggests that if county size does not span enough orders of magnitude then Benford's wouldn't apply because the distribution might lie in one of the "spikes" of the Benford curves, rather than reflecting the average. For example, if many counties had a population size starting with a "4", you'd expect more vote counts to start with "2" (presuming each candidate received close to 1/2 of the votes).
Hopefully someone with a stronger math background can expand in a more fluent way :)
IMO "weaving through traffic" is not a skill that makes you a good driver. It might take skill, but it's irresponsible and reckless. A good driver understands that weaving is more likely to result in injury, property damage, or no result (think of the lane-switchers in rush hour traffic that you end up right next to after 30 mins) than an actual benefit. I'm not sure that it should be included in a confidence measure for driving ability.
My parents did this for me. As I got older (highschool) it was paid quarterly. It even encompassed clothing/school essentials, eventually. Part of the beauty of it was that I was incentivized to work during the summers to supplement it. I turned out very frugal, was treasurer of my org in university, and now save > 50% of my income living in SF. This works.
I see how that's important. On the other hand, it's not as big of a deal to spread the virus if everyone has protection from the symptomatic risks. We should still shelter in place, but even turning active cases into carries would reduce loss of life (presuming we continue regular testing so people can KNOW if they are a carrier)
Not to mention the absolute abyss of useless care that is physical therapy. The same cookie cutter treatment plans are assigned to every patient. Any PTs that have real skill and interest in curing their patients (as opposed to symptom management for geriatric care, which is a huge majority of the market) don't accept insurance. I've been given almost the exact same home care program by 5 different PTs despite me describing what I've tried and didn't see results from, and I'm pretty sure it's because that's what their insurance allows them to prescribe. God forbid they try to dig in at the individual, underlying issues with a novel treatment plan that could open their practice up to liability issues.
This is the hard part... I would say my current company does a poor job, and every other company I've worked for has also done a poor job. They've treated it like an internal playground for devs to validate that their features work, not a representative copy of prod with all the scaling problems and user-data funkiness that come with it. Here are some options I see:
- load a replica of your prod DB to stage daily/weekly and have all the same ETL jobs running
- setup load testing or user behavior regression tests to automatically go through critical pathways like user authentication and registration ("bare essentials" functionality, since writing these is tedious). This might be a good chance to use traffic-capture to at least get started/make setting up these behavior tests easier
- if it's a consumer-facing product, have employees dogfood the product on stage
- if it's a product for businesses, run your business off the stage or a 3rd slightly more stable "internal" environment to create some consequences for not keeping it running smoothly.
My experiences have not had representative load on stage, so the extra billing is proportionally smaller (since you're paying what you use in most cases). I don't know the billing specifics, but you can also consider dropping the log/metric retention window significantly on stage (say 1mo instead of 6mos) to save costs.
Ultimately I don't think you're going to get the same scaling problems to manifest on stage. It's more of a functionality testing ground IME.
I have 3 YOE as a dev so don't base your whole business plan on my ideas
We have all our staging systems report to DD and Sentry, tagged with an `env:stage/prod/whatever` tag to slice the metrics by. This helps maintain parity for alerting too (although pagerduty is not enabled for stage. Sometimes it's tough to get right because the lower volume of traffic on stage makes the alert metric queries very noisy. For example, alerts that fire for error rates may not resolve if no new successful requests come in for a few hours on stage.
I could be totally wrong here.