{ "source_file": "0930", "source_platform": "个人博客", "author": "Jason Liu", "title_listed": "Why Is Context Engineering the Future of RAG?", "keywords": "上下文工程,分面搜索,Agent", "domain": "大模型算法", "content_type": "深度技术解析", "is_paid_flag": "否", "url": "https://jxnl.co/writing/2025/08/27/facets-context-engineering/", "publish_date": "2025-08", "corpus_stage": "推理部署", "notes": "分面搜索给Agent周边视野", "id": "d43a50d5bd0e", "collected_at": "2026-10-02T14:29:25", "title": "Beyond Chunks: Why Context Engineering is the Future of RAG - Jason Liu", "body_markdown": "Why Is Context Engineering the Future of RAG?\n¶\nThe core insight:\nIn agentic systems, how we structure tool responses is as important as the information they contain.\nThis is the first post in a series on context engineering. I'm starting here because it's the lowest hanging fruit—something every company can audit and experiment with immediately.\nKey Terms:\nContext Engineering:\nStructuring tool responses and information flow to give agents the right data in the right format for effective reasoning\nFaceted Search:\nExposing metadata aggregations (counts, categories, filters) alongside search results to reveal the data landscape\nAgent Peripheral Vision:\nProviding agents with structured metadata about the broader information space beyond just the top-k results\nTool Response as Prompt Engineering:\nUsing XML structure, metadata, and system instructions in tool outputs to guide future agent behavior\nRAG worked brilliantly for the past few years. You'd embed documents, search for relevant chunks, stuff them into a prompt, and get surprisingly good answers. Simple, effective, solved real problems. I've written extensively about\nsystematically improving RAG applications\nand\ncommon RAG anti-patterns\nto avoid.\nBut agents changed the game. They're persistent, make multiple tool calls, and build understanding across conversations. They don't just need the right chunk—they need to understand the landscape of available information so they can decide what to explore, make plans and then execute. This shift is exemplified by successful coding agents like those discussed in our\nCoding Agents Speaker Series\n, where simple tools with agentic loops consistently outperform complex retrieval systems.\nI learned this through my consulting work and teaching at\nimprovingrag.com\n. I get to talk to a lot of companies building AI systems, plus I host office hours where teams bring their real production challenges. The pattern is consistent: teams have perfectly functional search systems returning relevant text chunks. Then users start asking \"Who modified this document last?\" and \"How recent is this policy?\" and teams start asking themselves, what is the work that these systems can really do?\nThe breakthrough came when we realized chunks themselves were the limitation. When search results showed multiple fragments from the same document, we were asking agents to piece together puzzles instead of loading complete pages. A simple\nload_pages()\nfunction improved agent reasoning dramatically.\nThen we noticed something profound: these structured tool responses weren't just returning data—they were teaching agents how to think about the data. The metadata became prompt engineering itself.\nThis is the fundamental problem with chunk-based RAG in agentic systems. Agents aren't just looking for answers—they're trying to understand what questions to ask next. They need peripheral vision of the data landscape, not just the highest-scoring chunks.\nThe paradigm shift:\nAs\nAnthropic explains\n, tools represent a new kind of software contract—between deterministic systems and non-deterministic agents. Traditional functions like\ngetWeather(\"NYC\")\nwork predictably every time. But when an agent asks \"Should I bring an umbrella today?\" it might call the weather tool, answer from memory, ask for location clarification, or even hallucinate. This fundamental non-determinism means we need to design tools that increase the surface area over which agents can be effective, not just return the \"right\" answer.\nWhat Are the Four Levels of Context Engineering?\n¶\nI'll demonstrate this through four progressively complex levels:\nLevel 1 — Minimal Chunks\n- Basic tool responses without metadata\nLevel 2 — Chunks with Source Metadata\n- Enables citations and strategic document loading\nLevel 3 — Multi-Modal Content\n- Optimizes tables, images, and structured data for agents\nLevel 4 — Facets and Query Refinement\n- Reveals the complete data landscape for strategic exploration\nThis progression leads to two key predictions:\nTool results become prompt engineering\n- Metadata teaches agents how to use tools in future calls\nDatabases become reasoning partners\n- Facets surface patterns that agents leverage but humans wouldn't think to ask for\nWhy Is Search Quality Your Ceiling?\n¶\nHard Truth\nGood search is the ceiling on your RAG quality. If recall is poor, no prompt engineering or model upgrade will save you. I've seen teams spend weeks fine-tuning prompts when their real problem was that the relevant information simply wasn't being retrieved. This is why focusing on the right RAG evaluation metrics matters.\nContext engineering goes beyond returning chunks. It's about returning actionable structure about the result set so the next tool call can be smarter. Think of it as giving agents peripheral vision about the data landscape.\nStart Here: Audit Your Current Tools\nBefore building new infrastructure, audit what your tools actually return. Most improvements are just better string formatting—wrapping results in XML, adding source metadata, including system instructions. No major architectural changes required.\nDesign principle from\nAnthropic's tool development guide\n:\nThink of tool descriptions as prompt engineering for your agents. How you name functions, structure parameters, and format responses directly influences agent reasoning patterns. Clear tool boundaries and meaningful parameter names reduce confusion and hallucinations.\nHow Should We Balance Complexity?\n¶\nHere's the uncomfortable truth: there's no single right answer for how much metadata to include. Every system has different needs, and the more complex you make your tools, the higher the likelihood of hallucinations and tool misuse.\nThis reality demands two things from us as builders:\nBetter prompts.\nComplex tools require sophisticated instructions. You can't just throw a dozen parameters at an agent and hope it figures out the right combinations. Your system instructions become as important as your tool design.\nBetter creativity in system design.\nThe same outcome can often be achieved through simpler tool compositions rather than one mega-tool. Sometimes it's better to have separate\nsearch()\nand\nfilter_by_date()\nfunctions rather than cramming everything into a single interface with endless optional parameters.\nDesign Principle\nRecognize when complexity pays for itself. Metadata that doesn't change agent behavior is just expensive noise.\nToken efficiency insight:\nAnthropic's research\nshows that tool responses should prioritize contextual relevance over flexibility. Return high-signal information that directly informs downstream actions, not low-level technical identifiers. Consider adding\nresponse_format\nparameters (\"concise\" vs \"detailed\") to let agents control verbosity based on their current reasoning needs. They recommend implementing pagination, filtering, and truncation with sensible defaults for any responses that could consume significant context.\n**The beauty of context engineering:** You don't need to redesign your tools or rebuild your infrastructure. Most improvements are XML structuring, source tracking, and system instructions—essentially better string formatting with potentially massive upside.\nEvaluation-driven improvement:\nAnthropic's research\nshows that systematic evaluation is critical for tool optimization. Generate realistic test tasks based on your actual use cases, measure agent performance across tool response levels, and iterate based on concrete metrics rather than intuition. The teams that build comprehensive evaluations early dramatically outperform those that rely on ad-hoc testing.\nLevel 1 — Minimal Chunks (No Metadata)\n¶\ndef\nsearch\n(\nquery\n:\nstr\n,\nn_chunks\n:\nint\n=\n10\n)\n->\nlist\n[\nstr\n]:\n\"\"\"\nSearch documents and return relevant text chunks. No metadata or source\ninformation provided - you'll get raw text content only.\nUse this when you need quick answers but don't need to trace information\nback to sources or understand document structure.\nArgs:\nquery: What you're looking for in natural language\nn_chunks: How many text chunks to return (default: 10)\nReturns:\nList of text chunks that match your query\n\"\"\"\npass\n\n\n\nTermination\nfor\nConvenience.\nEither\nparty\nmay\nterminate\nthis\nAgreement\nupon\nthirty\n(30)\ndays'\nwritten\nnotice...\n\n\nConfidentiality.\nRecipient\nshall\nnot\ndisclose\nany\nConfidential\nInformation\nfor\nfive\n(5)\nyears...\n\n\nLimitation\nof\nLiability.\nIn\nno\nevent\nshall\naggregate\nliability\nexceed\nthe\nfees\npaid\nin\nthe\ntwelve\n(12)\nmonths...\n\n\n\nThe limitation:\nWithout metadata, agents can't make strategic decisions about where to search next. They're flying blind.\nLevel 2 — Chunks with Basic Source Metadata\n¶\nAvailable tools:\ndef\nsearch\n(\nquery\n:\nstr\n,\nsource\n:\nstr\n=\nNone\n,\nn_chunks\n:\nint\n=\n10\n)\n->\ndict\n:\n\"\"\"\nSearch documents with source tracking. Returns chunks with metadata\nso you can cite sources and see document patterns.\nWhen you see multiple chunks from the same document, that usually means\nthe document has comprehensive coverage of your topic.\nArgs:\nquery: What you're looking for in natural language\nsource: Limit search to a specific document (optional)\nn_chunks: How many chunks to return (default: 10)\nReturns:\nResults with source files, page numbers, and chunk content\n\"\"\"\npass\ndef\nload_pages\n(\nsource\n:\nstr\n,\npages\n:\nlist\n[\nint\n])\n->\ndict\n:\n\"\"\"\nGet full pages from a document when you need complete context instead\nof fragmented chunks.\nUse this when search results show multiple chunks from the same document -\nusually means you should read the full pages rather than piecing together\nfragments.\nArgs:\nsource: Document path (like \"contracts/MSA-2024.pdf\")\npages: Which pages to load (like [3, 7, 12])\nReturns:\nComplete page content with source information\n\"\"\"\npass\nExample tool response:\n\n\n\nRefunds.\nEnterprise\nplan\nrefunds\nrequire\nprior\nwritten\napproval\nby\nCustomer's\naccount\nadministrator\nand\nmust\nbe\nsubmitted\nwithin\nsixty\n(60)\ndays...\n\n\nChargebacks\nand\nAdjustments.\nProvider\nmay\nissue\ncredits\nin\nlieu\nof\nrefunds\nas\nmutually\nagreed\nin\nwriting...\n\n\nStandard\nrefunds\nare\navailable\nwithin\n30\ndays\nof\npurchase\nfor\nall\nstandard\nplan\nsubscriptions;\nenterprise\nterms\nmay\nsupersede...\n\n\n\nKey\ninsight:\nMultiple\nchunks\nfrom\nsame\nsource\n=\nuse\nload_pages()\ninstead\nof\nfragments.\nDecision\nframework:\nSame\nsource\nclustering\n→\nload\nfull\npages;\nMultiple\nsources\n→\ntargeted\nfollow-up\nsearches.\nTool\nusage\nguidance:\nWhen\nwriting\ntool\ndescriptions,\nthink\nlike\nyou're\ntraining\na\nnew\nteam\nmember.\nMake\nimplicit\nknowledge\nexplicit—specialized\nquery\nformats,\nterminology\ndefinitions,\nand\nrelationships\nbetween\nresources.\nAmbiguous\nparameter\nnames\nlike\n\"user\"\nshould\nbecome\n\"user_id\"\nfor\nclarity.\nError\nhandling\nstrategy:\nIf\ntool\ncalls\nfail\nvalidation,\nreturn\nactionable\nerror\nmessages\nthat\nguide\nagents\ntoward\ncorrect\nusage\nrather\nthan\ncryptic\nerror\ncodes.\nFor\nexample:\n\"Date\nfilter\nrequires\nYYYY-MM-DD\nformat,\nreceived\n'2024/03/15'\"\ninstead\nof\n\"ValueError:\ninvalid\ndate\nformat\".\n\n\nThe breakthrough:\nAgents now see document clustering patterns and can strategically load full pages instead of piecing together fragments. Citations become possible.\nLevel 3 — Multi-Modal Content Representation\n¶\nModern documents aren't just text - they contain tables, charts, diagrams, code blocks, and other structured content. Agents need appropriate representations for different content modalities to reason effectively.\nAvailable tools:\ndef\nsearch\n(\nquery\n:\nstr\n,\nsource\n:\nstr\n=\nNone\n,\ncontent_types\n:\nlist\n[\nstr\n]\n=\nNone\n,\n# [\"text\", \"table\", \"image\", \"code\"]\nn_chunks\n:\nint\n=\n10\n)\n->\ndict\n:\n\"\"\"\nSearch documents and get back content in the right format for reasoning.\nTables, images, and structured content are automatically formatted for\noptimal analysis.\nSimple tables return as Markdown for easy data work. Complex tables with\nmerged cells return as HTML so you can understand the relationships.\nImages include both the visual content and searchable OCR text.\nArgs:\nquery: What you're looking for in natural language\nsource: Limit to specific document (optional)\ncontent_types: Filter by content type like [\"table\"] or [\"image\"] (optional)\nn_chunks: How many chunks to return (default: 10)\nReturns:\nContent formatted appropriately for each type (Markdown, HTML, images with OCR)\n\"\"\"\npass\ndef\nload_pages\n(\nsource\n:\nstr\n,\npages\n:\nlist\n[\nint\n])\n->\ndict\n:\n\"\"\"\nGet complete pages when you need full context instead of fragments.\nUse this when search shows multiple chunks from the same document -\nusually better to read full pages than piece together fragments.\nArgs:\nsource: Document path (like \"reports/Q3-2024.pdf\")\npages: Which pages to load (like [3, 7, 12])\nReturns:\nComplete page content with all formatting preserved\n\"\"\"\npass\nExample with multi-modal content:\n\n\n\n|\nQuarter\n|\nRevenue\n|\nGrowth\n|\n|---------|---------|--------|\n|\nQ1\n2024\n|\n$45M\n|\n12%\n|\n|\nQ2\n2024\n|\n$52M\n|\n18%\n|\n|\nQ3\n2024\n|\n$58M\n|\n22%\n|\n\n\n\n\n\nRegion\n\nQ3\n2024\n\n\n\n\n\n\n
\nRevenue\n\nUnits\n\nMargin\n
\nNorth\nAmerica\n\n$25.2M\n\n1,250\n\n34%\n
\n\n\n\n\nQ3\nRevenue\nBreakdown\n•\nNorth\nAmerica:\n$25.2M\n(43%)\n•\nEurope:\n$18.3M\n(32%)\n\n\n[base64\nencoded\npie\nchart]\n\n\n\n\n\nBut even with perfectly formatted multi-modal content, agents still face a fundamental limitation: they can only see the top-k results. What about all the other relevant documents that didn't make the similarity cutoff? What patterns exist in the broader dataset that could guide their next search?\nThis is where facets transform the game entirely. Instead of just returning results, we start returning the\nlandscape\nof results.\nLevel 4 — Facets and Query Refinement\n¶\nAt this level, we introduce facets - aggregated metadata that helps agents understand the data landscape and refine their queries iteratively, just like users do on e-commerce sites.\nThink e-commerce: search \"running shoes\" → get results + facets (Nike: 45, Adidas: 32, 4-star: 28, 5-star: 12). Click \"Nike\" + \"4+ stars\" → refined results, still targeted.\nAgents use the same pattern, but they already understand this instinctively. Consider how coding agents work today:\n$\ngrep\n-r\n\"UserService\"\n.\n--include\n=\n\"*.py\"\n|\ncut\n-d:\n-f1\n|\nsort\n|\nuniq\n-c\n6\n./user_controller.py\n4\n./auth_service.py\n3\n./models.py\n2\n./test_user.py\nThe agent sees these file distribution counts and immediately recognizes that\nuser_controller.py\n(6 occurrences) and\nauth_service.py\n(4 occurrences) deserve full attention. Instead of reading 20 disconnected grep snippets, it strategically calls\nread_file()\non the files with the highest relevance signals.\nThis is exactly faceted search: aggregate counts reveal which documents deserve complete context rather than fragmented chunks.\nAvailable tools:\nThe same\nsearch()\nfunction from previous levels, but now automatically returns facet information alongside results. The filter parameters align with the facet dimensions returned.\ndef\nsearch\n(\nquery\n:\nstr\n,\nsource\n:\nstr\n=\nNone\n,\ndocument_type\n:\nstr\n=\nNone\n,\nfreshness_score_min\n:\nfloat\n=\nNone\n,\nn_chunks\n:\nint\n=\n10\n)\n->\ndict\n:\n\"\"\"\nSemantic search that automatically returns results with facet information.\nArgs:\nquery: Natural language search query\nsource: Optional filter by document source (aligns with source_facet)\ndocument_type: Optional filter by document category\nfreshness_score_min: Optional minimum freshness score\nn_chunks: Number of chunks to return (default: 10)\nReturns:\nDict with chunks, facets, and system instructions\n\"\"\"\npass\nExample search with facets:\n\n\n\nData\nProcessing.\nAll\ncustomer\ndata\nshall\nbe\nprocessed\nin\naccordance\nwith\napplicable\ndata\nprotection\nlaws,\nincluding\nGDPR\nand\nCCPA.\nData\nresidency\nrequirements\nspecify\nthat\nEU\ncustomer\ndata\nmust\nremain\nwithin\napproved\nEuropean\ndata\ncenters...\n\n\nData\nSubject\nRights.\nCustomer\nmay\nrequest\naccess,\nrectification,\nerasure,\nor\nportability\nof\ntheir\npersonal\ndata.\nProvider\nmust\nrespond\nto\nsuch\nrequests\nwithin\n30\ndays\nand\nprovide\nmechanisms\nfor\nautomated\ndata\nexport...\n\n\nPrivacy\nPolicy\nUpdates.\nWe\ncollect\nand\nprocess\npersonal\ninformation\nin\naccordance\nwith\nour\nprivacy\npolicy.\nData\nprocessing\npurposes\ninclude\nservice\ndelivery,\nanalytics,\nand\ncompliance\nwith\nlegal\nobligations...\n\n\nCross-Border\nTransfers.\nAny\ntransfer\nof\npersonal\ndata\noutside\nthe\nEEA\nrequires\nadequate\nsafeguards\nincluding\nStandard\nContractual\nClauses\nor\nadequacy\ndecisions.\nProvider\nmaintains\ncurrent\ntransfer\nimpact\nassessments...\n\n\nGDPR\nCompliance\nChecklist.\nEnsure\nlawful\nbasis\nfor\nprocessing,\nimplement\ndata\nsubject\nrights,\nconduct\nprivacy\nimpact\nassessments\nfor\nhigh-risk\nprocessing\nactivities...\n\n\n\n\n\n\n\n\n\n\n\nFacets\nreveal\nthe\ncomplete\ndata\nlandscape\nbeyond\ntop-k\nsimilarity\ncutoffs.\nCounts\nshow\nthe\nfull\nscope\nof\nrelevant\ninformation,\nnot\njust\nwhat\nranked\nhighest.\nKey\ninsight:\nHigh\nfacet\ncounts\nfor\nsources\nwith\nfew/zero\nreturned\nchunks\nindicate\nvaluable\ninformation\nfiltered\nout\nby\nsimilarity\nranking.\nDecision\nframework:\n-\nHigh\nfacet\ncounts\nvs.\nlow\nreturned\nchunks:\ninvestigate\nwith\nsource\nfilters\n-\nOne\nsource\ndominates\nresults:\nconsider\nloading\nfull\ndocument\npages\n-\nClear\nclustering\npatterns:\napply\ntargeted\nfilters\nfor\nfocused\nsearch\nUse\ndocument_type,\nsource,\nand\nother\nmetadata\nfilters\nstrategically\nbased\non\nfacet\ndistributions.\n\n\nThe transformation:\nAgents gain peripheral vision of the entire data landscape. Facets reveal hidden documents that similarity search missed, enabling strategic exploration beyond the top-k cutoff.\nWhat Types of Facet Data Sources Exist?\n¶\nFacets can come from two primary sources: existing structured systems and AI-extracted metadata from unstructured documents.\nWhat Are Structured Systems for Facets?\n¶\nCRMs, ERPs, HR systems, and other business databases already contain rich structured data that can power faceted search. These systems track entities, relationships, and metadata that users often don't realize can be leveraged for search.\nHow Would This Work for Linear Ticket Search?\n¶\ndef\nsearch\n(\nquery\n:\nstr\n,\nteam\n:\nLiteral\n[\n\"Backend\"\n,\n\"Frontend\"\n,\n\"QA\"\n,\n\"DevOps\"\n]\n|\nNone\n=\nNone\n,\nstatus\n:\nLiteral\n[\n\"Open\"\n,\n\"Done\"\n,\n\"In Progress\"\n,\n\"Backlog\"\n]\n|\nNone\n=\nNone\n,\npriority\n:\nLiteral\n[\n\"High\"\n,\n\"Medium\"\n,\n\"Low\"\n,\n\"Urgent\"\n]\n|\nNone\n=\nNone\n,\nassignee\n:\nstr\n|\nNone\n=\nNone\n,\nn_results\n:\nint\n=\n10\n)\n->\ndict\n:\n\"\"\"\nSearch Linear tickets with faceted filtering.\nArgs:\nquery: Natural language search query\nteam: Filter by team\nstatus: Filter by status\npriority: Filter by priority\nassignee: Filter by assigned user\nn_results: Number of tickets to return\nReturns:\nDict with tickets, facets, and system instructions\n\"\"\"\npass\nWhen an agent searches\nsearch(\"API timeout issues\")\n, it gets:\n\n\n\n\nAPI\nGateway\ntimeout\nafter\n30s\non\nheavy\nload\n\n\nFixed\nby\nincreasing\ntimeout\nthresholds\nto\n60s\nand\noptimizing\nconnection\npooling.\nLoad\nbalancer\n504\nerrors\nreduced\nby\n95%...\n\n\n\n\nClient-side\ntimeout\nhandling\nfor\nslow\nAPI\nresponses\n\n\nImplemented\nretry\nlogic\nand\nuser\nfeedback\nfor\nAPI\ntimeouts.\nAdded\nexponential\nbackoff\nand\ncircuit\nbreaker\npattern...\n\n\n\n\nDatabase\nquery\noptimization\ncausing\nAPI\ndelays\n\n\nResolved\nN+1\nquery\nproblem\nby\nimplementing\nbatched\nqueries\nand\nadding\nproper\nindexes.\nAPI\nresponse\ntimes\nimproved\n3x...\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nFacets\nreveal\nmetadata\nclustering\npatterns\nacross\nteam,\nstatus,\npriority,\nand\nassignee\ndimensions.\nHigh\ncounts\nindicate\nwhere\nrelevant\ninformation\nconcentrates.\nKey\ninsight:\nWhen\nall\nreturned\nresults\nshare\ncharacteristics\n(like\nstatus=\"Done\"),\nfacets\noften\nreveal\nhidden\nrelevant\ndata\nwith\ndifferent\nvalues\nthat\nneed\ninvestigation.\nDecision\nframework:\n-\nAll\nresults\nshare\ntraits:\ncheck\nfacets\nfor\nhidden\ndifferent\nvalues\n(e.g.,\n\"Open\"\ntickets)\n-\nStrong\nclustering\npatterns:\napply\ntargeted\nfilters\nfor\nfocused\ninvestigation\n-\nUncertain\nrelevance:\nsurface\nmetadata\ndistributions\nto\nuser\nfor\nguidance\nCombine\nmultiple\nfilters\n(team\n+\nstatus\n+\npriority)\nto\nnarrow\nsearch\nscope\nstrategically.\n\n\nSimilarity Bias Alert\nAll 3 returned tickets are \"Done\" but facets show 5 \"Open\" tickets exist. Resolved tickets have better documentation and rank higher in similarity search, while active issues get filtered out. Call\nsearch(\"API timeout\", status=\"Open\")\nto find them.\nWhat Are Extracted Facets?\n¶\nCompanies like Extend and Reducto can perform structured data extraction over documents to create facets that don't naturally exist in the raw text.\nHow Would This Work for Contract Analysis?\n¶\ndef\nsearch\n(\nquery\n:\nstr\n,\nsignature_status\n:\nLiteral\n[\n\"Signed\"\n,\n\"Unsigned\"\n,\n\"Partially Signed\"\n]\n|\nNone\n=\nNone\n,\nproject\n:\nLiteral\n[\n\"Project Alpha\"\n,\n\"Project Beta\"\n,\n\"General Services\"\n]\n|\nNone\n=\nNone\n,\ndocument_type\n:\nLiteral\n[\n\"contract\"\n,\n\"amendment\"\n,\n\"renewal\"\n]\n|\nNone\n=\nNone\n,\nn_results\n:\nint\n=\n10\n)\n->\ndict\n:\n\"\"\"\nSearch legal contracts with AI-extracted faceted filtering.\nArgs:\nquery: Natural language search query\nsignature_status: Filter by signing status\nproject: Filter by project classification\ndocument_type: Filter by document type\nn_results: Number of contracts to return\nReturns:\nDict with contracts, facets, and system instructions\n\"\"\"\npass\nAn AI system first processes legal documents and extracts:\nDocument type detection\n: Uses classification to identify \"contract\" vs \"amendment\" vs \"renewal\"\nSignature extraction\n: Analyzes signature blocks to determine signed/unsigned status\nProject classification\n: Matches contract language to project codes or client names\nWhen an agent searches\nsearch(\"liability provisions\")\n, it gets:\n\n\n\n\nMaster\nService\nAgreement\n-\nACME\nCorp\n\n\nLimitation\nof\nLiability.\nIn\nno\nevent\nshall\neither\nparty's\naggregate\nliability\nexceed\nthe\ntotal\nfees\npaid\nunder\nthis\nAgreement\nin\nthe\ntwelve\n(12)\nmonths\npreceding\nthe\nclaim.\nThis\nlimitation\napplies\nto\nall\nclaims\nin\ncontract,\ntort,\nor\notherwise...\n\n\n\n\nStatement\nof\nWork\n-\nBeta\nIndustries\n\n\nLiability\nCap.\nProvider's\nliability\nis\nlimited\nto\ndirect\ndamages\nonly,\nnot\nto\nexceed\n$100,000\nper\nincident.\nConsequential,\nincidental,\nand\npunitive\ndamages\nare\nexcluded...\n\n\n\n\nAmendment\nto\nServices\nAgreement\n-\nGamma\nLLC\n\n\nModified\nLiability\nTerms.\nSection\n8.3\nis\nhereby\namended\nto\ninclude\njoint\nliability\nprovisions\nfor\nthird-party\nclaims\narising\nfrom\ndata\nprocessing\nactivities...\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nFacets\nexpose\nthe\ncomplete\nmetadata\nlandscape,\nrevealing\ninformation\npatterns\nbeyond\nsimilarity\nrankings.\nExtracted\nfacets\nshow\nclustering\nacross\nsignature\nstatus,\nproject,\nand\ndocument\ntype.\nKey\ninsight:\nWhen\nreturned\nresults\nshow\nbias\n(e.g.,\nall\nsigned\ncontracts),\nfacets\noften\nreveal\ncritical\nhidden\ndata\nwith\ndifferent\ncharacteristics\nthat\nneed\nattention.\nDecision\nframework:\n-\nResults\nshow\nbias:\ninvestigate\nfacet\nvalues\nnot\nrepresented\nin\ntop-k\nresults\n-\nHigh\nclustering\nin\nfacets:\nfocused\nfiltering\nmore\neffective\nthan\nbroad\nsearch\n-\nClear\nrelevance\npatterns:\napply\nfilters\nautonomously\nfor\ntargeted\ninvestigation\nUse\nsignature_status,\nproject,\ndocument_type\nfilters\nstrategically\nbased\non\nfacet\ndistributions\nand\nbusiness\npriorities.\n\n\nCritical Documents Missing\nAll 3 returned contracts are signed, but facets reveal 12 unsigned contracts exist in the broader result set. Signed contracts have better-developed liability language (higher similarity scores), while unsigned contracts with liability provisions didn't make the top-k cut. The agent should call\nsearch(\"liability\", signature_status=\"Unsigned\")\nto examine those hidden contracts - they need attention before signing.\nWhy Does Agent Persistence Change Everything?\n¶\nThis is the paradigm shift most teams miss: agentic systems are incredibly persistent. Given enough budget and time, they'll keep searching until they find what they need. This fundamentally changes how we should think about search system design. This persistence enables continuous feedback loops that improve system performance over time.\nTraditional RAG optimized for humans who make one query and expect comprehensive results. Miss something? The human has to think of a different search term or give up. This pressure created the \"stuff everything relevant into the first response\" mentality that led to context window bloat and degraded performance.\nAgents operate differently. They're methodical, systematic, and don't get frustrated. Show them a facet indicating 47 relevant documents in a category they haven't explored? They'll investigate. Reveal that unsigned contracts contain different terms than signed ones? They'll filter specifically for unsigned contracts and analyze the gaps.\nThe strategic implication:\nYou don't need perfect recall on query\n#1\n. You need to give agents enough context about the information landscape that they can systematically traverse it. Each faceted search reveals new dimensions to explore, creating an implicit knowledge graph that agents can navigate without you having to explicitly define node relationships.\nThis matches\nAnthropic's observation\nthat effective tools increase the \"surface area over which agents can be effective.\" Rather than trying to solve everything in one perfect retrieval, facets guide agents through multiple successful strategies until they achieve comprehensive coverage. The goal isn't perfect tools—it's tools that help agents pursue diverse paths to success.\nConsider the contract example: the agent didn't need to find all liability provisions in one search. It needed to discover that liability provisions cluster around document types (contracts vs. amendments), signing status (signed vs. unsigned), and projects (Alpha vs. Beta vs. General). Armed with these facets, it can systematically explore each combination until it has complete coverage.\nThis transforms the database from a passive responder to an active reasoning partner. Facets surface patterns and gaps that agents can leverage but humans would never think to ask for directly.\nHow Do We Evolve from Chunks to Context?\n¶\nWe've traced the evolution from basic chunks to sophisticated context engineering across four levels. Level 1 gives agents raw text but leaves them blind to metadata patterns. Level 2 adds source tracking, enabling strategic document loading and proper citations. Level 3 optimizes multi-modal content formatting so agents can reason about tables, images, and structured data. Level 4 introduces facets that reveal the complete data landscape, transforming search from similarity-based retrieval to exploration.\nThe progression shows a clear pattern:\neach level adds peripheral vision about the information space.\nAgents don't just get better answers—they get better context about what questions to ask next. Tool responses become teaching moments, showing agents how to think about the data systematically.\nThe business impacts are measurable: 90% reduction in clarification questions, 75% reduction in expert escalations, 95% reduction in 504 errors, 4x improvement in resolution times. But the deeper transformation is architectural—databases evolve from passive storage to active reasoning partners that surface patterns human users would never think to request.\nWhat Comes Next?\n¶\nThis is the first post in a series on context engineering. I started here because it's the most accessible entry point—something every team can experiment with today.\nWhy this is the lowest hanging fruit:\nContext engineering doesn't require rebuilding your infrastructure or redesigning your tools. It's primarily about better string formatting—wrapping responses in XML, adding source metadata, including strategic system instructions. Low technical lift, potentially massive business impact.\nThe immediate action:\nGo audit your current RAG implementation. Look at what your tools actually return. Are you giving agents peripheral vision of the data landscape, or just the highest-scoring chunks? Most teams can implement Level 2 (source metadata) in an afternoon.\nFor rapid validation:\nUse the\nprototyping methodology\nto test different tool response levels quickly. Claude Code's project runner lets you experiment with minimal chunks vs faceted responses without building infrastructure—you can discover which level your use case needs through folder-based testing.\nCollaborative optimization:\nOne of Anthropic's most powerful insights is using Claude to optimize its own tools. After building your initial tools, have Claude analyze the tool responses, suggest improvements to the schemas and descriptions, and even generate better evaluation tasks. The tools that are most ergonomic for agents often end up being surprisingly intuitive for humans too.\nAdoption will follow the usual pattern:\nThe teams building agents today will implement context engineering first, then the tooling will catch up. Vector databases are already adding facet support (TurboPuffer ships facets and aggregations), but you don't need to wait for perfect tooling to start.\nTool responses become teaching moments.\nThe XML structures and system instructions in your tool responses directly influence how agents think about subsequent searches. Design them intentionally. As\nAnthropic's engineering team notes\n, effective tools help agents pursue diverse successful strategies by providing meaningful context that guides future reasoning patterns.\nNext in this series: Advanced faceting strategies, when to use structured vs. extracted metadata, and measuring the business impact of context engineering improvements. For additional insights on building effective agent tools, see\nAnthropic's comprehensive guide\non writing tools for agents. For those looking to dive deeper into RAG optimization, check out my posts on\nRAG low-hanging fruit improvements\nand\nsix key strategies for improving RAG\n.", "metadata": { "title": "Beyond Chunks: Why Context Engineering is the Future of RAG - Jason Liu", "description": "Learn how to move beyond traditional chunk-based RAG to context engineering that gives agents peripheral vision of data landscapes. Explore four levels from basic chunks to faceted search with business outcomes and practical implementation strategies.", "keywords": null, "author": "Jason Liu", "og:type": "website", "og:title": "Beyond Chunks: Why Context Engineering is the Future of RAG - Jason Liu", "og:description": "Learn how to move beyond traditional chunk-based RAG to context engineering that gives agents peripheral vision of data landscapes. Explore four levels from basic chunks to faceted search with business outcomes and practical implementation strategies.", "og:image": "https://jxnl.co/assets/images/social/writing/2025/08/27/facets-context-engineering.png", "og:image:type": "image/png", "og:image:width": "1200", "og:image:height": "630", "og:url": "https://jxnl.co/writing/2025/08/27/facets-context-engineering/" }, "paywall": { "listed_paid": false, "detected": false, "marker": "", "public_only": false, "policy": "付费/会员内容只保留页面公开可见部分，不绕过付费墙" }, "crawl": { "success": true, "status_code": 200, "error": "" }, "code_blocks": [ { "file": "attachments/d43a50d5bd0e/code/body-000.txt", "chars": 259, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-001.txt", "chars": 548, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-002.txt", "chars": 482, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-003.txt", "chars": 1180, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-004.txt", "chars": 1575, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-005.txt", "chars": 1440, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-006.txt", "chars": 1132, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-007.txt", "chars": 172, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-008.txt", "chars": 647, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-009.txt", "chars": 2836, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-010.txt", "chars": 709, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-011.txt", "chars": 2482, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-012.txt", "chars": 734, "language": "text" }, { "file": "attachments/d43a50d5bd0e/code/body-013.txt", "chars": 2448, "language": "text" } ], "images": [], "audio": [], "videos": [], "links": [ { "href": "https://github.com/jxnl/blog/edit/main/docs/writing/posts/context-engineering-tool-response.md", "label": "", "type": "a" }, { "href": "https://github.com/jxnl/blog/raw/main/docs/writing/posts/context-engineering-tool-response.md", "label": "", "type": "a" }, { "href": "https://jxnl.co/writing/2025/05/29/systematically-improving-rag-with-raindrop-and-oleve/", "label": "systematically improving RAG applications", "type": "a" }, { "href": "https://jxnl.co/writing/2025/06/11/rag-anti-patterns-with-skylar-payne/", "label": "common RAG anti-patterns", "type": "a" }, { "href": "https://jxnl.co/writing/2025/09/11/coding-series-index/", "label": "Coding Agents Speaker Series", "type": "a" }, { "href": "https://improvingrag.com/", "label": "improvingrag.com", "type": "a" }, { "href": "https://www.anthropic.com/engineering/writing-tools-for-agents", "label": "Anthropic explains", "type": "a" }, { "href": "https://github.com/jxnl/instructor/issues/1", "label": "#1", "type": "a" }, { "href": "https://jxnl.co/writing/2025/09/04/context-engineering-rapid-agent-prototyping/", "label": "prototyping methodology", "type": "a" }, { "href": "https://jxnl.co/writing/2024/05/11/low-hanging-fruit-for-rag-search/", "label": "RAG low-hanging fruit improvements", "type": "a" }, { "href": "https://jxnl.co/writing/2024/11/04/how-to-improve-rag-applications-6-proven-strategies/", "label": "six key strategies for improving RAG", "type": "a" } ], "repair_version": 2, "repaired_at": "2026-10-14T10:52:56Z", "source_url": "https://jxnl.co/writing/2025/08/27/facets-context-engineering/", "papers": [], "actual_video_files": [], "body_chars": 33465, "expected_body_images": 0, "discovery_status": "ok", "delivery_status": "ok", "missing_reason": "", "raw_html": "attachments/d43a50d5bd0e/pages/source.html", "local_html": "attachments/d43a50d5bd0e/pages/article.html", "body_base_path": "attachments/d43a50d5bd0e/pages/", "body_markdown_path": "attachments/d43a50d5bd0e/pages/article.md" }