Asking for beta at the gym: moves, foot placements and demonstrations
Ask about a completed move with How did you do this move?, request a demonstration with Can you show me how to do it?, and offer advice with Do you want beta?
learning
345 postsTalking with Colleagues About Health and Lunch: Keep an Everyday Conversation Going
Use I have a cold for the illness, and distinguish a sore throat from losing your voice. Start lunch talk with today's meal, then ask about habits; bringing food from home does not tell you who cooked it.
Questions at a new surf spot: waves, the paddle-out and currents
Ask separate questions about waves, water temperature, the paddle-out and currents; a language exchange does not establish whether conditions are suitable for you.
English when travel goes wrong: flight delays, the next flight and a lost bag
Use is delayed by for the length of a delay, When do you expect… for an estimated departure, and I think I left it on the plane to explain where your missing bag might be.
Chunking and Indexing: How Big to Cut, What to Search With, and How to Know You Chose Right
Building an index means three decisions: the chunking unit, whether to search with keywords, vectors or both, and which embedding model to use. All three are semi-permanent, since changing any of them means rebuilding. The research is cautious: semantic chunking isn't consistently better, splitting by sentences or by document structure is usually enough, and overlap has small, setup-dependent effects. In one Traditional Chinese study, the correct passage ranked first 57% of the time with vector search alone, keyword search 76%, and the two combined 81%. Don't choose by feel: compare two setups on order 11's test questions, changing one thing at a time.
Evaluation and Launch: How to Know Your AI Knowledge Base Works, and Keep It Improving
Evaluate in two layers: did retrieval find the source passage, and is the answer grounded in it and correct. Looking only at answers can fool you: one study found that when the context wasn't enough to answer, models still got 35% to 62% right using their own knowledge, which breaks on questions only your organization can answer. Use order 11's test questions for both layers, and evaluate permission-crossing and unanswerable questions too; calibrate LLM judges against human samples. After launch, turn escalated and complained-about conversations into failure cases, hand them back to document owners, and add them to the test set.
Structure and Metadata: Which Fields to Record Besides the Text
Metadata serves three purposes: returned for citation, used in search, and used to filter before retrieval; exact conditions like model, year or region belong in fields, and one study that wrote the company and year in front of every chunk raised top-five hits from 33% to 55%. Take filter values from source systems as fixed options, store dates as numbers, and don't let an LLM generate them freely.
Parsing and Cleaning: What Quietly Breaks When PDFs, Tables and Scans Become Text
When documents become text, what breaks usually doesn't throw an error: multi-column paragraphs joined in the wrong order, merged table cells flattened, headers and footers mixed into the body, OCR typos in scans, images and strikethroughs gone. High OCR accuracy doesn't mean good RAG either: in one study, documents with strikethroughs and color marks scored 82.9% on OCR but only 52.8% on question answering. Chunking matters more than switching tools: from the same conversion output, chunking by heading hierarchy with the heading path attached raised table questions from 66.6% to 99.8%. So always spot-check parsed output against the originals for these failure types.
Permissions: How to Make Sure the AI Doesn't Hand Department A's Documents to Department B
Filter permissions at retrieval time: each chunk carries the groups allowed to see it, each query carries the user's groups, and anything that doesn't match never becomes a candidate, rather than letting the model read it and then telling it not to say it. AI doesn't create new permissions, but it makes documents that were shared too widely findable with a single question, so clean up oversharing before launch. When permissions change, the index doesn't necessarily follow: some connectors update permissions only on full crawls, up to a day late. Filtering has a cost too: with strict conditions, some vector databases return too few results. Before launch, add a permission-crossing question to your test set.
Security: Can Documents in Your Knowledge Base Leak Personal Data or Give Orders to the AI?
Documents in a knowledge base may carry personal data or hidden instructions for the AI, and the latter has been demonstrated on Slack AI and Microsoft 365 Copilot. Telling the model to ignore them in the system prompt does little; it's safer to add personal-data and instruction gates at ingestion and limit what the model can do. No detection tool catches everything, so every layer only reduces the risk.
Inventorying Sources: Which Documents Belong in an AI Knowledge Base, and Which Version to Trust
Importing the whole shared drive is the most common way to start an AI knowledge base, and the most common mistake. When old and current versions are retrieved together, the model blends them: in one study, even with the current information retrieved, adding a single outdated passage cut the overall score by more than 24%. First build a source inventory recording each source's owner, update frequency, access restrictions and handling decision; collect only one workflow's well-governed sources in the first batch; and keep only the current version of each document, labeling any old version you must keep with its version and expiry date. After importing, check the file counts, because some connectors import nothing and report no error when they lack permissions.
Updates and Deletion: How an AI Knowledge Base Keeps Up When Documents Change or Disappear
When documents change or are deleted, the index doesn't keep up on its own. A sturdier incremental sync uses a content hash to find which documents changed and redoes only those; deletion has to reach every place a document is stored, including the full-text index and the vector store. Many tools don't handle deletion by default, and deletes and updates can take a while to take effect. Why clean up thoroughly: one preprint put a single outdated document into the context, and two small models flipped three to four in ten medical questions they had answered correctly; when told to answer from the documents, that rose to between two-thirds and three-quarters.
What's Different When AI Reads Your Knowledge Base: Write the Test Questions First
A wiki that people understand can still trip up an AI: what it sees is a few chunks cut out of the pages, without the navigation, heading hierarchy or surrounding text. So before building RAG, write a set of test questions: each with its answer and its source passage, plus a few deliberately unanswerable ones. Azure's RAG guide does this in parallel with content analysis; one study found that evaluating only with AI-generated questions overstated retrieval performance by 29 to 37 percentage points, so mix in real users' questions. If your knowledge base is under about 500 pages, you may not need RAG at all: put the whole thing in the prompt.
Building a Knowledge Base: Four Questions for Personal Notes, Team Wikis and AI Knowledge Bases
Personal notes, a team wiki and a knowledge base for AI differ in who reads them: your future self, your colleagues, a model. All three have to answer what to keep, how to organize it, how it gets found and who maintains it. Research on personal collections finds that most 'finding' is re-finding things you have already seen; research on enterprise wikis finds that once the person who tidied or wrote the content leaves, it starts to decay.
Choosing a Note Tool: Obsidian, Notion, and Whether Your Data Comes With You
Before choosing a note tool, ask five things: can other programs open its files, do links survive renaming, can you search and filter, does it sync across devices, and does it work offline. Obsidian's notes are just Markdown files in a folder on your computer, but syntax such as block references can't be followed outside Obsidian, and on iPhone only two sync methods are officially recommended. Notion's databases are powerful, but an export takes only one view, callouts become HTML, and an export can't simply be uploaded back to restore your workspace. Before switching tools, export once and open the result in another program.
Where to Put Things: PARA, Johnny.Decimal, and Whether to Use Folders at All
For files people create themselves, research keeps finding that most retrieval happens by clicking through folders, and better search tools haven't changed that much; few people use tags, and those who do mostly apply just one. So notes are worth organizing, but each note needs only one main home, the structure shouldn't get too deep, and folders shouldn't get too full. PARA sorts things by how close they are to your current work, Johnny.Decimal allows at most ten per level and fixes each item's place with a number; the numbers in both are their authors' experience, not experimental findings.
Writing for Colleagues: How-to Templates, Decision Records, and Writing Less
Getting team documents to look alike and make sense takes two templates and one principle. The principle is fewer but fresh: Google's documentation guide says a small set of fresh, accurate docs beats a large pile in disrepair, and if something exists elsewhere, link to it. The how-to template runs prerequisites, steps, how to confirm it worked, and whom to ask when it fails; in one study, installation instructions rewritten to a template scored better on eight of ten aspects readers rated. Architecture decision records (ADRs) note why a decision was made; when one is reversed, you don't delete it, you mark it superseded and link to the new decision. Research also finds ADRs are often tried and dropped, and that the "considered options" section is the most problematic, often missing or misplaced, so keep the template short and keep that section.
Information Architecture: Organizing a Team Wiki by Department or by Task, and How to Test It
A common team-wiki argument is whether to organize by department or by task. The research is more cautious than you might expect: employees who know the org chart were actually faster on an intranet organized by department, and label quality mattered far more than the organizing scheme. A safer approach: give the main structure a scheme where every page has an owner, then add a few task-based entry pages that hold only links, and title pages with the words readers will search for. Before organizing, use card sorting to learn how readers think; afterwards, use tree testing to check whether they can find things.
Maintenance: Who Owns It, How Often to Check It, and When to Delete It
Documentation going out of date is normal, and it throws no errors: eight in ten of GitHub's most popular projects have at some point left references in their docs to code that had been deleted. There are four ways to maintain docs: give every page a responsible role, set verification expiry, change the docs in the same change as the process, and fix pages when they're used. Each one fails in its own way: the owner leaves, expiry notices get treated as spam, the rule exists but nobody follows it, and articles nobody uses never get checked. The deletion principle: delete what's certainly wrong first, and archive what's correct but rarely used. By the end you'll be able to draw up a maintenance table for your team: document type, responsible role, review cycle, and deletion conditions.
Findability: Using Search Logs to Find the Gaps, and the AI That Has Started Reading Team Docs
When colleagues can't find something, it usually isn't missing: of 50 zero-result queries at one university library, only one in ten was for something it didn't have. Sort the gaps in three to six months of search logs into can't be found, doesn't exist and different words, and fix titles and synonyms first; AGENTS.md files for AI need the same care, since one evaluation found they didn't raise success rates overall while raising costs by about a fifth.