TL;DRTL;DR
- I built a dataset Q&A system and trusted a RAG answer that was less than half-correct.我构建了一个数据集问答系统，并相信了一个正确率不到一半的RAG答案。
- I measured this across 7 query types and 5 context sizes on 100,000 rows.我在10万行数据上，针对7种查询类型和5种上下文大小进行了测量。
The fix: route computation解决方案：分流计算 queries away from RAG entirely.解决方案：将计算查询完全从RAG中分流。
I Trusted the Wrong Number我信错了数字
Last month I was heads-down building a new feature for EmiTechLogic. Learners can now upload their own messy CSV files and ask questions in plain English about their data. Sounded perfect for RAG, so I went all in — embeddings, retrieval, nice-looking responses.上个月，我埋头为EmiTechLogic构建一个新功能。学习者现在可以上传自己杂乱的CSV文件，并用自然语言提问关于数据的问题。这听起来非常适合RAG，所以我全力以赴——嵌入、检索、漂亮的回答。
The first few demos looked amazing. Clean tables, confident numbers, professional formatting. I actually started trusting the system in our internal testing.最初的几个演示看起来很棒。清晰的表格、自信的数字、专业的格式。在内部测试中，我甚至开始信任这个系统。
Then I picked one number to double-check.然后我挑了一个数字去复核。
Real grocery spend in the dataset: $1,140,033.24. 数据集中真实的杂货支出：1,140,033.24美元。
The model gave me a beautiful breakdown by category. It looked legit. I added up the numbers it returned.模型给了我一个按类别划分的漂亮细分。看起来合理。我加总了它返回的数字。
It was less than half.结果不到一半。
I sat there staring at the screen thinking “this can’t be right.” So I did what any engineer would do. I increased the context window. 4k… 16k… 32k… 128k tokens. Each time the answer got longer, more detailed, and more confidently wrong.我坐在那里盯着屏幕，心想“这不可能是对的”。于是我做了任何工程师都会做的事：增大上下文窗口。4k… 16k… 32k… 128k tokens。每次答案都变得更长、更详细，也更自信地错误。
That’s when it finally clicked. This wasn’t a retrieval issue. I was asking a retrieval system to perform heavy computation on data it had only partially seen. And instead of saying it was unsure or missing information, the model was producing polished, structured answers that looked correct.那一刻我终于明白了。这不是检索问题。我是在让一个检索系统对仅部分看到的数据进行大量计算。而模型并没有表示不确定或信息缺失，而是生成了看起来正确的、精雕细琢的结构化答案。
Why RAG Cannot Aggregate为什么RAG无法聚合
The RAG pipeline doesn’t truly understand structured data. All it does is take each CSV row and flatten it into plain text. That’s it. To the model, a row looks something like this:RAG流水线并不真正理解结构化数据。它所做的只是将每一行CSV展平为纯文本。仅此而已。对模型来说，一行数据看起来像这样：
"2019-01-01 grocery_pos 107.23 F NC Jennifer Banks ..."For a query like “What is the total spend by category?”, the RAG pipeline does this:对于像“按类别计算总支出是多少？”这样的查询，RAG流水线会这样做：
1. Tokenise: ["total", "spend", "category"]
2. Score all 100,000 rows by keyword overlap
3. Return the top-N rows as serialised plain text
4. Ask the LLM to sum and group from that textStep 4 is where the system fails. The LLM is not running a SUM. It is pattern-matching numbers from a text blob and generating a response that mimics an aggregation.第4步是系统失败的地方。LLM并没有执行SUM操作。它只是从文本块中匹配数字模式，并生成一个模仿聚合结果的回答。
Models struggle with numerical precision at scale [1], but the real issue is the presentation. The model gives you a detailed breakdown across all categories. This is a classic trap. The output looks professional. It mimics the structure of a real report so well that your brain assumes the content is valid. You have no way to verify that 92% of your data is missing.模型在数值精度上存在困难[1]，但真正的问题是呈现方式。模型给出了所有类别的详细细分。这是一个经典陷阱。输出看起来很专业。它模仿了真实报告的结构，以至于你的大脑默认内容有效。你无法验证92%的数据是否缺失。
RAG is a retrieval tool. It is not a calculation engine. Retrieval finds relevant fragments. Computation requires a full dataset scan. When you use RAG for math, you get a wrong answer that looks authoritative. That distinction is critical. A partial answer signals that data is missing. A complete-looking wrong answer just signals false confidence.RAG是一个检索工具。它不是计算引擎。检索找到相关片段。计算需要完整的数据集扫描。当你用RAG做数学运算时，你会得到一个看起来权威的错误答案。这种区别至关重要。部分答案表明数据缺失。一个看起来完整的错误答案只是虚假的自信。
Complete code: https://github.com/Emmimal/context-window-engine/完整代码：https://github.com/Emmimal/context-window-engine/
The Benchmark: Two Pipelines, Same Query基准测试：两个流水线，同一查询
To measure this precisely, I built a benchmark that runs two pipelines side by side for every query.为了精确测量这一点，我构建了一个基准测试，对每个查询并行运行两个流水线。
The first pipeline is a RAG simulation. It models what a naive vector pipeline passes to an LLM at five context sizes. I tested five context sizes, ranging from 5 rows up to 8,000. That scales from 325 tokens to 500,000. For each size, I tracked three metrics: how much data the LLM sees, what sum it computes from that specific slice, and whether a reader could actually spot the error.第一个流水线是RAG模拟。它模拟了一个朴素的向量流水线在五种上下文大小下传递给LLM的内容。我测试了五种上下文大小，从5行到8000行。这从325个token扩展到50万个。对于每种大小，我跟踪了三个指标：LLM看到了多少数据，它从该特定切片计算出的总和是多少，以及读者是否真的能发现错误。
The second pipeline is a semantic engine that executes the same query as a deterministic full-scan over all 100,000 rows and returns the exact correct answer.第二个流水线是一个语义引擎，它将同一查询作为确定性全扫描在所有10万行上执行，并返回精确的正确结果。
The simulation does not reproduce exact LLM outputs. What it preserves is the key structural property: a partial slice of data fed into a system that returns a full-form answer. That is the property that causes the problem, and that is what the benchmark measures.模拟并不精确复现LLM的输出。它保留了关键的结构特性：将部分数据切片输入到一个返回完整形式答案的系统中。这正是导致问题的特性，也是基准测试所测量的。
I chose seven query types to cover every aggregation pattern a structured data system is likely to encounter:我选择了七种查询类型，以覆盖结构化数据系统可能遇到的所有聚合模式：
| Query | Operation | Why it breaks RAG |
|---|---|---|
| Total spend by category | SUM + GROUP BY | Requires summing all rows across 14 groups |
| Highest average transaction by category | AVG + GROUP BY | Average changes with every missing row |
| Total spent on grocery_pos | SUM + categorical filter | Filter requires seeing all matching rows |
| How many female customers transacted | COUNT + filter | Count is meaningless on a partial scan |
| Total spend where amount > $500 | SUM + numeric comparison | Threshold logic requires full data |
| State with lowest total spending | MIN + GROUP BY across 50 groups | Minimum can only be found with all groups present |
| Percentage of transactions that are fraudulent | COUNT + ratio | Ratio is undefined on a partial denominator |
These queries are not unique or complex. They are the standard questions any analyst asks when looking at a new dataset. That is exactly why this failure is so critical.这些查询并不独特或复杂。它们是任何分析师在查看新数据集时都会问的标准问题。这正是为什么这种失败如此关键。
Error Observability Collapse错误可观测性崩溃
Here is the full benchmark output for the query that started all of this. I am showing it in full because the numbers make the problem impossible to dismiss.以下是引发这一切的查询的完整基准测试输出。我完整展示它，因为这些数字使问题无法忽视。
GROUND TRUTH (Semantic Engine)
SUM(amt) GROUP BY category → 14 groups
#1 grocery_pos 1,140,033.24
#2 shopping_net 773,527.93
#3 shopping_pos 725,766.14
#4 gas_transport 648,804.24
#5 home 556,526.53
Latency: 100.47ms | Rows scanned: 100,000
RAG SIMULATION — what the LLM receives at each context size
Context Rows Coverage Partial sum Error detectable?
tiny (~325 tokens) 5 0.0050% 197.73 EASY
small (~3K tokens) 50 0.0500% 2,003.56 MODERATE
medium (~32K tokens) 500 0.5000% 31,023.21 HARD
large (~130K tokens) 2,000 2.0000% 140,093.16 VERY HARD
xlarge (~520K tokens) 8,000 8.0000% 569,368.22 NEAR IMPOSSIBLEI stared at these results for a while. The most troubling part wasn’t just that the answers were wrong, it was how much harder the errors became to spot as the context window grew.我盯着这些结果看了一会儿。最令人不安的部分不仅仅是答案错误，而是随着上下文窗口增大，错误变得多么难以发现。
At 8,000 rows the error was still over 50%, yet the response looked like a professional report. You’d need to manually verify the numbers to notice something was off. That’s what I started calling Error Observability Collapse. The more context I gave the model, the more convincing — but not more accurate — the output became.在8000行时，错误仍然超过50%，但回答看起来像一份专业报告。你需要手动验证数字才能发现不对劲。这就是我开始称之为“错误可观测性崩溃”的现象。我给模型越多上下文，输出就越有说服力——但并不更准确。
The “Partial sum” column shows the total if the LLM added every amount value in the rows it actually retrieved. The “Error detectable?” column scores how likely a human reader is to spot a mistake.“部分和”列显示如果LLM将实际检索到的行中的所有金额值相加的总和。“错误可检测？”列评估人类读者发现错误的可能性。
With 5 rows, the partial sum is 197.73. The correct total is 1,140,033.24. It is obvious. The output is short, the numbers are wrong, and the missing data is clear. The error is instant.对于5行，部分和为197.73。正确总计是1,140,033.24。这很明显。输出简短，数字错误，缺失数据清晰。错误立即可见。
At 8,000 rows, the partial sum hits 569,368.22. The LLM has now seen all 14 categories. It generates a 1,500-word report with specific figures and confident language. The error is 50%, but it is hidden inside authoritative, well-structured prose. Without an external reference, a reader has no way to catch it.在8000行时，部分和达到569,368.22。LLM现在看到了所有14个类别。它生成了一份1500字的报告，包含具体数字和自信的语言。错误率为50%，但隐藏在权威、结构良好的散文中。没有外部参考，读者无法发现。
This is the pattern that held across all seven queries:这是所有七个查询中一致的模式：
| Context Window | Rows | Dataset Coverage | Response Length | Error Detectable? |
|---|---|---|---|---|
| ~325 tokens | 5 | 0.005% | ~50 words | YES — obviously a guess |
| ~3K tokens | 50 | 0.050% | ~150 words | MAYBE |
| ~32K tokens | 500 | 0.500% | ~400 words | HARD |
| ~130K tokens | 2,000 | 2.000% | ~800 words | VERY HARD |
| ~520K tokens | 8,000 | 8.000% | ~1,500 words | NEAR IMPOSSIBLE |
| Semantic Engine | 100,000 | 100% | <200ms | N/A — exact |
I called this Error Observability Collapse. As context grows, confidence scales with it. Correctness does not.我称之为错误可观测性崩溃。随着上下文增长，自信也随之增长。正确性却没有。
The failure modes are asymmetric, which makes them dangerous:失败模式是不对称的，这使得它们危险：
A wrong RAG answer looks correct. It is formatted, specific, and confident. A failed computation throws an explicit error. It is visible.错误的RAG答案看起来正确。它格式规范、具体且自信。失败的计算会抛出显式错误。它是可见的。
One failure is silent. The other is loud. As context windows reach millions of tokens, the silent failure becomes harder to detect [4]. The system does not get safer as it scales. It just gets more convincing.一种失败是无声的。另一种是响亮的。随着上下文窗口达到数百万token，无声失败变得更难检测[4]。系统并不会随着规模扩大而变得更安全。它只是变得更有说服力。
The Semantic Engine: Proof That the Correct Answer Is Fast语义引擎：证明正确答案是快速的
Before I fully understood the problem, I had already thrown together a simple semantic engine out of frustration. I just wanted the correct answer at least once.在我完全理解问题之前，我已经出于沮丧拼凑了一个简单的语义引擎。我只是想至少得到一次正确答案。
The approach turned out to be simple: parse the query into proper operations and run a single pass over the entire dataset. No embeddings, no retrieval, no guessing.方法结果很简单：将查询解析为适当的操作，并对整个数据集运行一次单次扫描。没有嵌入，没有检索，没有猜测。
Here’s what that looks like in practice:实际效果如下：
The logic is simple. Take a query like “What is the total spend by category?”. The engine maps this to a direct operation: SUM(amt) GROUP BY category. It processes the full 100,000-row set in a single pass. It accumulates grouped totals. There is no retrieval. No inference. No partial scanning. It visits every row once and returns the exact result.逻辑很简单。以“按类别计算总支出是多少？”这样的查询为例。引擎将其映射为直接操作：SUM(amt) GROUP BY category。它一次处理完整的10万行数据集。它累积分组总计。没有检索。没有推理。没有部分扫描。它访问每一行一次并返回精确结果。
This proves that the correct answer is not expensive. Benchmark queries finished under 200ms. Sample size: 100,000 rows. Aggregation is trivial. The failure happens when you route those queries to a system built to misunderstand them.这证明了正确答案并不昂贵。基准查询在200毫秒内完成。样本量：10万行。聚合是微不足道的。失败发生在你将那些查询路由到一个为误解它们而构建的系统时。
from context_window_engine import compute_ground_truth, load_csv
rows = load_csv("data/credit_card_transactions.csv", max_rows=100_000)
gt = compute_ground_truth(
query_label = "total by category",
rows = rows,
agg_func = "sum",
agg_col = "amt",
group_col = "category",
)
# gt.answer → [(grocery_pos, 1140033.24), (shopping_net, 773527.93), ...]
# gt.latency_ms → 100.47Engine supports SUM, AVG, COUNT, MIN, MAX. Handles categorical and numeric filters. Includes GROUP BY and ratios. Zero external dependencies. Every operation runs as a deterministic function over the full list.引擎支持SUM、AVG、COUNT、MIN、MAX。处理分类和数值过滤器。包括GROUP BY和比率。零外部依赖。每个操作都作为确定性函数在完整列表上运行。
The engine itself isn’t the product. It’s the proof: the correct answer is reachable under a second. No inference required. The real challenge is routing queries there reliably. 引擎本身不是产品。它是证明：正确答案在一秒内可达。无需推理。真正的挑战是可靠地将查询路由到那里。
The Fix Is Not Better Retrieval解决方案不是更好的检索
Stop trying to improve retrieval. If a query needs 100% of the data, an 8% sample fails. The fix is removing retrieval from the loop.停止尝试改进检索。如果查询需要100%的数据，8%的样本就会失败。解决方案是将检索从循环中移除。
We need a classification layer. It sits before the pipeline and makes one binary call: computation or lookup?我们需要一个分类层。它位于流水线之前，做出一个二元判断：计算还是查找？
The difference is clear. “Total spend by category” demands a full scan. “Find transactions from Jennifer Banks” is a simple lookup. Standard RAG forces both down the same path. That is the design flaw.区别很明显。“按类别计算总支出”需要全扫描。“查找Jennifer Banks的交易”是简单的查找。标准RAG将两者强制走同一条路径。这就是设计缺陷。
A QueryRouter fixes this. It inspects every incoming query and routes it to the correct path before a single retrieval begins.QueryRouter解决了这个问题。它在任何检索开始之前检查每个传入查询，并将其路由到正确的路径。
The classifier uses three signal tiers, prioritized. Tier 1: aggregation verbs—total, how many, average, lowest, percentage. These demand full-dataset computation. Tier 2: numeric comparison—greater than 500, above $1,000, at least. These imply filter-then-aggregate, impossible for RAG. Tier 3: retrieval signals—find, show me, list, fetch. These indicate lookups where semantic similarity works.分类器使用三个信号层级，按优先级排序。第一层：聚合动词——总计、多少、平均、最低、百分比。这些需要全数据集计算。第二层：数值比较——大于500、超过1000美元、至少。这些意味着过滤后聚合，RAG无法做到。第三层：检索信号——查找、显示、列出、获取。这些表示语义相似性适用的查找。
| Tier | Signal | Examples | Route |
|---|---|---|---|
| 1 | Aggregation verb | total, how many, average, lowest, percentage | COMPUTATION |
| 2 | Numeric comparison | greater than 500, above $1,000, at least | COMPUTATION |
| 3 | Retrieval signal | find, show me, list, fetch | RETRIEVAL |
| 0 | No match | ambiguous | COMPUTATION — safer default |
Default to COMPUTATION if no tier matches. This is deliberate. Failure modes are asymmetric: a wrong RAG answer on an aggregation is silently wrong. A computation engine that can’t parse a query throws an error. When in doubt, fail loudly.如果没有匹配的层级，默认走计算。这是故意的。失败模式不对称：聚合上的错误RAG答案是无声的错误。无法解析查询的计算引擎会抛出错误。有疑问时，大声失败。
from query_router import QueryRouter
router = QueryRouter(rows)
result = router.route("What is the total spend by category?")
# result.routed_to → "COMPUTATION"
# result.answer.answer → [(grocery_pos, 1140033.24), ...]
# result.total_latency → ~250ms — classify + execute combined
result = router.route("Find transactions from Jennifer Banks")
# result.routed_to → "RETRIEVAL"
# result.answer.safe → True — RAG is appropriateRouting the Full Benchmark路由完整基准测试
I ran nine queries through the router to verify performance across both types: seven aggregation queries destined for the semantic engine, and two lookup queries for RAG.我通过路由器运行了九个查询，以验证两种类型的性能：七个聚合查询（目标为语义引擎）和两个查找查询（目标为RAG）。
Every route was correct. The seven aggregation queries hit the full-scan engine and returned exact results. The two lookup queries correctly triggered the RAG path. Look at the output: high confidence scores, correct pattern matching, and latency under 130ms—even with the 100,000-row scan.每个路由都是正确的。七个聚合查询命中全扫描引擎并返回精确结果。两个查找查询正确触发了RAG路径。看输出：高置信度分数、正确的模式匹配，以及低于130毫秒的延迟——即使有10万行扫描。
[1] ✓ COMPUTATION "What is the total spend by category?"
Tier 1 | matched='total' | confidence=0.97
#1 grocery_pos 1,140,033.24 (102.57ms | 100,000 rows | exact)
[2] ✓ COMPUTATION "Which category has the highest average transaction amount?"
Tier 1 | matched='highest' | confidence=0.97
71.91 (119.47ms | 100,000 rows | exact)
[3] ✓ COMPUTATION "What is the total amount spent on grocery_pos?"
Tier 1 | matched='total' | confidence=0.97
1,140,033.24 (49.96ms | 100,000 rows | exact)
[4] ✓ COMPUTATION "How many transactions were made by female customers?"
Tier 1 | matched='How many' | confidence=0.97
54,641.00 (90.45ms | 100,000 rows | exact)
[5] ✓ COMPUTATION "What is the total spend where amount is greater than 500?"
Tier 1 | matched='total' | confidence=0.97
1,274,269.60 (91.65ms | 100,000 rows | exact)
[6] ✓ COMPUTATION "Which state has the lowest total spending?"
Tier 1 | matched='lowest' | confidence=0.97
lowest RI 2,125.60 (109.05ms | 100,000 rows | exact)
[7] ✓ COMPUTATION "What percentage of transactions are fraudulent?"
Tier 1 | matched='percentage' | confidence=0.97
0.9900% (87.35ms | 100,000 rows | exact)
[8] ✓ RETRIEVAL "Find transactions from Jennifer Banks"
Tier 3 | matched='Find' | confidence=0.85
RAG is appropriate — no aggregation required
[9] ✓ RETRIEVAL "Show me a sample transaction from Texas"
Tier 3 | matched='Show me' | confidence=0.85
RAG is appropriate — no aggregation required
Routing accuracy: 9/99/9 correct. Error Observability Collapse is impossible if aggregation queries never reach RAG.9/9正确。如果聚合查询从不到达RAG，错误可观测性崩溃就不可能发生。
The Test Suite测试套件
The benchmark verifies nine specific queries. The test suite ensures reliability across a broader range: edge cases, malformed inputs, missing data, and common production failure points. 基准测试验证了九个特定查询。测试套件确保在更广泛范围内的可靠性：边缘情况、格式错误的输入、缺失数据以及常见的生产故障点。
The engine suite has 87 tests across 10 classes. It covers float parsing with dollar signs, commas, and scientific notation; all five aggregation functions under normal conditions and with empty inputs; all five numeric filter operators; full GROUP BY aggregation with categorical and numeric filters combined; RAG simulation coverage metrics at each context size; and edge cases including empty datasets, rows with missing column values, and single-row inputs.引擎套件有87个测试，涵盖10个类别。它覆盖了带美元符号、逗号和科学记数法的浮点数解析；所有五种聚合函数在正常条件和空输入下的情况；所有五种数值过滤运算符；带分类和数值过滤器的完整GROUP BY聚合；每个上下文大小下的RAG模拟覆盖率指标；以及边缘情况，包括空数据集、缺少列值的行和单行输入。
The router suite has 72 tests across 5 classes. It covers all three tier patterns, including edge cases like all-caps queries and very long queries; natural language to typed operation parsing for every supported query form; routing and execution correctness against all seven benchmark queries; and a contrast suite that verifies router answers match independent ground-truth computation — ensuring the router does not introduce any deviation from the engine’s own output.路由器套件有72个测试，涵盖5个类别。它覆盖了所有三个层级模式，包括全大写查询和非常长查询等边缘情况；针对所有支持的查询形式的自然语言到类型化操作解析；针对所有七个基准查询的路由和执行正确性；以及一个对比套件，验证路由器答案与独立真实计算匹配——确保路由器不引入任何与引擎自身输出的偏差。
Run the engine tests by typing python space -m space unittest space test_engine space -v. This executes the 87 tests in the suite.通过输入python -m unittest test_engine -v运行引擎测试。这将执行套件中的87个测试。
Run the router tests by typing python space -m space unittest space test_router space -v. This executes the 72 tests in the suite.通过输入python -m unittest test_router -v运行路由器测试。这将执行套件中的72个测试。
All 159 pass on Python 3.9+ with zero external dependencies.所有159个测试在Python 3.9+上通过，零外部依赖。
Honest Limitations诚实的局限性
This solution isn’t perfect. It only works on single CSV files right now. Real production datasets are usually messy with multiple tables that need joining — I deliberately kept the scope small because I wanted something that actually worked end-to-end first.这个解决方案并不完美。目前它只适用于单个CSV文件。真实的生产数据集通常很杂乱，包含多个需要连接的表——我故意保持范围较小，因为我希望先有一个真正端到端工作的东西。
The router is also still pretty basic (regex-based). I tried a small LLM-based classifier early on but it was inconsistent and added latency, so I went back to the simple approach. Sometimes the boring solution wins.路由器也仍然相当基础（基于正则表达式）。我早期尝试了一个小型LLM分类器，但它不一致且增加了延迟，所以我回到了简单的方法。有时无聊的解决方案胜出。
I also simulated the RAG responses instead of hitting real APIs for the benchmark. The patterns hold up, but your mileage with GPT-4o or Claude 3.5 will vary slightly.我还模拟了RAG响应，而不是在基准测试中调用真实API。模式成立，但你在GPT-4o或Claude 3.5上的体验会略有不同。
CSV format required. The engine loads structured data directly from CSV files. Database connections, Parquet files, and other tabular formats are not supported at this time.需要CSV格式。引擎直接从CSV文件加载结构化数据。目前不支持数据库连接、Parquet文件和其他表格格式。
What This Changes这改变了什么
Adding a routing layer costs almost nothing. Classifying a query against 65 regex patterns takes just microseconds. The semantic engine adds less than 200ms to scan a 100,000 row dataset. The total overhead is smaller than a single embedding call.添加一个路由层几乎不花什么成本。针对65个正则表达式模式分类一个查询只需微秒。语义引擎扫描10万行数据集增加不到200毫秒。总开销小于一次嵌入调用。
What you get in return is a deterministic answer for every aggregation query. Every total, every count, and every percentage now comes from a full scan instead of a confident approximation based on 8 percent of the data. RAG keeps handling what it is actually good at: retrieving specific records, surfacing relevant passages, and answering lookup questions where semantic similarity is the right tool for the job.你得到的是每个聚合查询的确定性答案。每个总计、每个计数和每个百分比现在都来自全扫描，而不是基于8%数据的自信近似。RAG继续处理它真正擅长的事情：检索特定记录、呈现相关段落以及回答语义相似性适用的查找问题。
RAG is not broken. It is just being asked to compute, and it cannot do that.
The dangerous part is not that it fails. It is that it fails convincingly. And no amount of context changes that.RAG并没有坏。它只是被要求进行计算，而它做不到。危险的部分不是它失败。而是它失败得令人信服。再多的上下文也改变不了这一点。
You can try typing it out like this:你可以这样尝试输入：
To start, clone the repository using git clone followed by the URL https://github.com/Emmimal/context-window-engine/. Once that finishes, move into the directory by typing cd context-window-engine. Finally, launch the project by running python demo.py in your terminal.首先，使用git clone命令后跟URL https://github.com/Emmimal/context-window-engine/ 克隆仓库。完成后，通过输入cd context-window-engine进入目录。最后，在终端中运行python demo.py启动项目。
References参考文献
[1] Levy, M., Jacoby, A., & Goldberg, Y. (2024). Same task, more tokens: The impact of input length on the reasoning performance of large language models. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 15339–15353, Bangkok, Thailand. Association for Computational Linguistics.
https://doi.org/10.18653/v1/2024.acl-long.818[1] Levy, M., Jacoby, A., & Goldberg, Y. (2024). Same task, more tokens: The impact of input length on the reasoning performance of large language models. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 15339–15353, Bangkok, Thailand. Association for Computational Linguistics.https://doi.org/10.18653/v1/2024.acl-long.818
[2] Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W.-t., Rocktäschel, T., Riedel, S., & Kiela, D. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems, 33, 9459–9474. https://doi.org/10.48550/arXiv.2005.11401[2] Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W.-t., Rocktäschel, T., Riedel, S., & Kiela, D. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. Advances in Neural Information Processing Systems, 33, 9459–9474. https://doi.org/10.48550/arXiv.2005.11401
[3] Gao, Y., Xiong, Y., Gao, X., Jia, K., Pan, J., Bi, Y., Dai, Y., Sun, J.,
Guo, Q., Wang, M., & Wang, H. (2023). Retrieval-augmented generation for large language models: A survey. arXiv preprint arXiv:2312.10997.
https://doi.org/10.48550/arXiv.2312.10997[3] Gao, Y., Xiong, Y., Gao, X., Jia, K., Pan, J., Bi, Y., Dai, Y., Sun, J.,Guo, Q., Wang, M., & Wang, H. (2023). Retrieval-augmented generation for large language models: A survey. arXiv preprint arXiv:2312.10997.https://doi.org/10.48550/arXiv.2312.10997
[4] Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). Lost in the middle: How language models use long contexts. Transactions of the Association for Computational Linguistics, 12, 157–173. https://doi.org/10.1162/tacl_a_00638[4] Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023). Lost in the middle: How language models use long contexts. Transactions of the Association for Computational Linguistics, 12, 157–173. https://doi.org/10.1162/tacl_a_00638
[5] Koshorek, O., Granot, N., Alloni, A., Admati, S., Hendel, R., Weiss, I., Arazi, A., Cohen, S.-N., & Belinkov, Y. (2025). Structured RAG for answering aggregative questions. arXiv preprint arXiv:2511.08505.
https://doi.org/10.48550/arXiv.2511.08505[5] Koshorek, O., Granot, N., Alloni, A., Admati, S., Hendel, R., Weiss, I., Arazi, A., Cohen, S.-N., & Belinkov, Y. (2025). Structured RAG for answering aggregative questions. arXiv preprint arXiv:2511.08505.https://doi.org/10.48550/arXiv.2511.08505
Disclosure披露
All benchmark numbers are from actual runs on Python 3.12.6, Windows 11, CPU only, no GPU. The benchmark uses the Credit Card Transactions Fraud Detection dataset (Kartik Gajjar, Kaggle, 2020), a synthetic dataset generated using the Sparkov transaction simulator created by Brandon Harris, licensed CC0 (Public Domain), available at kaggle.com/datasets/kartik2112/fraud-detection. The RAG baseline simulates retrieval and models confidence signals — no real LLM API calls are made. No external API keys are required to reproduce any result in this article. All code described here was written and tested by me.所有基准数字均来自Python 3.12.6、Windows 11、仅CPU、无GPU的实际运行。基准测试使用信用卡交易欺诈检测数据集（Kartik Gajjar, Kaggle, 2020），这是一个使用Brandon Harris创建的Sparkov交易模拟器生成的合成数据集，采用CC0（公共领域）许可，可在kaggle.com/datasets/kartik2112/fraud-detection获取。RAG基线模拟检索并建模置信信号——未进行真实的LLM API调用。无需外部API密钥即可重现本文中的任何结果。本文描述的所有代码均由我编写和测试。
