A ok got it, the next token is sampled from a deterministic probability distribution, hence the random output. But why not get the token with the highest probability/weight? Is this to avoid some local minima?
There was a very fun debate on this, summarised nicely here[1]. Two parties took opposing positions on lab leak theory, with 2 independent expert judges (accepted by both participants). Loser had to pay the winner 100K USD
I am saying that a government,and any other system, operating in an environment of abundance without external pressures to improve, ends up accumulating year's of cruft, inneficiencies, unproductive bureaucracies and 4-eye principles everywhere .
Sometimes a system needs a good shock to improve. And at the end of the day, what is the absolute worst that can happen? Cause the upside of this working is definitely worth the risk in my eyes.
Well,it didn't say anywhere that they are stopping grandma's checks. And if the system is so fragile that grandma will die before getting some human person to resolve her case, then we've got bigger problems than a 25 year old having r/w on the system.
Having a young optimistic uncynical person, untainted by years of painful lessons and bitterness, attempt to fix these systems with raw speed and brute urgency, might be the exact shock a system like the public sector needs.
People complain about Facebook's move fast and break things philosophy whenever something bad happens, completely ignoring the fact that they are a trillion dollar corporation that 20 years ago did not exist.
Sometime you just have to get rid of the guardrails and YOLO it
interesting perspective. Care to elaborate a bit more? Where you in the design department? Why did they put up chinese walls? Was it to enable the foundry to have other customers other than Intel designs? Why did you have similar type of equipment? Were you also manufacturing chipsets? If so, why didn't they expand your division to become a foundry?
4. If it is personal data, you have to know where they came from, where they are stored and why. If you don't want to do that, then invest the minimal effort it takes to anonymize them during ingestion and then you can do whatever you want with them.
5. Now that is just false, or you have some really bad architects, if you are so sensitive to new legal interpretation (which there haven't been any significant ones)
Their rocket is closest to capabilities to a falcon-heavy [1], but to get to the space-x level, they need to demonstrate reusability, turn around times, and the ability to produce second stages once every 2&3 days, whilst maintaining an operational lunch tempo of 1 lunch every 2 days [2]
Elon had a great year.Him weaponizing Twitter to go all-in on Trump has earned him so much political capital that those perky 50billion he paid for it look like a still now. I bet Zuck is feeling the heat, now with the government gunning for TikTok and looking at monopolies
Private insurance can and generally withstands large calamities (known as natcat losses) without government intervention via the utilisation of global reinsurance organizations. Especially for earthquake, a properly reinsured insurance can cover a large earthquake loss about once every 15-20years
No this is general insurance (motor, property, travel etc). It is also founder-led, which is an important factor, as the reason they started it was their personal frustration with the motor insurances.
Scale-up means youngish (10-12years old), mid-size in the countries we are operating, think 3 countries 600-800m revenue.
Fraudulent claims are a tiny percentage of claims, and are rejected after human review, usually involving detectives. In the countries we operate, fraudulent claims are about 6-8% of all claims, and that's usually the level we aim to detect. Being able to absorb some false negatives is usually cheaper than going for the full 100% detection rate. It is definitely more customer oriented than rejecting due to false positives.
I don't understand the comments excusing the CEO of his responsibility. I work for a scale-up insurance company, and the CEOs are pretty clear with their mandate: customer service is paramount, we make money by streamlining our processes, negotiating hard with our network, and pricing properly our products. NOT by denying claims. This philosophy is enforced from the top all the way down, with Chinese walls between pricing and claims handling, proper training, and continuous NPS surveys
That's for people outside the Scrum team, meaning that no external stakeholder may manipulate the backlog by bypassing the POs.
Internally the team must act as a cohesive unit, which means that a Scrum dev should have the same objectives as a PO, with regards to both priorities and goals. That may mean adding items in the backlog pertaining to technical debt, and so forth
FTA
>T-Mobile contradicted that clear promise on a separate FAQ page, which said the only real guarantee was that T-Mobile would pay your final month's bill if the company raised the price and you decided to cancel
Same here. After doing Java the entire first year, the second year we did a 6-hour course for C, and then had to write a ram-disk for a toy Linux operating system. We had to write the code, compile, boot in the new system, run a specific test suite, and repeat till the test passed. I am still not sure how we got the tests to pass, but I remember praying to the computer gods at one point, as well as a bunch of boot&hope development.
I' ve done 2 large software migrations in my life, here are my findings:
1. If you can't do gradual deployment, try to do a primary-secondary (master/slave) type of deployment where new system runs in read-only mode (mirroring old system data) for a while.
2. Whatever you budgeted for migrating data, double it. Set a data cleansing specialist to start working on the data-to-be migrated ASAP.
3. Document all processes of the current system. Have the painful conversations up-front about functionality that will be eliminated, migrating usually means eliminating a bunch of features that do not pass the cost/benefit threshold. Your users/stakeholders might not see it that way, make it explicit what the cost of those features is, get as much buy-in as possible
But there is so much context that the LLM has no access to. Implicit assumptions in the system, undocumented workflows, hard edge cases, acceptable bugs and workarounds, Peter principle boundaries, etc... All these trade-offs need someone that understands the entire business domain, the imperfect users, the system' implementation and invariants, the company's politics and so much more. I have never encountered a single programmer, no matter intelligence and seniority, that could be onboarded on a project simply by looking at the code.
That's because we've been here before. Be it the ERPs of the 90s-00s, the low/no-codes of the 2010s, the SaaS and the chatbots of 2015. There was always hype about automating the job. At the end of the day, most of a programmer's job is understanding the business domain, it's differences and edge cases, and translating those into code. An LLM can do the latter part, the same way a compiler can do high-level java into assembly