{"path":"research/corpus-graph/graphrag-cost-benefit.md","content":"# GraphRAG for the corpus graph: what it would cost and what it would give\n\n**Date**: 2026-10-11 · **Type**: a cost-benefit analysis, with one new measurement of our own, prices\nworked out from recorded figures, and outside sources read at the depth stated at the end ·\n**Status**: Claude's analysis and recommendation. Nothing here is ruled, nothing was built, and no\nmoney was spent.\n\n**His words**: *\"Cost benefit analysis of implementing GraphRAG for our corpus graph please.\"* The\nearlier question, the day the corpus graph was begun: *\"Sort of like GraphRAG, I guess. Is this\nfeasible?\"* ([README.md](README.md), top).\n\n---\n\n## 0. The short answer\n\n**Do not build it. The reason is no longer the price.** A first build over all 411 notes would cost\nabout three to seven dollars at list price on the small model that came out this week, where earlier\nestimates for the same kind of work ran to hundreds. What decides it is what the method gives:\n\n1. **For finding what bears on a note it gives nothing over search.** Measured five ways on our own\n   test, the fifth today: a graph of the terms the notes share, which is what GraphRAG's cheap method\n   builds, puts 19 to 24 of the 57 bearing notes in its first 84. Search puts 25 there, and chance 15.\n2. **What only it offers is a written summary of each group of notes, and answers put together from\n   those summaries.** In this corpus a summary is the risky object. The notes hold claims beside their\n   later corrections, and a summary states both in the present tense with no date and no author. It\n   also drops the rare item first, which this project has measured in summarisers and names as a\n   standing danger.\n3. **The saving those summaries exist for has shrunk to cents.** They spare a model from reading the\n   sources again for each question. The whole corpus can now be read once by the small model for about\n   forty cents at list price.\n\nTwo cheaper things would give most of what is worth having: a map of themes made by code from the\nconnections already kept, and a way to put one question to the whole corpus by reading it. Both are\nproposals (§ 7).\n\n---\n\n## 1. What GraphRAG is\n\nA method from Microsoft Research (Edge and others, 2024) for answering questions over a collection\nof texts. It comes in three forms.\n\n| Form | How the graph is made | Where a model is used | State |\n|---|---|---|---|\n| **Standard** | a model reads every piece of text and writes down the named things in it, how they relate, and a description of each; descriptions of one thing from many texts are merged into one | every piece of text, every thing named more than once, every group | in the open library |\n| **Fast** | no model: the noun phrases a text uses, tied when two appear in the same short piece | only to write a report on each group | in the open library |\n| **Lazy** | as fast | none until a question is asked; then a model tests pieces of text for relevance, within a set budget | not in the open library; offered inside two Microsoft products |\n\nIn every form the things are then grouped by how densely they are tied, at several levels, and (in\nthe first two forms) a model writes a **report on each group**. A question about the whole\ncollection is answered by putting it to every report and merging the answers. A question about one\nthing is answered from that thing's neighbours in the graph.\n\n**The state of the tool.** Its own front page now says the project *\"is largely in maintenance mode,\nand won't be accepting new PRs or implementing new features\"*, giving as the reason that models have\nchanged since its release. The lazy form, which its makers presented in 2024 as costing a\nthousandth as much to index, was still not in the open library in July 2026 by one outside check of\nthe code.\n\n## 2. What it would cost here\n\n**The corpus today**: 411 notes, 1.62 million words, 11.1 million bytes. That is between 2.8 and 4.1\nmillion tokens, depending on the model that counts them.\n\n**A first build.** Worked out from a published model of the standard method's calls (one extraction\ncall and one follow-up for each piece of text, a merging call for each thing named more than once, a\nreport for each group). For each million tokens of source it comes to about 6.5 to 10.6 million\ntokens read and 1.1 to 1.2 million written, in 3,900 to 6,200 calls. Microsoft's own page puts the\nextraction at about three quarters of the whole. Prices are the list prices recorded in\n[haiku-5-5-for-the-filling.md](haiku-5-5-for-the-filling.md).\n\n| | Calls | Tokens read | Tokens written | List price |\n|---|---|---|---|---|\n| Standard, on Haiku 5.5 | 11,000 to 25,000 | 18 to 44 million | 3 to 5 million | **$3 to $7** |\n| Standard, on Sonnet 5.5 | the same | the same | the same | $70 to $135 |\n| Fast, on Haiku 5.5 (reports only) | 600 to 800 | about 2 million | about 0.6 million | under $1 |\n\nOne measured run for comparison, from a practitioner in 2024: two million tokens, an hour, $6.50.\nThe estimates made on 9 October for loading the same corpus into the fact graph the keeper already\nruns were $37 to $49 on Haiku 5.5 (a helper's) and $160 to $300 on an older small model (Claude's).\n\n**Who would pay.** The method calls a model through a provider's programming interface with a key.\nThe subscription that runs our readers is not such an interface, so the build would be paid from\nthe founder's prepaid account, which is his to grant. (Which providers the current version accepts\nwas not checked.) A loop of our own over the command-line tool would cost no money and take, at\nseveral seconds a call, between half a day and three days.\n\n**Keeping it up.** In the seven days to today 111 notes were added and 103 of the 297 older ones were\nchanged. Unchanged text is answered from a cache, so the money is cents. The cost is elsewhere:\nevery changed note changes the things extracted from it, the merged descriptions of those things,\nthe groups, and the reports on the groups. The maintainers have said they do not plan to invest in\nhandling edited or deleted texts, and recommend removing and indexing again.\n\n**A question.** One question to the whole collection reads every report at one level: for 150\nreports, about 41 calls and 142,000 tokens, which is about two cents on Haiku 5.5 and forty cents on\nSonnet 5.5.\n\n**The costs that are not money**, which are the larger ones:\n\n- **A second store that cannot be rebuilt the same.** The index today is derived from the files in a\n  second or two with no model, so it can be thrown away at will and cannot drift from the notes\n  ([README.md](README.md) § 2). A graph a model wrote comes out differently each time it is made.\n- **Statements lose their date and their author.** The standard method merges what every note says\n  about a thing into one description. This corpus has about 80 commits marked as corrections and many\n  dated warning lines, because what was said in April about a part of the system is often no longer\n  so. A merged description holds the April sentence and the October one together. The failure the\n  corpus graph was built against was a session acting on a statement that a ruling had replaced.\n- **A summary drops the rare item first.** Measured for key-point systems and for models summarising\n  long debates, and named in this project's standing list of dangers. A report on a group is a\n  summary of merged descriptions, and an answer is a summary of reports.\n- **No passage to check.** Our readers must quote the words and the line, and a script refuses a\n  finding whose words are not in the file. A report cites the things it was written from.\n- **It is the machinery he wanted to avoid.** His question set the graph apart from a store that\n  takes every sentence as a fact. Extraction of named things and their relations from prose is that.\n\n## 3. What it would give here\n\n**Finding what bears on a note: nothing over search, measured.** The test is the one this tool was\nbuilt on: six notes that a week's proposals came from, and the 57 other notes that readers found to\nbear on them. Each method ranks every other note, and the count is how many of the 57 are in its\nfirst 84, the number a reader of the search results had to open.\n\n| Method | Of the 57, in the first 84 |\n|---|---|\n| chance | 15 |\n| search by meaning, passage by passage | 25 |\n| a walk over links, ledger references and shared commits | 23 |\n| notes that cite the same things | 20 |\n| nearest in meaning, whole note against whole note | 20 |\n| those merged | 24 |\n| one reader with a one-line card for each note | 16 (it named 59 notes) |\n| **terms shared with the six, rare terms counting more** (today) | **20** |\n| **the same, names only** (today) | **19** |\n| **a walk over notes and the terms they use** (today) | **22 to 24** |\n\nThe three rows marked today are the graph the fast and lazy forms build: 67,000 terms taken by rule\nfrom the notes (names, hyphenated compounds, short phrases), with no model. *Written before the\nrun: each ranking holds 18 to 26 of the 57, and at most 12 of the 40 bearing notes that have no link\nto or from the six. Both held (19 to 24; 7 to 12).* The terms are taken by rule and not by the\ntagger the method uses, so this approximates its graph. The standard form's graph is cleaner than\nthis one, since a model merges two names for one thing. It was not tested, and the reason to expect\nlittle from it is what the 40 are: notes tied to the six by a likeness of pattern, with no name in\ncommon. The nearest measurement is the card test, where a model's own restatement of a passage\nshared a name with its partner's in 23 pairs of 67 ([README.md](README.md) § 18.6).\n\n**Joining two notes through a named thing: a real gain elsewhere, small here.** On questions that\nneed two passages joined, a graph method scored 53.4 against 42.9 for plain retrieval in a large\nindependent benchmark, and that method was not Microsoft's. On questions one passage answers\nthe two tie, and Microsoft's own method lost by a wide margin on one set (38.6 against 64.7). Here a\nnamed thing is already found by a search for its name, and the tool lists every place that names a\nnote or a ledger row.\n\n**Answers to questions about the whole corpus: the one thing only this method aims at.** In its\nmakers' tests the answers from group reports were preferred to those of plain retrieval in 72 to 83\ncomparisons of 100, for covering more. The judge was a model and the questions were written by a\nmodel. Two later studies found that with reference answers plain retrieval covers as much, that\nswapping the order of the two answers flips the judge, and that the gains *\"become much more\nmoderate or even vanish\"* once order and length are controlled. And every system of this family\nanswers a question somebody posed. The founder's aim for the read-throughs is what nobody asked.\n\n**A map of themes that can be browsed.** Real, and the part worth having. It does not need the\nmethod (§ 7).\n\n## 4. The premise that has changed\n\nThe reports exist so that a question does not have to be put to the sources themselves. The makers'\nfigure is that the top-level reports use over 97 in 100 fewer tokens than doing so.\n\nAt this corpus's size and this week's prices, reading the sources costs this: 4.1 million tokens, in\nmessages kept under 100,000 tokens each, is about **41 cents** at Haiku 5.5's list price, and about\n4 cents when read again from the cache. So the saving is some tens of cents a question, and what is\ngiven up for it is the passage itself.\n\nThis is arithmetic from recorded prices. How well a small model answers a question from forty\nmessages of raw notes is not measured here. What is measured: in this week's pilot every passage the\nsmall model quoted stood at its line, and it found things the larger model did not\n([haiku-5-5-for-the-filling.md](haiku-5-5-for-the-filling.md) § 6). Outside, a model given a whole\ncollection of about 93,000 tokens covered as many of its planted insights as people did, and was\nfar worse than people at saying which document each came from. A script that checks quoted words\nagainst the file answers the second half.\n\n## 5. The options side by side\n\n| Option | Cost | What it gives | Main risk |\n|---|---|---|---|\n| **As now**: keep what readers find, deliver it when a note is opened | readers on the subscription: 290,000 to 440,000 tokens for each batch of four notes | findings with checked quotes; the only thing measured to find unexpected connections | slow to cover 411 notes |\n| **A map of themes by code** (§ 7) | an afternoon, no model, rebuilt in seconds | groups of notes, the notes that stand apart, the pairs of groups no reader has read together | groups that reflect where readers went and not what the corpus holds |\n| **One question to the whole corpus by reading** (§ 7) | about 4 million tokens of the small model for each question | passages quoted from every note that bears on a question, with nothing summarised beforehand | untested; a reader of 100,000 tokens misses things |\n| **GraphRAG, fast form** | under $1 to build, cents a question, a key | reports on groups of shared terms; answers from reports | a noisy graph (Microsoft's own word); summaries with no dates |\n| **GraphRAG, standard form** | $3 to $7 on the small model, 11,000 to 25,000 calls, a key; a store to keep up | named things with merged descriptions; reports; answers from reports | dated statements merged; the rare item dropped; a second store that drifts |\n\n## 6. Recommendation, and what would change it\n\n**Neither form of GraphRAG.** The standard form gives a fact graph, which he asked not to have, and\nsummaries of a corpus whose value is in what was corrected and when. The fast form's graph was\nmeasured today and finds what search finds.\n\nIt would be worth asking again if:\n\n- a kind of question about the whole corpus keeps failing when the notes are read for it;\n- a graph of named things, built on a sample by a model, puts 35 or more of the 57 in its first 84,\n  which would cost about a dollar to learn;\n- the lazy form is released, since it keeps no summaries and spends only when asked.\n\n## 7. Two things proposed in its place\n\n**A map of themes, by code.** Group the notes by the connections kept between them (about 740) and\nthe links they write, with no model. Out of it: the groups, the notes tied to nothing, and the\npairs of groups that no reader has been sent through together, which is where the next unexpected\nconnection is likeliest. It serves the planning of read-throughs and can be handed to a reader\nbefore it reads, which the research on whole-corpus reading recommends. To be tested before it is\ntrusted, with the prediction written first: hold back the most recent findings and see whether the\ngroups say where they fell. A written line for each group is a later question, and would be marked\nas a machine's and kept for finding one's way only.\n\n**One question put to the whole corpus by reading.** A script that hands the notes to the small\nmodel in batches under 100,000 tokens with one question, asks for the passages that bear on it with\ntheir lines, checks every quote by code, and gathers them. The first trial would use a question\nwhose answer is already on file: his *\"Haven't we thought a lot about unwritten premises?\"*, which\na session answered by hand on 7 October. That gives a count of how much of a known answer comes\nback. About 4 million tokens of the small model on the subscription, and no money.\n\nBoth are his to say. Neither is filed as work yet beyond a line in `TODO.md`.\n\n---\n\n## Read depth\n\n- **Microsoft's front page for the project and its page on indexing methods**: read as fetched, in\n  full. The maintenance notice, the three quarters, and the description of the fast form are from\n  them.\n- **The model of calls and tokens** (a chapter of an online book on the method) and **the\n  practitioner's measured run**: as long excerpts returned by a search. The figures for this corpus\n  are Claude's arithmetic on that model and on the recorded prices; nothing was run.\n- **Whether the lazy form is released**: one outside author's dated check of the code, as an excerpt.\n  Not checked against the code by Claude.\n- **The benchmark figures, the critiques of the makers' tests, and the 97 in 100**: from two\n  helpers' reports kept in this folder,\n  [graph-retrieval-measured-gotchas-as-a-helper-read-it.md](graph-retrieval-measured-gotchas-as-a-helper-read-it.md)\n  and [reading-for-insight/whole-corpus-insight-as-a-helper-read-it.md](reading-for-insight/whole-corpus-insight-as-a-helper-read-it.md),\n  each of which marks how deeply it read every source. Claude opened none of those papers.\n- **The term test**: `term_graph_test.py` in the keeper's test folder of 2026-10-08, beside the\n  earlier ranking tests; what it printed is in\n  [what-the-term-graph-printed.txt](what-the-term-graph-printed.txt).\n\n## See also\n\n[README.md](README.md) § 1 to § 8 (why the index is what it is) and § 18.14 (the take before this\nnote) · [reading-for-every-kind-of-insight.md](reading-for-every-kind-of-insight.md) § 10, point 12\n(themes from the index) · [../the-residual-error-taxonomy.md](../the-residual-error-taxonomy.md)\n(what a summary cannot hold) · [../saturation-and-the-long-tail.md](../saturation-and-the-long-tail.md)\n§ 3b (the rare item) · [../structure-versus-scale.md](../structure-versus-scale.md) (the same\nbenchmark, read for the claim graph).\n"}