Turns out that under certain conditions, such as severe exhaustion, that "sus filter" just... doesn't turn on quickly enough. The aim of passkeys is to ensure that it _cannot_ happen, no matter how exhausted/stressed/etc someone is. I'm not familiar enough with passkeys to pass judgement on them, but I do think there's a real problem they're trying to solve.
If you're saying something is less secure because the users might suffer from "severe exhaustion", then I know that there aren't any proper arguments for migrating to it. Thanks for confirming I can continue using OTP without feeling like I might be missing something :)
Yeah, but they genuinely also prevent you from moving away from companies in the process of enshittification, since the whole export/import thing seemingly hasn't been figured out or even less been deployed yet.
Besides, if you ignore security alarm-bells going off when exhausted, I'm not sure what solution can 100% protect you.
That matches my experience, in an admittedly slightly older car. Note that you'll rarely be charging over 80% because it's just too slow, and going under 5-10% is a bit too stressful, so practical range is probably 70-75% of maximum on longer trips. Less if it's winter and/or the AC is running.
If I could rely on every Rasthof having multiple functional EV chargers, I think range anxiety would be far, far less of an issue for me, but as of now it's something that I do think about for longer trips, and do have to plan for.
Of course you start the trip off at 100%, but the point is that charging speed varies substantially based on the SoC in the battery. So if you deplete most of your charge and need to stop, recharging to 80% takes substantially less time than topping it off to 100%. So if your battery range is 300 miles, you might get 280 on the first leg of your trip but will only be able to do maybe 220 on the second leg.
I have a PHEV specifically so I can take an occasional 500-600 mile trip without range anxiety. With the ICE, I can almost do the trip without a pit stop. But I make a stop. So it seems that ICE or EV both have to make one stop for a 500 mile journey. Of course, the ICE could make a 1000 mile journey with two stops where your EV would need three. But I make a 1000 mile journey in a single day less than once a year. So 10 extra pit stops in 10 years doesn't seem like a bad trade-off for the 4 or 5 fill-ups I skip every month.
> Of course, the ICE could make a 1000 mile journey with two stops where your EV would need three.
It sadly doesn't work like that. Range is reduced by about 25% in the cold. Further, one doesn't charge 0-100% at stations. They charge 10-80%. This is suggested by Tesla because the last 20% takes longer than the first 70%. So the effective range on a new standard range Tesla Model Y is 455 * 0.75 * 0.7 = 239km between stops. Assuming Tesla's 455km initial estimate is accurate, and it's not really. It tends to overestimate, so in reality, it's less than 239km. Especially at highway speeds.
A 1,000 mile journey would require approximately 7-8 stops, depending on charge at journey start and end.
Answered different thread - superchargers get from 5-10% to 95-100% in line 30 minutes.
When we are on roadtrips I often have to go and unplug it so I don't get extra charges for idle. I know superchargers are not everywhere.
Thats… not obvious at all. Unless you’re within the super small part of society that can charge at home, you might be as well starting with 20 or 30% - exactly the same as with a regular car.
Right, but that’s just a single, very un-typical country. Most people in developed countries live in cities. If you live in a city - you live in an apartment (unless you’re quite wealthy)z
I expect that most people living in NYC do not have a single family house with a garage and a garden.
It is not at all an un-typical country. It might even be the case for the majority of the US, most of which live outside New York City.
Plus, cities in countries over on this side of the pond provide street charging and even have legislation about maximum distance to a charger. Parking garages and lots also provide charging. Not as convenient as living in a house with a charger where you can always plug in at night (and possibly use private solar cells for extra benefit), but good enough for most commuting.
I had a road trip, and pretty much all the time I got 95-100% charge while having lunch with supercharges, which are everywhere. It takes 30 minutes to do it.
* In the big cities, increased rents will almost immediately eat up the extra income from the UBI, and there won't be any meaningful change in the status quo for anyone who rents — which I imagine includes the majority of the people who do the important but undesirable jobs.
* Anywhere that the people doing these jobs either can afford houses (smaller American towns, e.g.), or where there's enough rental supply that rent won't immediately go up by the same amount as the UBI, will have to start paying people more to do these jobs. As far as I understand it, jobs like trash collection are already relatively well-paid given the training and qualifications required, so they might not even have to pay that much more.
Most people who prefer DW would say that D&D sometimes has clear rules for something, but often has no rules, boring rules, or rules that aren't necessarily "fun". Combat, while tactical, tends to be slow and can frequently consume a lot of time in a session, plus the majority of rules and character powers are focused on combat.
If you're playing sessions with a lot of RP, DW will have a much better balance of rules:session-time, it's much easier to prep for, and given how rules-lite D&D really is outside combat, will probably have about the same amount of narrative input. Note that it's not necessarily the "group debating if the player survived", but typically the GM giving the player a choice when they fail to climb the wall, like "you fall and take a little damage, or you slip a little, cursing loudly and alerting the enemies at the top to you".
Done well, it gives the players a lot more agency, and much better buy-in for the story as they're now shaping it, instead of just being along for the ride. I would also say that pre-written narratives aren't really a thing for DW (at least, as far as I know!), so it's really down to what the DM sees as an appropriate penalty or choice, often phrased as "you succeed, but <thing>".
It's not really better or worse than D&D overall, I'd just say that it's much better suited for certain play-styles. If you enjoy tactical gameplay and using miniatures, then D&D (or maybe Pathfinder) are much better options. If the thought of yet another fight makes you want to gouge your eyes out, I'd recommend giving DW a try.
The player choices and handling of partial success in PBtA games (like dungeon world) really makes them sing. A partial success leads to adding complications, which creates really interesting situations.
The original Apocalypse World book has some really great ideas on how to run a campaign, as well - very worth reading for anyone who runs ttrpgs.
I had played enough TTRPGs at that point that when I encountered Apocalypse World that I found the advice to generally just be common knowledge. But if you're new to TTRPGs I highly recommend it for good advice even when running traditional TTRPGs.
So here's something I've been wanting to do for a while, but have kinda been struggling to figure out _how_ to do it. txtai looks like it has all the tools necessary to do the job, I'm just not sure which tool(s), and how I'd use them.
Basically, I'd like to be able to take PDFs of, say, D&D books, extract that data (this step is, at least, something I can already do), and load it into an LLM to be able to ask questions like:
* What does the feat "Sentinel" do?
* Who is Elminster?
* Which God(s) do Elves worship in Faerûn?
* Where I can I find the spell "Crusader's Mantle"?
And so on. Given this data is all under copyright, I'd probably have to stick to using a local LLM to avoid problems. And, while I wouldn't expect it to have good answers to all (or possibly any!) of those questions, I'd nevertheless love to be able to give it a try.
I'm just not sure where to start - I think I'd want to fine-tune an existing model since this is all natural language content, but I get a bit lost after that. Do I need to pre-process the content to add extra information that I can't fetch relatively automatically. e.g., page numbers are simple to add in, but would I need to mark out things like chapter/section headings, or in-character vs out-of-character text? Do I need to add all the content in as a series of questions and answers, like "What information is on page 52 of the Player's Handbook? => <text of page>"?
Fine tune will bias something to return specific answers. It's great for tone and classification. It's terrible for information. If you get info out of it, it's because it's a consistent hallucination.
Embeddings will turn the whole thing into a bunch of numbers. So something like Sentinel will probably match with similar feats. Embeddings are perfect for searching. You can convert images and sound to these numbers too.
But these numbers can't be stored in any regular DB. Most of the time it's somewhere in memory, then thrown out. I haven't looked deep into txtai but it looks like what it does. This is okay, but it's a little slow and wasteful as you're running the embeddings each time. So that's what vector DBs are for. But unless you're running this at scale where every cent adds up, you don't really need one.
As for preprocessing, many embedding models are already good enough. I'd say try it first, try different models, then tweak as needed. Generally proprietary models do better than open source, but there's likely an open source one designed for game books, which would do best on an unprocessed D&D book.
However it's likely to be poor at matching pages afaik, unless you attach that info.
RAG sounds sophisticated but it's actually quite simple. For each question, a database (vector database, keyword, relational etc) is first searched. The top n results are then inserted into a prompt and that is what is run with the LLM.
Before fine-tuning, I'd try that out first. I'm planning to have another example notebook out soon building on this.
Ah, that's very helpful, thanks! I'll have a dig into this at some point relatively soon.
An example of how I might provide references with page numbers or chapter names would be great (even if this means a more complex text-extraction pipeline). As would examples showing anything I can do to indicate differences that are obvious to me but that an LLM would be unlikely to pick up, such as the previously mentioned in-character vs out-of-character distinction. This is mostly relevant for asking questions about the setting, where in-character information might be suspect ("unreliable narrator"), while out-of-character information is generally fully accurate.
Tangentially, is this something that I could reasonably experiment with without a GPU? While I do have a 4090, it's in my Windows gaming machine, which isn't really set up for AI/LLM/etc development.
Will do, I'll have the new notebooks published within the next couple weeks.
In terms of a no GPU setup, yes it's possible but it will be slow. As long as you're OK with slow response times, then it will eventually come back with answers.
Thanks, I'd really appreciate it! The blog post you linked earlier was what finally made RAG "click" for me, making it very clear how it works, at least for the relatively simple tasks I want to do.
All the people saying "don't use fine-tuning" don't realize that most of traditional fine-tuning's issues are due to modifying all of the weights in your model, which causes catastrophic forgetting
There's tons of parameter efficient fine-tuning methods, i.e. lora, "soft prompts", ReFt, etc which are actually good to use alongside RAG and will likely supercharge your solution compared to "simply using RAG". The fewer parameters you modify, the more knowledge is "preserved".
Also, look into the Graph-RAG/Semantic Graph stuff in txtai. As usual, David (author of txtai) was implementing code for things that the market only just now cares about years ago.
For now it still uses openai for embeddings generation by default and we are updating that in the next couple of releases to be able to use a local model for embedding generation before writing to a vector db.
Disclosure: I'm the maintainer of LLMStack project
I did something similar to this using RAG except for Vampire rather than D&D. It wasn't overwhelmingly difficult, but I found that the system was quite sensitive to how I chunked up the books. Just letting an automated system prepare the PDFs for me gave very poor results all around. I had to ensure that individual chunks had logical start/end positions, that tables weren't cut off, and so on.
I wouldn't fine-tune, that's too much cost/effort.
Yeah, that's about what I'd expected (and WoD books would be a priority for me to index). Another commentator mentioned that Knowledge Graphs might be useful for dealing with the limitations imposed by RAG (e.g., have to limit results because context window is relatively small), which might be worth looking into as well. That said, properly preparing this data for a KG, ontologies and all, might be too much work.
RAG is all you need*. This is a pretty DIY setup, but I use a private instance of Dify for this. I have a private Git repository where I commit my "knowledge", a Git hook syncs the changes with the Dify knowledge API, and then I use the Dify API/chat for querying.
*it would probably be better to add a knowledge graph as an extra step, which first tells the system where to search. RAG by itself is pretty bad at summarizing and combining many different docs due to the limited LLM context sizes, and I find that many questions require this global overview. A knowledge graph or other form of index/meta-layer probably solves that.
From a quick search, it seems like Knowledge Graphs are particularly new, even by AI standards, so it's harder to get one up off the ground if you haven't been following AI extremely closely. Is that accurate, or is it just the integration points with AI that are new?
First I would calculate the number of tokens you actually need. If its less than 32k there are plenty of ways to pull this off without RAG. If more (millions), you should understand RAG is an approximation technique and results may not be as high quality. If wayyyy more (billions), you might actually want to finetune
Fine-tuning is almost certainly the wrong way to go about this. It's not a good way of adding small amounts of new knowledge to a model because the existing knowledge tends to overwhelm anything you attempt to add in the fine-tuning steps.
Look into different RAG and tool usage mechanisms instead. You might even be able to get good results from dumping large amounts of information into a long context model like Gemini Flash.
No fine-tuning is necessary. You can use something reasonably good at RAG that's small enough to run locally like the Command-R model run by Ollama and a small embedding model like Nomic. There are dozens of simple interfaces that will let you import files to create a RAG knowledgebase to interact with as you describe, AnythingLLM is a popular one. Just point it at your locally-running LLM or tell them to download one using the interface. Behind the scenes they store everything in LanceDB or similar and perform the searching for you when you submit a prompt in the simple chat interface.
Very easy to do with Milvus and LangChain. I built a private slack bot that takes PDFs, chunks it into Milvus using PyMuPDF, the uses LangChain for recall, its surprising good for what your describe and took maybe 2 hours to build and run locally.
From my limited experience, Staff+ seems to have a lot of the same responsibilities as a manager, but without the direct reports—they're both “leadership” positions and focus on long(er)-term planning, business needs, cross-team communication, and enabling others rather than doing the work themselves. Though in lieu of people management, Staff+ engineers do get to spend some time coding, but it's pretty rarely the majority of their job.
So to that extent, I think there's quite a lot in common between engineering and management tracks after a certain point, both because there's a genuine need for that, and because direct code contributions just don't scale in the same way that helping others does.
I think you can set it to be the other way around and have it be "never mark as spam when via team@example.com" - of course, depending on how much spam it gets that might be worse.
That... pretty much already exists, in the form of Home Assistant + Zigbee and/or Thread? Though that's still wireless, and I haven't seen any focus on trying to connect everything with wires (not something I'd be keen on, personally, I'm quite happy with the wireless protocols).
Turns out that under certain conditions, such as severe exhaustion, that "sus filter" just... doesn't turn on quickly enough. The aim of passkeys is to ensure that it _cannot_ happen, no matter how exhausted/stressed/etc someone is. I'm not familiar enough with passkeys to pass judgement on them, but I do think there's a real problem they're trying to solve.
reply