Kimi K3 + 图工程：降低85%成本并提升18%准确率

✍ Noisy🕐 2026-07-23📦 17.2 KB 🟢 已读 𝕏 文章列表

文章介绍了通过结合 Kimi K3 模型与图工程构建 AI 系统的方法。相比传统 RAG，该架构利用知识图谱存储实体关系，能处理复杂推理，实现成本降低85%和准确率提升18%。文章引用微软 GraphRAG 等研究，详细阐述了如何从零开始构建该系统。

# Kimi K3 + Graph Engineering: 85% lower token costs and 18% better accuracy. Full guide to building t **作者**: Noisy **日期**: 2026-07-22T17:31:11.000Z **来源**: [https://x.com/noisyb0y1/status/2079982601498964218](https://x.com/noisyb0y1/status/2079982601498964218) --- ![Image](/doc/3326/image/img_e97b3398a717.jpg) Most people use AI like an expensive search engine. Open a chat, ask a question, get an answer, close the tab. Next day they start from zero because the AI remembers nothing. But there are developers making $10,000-20,000 a month simply because their AI system responds twice as fast, gives more accurate answers and costs 85% less than their competitors. They're not using some secret model. They built the right architecture around a regular model. It's called Kimi K3 + Graph Engineering. Microsoft spent years proving it works - 85% lower costs, 18% better accuracy. Here's how to build this yourself from scratch in a week. Why regular RAG stops working at some point Most developers build AI systems the same way. User asks something, the system searches through documents, finds similar text fragments, model generates an answer. Works fine for simple questions. Falls apart completely for complex ones. Ask "why did our sales drop in March?" and regular RAG finds documents with the words "sales" and "March." It finds fragments. It doesn't find the chain of causes. ``` Regular RAG answer: Here are 5 documents mentioning sales in March. Graph Engineering answer: Sales dropped because of a release delay caused by a supplier problem triggered by a warehouse failure which generated negative reviews which reduced conversion by 23%. ``` Same model. Same data. Completely different result - because one system searches text and the other searches connections between real facts. This is what Microsoft, Stanford and Anthropic all independently figured out. And it's why the developers who understand this are moving faster than everyone else. What a knowledge graph actually is A knowledge graph stores information as triples: ``` Subject → Relation → Object ``` Real examples: ``` Kimi K3 → developed by → Moonshot AI Kimi K3 → context window → 1 million tokens Microsoft → built → GraphRAG GraphRAG → reduces costs by → 85% Anthropic → created → Claude Claude → supports → MCP ``` Every piece of information is an explicit connection between two entities. Not a paragraph of text that might contain this information somewhere - a structured fact you can query directly. ``` Regular database: Table of companies Table of products No explicit connections between them Knowledge graph: Company → created → Product Product → competes with → Other Product Other Product → owned by → Other Company Company → invested in → Other Company ``` The graph doesn't just store facts. It stores how facts connect to each other. That's what makes complex reasoning possible - and what regular RAG can never do no matter how good the model is. Stanford AI Lab defines a knowledge graph as a structured database where information is represented as a network of entities and relationships in subject-relation-object triples. Used in search, recommendations and tasks where you need to find indirect connections. > ai.stanford.edu/blog/introduction-to-knowledge-graphs ![Image](/doc/3326/image/img_2ed66b7544cd.jpg) Why Kimi K3 is the right model for this architecture Most models have 128,000-200,000 token context windows. Kimi K3 has one million. This isn't just an impressive number - it's an architectural advantage specifically for Graph Engineering. A graph returns subgraphs, chains of evidence, lists of connected entities. All of this takes up space in the context window. With a small context you have to cut the graph. With one million tokens the entire relevant part of the graph fits in one session. ``` Kimi K3 architecture: 2.8 trillion total parameters 896 experts in MoE, 16 active per token 1,048,576 token context window Native image analysis Kimi Delta Attention for long sequences Attention Residuals for preserving signals between layers ``` > kimi.com/blog/kimi-k3 ![Image](/doc/3326/image/img_ad924511be12.jpg) Kimi Delta Attention is a hybrid mechanism that reduces the cost of working with long sequences. For Graph Engineering this means the system can pass the model large subgraphs, long evidence lists, dozens of documents and repository structure without catastrophic cost increases. But even one million tokens is temporary memory. After the session everything disappears. ``` 1M token context = large working surface per session Knowledge graph = permanent structured memory between sessions ``` Kimi K3 gives scale and reasoning. Graph Engineering gives memory and structure. Together they solve different problems at the same time. Document 1 - Microsoft GraphRAG > github.com/microsoft/graphrag > arxiv.org/abs/2603.22528 ![Image](/doc/3326/image/img_90875796e38e.jpg) Microsoft built GraphRAG and open-sourced it. The numbers from their research are the most concrete evidence available for what Graph Engineering actually delivers versus regular RAG. The architecture converts unstructured text into a full knowledge graph: ``` Load documents ↓ Chunk documents ↓ Extract entities and relations ↓ Build graph ↓ Detect communities ↓ Generate community reports ↓ Embed entities and reports ↓ Local Search / Global Search ``` Key insight from Microsoft: regular RAG answers local questions well - find information about this specific entity. It fails on global questions - what are the main patterns across these 10,000 documents, what connects these events across the entire dataset. Graph Engineering answers both. ``` Local Search | what happened with supplier X in March | finds specific node and its connections Global Search | what are the main risk patterns | across all our supplier relationships | finds patterns across the entire graph ``` Real numbers from the ChatP&ID research: ``` Accuracy improvement | 18% higher than raw document approach Token cost reduction | 85% lower than loading structured files directly Cost per task | approximately $0.004 in tested configuration ``` Document 2 - Three modes of combining LLM and Knowledge Graph > arxiv.org/abs/2306.08302 One of the strongest theoretical papers on combining language models and knowledge graphs describes three modes: ``` Mode 1 - KG-enhanced LLM Graph gives the model facts and structure Model generates better answers Mode 2 - LLM-augmented KG Model creates, cleans and expands the graph Graph gets better over time Mode 3 - Synergized LLM + KG Graph and model improve each other mutually Most powerful mode ``` For Kimi K3 + Graph Engineering the third mode works best. Kimi K3 extracts new facts and adds them to the graph. The graph gives Kimi K3 structured context for reasoning. The cycle repeats and the system gets better with every iteration. Document 3 - Relational Memory for language models > direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00476 MIT Press, Transactions of the Association for Computational Linguistics. The research shows what happens when you connect a language model to relational memory - a knowledge graph of relationships instead of text fragments. ``` Text context ↓ Extract relevant relations from graph ↓ Relational Memory ↓ Language model ↓ More coherent and accurate generation ``` Key finding: models with access to explicit relationship structures produce more coherent text and make fewer logical errors than models working from text alone. This is the scientific explanation for why Graph Engineering works. The model doesn't have to infer relationships from text. The relationships are explicit in the graph. The model uses them directly. Published under CC BY 4.0 - can be freely used with attribution. Document 4 - Scaling Laws for Knowledge Graph Engineering > arxiv.org/abs/2505.16276 Research that compared 26 open-source models on knowledge graph engineering tasks. The conclusion is one of the most important findings in the field: ``` Larger model + bad graph | worse results Smaller model + good graph | better results ``` The right graph beats the bigger model. Every time. Same conclusion Microsoft reached with GraphRAG and Anthropic reached with Claude Code - the system around the model determines the output more than the model itself. Graph Engineering is the most concrete implementation of that principle. Document 5 - Agent-as-a-Graph > arxiv.org/abs/2511.18194 This paper shows how to represent not just knowledge but agents and tools as nodes in a graph. ``` User question ↓ Graph of capabilities ↓ Select research agent ↓ Select GitHub tool ↓ Select ArXiv tool ↓ Select graph database tool ↓ Kimi K3 coordinates execution ``` Authors report Recall@5 improvement of 14.9% and nDCG@5 improvement of 14.6% versus comparable retrievers on LiveMCPBenchmark. For Kimi K3 this means the graph can manage not just knowledge but which agent and which tool to use for each specific task. Document 6 - Kimi Code and Agent SDK > github.com/MoonshotAI/kimi-code > github.com/MoonshotAI/kimi-agent-sdk Kimi Code is a terminal agent that can: ``` Read and edit code Run shell commands Search files Fetch web pages Analyze the result of each step Independently choose the next action Supports MCP Lifecycle hooks Approval modes ``` Kimi Agent SDK lets you use Kimi Code as the foundation of your own agent. It reuses the tools, skills and MCP server configuration from Kimi Code. For Graph Engineering this is a ready-made execution layer. The graph provides structured knowledge and reasoning paths. Kimi Code takes actions in the real environment. The SDK ties everything together. The full system architecture ``` Step 1 - Ingestion Layer PDFs, websites, databases, APIs, Slack, Notion ↓ Step 2 - Extraction Layer Kimi K3 extracts entities and relationships { "entity": "Kimi K3", "type": "AI model", "relations": [ { "predicate": "developed_by", "object": "Moonshot AI", "confidence": 0.98 } ] } ↓ Step 3 - Resolution Layer System resolves whether these are the same entity: Moonshot AI / Moonshot / Beijing Moonshot / 月之暗面 ↓ Step 4 - Graph Storage Neo4j / Memgraph / Amazon Neptune / PostgreSQL ↓ Step 5 - Retrieval Layer Vector search + Entity lookup + Path search Community search + Temporal filtering ↓ Step 6 - Agent Layer Kimi K3: Plans the approach Chooses the right tool Generates Cypher or SPARQL queries Analyzes subgraph Runs web research Draws conclusions Identifies the next knowledge gap ↓ Step 7 - Verification Layer Checks evidence coverage Finds contradictions Evaluates confidence Verifies sources ↓ Step 8 - Graph Update New facts added to graph Contradictions flagged Old information gets timestamp ``` This is a closed knowledge-action loop. Kimi K3 doesn't just read the graph. It identifies what's missing, forms sub-questions, selects a node or subgraph, runs a search, checks the result, adds a new fact and re-evaluates the hypothesis. Five prompts that run the entire pipeline Graph Engineering doesn't replace prompts. It uses them at each specific stage. Prompt 1 - Extraction ``` Extract all organizations, people, products and events. For each entity return: - canonical_name - type - description - source For each relationship return: - source_entity - relation_type - target_entity - evidence - confidence_score ``` Prompt 2 - Normalization ``` Compare the following entities. Determine whether they refer to: - the same entity - related but different entities - unrelated entities Return canonical name and explanation. Do not merge entities without clear evidence. ``` Prompt 3 - Graph Query ``` Translate the user question into a Cypher query. Use only relationships present in the schema. Do not invent labels or properties. Return the query and explanation of the logic. ``` Prompt 4 - Grounded Answer ``` Answer using only the retrieved graph paths. For every conclusion: - identify the supporting nodes - identify the relationship path - state uncertainty clearly - do not infer causation from correlation ``` Prompt 5 - Graph Maintenance ``` Compare new facts with the existing graph. Classify each fact as: - new - duplicate - contradiction - update - uncertain Do not overwrite existing facts without evidence. ``` Five businesses you can build on this system 1 - Investment Research ``` Company ├── founders and their previous projects ├── investors and their portfolio ├── competitors and their strategies ├── legal risks ├── patents ├── job openings as strategy signal └── financial metrics over time ``` Kimi K3 reads reports and news. The graph shows hidden connections between companies, shared investors, supplier dependencies and personnel signals. Clients: investment funds, law firms, M&A consultants. $2,000-10,000 per client per month. 2 - Engineering Intelligence ``` GitHub commits + Jira tickets + Linear tasks ↓ Graph of Engineering Work ↓ 5x faster incident detection 50% less meeting time Automatic release notes ``` > anthropic.com/customers/graph LaunchNotes already sells this. The market is every engineering team using more than one project management tool. 3 - Scientific Research Engine ``` Paper → author → institution → method → dataset → result ↓ Which GraphRAG methods use community detection, on which datasets they were tested and which papers contradict each other ``` Regular search gives a list of documents. A graph system builds a map of evidence and contradictions. 4 - Cybersecurity Threat Graph ``` IP → domain → certificate → malware → campaign → actor ↓ Kimi K3 analyzes threat reports Maps indicators across sources Explains attack paths Updates threat graph automatically ``` 5 - Personal Knowledge OS ``` People ↔ Meetings ↔ Projects ↔ Documents ↔ Decisions ↔ Promises ↓ Questions Kimi K3 can answer: Who is blocking this task? What decision did we make and what was it based on? What did I promise to do this month? Which old assumptions are no longer valid? ``` Where to start this week ``` Day 1 | install Neo4j locally | read DSPy README | github.com/stanfordnlp/dspy | understand the difference between prompting | and programming a system Day 2 | take one set of documents | run Kimi K3 via API | extract first entities and relationships | save to Neo4j Day 3 | build first retrieval layer | combine vector search and graph search | test on a complex question RAG can't answer Day 4 | connect Kimi Code via MCP | github.com/MoonshotAI/kimi-code | let the agent read the graph and add new facts | run first knowledge-action loop Day 5 | measure the result | compare accuracy vs regular RAG | compare token costs | find first real client use case ``` What Microsoft, Stanford and Anthropic figured out together ``` Microsoft GraphRAG | graph cuts costs 85%, improves accuracy 18% Stanford DSPy | model is a node in a graph, not the center Stanford Scaling Laws | smaller model + good graph beats bigger model MIT Press Research | explicit relationships improve coherence and accuracy Anthropic LaunchNotes | 5x faster incident detection, 50% less meeting time ``` Kimi K3 is the engine. Graph Engineering is the map, the memory and the coordinate system. Without the engine the graph doesn't act. Without the graph the engine moves very fast but doesn't always know where it's going. Most developers will keep building regular RAG and wonder why complex questions give bad answers. A few will spend a week building a graph system and never go back to searching text. You build your own life - so choose the right path. / If this was useful - follow / ## 相关链接 - [Noisy](https://x.com/noisyb0y1) - [@noisyb0y1](https://x.com/noisyb0y1) - [29K](https://x.com/noisyb0y1/status/2079982601498964218/analytics) - [ai.stanford.edu/blog/introduction-to-knowledge-graphs](https://ai.stanford.edu/blog/introduction-to-knowledge-graphs) - [kimi.com/blog/kimi-k3](https://kimi.com/blog/kimi-k3) - [github.com/microsoft/graphrag](https://github.com/microsoft/graphrag) - [arxiv.org/abs/2603.22528](https://arxiv.org/abs/2603.22528) - [arxiv.org/abs/2306.08302](https://arxiv.org/abs/2306.08302) - [direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00476](https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00476) - [arxiv.org/abs/2505.16276](https://arxiv.org/abs/2505.16276) - [arxiv.org/abs/2511.18194](https://arxiv.org/abs/2511.18194) - [github.com/MoonshotAI/kimi-code](https://github.com/MoonshotAI/kimi-code) - [github.com/MoonshotAI/kimi-agent-sdk](https://github.com/MoonshotAI/kimi-agent-sdk) - [anthropic.com/customers/graph](https://anthropic.com/customers/graph) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [1:31 AM · Jul 23, 2026](https://x.com/noisyb0y1/status/2079982601498964218) - [29K Views](https://x.com/noisyb0y1/status/2079982601498964218/analytics) - [View quotes](https://x.com/noisyb0y1/status/2079982601498964218/quotes) --- *导出时间: 2026/7/23 13:14:12* --- ## 中文翻译 # Kimi K3 + 图工程：Token 成本降低 85%，准确率提升 18%。从零构建完整指南 **作者**: Noisy **日期**: 2026-07-22T17:31:11.000Z **来源**: [https://x.com/noisyb0y1/status/2079982601498964218](https://x.com/noisyb0y1/status/2079982601498964218) --- ![Image](/doc/3326/image/img_e97b3398a717.jpg) 大多数人把 AI 当作昂贵的搜索引擎。打开聊天框，问个问题，得到答案，关掉标签页。第二天他们又从零开始，因为 AI 什么也记不住。但有些开发者每月能赚 1 万到 2 万美元，仅仅是因为他们的 AI 系统响应速度快一倍，答案更准确，而且成本比竞争对手低 85%。他们并没有使用什么秘密模型。他们在普通模型周围构建了正确的架构。这就是 Kimi K3 + 图工程。微软花了数年时间证明它的有效性——成本降低 85%，准确率提升 18%。以下是如何在一周内从零开始构建这个系统的方法。为什么普通的 RAG 在某个阶段会失效大多数开发者构建 AI 系统的方式都一样。用户提问，系统搜索文档，找到相似的文本片段，模型生成答案。这对简单问题很有效。对于复杂问题则完全崩溃。问“为什么我们的三月份销售额下降了？”，普通的 RAG 会找到包含“销售”和“三月”这两个词的文档。它找到了片段。但它找不到因果链条。 ``` Regular RAG answer: Here are 5 documents mentioning sales in March. Graph Engineering answer: Sales dropped because of a release delay caused by a supplier problem triggered by a warehouse failure which generated negative reviews which reduced conversion by 23%. ``` 同样的模型。同样的数据。完全不同的结果——因为一个系统搜索文本，另一个搜索真实事实之间的连接。这是微软、斯坦福和 Anthropic 各自独立发现的。这也是为什么理解这一点的开发者比其他人跑得更快。知识图谱到底是什么知识图谱以三元组的形式存储信息： ``` Subject → Relation → Object ``` 真实示例： ``` Kimi K3 → developed by → Moonshot AI Kimi K3 → context window → 1 million tokens Microsoft → built → GraphRAG GraphRAG → reduces costs by → 85% Anthropic → created → Claude Claude → supports → MCP ``` 每一条信息都是两个实体之间的显式连接。不是一段可能包含该信息的文本段落——而是一个可以直接查询的结构化事实。 ``` Regular database: Table of companies Table of products No explicit connections between them Knowledge graph: Company → created → Product Product → competes with → Other Product Other Product → owned by → Other Company Company → invested in → Other Company ``` 图谱不仅存储事实。它还存储事实之间如何连接。这正是使复杂推理成为可能的原因——也是无论模型多好，普通 RAG 都永远无法做到的。斯坦福 AI 实验室将知识图谱定义为一个结构化数据库，其中信息以主体-关系-客体三元组形式的实体和关系网络来表示。用于搜索、推荐以及需要找到间接连接的任务。 > ai.stanford.edu/blog/introduction-to-knowledge-graphs ![Image](/doc/3326/image/img_2ed66b7544cd.jpg) 为什么 Kimi K3 是适合这种架构的正确模型大多数模型拥有 128,000 到 200,000 token 的上下文窗口。Kimi K3 拥有一百万。这不仅仅是一个令人印象深刻的数字——这是专门针对图工程的架构优势。图谱返回子图、证据链、连接的实体列表。所有这些都会占用上下文窗口的空间。如果上下文很小，你就不得不裁剪图谱。如果有一百万 token，整个相关的图谱部分都能放入一个会话中。 ``` Kimi K3 architecture: 2.8 trillion total parameters 896 experts in MoE, 16 active per token 1,048,576 token context window Native image analysis Kimi Delta Attention for long sequences Attention Residuals for preserving signals between layers ``` > kimi.com/blog/kimi-k3 ![Image](/doc/3326/image/img_ad924511be12.jpg) Kimi Delta Attention 是一种混合机制，降低了处理长序列的成本。对于图工程来说，这意味着系统可以向模型传递大型子图、长证据列表、数十个文档和仓库结构，而不会导致灾难性的成本增加。但即使是一百万 token 也只是临时记忆。会话结束后一切都会消失。 ``` 1M token context = large working surface per session Knowledge graph = permanent structured memory between sessions ``` Kimi K3 提供规模和推理能力。图工程提供记忆和结构。它们结合在一起同时解决了不同的问题。文档 1 - Microsoft GraphRAG > github.com/microsoft/graphrag > arxiv.org/abs/2603.22528 ![Image](/doc/3326/image/img_90875796e38e.jpg) 微软构建了 GraphRAG 并将其开源。他们研究中的数据是图工程相比普通 RAG 实际能带来什么的现有最具体证据。该架构将非结构化文本转化为完整的知识图谱： ``` Load documents ↓ Chunk documents ↓ Extract entities and relations ↓ Build graph ↓ Detect communities ↓ Generate community reports ↓ Embed entities and reports ↓ Local Search / Global Search ``` 微软的关键洞察：普通 RAG 很好地回答局部问题——查找关于该特定实体的信息。它在全局问题上失败——这 10,000 份文档中的主要模式是什么，是什么连接了整个数据集中的这些事件。图工程两者都能回答。 ``` Local Search | what happened with supplier X in March | finds specific node and its connections Global Search | what are the main risk patterns | across all our supplier relationships | finds patterns across the entire graph ``` 来自 ChatP&ID 研究的真实数据： ``` Accuracy improvement | 18% higher than raw document approach Token cost reduction | 85% lower than loading structured files directly Cost per task | approximately $0.004 in tested configuration ``` 文档 2 - 结合 LLM 和知识图谱的三种模式 > arxiv.org/abs/2306.08302 关于结合语言模型和知识图谱的最强理论论文之一描述了三种模式： ``` Mode 1 - KG-enhanced LLM Graph gives the model facts and structure Model generates better answers Mode 2 - LLM-augmented KG Model creates, cleans and expands the graph Graph gets better over time Mode 3 - Synergized LLM + KG Graph and model improve each other mutually Most powerful mode ``` 对于 Kimi K3 + 图工程，第三种模式效果最好。Kimi K3 提取新事实并将它们添加到图谱中。图谱为 Kimi K3 的推理提供结构化上下文。这个循环不断重复，系统在每次迭代中变得更好。文档 3 - 语言模型的关系记忆 > direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00476 MIT Press, 计算语言学协会汇刊。该研究展示了将语言模型连接到关系记忆——即关系的知识图谱而非文本片段——时会发生什么。 ``` Text context ↓ Extract relevant relations from graph ↓ Relational Memory ↓ Language model ↓ More coherent and accurate generation ``` 关键发现：与仅基于文本工作的模型相比，能够访问显式关系结构的模型能产生更连贯的文本，并且犯更少的逻辑错误。这是图工程之所以有效的科学解释。模型不必从文本中推断关系。关系在图谱中是显式的。模型直接使用它们。根据 CC BY 4.0 发布——可署名后自由使用。文档 4 - 知识图工程的扩展定律 > arxiv.org/abs/2505.16276 该研究在知识图工程任务上比较了 26 个开源模型。其结论是该领域最重要的发现之一： ``` Larger model + bad graph | worse results Smaller model + good graph | better results ``` 正确的图谱胜过更大的模型。每一次。这与微软使用 GraphRAG 以及 Anthropic 使用 Claude Code 得出的结论相同——模型周围的系统比模型本身更能决定输出。图工程是该原则最具体的实现。文档 5 - 即图的智能体 > arxiv.org/abs/2511.18194 这篇论文展示了如何不仅将知识，还将智能体和工具表示为图谱中的节点。 ``` User question ↓ Graph of capabilities ↓ Select research agent ↓ Select GitHub tool ↓ Select ArXiv tool ↓ Select graph database tool ↓ Kimi K3 coordinates execution ``` 作者报告称，在 LiveMCPBenchmark 上，与可比的检索器相比，Recall@5 提高了 14.9%，nDCG@5 提高了 14.6%。对于 Kimi K3 来说，这意味着图谱不仅可以管理知识，还可以管理针对每个特定任务使用哪个智能体和哪个工具。文档 6 - Kimi Code 和 Agent SDK > github.com/MoonshotAI/kimi-code > github.com/MoonshotAI/kimi-agent-sdk Kimi Code 是一个终端智能体，它可以： ``` Read and edit code Run shell commands Search files Fetch web pages Analyze the result of each step Independently choose the next action Supports MCP Lifecycle hooks Approval modes ``` Kimi Agent SDK 让你可以使用 Kimi Code 作为你自己的智能体的基础。它复用了 Kimi Code 的工具、技能和 MCP 服务器配置。对于图工程来说，这是一个现成的执行层。图谱提供结构化知识和推理路径。Kimi Code 在真实环境中采取行动。SDK 将一切连接在一起。完整的系统架构 ``` Step 1 - Ingestion Layer PDFs, websites, databases, APIs, Slack, Notion ↓ Step 2 - Extraction Layer Kimi K3 extracts entities and relationships { "entity": "Kimi K3", "type": "AI model", "relations": [ { "predicate": "developed_by", "object": "Moonshot AI", "confidence": 0.98 } ] } ↓ Step 3 - Resolution Layer System resolves whether these are the same entity: Moonshot AI / Moonshot / Beijing Moonshot / 月之暗面 ↓ Step 4 - Graph Storage Neo4j / Memgraph / Amazon Neptune / PostgreSQL ↓ Step 5 - Retrieval Layer Vector search + Entity lookup + Path search Community search + Temporal filtering ↓ Step 6 - Agent Layer Kimi K3: Plans the approach Chooses the right tool Generates Cypher or SPARQL queries Analyzes subgraph Runs web research Draws conclusions Identifies the next knowledge gap ↓ Step 7 - Verification Layer Checks evidence coverage Finds contradictions Evaluates confidence Verifies sources ↓ Step 8 - Graph Update New facts added to graph Contradictions flagged Old information gets timestamp ``` 这是一个封闭的知识-行动循环。Kimi K3 不仅读取图谱。它识别缺失的内容，形成子问题，选择一个节点或子图，运行搜索，检查结果，添加新事实并重新评估假设。运行整个管道的五个提示词图工程并不取代提示词。它在每个特定阶段使用它们。提示词 1 - 提取 ``` Extract all organizations, people, products and events. For each entity return: - canonical_name - type - description - source For each relationship return: - source_entity - relation_type - target_entity - evidence - confidence_score ``` 提示词 2 - 归一化 ``` Compare the following entities. Determine whether they refer to: - the same entity - related but different entities - unrelated entities Return canonical name and explanation. Do not merge entities without clear evidence. ``` 提示词 3 - 图谱查询 ``` Translate the user question into a Cypher query. Use only relationships present in the schema. Do not invent labels or properties. Return the query and explanation of the logic. ``` 提示词 4 - 有依据的答案 ``` Answer using only the retrieved graph paths. For every conclusion: - identify the supporting nodes - identify the relationship path - state uncertainty clearly - do not infer causation from correlation ``` 提示词 5 - 图谱维护 ``` Compare new facts with the existing graph. Classify each fact as: - new - duplicate - contradiction - update - uncertain Do not overwrite existing facts without evidence. ``` 你可以在这个系统上建立的五项业务 1 - 投资研究 ``` Company ├── founders and their previous projects ├── investors and their portfolio ├── competitors and their strategies ├── legal risks ├── patents ├── job openings as strategy signal └── financial metrics over time ``` Kimi K3 阅读报告和新闻。图谱显示公司之间的隐藏连接、共同投资者、供应商依赖关系和人员信号。客户：投资基金、律师事务所、并购顾问。每位客户每月 2,000-10,000 美元。 2 - 工程情报 ``` GitHub commits + Jira tickets + Linear tasks ↓ Graph of Engineering Work ↓ 5x faster incident detection 50% less meeting time Automatic release notes ``` > anthropic.com/customers/graph LaunchNotes 已经在销售这个了。市场是所有使用不止一个项目管理工具的工程团队。 3 - 科学研究引擎 ``` Paper → author → institution → method → dataset → result ↓ Which GraphRAG methods use community detection, on which datasets they were tested and which papers contradict each other ``` 普通搜索给出一个文档列表。图谱系统构建证据和矛盾的地图。 4 - 网络安全威胁图谱 ``` IP → domain → certificate → malware → campaign → actor ↓ Kimi K3 analyzes threat reports Maps indicators across sources Explains attack paths Updates threat graph automatically ``` 5 - 个人知识操作系统 ``` People ↔ Meetings ↔ Projects ↔ Documents ↔ Decisions ↔ Promises ↓ Questions Kimi K3 can answer: Who is blocking this task? What decision did we make and what was it based on? What did I promise to do this month? Which old assumptions are no longer valid? ``` 本周从哪里开始 ``` Day 1 | install Neo4j locally | read DSPy README | github.com/stanfordnlp/dspy | understand the difference between prompting | and programming a system Day 2 | take one set of documents | run Kimi K3 via API | extract first entities and relationships | save to Neo4j Day 3 | build first retrieval layer | combine vector search and graph search | test on a complex question RAG can't answer Day 4 | connect Kimi Code via MCP | github.com/MoonshotAI/kimi-code | let the agent read the graph and add new facts | run first knowledge-action loop Day 5 | measure the result | compare accuracy vs regular RAG | compare token costs | find first real client use case ``` 微软、斯坦福和 Anthropic 共同发现了什么 ``` Microsoft GraphRAG | graph cuts costs 85%, improves accuracy 18% Stanford DSPy | model is a node in a graph, not the center Stanford Scaling Laws | smaller model + good graph beats bigger model MIT Press Research | explicit relationships improve coherence and accuracy Anthropic LaunchNotes | 5x faster incident detection, 50% less meeting time ``` Kimi K3 是引擎。图工程是地图、记忆和坐标系。没有引擎，图谱无法行动。没有图谱，引擎移动得很快，但并不总是知道要去哪里。大多数开发者将继续构建普通的 RAG，并想知道为什么复杂问题会给出糟糕的答案。少数人将花一周时间构建一个图谱系统，并且再也不会回到搜索文本。你构建你自己的生活——所以选择正确的道路。 / 如果这很有用 - 请关注 /

🔗 相关文档