vault backup: 2026-04-17 12:54:50
This commit is contained in:
windyboy
+11
@@ -238,3 +238,14 @@ FIRST_RUN_COMPLETED
|
||||
|
||||
#MCP
|
||||
.claude/mcp.json
|
||||
|
||||
# --------------------------------------------
|
||||
# Python bytecode / caches
|
||||
# --------------------------------------------
|
||||
__pycache__/
|
||||
*.py[cod]
|
||||
|
||||
# --------------------------------------------
|
||||
# Agent / tool temporary files
|
||||
# --------------------------------------------
|
||||
.memory-changes-*.txt
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
A airport-wiki/raw/articles/机场数据中心建设方案（综合性完整方案）.md
|
||||
Vendored
+7
-18
@@ -1,22 +1,11 @@
|
||||
[
|
||||
"cm-chs-patch",
|
||||
"obsidian-tasks-plugin",
|
||||
"obsidian-style-settings",
|
||||
"quickadd",
|
||||
"any-block",
|
||||
"omnisearch",
|
||||
"obsidian-local-rest-api",
|
||||
"obsidian-kanban",
|
||||
"obsidian-icon-folder",
|
||||
"highlightr-plugin",
|
||||
"obsidian-excalidraw-plugin",
|
||||
"code-styler",
|
||||
"calendar",
|
||||
"better-word-count",
|
||||
"obsidian-git",
|
||||
"table-editor-obsidian",
|
||||
"obsidian-advanced-uri",
|
||||
"advanced-canvas",
|
||||
"obsidian-git",
|
||||
"claudian",
|
||||
"templater-obsidian"
|
||||
"better-word-count",
|
||||
"highlightr-plugin",
|
||||
"obsidian-icon-folder",
|
||||
"omnisearch",
|
||||
"templater-obsidian",
|
||||
"dataview"
|
||||
]
|
||||
+518
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
Binary file not shown.
Binary file not shown.
@@ -0,0 +1,208 @@
|
||||
---
|
||||
title: "This New Method Just Killed RAM Limitations"
|
||||
source: "https://www.youtube.com/watch?v=erV_8yrGMA8"
|
||||
author:
|
||||
- "[[AI News & Strategy Daily | Nate B Jones]]"
|
||||
published: 2026-04-11
|
||||
created: 2026-04-17
|
||||
description: "Full Story w/ Prompts: https://natesnewsletter.substack.com/p/your-gpus-just-got-6x-more-valuable?r=1z4sm5&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true___________________What's really ha"
|
||||
tags:
|
||||
- "clippings"
|
||||
- "webclipper"
|
||||
---
|
||||
> [!info] Source
|
||||
> URL: https://www.youtube.com/watch?v=erV_8yrGMA8
|
||||
> Title: This New Method Just Killed RAM Limitations
|
||||
> Clipped:
|
||||
|
||||
|
||||
|
||||
Full Story w/ Prompts: https://natesnewsletter.substack.com/p/your-gpus-just-got-6x-more-valuable?r=1z4sm5&utm\_campaign=post&utm\_medium=web&showWelcomeOnShare=true
|
||||
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
|
||||
What's really happening inside AI memory — and why it's the bottleneck threatening every LLM deployment at scale?
|
||||
|
||||
The common story is that we just need more chips — but the reality is more interesting: a new Google paper may have just changed the math without touching the hardware.
|
||||
|
||||
In this video, I share the inside scoop on TurboQuant, Google's lossless KV cache compression breakthrough:
|
||||
|
||||
• Why the AI memory crisis is structural, not temporary
|
||||
• How TurboQuant achieves 6x compression with zero data loss
|
||||
• What lossless KV cache optimization means for LLM architecture
|
||||
• Where Google, NVIDIA, and enterprises each stand to win or lose
|
||||
|
||||
The operators and builders who start treating memory as a years-long constraint — and take control of their own context layers now — will hold a real structural advantage as this rolls toward production.
|
||||
|
||||
Chapters
|
||||
00:00 Introduction: TurboQuant and the Memory Problem
|
||||
01:15 The AI Memory Crisis, Explained
|
||||
03:00 Why Memory Supply Is Structurally Constrained
|
||||
05:00 Demand Explosion: Agents and Token Consumption
|
||||
06:30 How Traditional Compression Fails
|
||||
08:00 TurboQuant Part One: PolarQuant Rotation
|
||||
09:30 TurboQuant Part Two: QJL Error Correction
|
||||
11:00 Test Results Across Real LLM Tasks
|
||||
12:30 Why TurboQuant Isn't in Production Yet 14:00 What Is the KV Cache?
|
||||
15:30 Percepta: Embedding Compute Inside an LLM
|
||||
17:00 Strategic Implications: Google, NVIDIA, Enterprises
|
||||
18:30 Five Angles Attacking the Memory Problem
|
||||
20:00 Sovereign Memory: Your Takeaway
|
||||
|
||||
Subscribe for daily AI strategy and news. For deeper playbooks and analysis: https://natesnewsletter.substack.com/
|
||||
|
||||
Listen to this video as a podcast.
|
||||
\- Spotify: https://open.spotify.com/show/0gkFdjd1wptEKJKLu9LbZ4
|
||||
\- Apple Podcasts: https://podcasts.apple.com/us/podcast/ai-news-strategy-daily-with-nate-b-jones/id1877109372
|
||||
|
||||
## Transcript
|
||||
|
||||
### Introduction: TurboQuant and the Memory Problem
|
||||
|
||||
**0:00** · Google just published one of the most important breakthroughs of the year.
|
||||
|
||||
**0:03** · It's called TurboQuant. And it has everything to do with how we use memory in LLMs. Not just in agents, not just in applications, but like the core LLM architecture becoming more memory efficient. And that is a huge deal because right now one of the biggest crises in the industry is the fact that intelligence and demand for intelligence are scaling way way faster than memory.
|
||||
|
||||
**0:24** · And if you're hearing this and you're thinking TurboQuant, this sounds like Silicon Valley the television show.
|
||||
|
||||
**0:30** · You're absolutely right. In fact, that's what most of the newspapers said. They said Turboquant is the new Pied Piper.
|
||||
|
||||
**0:34** · They were kidding around because in the television show Silicon Valley, the little startup Pied Piper actually makes a compression algorithm that saves a ton of hard disk space and memory and that's how they're valued and that's like their whole startup thesis. In this case, I would argue it's even more valuable because TurboQuant compresses the way LLMs handle processing of text in a way that is lossless. And that's a big big deal. So, Pi Piper compressed video files and Turbo Quant compresses the memory that LLM use to think called the key value cache or the KV cache.
|
||||
|
||||
**1:07** · It's the thing that determines how much an AI can hold in its head at a time. And what TurboQuant showed is that they can do a six times memory reduction in the KV cache and up to an 8x speed up on chip without losing even one bit of data.
|
||||
|
||||
### The AI Memory Crisis, Explained
|
||||
|
||||
**1:25** · That's the the biggest news in the world, right? Like that is a huge deal from an AI perspective because it means that the structural economics of the memory crisis that we've been walking into for the last couple of years may actually be addressable. Now, just to give you the 30 secondond view of the memory crisis, supply is structurally constrained. HBM, high bandwidth memory, is getting harder and harder and harder to make. Partly that's because there's so much demand for it.
|
||||
|
||||
**1:49** · And partly because it's literally harder to make because the conflict in Iran means that there's less helium and more expensive power prices, both of which impact the ability to make memory. And so, for multiple reasons, memory is very hard to make right now. On top of that, demand is exploding because agents happened.
|
||||
|
||||
**2:06** · And that means that the average conversation length or the average token usage for a particular interaction went from how long it takes you to have a chat to a thousandx that because agents can burn so many tokens. It's not unusual for agents to burn 100 million tokens, even a billion tokens. Now that means there's more and more demand for exactly the working memory that this Google paper addresses. And just to underline how big a deal this is, token consumption is already reaching 25 billion tokens a year for enterprises with AI native workers. That's that's a year per engineer just to be clear, not for the enterprise as a whole.
|
||||
|
||||
**2:38** · And also memory prices are soaring. Memory prices are multiple hundreds of percent up which is increasing the bill of materials and costs for everything that we use for computing including our personal computers. And the squeeze is relentless. Like we are looking at a situation where for the next half decade this is going to be difficult because bringing more fabrication units online is not easy. So that's the problem space. That's why everyone's stressed about memory. In the middle of this turbo quant looks like a possible way out. Now, I grant you it's a working paper. It's not yet in production systems.
|
||||
|
||||
### Why Memory Supply Is Structurally Constrained
|
||||
|
||||
**3:07** · I don't want to overpromise, but it's worth understanding how it works because it starts to paint a picture for how we can use memory more efficiently. And that's a big deal.
|
||||
|
||||
**3:17** · Look, traditional methods for compressing AI memory are really, really problematic. I want to go through a couple and then explain without math why Turbo Quant is so much better. So if you wanted to compress AI memory before Turbo Quant came out, something that you could do would be called vector quantization, which is a fancy way of saying that you can compress data, but then you need to add data to make sure the data is easily retrievable. So you add something called quantization constants, which sort of somewhat defeats the purpose of the compression because you're adding more data back in after you press it.
|
||||
|
||||
**3:47** · And that overhead actually literally adds one to two extra bits per number that you compress. And it sort of defeats some of the purpose of the compression. It's like packing a suitcase by folding everything tightly, but you have to carry a separate bag with the folding instructions, right?
|
||||
|
||||
**4:01** · That would be sort of silly, but that's a little bit like what vector quantization does. Turboqu Quant makes things easier. So, TurboQuant eliminates that overhead, the packing instruction, so to speak, in a couple of stages.
|
||||
|
||||
**4:12** · First, Polar Quant rotates the data into a standard coordinate system. So what I mean by that is that the data structure becomes predictable enough that you don't need special normalization to read it per block going through the LLM transformer head. So think of it as converting go three blocks east and four blocks north into go five blocks at a 37 degree angle. Both of those are technically the same thing, but one is a shorter way to say it. And so the radius captures the signal strength and the angles capture the meaning.
|
||||
|
||||
**4:44** · And it's a a more efficient way to pack up that data.
|
||||
|
||||
**4:48** · in this analogy because the angles capture all of that data. You don't need to carry the extra bag of folding instructions and it's just a clean, lossless, more efficient way to carry data. But we're not done there because the second technique is what makes this really brilliant. Even if you compress it and you make sure that you like carefully represent all of the original data in a slightly smaller form, it's still possible for tiny errors to creep in.
|
||||
|
||||
### Demand Explosion: Agents and Token Consumption
|
||||
|
||||
**5:10** · And if you're an LLM and you want to be not tolerant of tiny errors, then that's unacceptable because you actually have to do long running steps over many many layers of context and it's really really important to get it exactly right. Let's say in our example that three blocks east and four blocks north translated to 37°. It's actually 36 and a half. It's not 37, but it's close enough for most purposes. Well, Google went farther. Google didn't just say this is close enough for most purposes.
|
||||
|
||||
**5:36** · It's almost perfect. They also added a second technique called QJL or if you want to have a tongue twister, quantized Johnson Linden Strauss. Say that five times fast. That's basically a fancy name for a process that takes the tiny residual error that 36 12 versus 35 degrees or whatever it is. And it corrects it and it corrects it efficiently using just a single bit, a mathematical error checker that eliminates the bias and attention scores. And the combination leads to net net zero overhead and a perfect compression.
|
||||
|
||||
**6:10** · And so the result is eye opening. So where you have a KV cache that might have 16 or 30 bits in it for a key value, you can compress that up to 10x from 32 down to three bits of value without any loss. And that was tested across a variety of fields that we care about for LLM. So if you're wondering, is this just theoretical? I mean, yes, it's a paper, but it was tested. So it was tested across question answering, it was tested across code generation, it was tested across summarization, and it was tested critically across needle in a haststack retrieval.
|
||||
|
||||
### How Traditional Compression Fails
|
||||
|
||||
**6:40** · So if you have a big piece of context and you do this compression on it, can the LLM still find a specific tiny word or phrase in that gigantic context? And so they ran and threw a 100,000 traditional tokens at this compression system and TurboQuant compressed it. And then they said, "Okay, now can you find this tiny little phrase that we've put into this 100,000 tokens?" And it could. And the beautiful thing about this is that it's what we call a data oblivious algorithm.
|
||||
|
||||
**7:10** · So it's not specific to a specific data set. It's not specific to a specific large language model. It's actually a mathematical property we're working with here, which makes it more easy to translate. Now, if you're wondering, okay, this sounds great. Why don't we all have it? The answer is that rolling something to production takes time, and it's important to understand how it actually works. I'm going to give you an example of that. Here's why this matters and why we need to think beyond the spec sheet to make sure we get this right.
|
||||
|
||||
**7:33** · When you compress the KV cache by 6x or 8x or 10x, however big the number ends up being in production, you don't just save memory, you change the way concurrency math works on a chip. In other words, you change the number of simultaneous users that a single GPU can serve. And this is the number that determines whether the inference workloads that you're running end up being profitable for you with your GPU investment or not.
|
||||
|
||||
**7:55** · But one of the things that's interesting is if the concurrency number gets high, you may have to change the way your enterprise deployments work, the way your firmware works on top of the chips to enable more concurrency on a single chip because chips typically have concurrency limits that they may have put in place before.
|
||||
|
||||
### TurboQuant Part One: PolarQuant Rotation
|
||||
|
||||
**8:16** · In fact, certainly put in place. chips have concurrency limits typically that have been put in place long before Turbo Quant came out and that you may have to think about how you address when you want to take advantage of this. And so one of the things I want to call out is that whenever you try and production scale something, you have to think about the whole stack. And especially if you're thinking about something as near to the metal as memory use in a KV cache, you have to think about all of the implications for the stack before you can roll it out.
|
||||
|
||||
**8:44** · And that's why as much fun as this is, there's still work to be done before this is fully available for production. And so you might say, Nate, well, why are we talking about this? It's just theory.
|
||||
|
||||
**8:54** · Well, the answer is even if it's theory today, this is still the fastest possible path for us to solve this problem. And the reason why is that it can move at the speed of software. It doesn't necessarily have to move at the speed of hardware. Because if you're trying to fix these fab timelines, I talked about the issues with making HBM.
|
||||
|
||||
**9:11** · It's a half a decade timeline, right? If you're trying to address how demand works in the system, I'm sorry, but demand is just exploding for AI and that's not going anywhere. So that's an immovable force that's getting bigger and bigger all the time. In that world, software is sort of our only way through the memory problem. Now, if you're wondering what is a KV cache, I'm going to explain it really simply. KV cache is the memory for the language model. So it's the model's working memory while it does computation across a prompt. So every token the model has ever seen gets stored as a key value pair or in the KV cache.
|
||||
|
||||
### TurboQuant Part Two: QJL Error Correction
|
||||
|
||||
**9:43** · And the model computes over all of those pairs for every token generated. And so the KV cache is what lets a model connect token number 89,031 to token number 2354 in your giant prompt. It's what allows the model to hold a conversation, to follow an argument, to track a codebase. It's super super important. And so if model weights are effectively the processor that allows you to do the computing, the KV cache is like a hard drive. It's like RAM. It allows you to remember things.
|
||||
|
||||
**10:12** · And so if you were to invent a piece of software that effectively an algorithm that effectively compresses and makes the hard drive you already have potentially six, seven, eight times more efficient. That's a really really big deal. And I think that one of the things I want to call out is that this TurboQuant paper is happening in the context of a larger set of innovations that are around the core architecture of LLMs that we should be paying attention to. I'll give you one more example. This is from a company called Percepa, which is figuring out how to embed a computer inside a large language model.
|
||||
|
||||
**10:46** · Now, one of the things I want to call out for people who are like, "But an LLM is a computer." The answer is actually no.
|
||||
|
||||
**10:52** · It's not a computer. The LLM is a neural network architecture and it's inherently probabilistic. And so it does not compute in the classical sense normally.
|
||||
|
||||
### Test Results Across Real LLM Tasks
|
||||
|
||||
**11:03** · And so when you see great results where like the LLM does math these days, what you're really seeing is the LM calling a tool and using a tool like Python to do the math. And that's how that works. But that may not be how that works in the future. So what they figured out is they could get the model to deterministically solve a Sudoku puzzle by actually computing the answer logically step by step with 100% accuracy over a lengthy number of steps. We're talking a million plus steps at 33,000 tokens a second which is very very fast.
|
||||
|
||||
**11:34** · If you want to get into the details, what they did is they compiled a web assembly interpreter directly into the weight matrix of a standard PyTorch transform. Not as an external tool call, not as a code interpreter sandbox that was running alongside the model that it could use, but actually they compiled the computer inside the weights of the model. And so the model can execute C programs through a forward pass step by step and emits a stack trace as tokens. For the nerds out there, that's how they did it. And the implications of having a computer in your LLM are really interesting.
|
||||
|
||||
**12:05** · Not because again all of our LLMs will immediately have this, the production piece comes out here too. But because if you look at the combination of the memory piece where Google's pushing, the computer piece that Percepa is pushing, you start to see a changing capability envelope. What happens in 6 months or 8 months if our LLMs can now run native
|
||||
|
||||
**12:26** · compute inside the LLM weights as something they can invoke when they need to run particular programs and they don't need a tool call and what happens if that is also something that is super efficient because the KV cache has been compressed six or eight times and now you can do more. What you're looking at if you start to chain together some of these insights we're having at the cutting edge is a world of a stepchanging capability, right? A world where it's not the LLM itself getting smarter that makes the LLM better. It's the fact that the LLM architecture is changing.
|
||||
|
||||
### Why TurboQuant Isn't in Production Yet What Is the KV Cache?
|
||||
|
||||
**12:57** · And so the LM is much better at memory, holds way more memory without effort, seemingly holds six, seven, 8x more memory without working too hard, and also at the same time, oh by the way, doesn't have to call tools to do computing anymore. That is looking a lot like a revolutionary change in architecture that we may start to see in the second half of 2026 as it starts to roll toward production systems. This is how innovation works, right? You have a transformer architecture. There are a trillion dollars being poured into making this whole system better. And people are like constantly banging their heads on the wall figuring out how do we improve this?
|
||||
|
||||
**13:29** · These two breakthroughs that I'm talking about are not the only ones, but I've picked them because they highlight where the industry is going as a whole. The industry is thinking about how you can make true computing possible and a more flexible architecture that doesn't require all of this tool calling. The industry is thinking about how you can efficiently solve memory.
|
||||
|
||||
**13:47** · And when you put those two together, you get a capability breakthrough. That is a big big deal. Now let's imagine a world where we start to see this breakthrough architecture. Just walk back with me and look at the strategic implication for a second. Google wins twice in this world.
|
||||
|
||||
**14:01** · They wrote TurboQuant and they also run Gemini. And Google has explicitly stated that the KV cache is a bottleneck for Gemini. They've had trouble securing HPM high bandwidth memory. And so if they can actually get Turbo Quan implemented in Gemini, they effectively have a compounding cost advantage on top of their TPU stack and they are able to start to roll this out faster than anybody else because they had the breakthrough themselves originally. This also frees them from some of the competitive dynamic around acquiring memory which is going to be a structural advantage for them long term.
|
||||
|
||||
**14:32** · Now for Nvidia, the narrative gets complicated.
|
||||
|
||||
**14:35** · Jensen spent GTC arguing that Vera Rubin's 500x memory increase solves the inference bottleneck. And Turbo Quant effectively says, "Why not just compress the cash and you get 6x more out of the GPUs you already have?" Well, Nvidia makes money selling chips. They kind of want you to buy more chips to solve that problem. If Nvidia ends up selling fewer chips because compression works really well, they've got a problem. Now, so far that hasn't been the case because the world needs so much AI and is demanding so much AI that no matter what we do, Jensen keeps selling more chips.
|
||||
|
||||
**15:04** · But it is something that complexifies Nvidia's narrative a little bit as we start to move into a world where memory becomes more of a software fungeible constraint.
|
||||
|
||||
**15:14** · The other thing I want to call out is that middleware continues to not win here. So middleware is sitting on top of these foundation models. And if you're looking at where you acrew value, the foundation models are where you can acrue value. That's where the KV cache is being optimized. That's where the tool sets and tool calling capabilities are being optimized. And if you're sitting on top of these models, they may or may not pass their margins on to you.
|
||||
|
||||
### Percepta: Embedding Compute Inside an LLM
|
||||
|
||||
**15:33** · Certainly, they won't pass full margins on to you and you may still continue to get squeezed even as the foundation models reap the gains of these kinds of efficiencies. Enterprises on the other hand are in a really good spot because what enterprises can do is they can start to say, "Hey, we want more for our existing chips. How can we get more out of our existing chips? Can we use something like TurboQuant and actually implement the memory in a way that works?" Now, one thing I want to call out here is you might walk away thinking TurboQuant is the only answer.
|
||||
|
||||
**16:00** · TurboQuant is the only breakthrough on memory. And that is not true. There are other forces out there, other breakthroughs, other research papers out there on me. And so really what makes this whole memory conversation powerful, it's it's that it's not a single paper.
|
||||
|
||||
**16:12** · It's actually the breadth of the attack on the memory problem as a whole. So smart people are hitting this from at least five distinct angles and I want to outline them briefly so you understand the broader landscape. Quantization is how TurboQuant does it, right? They're representing the same vectors in the memory space in fewer bits. And that's the core insight, right? And before TurboQuant did this, KV demonstrated two-bit asymmetric quantization. If you want to get nerdy, zip cache has an approach here as well. So quantization is a stable vector of attack across at least three different research areas.
|
||||
|
||||
**16:41** · Eviction and sparity is actually a completely different strategy from Turboquan. Instead of compressing everything and throwing away the tokens that don't matter, H2O, which is uh Oracle's heavy hitter, keeps only the tokens that attention scores the highest and evicts the rest. Uh, Snap KV has an approach here where it does something similar during decoding. Streaming LLM keeps this sliding window of recent tokens plus a few attention sync tokens.
|
||||
|
||||
### Strategic Implications: Google, NVIDIA, Enterprises
|
||||
|
||||
**17:04** · So, essentially, eviction and sparity means we can pick the tokens that matter and keep those. It's not going to be lossless like Turboquant, but it is in production and it does help some. And there's there's three or four angles there as well. Architectural redesign.
|
||||
|
||||
**17:18** · Uh this attacks the problem at a model level. Deepseek v2 did this the first time. They introduced multi head latent attention which for the nerds projects keys and values into a lower dimensional latent space during training and then shrinks the KV cache footprint by design rather than after the fact. And there's been other work done here too, right?
|
||||
|
||||
**17:37** · Hybrid architectures like IBM's Granite 4.0, uh Nvidia's Neotronh.
|
||||
|
||||
**17:42** · These replace most of the quadratic attention mechanism, which is how LLMs traditionally work with uh what would we would call like a linear time state space model solution. In other words, it makes the memory problem smaller by definition because it's not quadratic attention. And these require training from scratch, right? You have to just train them from from the the get-go. And that limits immediate adoption, but it represents another direction the architecture is heading to make memory more efficient. A fourth approach is offloading and taring, right? It keeps the full cache, but it shifts it around strategically.
|
||||
|
||||
**18:13** · So, shadow KV will store compressed keys on a GPU and offload those values to a CPU, which allows you to achieve much larger batch sizes and uh very high throughput on the right chip. And it treats GPU memory and CPU memory as effectively a hierarchy, right? You can have RAM and solid state memory on your machine in the same way you have like GPUs and CPUs. Flex Gen is also going after this uh and they take it even further with really aggressive offloading to a disk for throughput optimized not latency optimized workload. So this is where you want like high throughput. You don't care how long it takes.
|
||||
|
||||
### Five Angles Attacking the Memory Problem
|
||||
|
||||
**18:44** · And so that's a way to get memory off of the model's immediate KV cache but still make it accessible to the model. Attention optimization uh is the fifth and final approach we'll talk about. It makes the computation itself cheaper without shrinking down the data.
|
||||
|
||||
**18:59** · So flash attention is an example of how companies are attacking this problem, right? Uh flash attention restructures how attention which is what LLMs do reads and writes GPU memory to minimize input output reads and writes which in theory improves performance dramatically on NVIDIA chips. Percept has been in this business for a while. Uh Perceptor's whole KVach also goes after this. It uses two-dimensional attention heads to reduce attention complexity, which by the way, the two-dimensional attention heads are what made that millionstep computation that we talked about earlier with percepta possible.
|
||||
|
||||
**19:32** · So, they've been working on this for a while. The point here is not that any of these is quote unquote the answer. I don't believe in a silver bullet. The point is there are now dozens of research groups and companies attacking the memory problem as a software problem or attacking it algorithmically from multiple directions. And the results are going to compound as we continue to innovate. And this represents one of our most efficient ways to solve one of the biggest problems in AI and really in computing in society today. Memory is something that is blocking us on harvesting a lot of the value of AI.
|
||||
|
||||
### Sovereign Memory: Your Takeaway
|
||||
|
||||
**20:01** · And it's something that I think we don't even realize because we can't even imagine a world where LLMs actually have excellent memory over a long term. Like we're excited that we have fragments of memory in chat GPT right now. We're excited that that that maybe Claude has a little bit of memory that it can remember us with and and maybe we can adjust that or edit that or maybe we can tell it to use an MCP server. Great.
|
||||
|
||||
**20:22** · Memory is such a big deal that we can't imagine a world where the LM just is ambiently aware and has persistent memory over a long period of time. But that's where we're investing and that's where we're going. That is the long-term vision. And the reason I made this video today is because the breakthroughs that we have, including Turboon, which I think is a huge deal, are going to enable us to start to build toward that world and ultimately build really interesting customer experiences, really interesting business experiences, unlock a world that feels more Star Trekian than the world we have today, more like there's just ambient compute and memory everywhere. But we have to build our way there.
|
||||
|
||||
**20:54** · We have to innovate our way there. And it is extremely difficult to do that in a world where it's getting harder and harder to make memory in, which is the world we live in today. I hope this little tour, slightly nerdy down memory lane has been helpful for you. Uh, and I hope you have a sense of where the industry is going on solving some of these really complex problems.
|
||||
|
||||
**21:12** · The biggest takeaway for you if you're looking like what do I do and how can I apply this is pretty simple. Make sure that you have a plan for how you want to handle your own memory and context layer. There is going to be personal memory and context layer stuff out there. I've recommended like you should have an open source one because then no company owns it. Uh that's why I launched uh open brain as an open source protocol. But regardless, you should think of memory as a long-term constraint in your life and in the life of your company if you have one uh or if you work at a company.
|
||||
|
||||
**21:42** · And you should be treating it that way. Treat it as something that is a yearslong problem.
|
||||
|
||||
**21:47** · And you want to make sure that what you are storing is something that you control, that you're okay with, and that you can retrieve aically. That's really important because the alternative is some company deciding for you. And then in that world, if the LMS get better at memory, it's just easier for you because you can throw more at them and it's fine and you don't have to worry about it. If you take anything away, it's what I would call sovereign memory. You should own your memory. You should decide what your memory does. Somebody else should own it for you. All right, best of luck and uh thank you Google for making a really cool breakthrough and uh allowing me to reference Silicon Valley, which is like the best Silicon Valley TV show.
|
||||
|
||||
**22:20** · Chips.
|
||||
+21
-9
@@ -1,3 +1,13 @@
|
||||
---
|
||||
created: 2026-03-16
|
||||
modified: 2026-04-11
|
||||
tags:
|
||||
- inbox
|
||||
- security
|
||||
- credentials
|
||||
status: needs-review
|
||||
---
|
||||
|
||||
# 2026-03-16
|
||||
|
||||
## Capture
|
||||
@@ -14,7 +24,7 @@ curl https://api.githubcopilot.com/models \
|
||||
|
||||
|
||||
```
|
||||
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
|
||||
[REDACTED_GITHUB_TOKEN]
|
||||
```
|
||||
|
||||
|
||||
@@ -23,19 +33,19 @@ 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
|
||||
matrix claw
|
||||
|
||||
```
|
||||
mpt_XgOmW8PcPL8BJAuIbK7pgVzoIZBluQ_SmSuL4
|
||||
[REDACTED_MATRIX_TOKEN]
|
||||
```
|
||||
|
||||
```
|
||||
curl -sS \
|
||||
-H "Authorization: Bearer mat_AvacXX49pkX2fDfxNg8J9zOoxVhkXK_bhYVH1" \
|
||||
-H "Authorization: Bearer [REDACTED_MATRIX_ACCESS_TOKEN]" \
|
||||
"https://synapse.chans.xyz/_matrix/client/v3/account/whoami" | jq
|
||||
```
|
||||
|
||||
|
||||
```
|
||||
curl -sS \
|
||||
-H "Authorization: Bearer mat_AvacXX49pkX2fDfxNg8J9zOoxVhkXK_bhYVH1" \
|
||||
-H "Authorization: Bearer [REDACTED_MATRIX_ACCESS_TOKEN]" \
|
||||
"https://synapse.chans.xyz/_matrix/client/v3/account/joined_rooms" | jq
|
||||
```
|
||||
|
||||
@@ -50,8 +60,8 @@ curl -sS https://synapse.chans.xyz/_matrix/client/v3/login \
|
||||
"type": "m.id.user",
|
||||
"user": "@claw:chans.xyz"
|
||||
},
|
||||
"password": "D929jA*&NrszMhm8",
|
||||
"device_id": "N8vYcZp7oo",
|
||||
"password": "[REDACTED_PASSWORD]",
|
||||
"device_id": "[REDACTED_DEVICE_ID]",
|
||||
"initial_device_display_name": "ZeroClaw Bot"
|
||||
}' | jq
|
||||
```
|
||||
@@ -64,7 +74,8 @@ curl -sS https://synapse.chans.xyz/_matrix/client/v3/login \
|
||||
|
||||
## Insights
|
||||
<!-- What did I learn or realize? -->
|
||||
-
|
||||
- This note previously contained plaintext credentials and tokens. They were redacted on 2026-04-11.
|
||||
- Any exposed credentials captured here should be treated as compromised and rotated.
|
||||
|
||||
## Connections
|
||||
<!-- Links to other notes or ideas -->
|
||||
@@ -72,9 +83,10 @@ curl -sS https://synapse.chans.xyz/_matrix/client/v3/login \
|
||||
|
||||
## For Tomorrow
|
||||
<!-- What needs follow-up? -->
|
||||
-
|
||||
- Rotate any GitHub, Matrix, or related credentials that were previously stored here.
|
||||
- Move durable command examples into a proper resource note after secrets are removed.
|
||||
|
||||
---
|
||||
← [[2026-03-15]] | [[2026-03-17]] →
|
||||
|
||||
*End of day: Ask Claude Code to review and find connections*
|
||||
*End of day: Ask Claude Code to review and find connections*
|
||||
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
created: 2026-04-11
|
||||
modified: 2026-04-11
|
||||
type: inbox-triage
|
||||
tags:
|
||||
- inbox
|
||||
- triage
|
||||
- hermes
|
||||
status: review
|
||||
---
|
||||
|
||||
# Inbox Triage - 2026-04-11
|
||||
|
||||
## Scope
|
||||
|
||||
- Folder reviewed: `00_Inbox/`
|
||||
- Notes reviewed: 8
|
||||
- Goal: identify low-risk cleanup and next moves without bulk reorganization
|
||||
|
||||
## Findings
|
||||
|
||||
### Keep in inbox for short-term follow-up
|
||||
|
||||
- [[00_Inbox/2026-01-07]]: useful daily capture with concrete follow-up actions across AI, Obsidian, GFW, and memory tooling
|
||||
- [[00_Inbox/2026-01-17]]: lightweight daily capture; likely should be moved or split after reviewing whether the Apple ID details are still needed
|
||||
|
||||
### Move to projects
|
||||
|
||||
- [[00_Inbox/IMPROVEMENT_PLAN_2026-02-03]] -> `01_Projects/AI-Development/Obsidian Agent/`
|
||||
- Reason: this is not inbox capture anymore; it is a structured implementation plan tied to vault/documentation improvement work
|
||||
|
||||
### Move to resources
|
||||
|
||||
- [[00_Inbox/Untitled]] -> likely `03_Resources/Development/AI-ML/` or `03_Resources/Community/`
|
||||
- Reason: after removing secrets, the remaining value is command/reference material for GitHub Copilot and Matrix APIs
|
||||
- [[00_Inbox/未命名]] -> `03_Resources/Development/` or `03_Resources/Productivity/`
|
||||
- Reason: contains a reusable PowerShell snippet rather than a transient capture
|
||||
|
||||
### Archive candidates
|
||||
|
||||
- [[00_Inbox/Welcome]] -> `04_Archive/Inbox-Clippings/`
|
||||
- Reason: onboarding note, no longer active, already fulfilled its purpose
|
||||
|
||||
### Operational / special-case notes
|
||||
|
||||
- [[00_Inbox/CLAUDE]]: likely auto-generated context from tooling, not normal inbox content
|
||||
- Recommendation: leave in place unless you want to relocate agent-generated memory artifacts systematically
|
||||
|
||||
## Risks
|
||||
|
||||
- `Untitled.md` contained plaintext credentials/tokens before redaction
|
||||
- Any credentials previously stored there should be considered compromised and rotated
|
||||
- Broad renames or moves may break your existing mental model or links, so they were not applied automatically in this pass
|
||||
|
||||
## Recommended Next Actions
|
||||
|
||||
- [ ] Rotate any credentials previously stored in `00_Inbox/Untitled.md`
|
||||
- [ ] Rename `Untitled.md` to a descriptive title after deciding its permanent destination
|
||||
- [ ] Rename `未命名.md` after deciding whether it belongs under Development or Productivity resources
|
||||
- [ ] Move `IMPROVEMENT_PLAN_2026-02-03.md` into the active Obsidian Agent project area
|
||||
- [ ] Archive `Welcome.md`
|
||||
|
||||
## Minimal Safe Changes Applied
|
||||
|
||||
- Redacted plaintext secrets from [[00_Inbox/Untitled]]
|
||||
- Added metadata and follow-up guidance to that note
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
created: {{date}}
|
||||
modified: {{date}}
|
||||
type: inbox-triage
|
||||
tags:
|
||||
- inbox
|
||||
- triage
|
||||
- hermes
|
||||
status: draft
|
||||
---
|
||||
|
||||
# Inbox Triage - {{date}}
|
||||
|
||||
## Scope
|
||||
- Folder reviewed:
|
||||
- Notes reviewed:
|
||||
- Time window:
|
||||
|
||||
## Keep In Inbox
|
||||
- [[ ]]
|
||||
|
||||
## Move To Projects
|
||||
- [[ ]] -> `01_Projects/`
|
||||
|
||||
## Move To Areas
|
||||
- [[ ]] -> `02_Areas/`
|
||||
|
||||
## Move To Resources
|
||||
- [[ ]] -> `03_Resources/`
|
||||
|
||||
## Archive Or Delete Candidates
|
||||
- [[ ]] - reason:
|
||||
|
||||
## Rename Suggestions
|
||||
- `Old title` -> `New title`
|
||||
|
||||
## Merge Suggestions
|
||||
- [[Note A]] + [[Note B]] -> [[Target Note]]
|
||||
|
||||
## Link Opportunities
|
||||
- [[ ]] <-> [[ ]]
|
||||
|
||||
## Next Actions
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
---
|
||||
Use with Hermes:
|
||||
"Use the obsidian skill. Fill this inbox triage template for recent notes in 00_Inbox and propose changes before applying them."
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
created: {{date}}
|
||||
modified: {{date}}
|
||||
type: project
|
||||
tags:
|
||||
- project
|
||||
- active
|
||||
status: active
|
||||
area:
|
||||
target_completion:
|
||||
---
|
||||
|
||||
# {{title}}
|
||||
|
||||
## Outcome
|
||||
<!-- What concrete result should exist when this project is done? -->
|
||||
|
||||
## Why Now
|
||||
<!-- Why this matters and why it belongs in Projects rather than Resources -->
|
||||
|
||||
## Scope
|
||||
- In:
|
||||
- Out:
|
||||
|
||||
## Success Criteria
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Current State
|
||||
<!-- What already exists? What constraints matter? -->
|
||||
|
||||
## Related Notes
|
||||
- [[ ]]
|
||||
- [[ ]]
|
||||
|
||||
## Key Resources
|
||||
- [[ ]]
|
||||
- [[ ]]
|
||||
|
||||
## Open Questions
|
||||
-
|
||||
-
|
||||
|
||||
## Next Actions
|
||||
- [ ]
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Progress Log
|
||||
### {{date}}
|
||||
- Project created
|
||||
|
||||
---
|
||||
Use with Hermes:
|
||||
"Use the obsidian skill. Create a project from this template under 01_Projects, infer likely related notes, and add a minimal set of wikilinks."
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
created: {{date}}
|
||||
modified: {{date}}
|
||||
type: resource
|
||||
tags:
|
||||
- resource
|
||||
- synthesis
|
||||
- hermes
|
||||
status: evergreen
|
||||
source_notes: []
|
||||
---
|
||||
|
||||
# {{title}}
|
||||
|
||||
## Summary
|
||||
<!-- 3-5 sentences synthesizing the topic -->
|
||||
|
||||
## Core Ideas
|
||||
-
|
||||
-
|
||||
-
|
||||
|
||||
## Patterns
|
||||
-
|
||||
-
|
||||
|
||||
## Contradictions
|
||||
-
|
||||
|
||||
## Useful Quotes Or Claims
|
||||
-
|
||||
|
||||
## Related Notes
|
||||
- [[ ]]
|
||||
- [[ ]]
|
||||
|
||||
## Gaps
|
||||
- What is still unclear?
|
||||
- Which note should be created or improved next?
|
||||
|
||||
## Actionable Takeaways
|
||||
- [ ]
|
||||
- [ ]
|
||||
|
||||
## Source Notes
|
||||
- [[ ]]
|
||||
- [[ ]]
|
||||
|
||||
---
|
||||
Use with Hermes:
|
||||
"Use the obsidian skill. Review related notes in 03_Resources and fill this synthesis note with patterns, contradictions, and missing links."
|
||||
@@ -1,5 +1,4 @@
|
||||
node_modules/
|
||||
raw/
|
||||
.obsidian/
|
||||
.trash/
|
||||
*.log
|
||||
|
||||
+239
-13
@@ -37,6 +37,17 @@ updated: YYYY-MM-DD
|
||||
type: entity | concept | comparison | query | summary
|
||||
tags: [從下方標籤體系選取]
|
||||
sources: [raw/articles/source-name.md]
|
||||
confidence: 0.0-1.0 # 知識置信度（可選，預設 0.5）
|
||||
sources_count: N # 支持該事實的來源數量（可選）
|
||||
last_confirmed: YYYY-MM-DD # 最近一次確認時間（可選）
|
||||
superseded_by: page-name # 被哪個頁面替代（可選，見 supersession 機制）
|
||||
supersedes: page-name # 替代了哪個頁面（可選）
|
||||
status: active|stale|dormant|archived # 知識狀態（預設 active）
|
||||
relationships: # 實體頁面專用（可選）
|
||||
- target: page-name
|
||||
type: uses|deploys|depends_on|supersedes|...
|
||||
detail: 可選描述
|
||||
confidence: 0.0-1.0
|
||||
---
|
||||
```
|
||||
|
||||
@@ -64,6 +75,18 @@ sources: [raw/articles/source-name.md]
|
||||
- 前沿技術：`digital-twins`, `agentic-ai`, `biometric`, `human-centered-design`, `hyper-personalization`, `sustainability`
|
||||
- 運營設施：`aocc`, `ioc`
|
||||
|
||||
### 知識管理標籤
|
||||
- `knowledge-management`：知識管理與 wiki 運營
|
||||
- `confidence`：置信度相關內容
|
||||
- `supersession`：替代機制
|
||||
- `forgetting`：遺忘曲線 / 知識衰減
|
||||
- `consolidation-tier`：整合層次（working/episodic/semantic/procedural）
|
||||
- `knowledge-graph`：知識圖譜、實體關係圖
|
||||
- `entity`：實體頁面標記
|
||||
- `typed-relationship`：類型化關係（uses/deploys/depends_on 等）
|
||||
- `automation`：自動化操作鉤子
|
||||
- `event-hooks`：事件驅動架構
|
||||
|
||||
### 通用標籤
|
||||
- `ai-ml`：AI/ML 應用
|
||||
- `comparison`：對比分析
|
||||
@@ -71,6 +94,8 @@ sources: [raw/articles/source-name.md]
|
||||
- `glossary`：術語表
|
||||
- `draft`：草稿
|
||||
- `archived`：歸檔
|
||||
- `stale`：已過時（被 supersede）
|
||||
- `dormant`：休眠（長期未訪問）
|
||||
|
||||
## Page Thresholds（頁面創建規則）
|
||||
|
||||
@@ -100,24 +125,40 @@ airport-wiki/
|
||||
│ │ ├── prefab-modular-dc.md
|
||||
│ │ ├── modern-airport-trends.md
|
||||
│ │ └── glossary.md
|
||||
│ └── flight-operations/ # 航班運營系統（10頁）
|
||||
│ ├── a-cdm.md
|
||||
│ ├── aodb-core.md
|
||||
│ ├── aodb-vendors.md
|
||||
│ ├── aodb-acdm-integration.md
|
||||
│ ├── smgcs.md
|
||||
│ ├── baggage-handling.md
|
||||
│ ├── flight-data-exchange.md
|
||||
│ ├── smart-gating.md
|
||||
│ ├── deicing-operations.md
|
||||
│ └── airport-systems-landscape.md # 系統層級總圖（新建）
|
||||
│ ├── flight-operations/ # 航班運營系統（16頁）
|
||||
│ │ ├── a-cdm.md
|
||||
│ │ ├── aodb-core.md
|
||||
│ │ ├── aodb-vendors.md
|
||||
│ │ ├── smgcs.md
|
||||
│ │ ├── baggage-handling.md
|
||||
│ │ ├── flight-data-exchange.md
|
||||
│ │ ├── smart-gating.md
|
||||
│ │ ├── deicing-operations.md
|
||||
│ │ ├── airport-systems-landscape.md
|
||||
│ │ ├── agentic-ai-airports.md
|
||||
│ │ ├── aocc-ioc.md
|
||||
│ │ ├── biometric-corridors.md
|
||||
│ │ ├── digital-twins-airports.md
|
||||
│ │ ├── future-airport-info-center.md
|
||||
│ │ ├── open-architecture.md
|
||||
│ │ └── universal-design-airports.md
|
||||
│ └── knowledge-management/ # 知識管理（3頁，2026-04-13 新增）
|
||||
│ ├── memory-lifecycle.md # 置信度/superset/遺忘機制
|
||||
│ ├── knowledge-graph.md # 實體圖譜/類型化關係
|
||||
│ └── wiki-operations.md # 事件鉤子/自動化
|
||||
├── comparisons/ # 橫向對比
|
||||
│ ├── airport-dc-case-studies.md
|
||||
│ └── airport-operations-systems.md
|
||||
├── entities/ # 機場實體案例
|
||||
│ ├── index.md # 實體索引 + 關係圖譜
|
||||
│ ├── shenzhen-airport.md
|
||||
│ ├── zhengzhou-airport-hangang.md
|
||||
│ └── fuzhou-changle-airport-bsj.md
|
||||
│ ├── fuzhou-changle-airport-bsj.md
|
||||
│ ├── jfk-airport.md
|
||||
│ ├── pittsburgh-airport.md
|
||||
│ ├── rome-fiumicino-airport.md
|
||||
│ └── singapore-changi-airport.md
|
||||
├── _archive/ # 被 supersede 的歷史版本（待建立）
|
||||
└── raw/
|
||||
├── articles/
|
||||
├── papers/
|
||||
@@ -130,8 +171,22 @@ airport-wiki/
|
||||
每個主要實體一頁，包括：
|
||||
- 概述 / 是什麼
|
||||
- 關鍵事實和數據
|
||||
- 與其他實體的關係（[[wikilinks]]）
|
||||
- 與其他實體的 Typed Relationships（`relationships` 字段）
|
||||
- 來源引用
|
||||
- 置信度（`confidence`）、來源數量（`sources_count`）、最後確認時間（`last_confirmed`）
|
||||
|
||||
```yaml
|
||||
# entities/example.md frontmatter 格式
|
||||
type: entity
|
||||
entity_type: airport # airport | vendor | hardware | system | standard | project
|
||||
confidence: 0.9
|
||||
sources_count: 2
|
||||
last_confirmed: 2026-04-13
|
||||
relationships:
|
||||
- target: another-entity
|
||||
type: uses|deploys|depends_on|supersedes|...
|
||||
confidence: 0.85
|
||||
```
|
||||
|
||||
## Concept Pages（概念頁面）
|
||||
|
||||
@@ -151,12 +206,183 @@ airport-wiki/
|
||||
|
||||
## Update Policy（更新政策）
|
||||
|
||||
### Supersession 機制（新）
|
||||
|
||||
當新信息與現有內容衝突或更新現有內容時：
|
||||
1. 將新內容寫入原頁面，更新 `updated` 日期
|
||||
2. 舊版本完整內容移動至 `_archive/[original-name]-[date].md`
|
||||
3. 舊版本 frontmatter 添加：
|
||||
```yaml
|
||||
superseded_by: [new-page-name]
|
||||
superseded_date: YYYY-MM-DD
|
||||
status: stale
|
||||
```
|
||||
4. 新版本 frontmatter 添加：
|
||||
```yaml
|
||||
supersedes: [old-page-name]
|
||||
supersedes_date: YYYY-MM-DD
|
||||
```
|
||||
5. 觸發 `On memory write` 鉤子，記錄至 log.md
|
||||
|
||||
### 衝突檢測（原有，擴展）
|
||||
|
||||
新信息與現有內容衝突時：
|
||||
1. 檢查日期 — 新來源通常取代舊來源
|
||||
2. 如確實矛盾，記錄雙方立場和日期、來源
|
||||
3. 在 frontmatter 標記：`contradictions: [page-name]`
|
||||
4. 在 lint 報告中標記待用戶審核
|
||||
|
||||
### Confidence Decay（新增）
|
||||
|
||||
定時任務自動衰減置信度：
|
||||
- 架構決策：每月衰減 0.5%
|
||||
- 供應商/硬件規格：每月衰減 1%
|
||||
- 項目進度：每月衰減 5%
|
||||
- 每次被引用/確認：置信度恢復 +0.1，上限 0.98
|
||||
|
||||
## Glossary（術語表）
|
||||
|
||||
建設和運營涉及的英文縮寫和術語，統一在 `concepts/tech-infrastructure/glossary.md` 中解釋。
|
||||
|
||||
---
|
||||
|
||||
# LLM Wiki v2 擴展架構
|
||||
*(基於 Andrej Karpathy 原版模式，融合 LLM Wiki v2 和 agentmemory 經驗)*
|
||||
|
||||
## 核心理念：停止重新推導，開始積累編譯
|
||||
|
||||
### 現有架構回顧
|
||||
- **原始數據**：`raw/` 目錄中的來源文件，保持原始、未經編輯
|
||||
- **Wiki 頁面**：經過整理、鏈接的知識頁面（`concepts/`, `entities/`, `comparisons/`）
|
||||
- **Schema 文檔**：`SCHEMA.md`，將通用 LLM 轉化為有紀律的知識工作者
|
||||
|
||||
### v2 關鍵擴展
|
||||
|
||||
#### 1. 記憶生命周期（Knowledge Lifecycle）
|
||||
知識具有生命周期，不是所有內容永久有效：
|
||||
- **置信度評分**：每個事實應基於來源數量、新近性、矛盾情況攜帶分數（0.0-1.0）
|
||||
- **替代機制**：新信息明確替代舊聲明，支持知識版本控制
|
||||
- **遺忘機制**：實施保留曲線（如艾賓浩斯遺忘曲線），逐步降低未使用知識的優先級
|
||||
- **整合層次**：知識壓縮管道：
|
||||
- **工作記憶**：近期觀察（當前會話）
|
||||
- **情景記憶**：會話總結（跨工作記憶的壓縮）
|
||||
- **語義記憶**：跨會話事實（穩定知識）
|
||||
- **程序記憶**：從重複語義中提煉的工作流和模式
|
||||
|
||||
#### 2. 超越扁平頁面：知識圖譜
|
||||
用類型化知識圖譜增強 wiki 頁面：
|
||||
- **實體提取**：提取結構化實體（人員、項目、庫、概念）及類型、屬性、關係
|
||||
- **類型化關係**：使用語義加權連接，如 `uses`、`depends_on`、`contradicts`、`supersedes`
|
||||
- **圖譜遍歷查詢**：導航連接以發現下游影響，超越關鍵詞搜索
|
||||
|
||||
#### 3. 真正可擴展的搜索（關鍵突破）
|
||||
當 `index.md` 超出 ~100-200 頁時變得不可行：
|
||||
- **混合搜索**：融合三種信息流：
|
||||
1. **BM25**：關鍵詞匹配（支持詞幹提取/同義詞）
|
||||
2. **向量搜索**：通過嵌入實現語義相似度（例如 OpenAI `text-embedding-3-small`）
|
||||
3. **圖譜遍歷**：基於實體關係的遍歷搜索
|
||||
- **結果融合**：使用倒數排名融合（Reciprocal Rank Fusion）合併結果
|
||||
- **保留 `index.md`**：僅作為人工可讀目錄，不再是主要檢索工具
|
||||
|
||||
#### 4. 自動化：從手動到事件驅動
|
||||
減少人工維護負擔：
|
||||
- **事件鉤子**（自動觸發）：
|
||||
- **新來源時**：自動攝入、提取實體、更新圖譜/索引
|
||||
- **會話開始/結束時**：加載上下文、將會話壓縮為觀察
|
||||
- **查詢時**：如質量分數 > 閾值，自動回寫答案
|
||||
- **內存寫入時**：檢查矛盾
|
||||
- **定時任務**：定期 lint、整合、保留衰減
|
||||
- **自動攝入管道**：`raw/` 中新增源文件 → 自動解析 → 創建/更新 wiki 頁面
|
||||
|
||||
#### 5. 質量與自我糾正
|
||||
防止噪聲積累的控制機制：
|
||||
- **評分一切**：LLM 生成內容應獲得質量分數（結構良好、引用來源、一致性）。低分標記待審查/重寫
|
||||
- **自我修復**：Lint 操作應自動修復孤立頁面、過時聲明、損壞的交叉引用
|
||||
- **矛盾解決**：基於新近性、權威性和支持觀察，LLM 應提出更可能正確的主張
|
||||
|
||||
#### 6. 多智能體與協作
|
||||
為多個智能體或人員擴展模式：
|
||||
- **網狀同步**：合併來自並行智能體的觀察；使用帶時間戳的最後寫入獲勝衝突解決
|
||||
- **共享 vs 私有**：知識範圍劃分（個人偏好 vs 項目架構）
|
||||
- **工作協調**：輕量級協調以防止重複工作並跟踪進展
|
||||
|
||||
#### 7. 隱私與治理
|
||||
處理敏感信息和問責：
|
||||
- **攝入時過濾**：在 wiki 存儲前自動剝離 API 密鑰、憑據、個人身份信息
|
||||
- **審計追踪**：記錄所有操作（攝入、編輯、刪除、查詢）的時間戳、更改和原因
|
||||
- **批量操作**：用於過時內容刪除、導出、合併的經過審計且可逆操作
|
||||
|
||||
#### 8. 結晶化：從探索中提煉
|
||||
自動將已完成的工作鏈提煉為結構化摘要：
|
||||
- **處理過程**：提取問題、發現、涉及的文件/實體、經驗教訓
|
||||
- **結果**：創建一等級 wiki 頁面，用新事實強化知識庫
|
||||
|
||||
#### 9. 超越 Markdown 的輸出格式
|
||||
基於受眾和問題的知識存儲應支持多樣輸出：
|
||||
- 對比表格、時間線可視化、依賴關係圖、幻燈片、結構化數據導出（JSON、CSV）、簡報
|
||||
|
||||
## 實施路線圖
|
||||
|
||||
### 階段 1：基礎 LLM Wiki（已實現）
|
||||
- ✓ 原始來源存儲（`raw/`）
|
||||
- ✓ Wiki 頁面（`concepts/`, `entities/`, `comparisons/`）
|
||||
- ✓ Schema 文檔（`SCHEMA.md`）
|
||||
- ✓ 目錄索引（`index.md`）
|
||||
- ✓ 操作日誌（`log.md`）
|
||||
|
||||
### 階段 2：v2 擴展（本次升級目標）
|
||||
1. **記憶生命周期**：置信度評分、替代機制、遺忘曲線
|
||||
2. **知識圖譜**：實體提取、類型化關係、圖譜可視化
|
||||
3. **混合搜索**：BM25 + 向量 + 圖譜遍歷
|
||||
4. **自動化鉤子**：事件驅動維護
|
||||
5. **質量控制**：自我糾正、矛盾檢測
|
||||
6. **結晶化**：工作鏈提煉
|
||||
|
||||
### 階段 3：高級功能
|
||||
1. **多智能體協作**：網狀同步、衝突解決
|
||||
2. **隱私過濾**：自動敏感信息剝離
|
||||
3. **多格式輸出**：API 導出、可視化生成
|
||||
|
||||
## 實施細節
|
||||
|
||||
### 混合搜索設置
|
||||
```
|
||||
# 檢索層級
|
||||
1. BM25 關鍵詞匹配（使用 ripgrep + 同義詞詞典）
|
||||
2. 向量語義搜索（使用 OpenAI embeddings）
|
||||
3. 知識圖譜遍歷（實體關係路徑）
|
||||
4. 結果融合（RRF 算法）
|
||||
```
|
||||
|
||||
### 記憶衰減公式
|
||||
```
|
||||
confidence_t = confidence_0 * exp(-λ * t) + Σ(citations * 0.1)
|
||||
λ = 衰減率（每月 0.005-0.05，依內容類型）
|
||||
```
|
||||
|
||||
### 自動化鉤子示例
|
||||
```bash
|
||||
# 新增來源時
|
||||
on_new_source() {
|
||||
parse_source → extract_entities → create_wiki_pages → update_index
|
||||
}
|
||||
|
||||
# 會話結束時
|
||||
on_session_end() {
|
||||
compress_session → update_episodic_memory → decay_confidence
|
||||
}
|
||||
|
||||
# 定期任務（每週）
|
||||
cron_weekly() {
|
||||
run_lint → fix_issues → prune_dormant → regenerate_embeddings
|
||||
}
|
||||
```
|
||||
|
||||
## 參考文檔
|
||||
|
||||
- [[knowledge-management/memory-lifecycle.md]] - 記憶生命周期詳細設計
|
||||
- [[knowledge-management/knowledge-graph.md]] - 知識圖譜實現指南
|
||||
- [[knowledge-management/wiki-operations.md]] - wiki 運營與自動化
|
||||
- [[hybrid-search.md]] - 混合搜索系統文檔
|
||||
- [[llm-wiki-v2-reference.md]] - LLM Wiki v2 完整參考
|
||||
```
|
||||
|
||||
@@ -0,0 +1,252 @@
|
||||
# AODB 事件 Schema 草案
|
||||
|
||||
## 1. 文档定位
|
||||
|
||||
本文档定义 AODB MVP 阶段的统一事件信封和关键事件 payload 草案，用于实现、联调和消费者契约评审。
|
||||
|
||||
## 2. 统一事件信封
|
||||
|
||||
所有事件必须使用统一 envelope：
|
||||
|
||||
```json
|
||||
{
|
||||
"event_id": "uuid",
|
||||
"event_type": "PublishedFactUpdated",
|
||||
"schema_version": 1,
|
||||
"occurred_at": "2026-04-13T16:00:00Z",
|
||||
"produced_at": "2026-04-13T16:00:01Z",
|
||||
"source": {
|
||||
"system": "aodb-flight-service",
|
||||
"organization": "airport-ops",
|
||||
"channel": "internal"
|
||||
},
|
||||
"idempotency_key": "string",
|
||||
"correlation_id": "string",
|
||||
"aggregate_type": "FlightOperation",
|
||||
"aggregate_id": "flight_123",
|
||||
"quality": {
|
||||
"confidence": "confirmed",
|
||||
"flags": []
|
||||
},
|
||||
"payload": {}
|
||||
}
|
||||
```
|
||||
|
||||
## 3. 字段说明
|
||||
|
||||
| 字段 | 说明 | 必填 |
|
||||
| --- | --- | --- |
|
||||
| `event_id` | 全局唯一事件 ID | 是 |
|
||||
| `event_type` | 事件类型 | 是 |
|
||||
| `schema_version` | schema 版本 | 是 |
|
||||
| `occurred_at` | 业务发生时间 | 是 |
|
||||
| `produced_at` | AODB 产出时间 | 是 |
|
||||
| `source` | 来源系统和组织 | 是 |
|
||||
| `idempotency_key` | 幂等键 | 是 |
|
||||
| `correlation_id` | 关联链路 ID | 是 |
|
||||
| `aggregate_type` | 聚合类型 | 是 |
|
||||
| `aggregate_id` | 聚合 ID | 是 |
|
||||
| `quality` | 可信度和数据质量标记 | 否 |
|
||||
| `payload` | 事件负载 | 是 |
|
||||
|
||||
## 4. 事件列表
|
||||
|
||||
### 4.1 `FlightImported`
|
||||
|
||||
用途：
|
||||
|
||||
- 表示计划航班已进入 AODB 标准化流程。
|
||||
|
||||
```json
|
||||
{
|
||||
"payload": {
|
||||
"flight_id": "flight_123",
|
||||
"flight_key": "MU-1234-2026-04-13-1",
|
||||
"op_date": "2026-04-13",
|
||||
"carrier": "MU",
|
||||
"flight_number": "1234",
|
||||
"leg_no": "1",
|
||||
"batch_id": "ssim_batch_001"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 `MilestoneObserved`
|
||||
|
||||
用途：
|
||||
|
||||
- 表示接收到一条原始或标准化里程碑观测。
|
||||
|
||||
```json
|
||||
{
|
||||
"payload": {
|
||||
"observation_id": "obs_001",
|
||||
"flight_id": "flight_123",
|
||||
"milestone_type": "ALDT",
|
||||
"observed_value": "2026-04-13T15:22:00Z",
|
||||
"source_sequence": "aidx-889",
|
||||
"raw_message_ref": "msg_777"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.3 `PublishedFactUpdated`
|
||||
|
||||
用途：
|
||||
|
||||
- 表示 Published Fact 发生变化，是对外共享的关键事件。
|
||||
|
||||
```json
|
||||
{
|
||||
"payload": {
|
||||
"flight_id": "flight_123",
|
||||
"field_name": "ALDT",
|
||||
"previous_value": "2026-04-13T15:20:00Z",
|
||||
"current_value": "2026-04-13T15:22:00Z",
|
||||
"decision_ref": "decision_321",
|
||||
"published_state_version": 9
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.4 `TurnaroundLinked`
|
||||
|
||||
用途：
|
||||
|
||||
- 表示到离港航班形成过站关联。
|
||||
|
||||
```json
|
||||
{
|
||||
"payload": {
|
||||
"turnaround_id": "ta_001",
|
||||
"arrival_flight_id": "flight_arr_001",
|
||||
"departure_flight_id": "flight_dep_001",
|
||||
"tail_number": "B-1234",
|
||||
"link_confidence": "estimated"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.5 `ResourceAssigned`
|
||||
|
||||
用途：
|
||||
|
||||
- 表示资源分配已生效。
|
||||
|
||||
```json
|
||||
{
|
||||
"payload": {
|
||||
"allocation_id": "alloc_001",
|
||||
"resource_id": "stand_12",
|
||||
"resource_type": "Stand",
|
||||
"flight_id": "flight_123",
|
||||
"turnaround_id": "ta_001",
|
||||
"lock_type": "hard",
|
||||
"assignment_source": "manual",
|
||||
"validity_window": {
|
||||
"start_at": "2026-04-13T15:00:00Z",
|
||||
"end_at": "2026-04-13T16:30:00Z"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.6 `ResourceConflictDetected`
|
||||
|
||||
用途：
|
||||
|
||||
- 表示资源冲突被识别出来。
|
||||
|
||||
```json
|
||||
{
|
||||
"payload": {
|
||||
"resource_id": "stand_12",
|
||||
"resource_type": "Stand",
|
||||
"conflict_type": "time_overlap",
|
||||
"affected_allocations": ["alloc_001", "alloc_002"],
|
||||
"affected_flights": ["flight_123", "flight_456"],
|
||||
"rule_ref": "resource.time-window.v1"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.7 `AlertRaised`
|
||||
|
||||
用途：
|
||||
|
||||
- 表示告警进入打开状态。
|
||||
|
||||
```json
|
||||
{
|
||||
"payload": {
|
||||
"alert_id": "alert_001",
|
||||
"alert_type": "resource_conflict",
|
||||
"severity": "high",
|
||||
"related_aggregate_type": "ResourceAllocation",
|
||||
"related_aggregate_id": "alloc_001",
|
||||
"summary": "Stand 12 conflict detected"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.8 `ManualDecisionRecorded`
|
||||
|
||||
用途：
|
||||
|
||||
- 表示人工裁决已经完成。
|
||||
|
||||
```json
|
||||
{
|
||||
"payload": {
|
||||
"decision_id": "decision_321",
|
||||
"decision_type": "field_override",
|
||||
"target_aggregate_type": "FlightOperation",
|
||||
"target_aggregate_id": "flight_123",
|
||||
"field_name": "ALDT",
|
||||
"selected_value": "2026-04-13T15:22:00Z",
|
||||
"reason": "tower confirmation",
|
||||
"operator": "ops_user_007"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4.9 `ReviewTaskOpened`
|
||||
|
||||
用途：
|
||||
|
||||
- 表示复核任务已创建。
|
||||
|
||||
```json
|
||||
{
|
||||
"payload": {
|
||||
"review_task_id": "review_001",
|
||||
"review_type": "milestone_conflict",
|
||||
"target_aggregate_type": "FlightOperation",
|
||||
"target_aggregate_id": "flight_123",
|
||||
"reason": "conflicting ALDT observations"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 5. 版本演进规则
|
||||
|
||||
- `schema_version` 必须随破坏性变更升级。
|
||||
- 非破坏性新增字段只允许追加，不允许重定义现有字段含义。
|
||||
- 下游必须按“忽略未知字段”实现兼容。
|
||||
- 被废弃字段必须至少保留一个发布周期。
|
||||
|
||||
## 6. Topic 建议
|
||||
|
||||
| Topic | 用途 | 分区键 |
|
||||
| --- | --- | --- |
|
||||
| `aodb.flight.events` | FlightOperation 和 Published Fact 事件 | `flight_id` |
|
||||
| `aodb.resource.events` | 资源分配和冲突事件 | `flight_id` |
|
||||
| `aodb.alert.events` | 告警和处置事件 | `alert_id` |
|
||||
| `aodb.review.events` | 人工复核和裁决事件 | `target_aggregate_id` |
|
||||
|
||||
## 7. 消费者要求
|
||||
|
||||
- 必须按 `event_id` 去重。
|
||||
- 必须处理至少一次投递。
|
||||
- 必须把 `quality.flags` 作为强语义，而不是展示附注。
|
||||
- 不得把查询接口结果当作事件流补偿来源。
|
||||
@@ -0,0 +1,65 @@
|
||||
# AODB 字段级权威矩阵
|
||||
|
||||
## 1. 文档定位
|
||||
|
||||
本文档用于定义 AODB 关键字段的来源优先级、更正规则、人工覆盖规则和对外可见性。它是 Published Fact 生成和测试用例设计的直接依据。
|
||||
|
||||
## 2. 适用原则
|
||||
|
||||
- 规则粒度以字段为准，而不是以“整条航班记录”统一处理。
|
||||
- 原始 Observation 永不改写。
|
||||
- Published Fact 只能由字段级权威矩阵和裁决逻辑生成。
|
||||
- 人工覆盖必须事件化和审计化。
|
||||
|
||||
## 3. 字段矩阵
|
||||
|
||||
| 字段 | 字段类别 | 主来源 | 次来源 | 默认可信度规则 | 过期规则 | 更正规则 | 人工覆盖规则 | 对外可见性 |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| SIBT / SOBT | 计划时间 | SSIM / 计划导入 | 人工计划调整 | 计划导入为 `reported`，人工调整为 `confirmed` | 新计划版本到达后旧计划失效 | 新批次或更高版本覆盖旧计划 | 允许，必须记录变更原因 | 返回当前值 + 来源 |
|
||||
| EOBT | 预计时间 | 航司计划源 | 机场运行 | 航司上报优先 | 超过配置阈值后降为 `suspect` | 新版本或更正报文优先 | 允许 | 返回当前值 + 来源 + 可信度 |
|
||||
| TOBT | 协同计划时间 | 航司 / 地服 | 机场运行 | 航司 / 地服 `confirmed` 高于机场运行 `reported` | 若长时间未更新且实际进度明显偏离，则标记 `suspect` | 显式更正优先 | 允许，必须给出裁决摘要 | 返回当前值 + 裁决摘要 |
|
||||
| TSAT | 系统计算时间 | AODB / PDS | 机场运行人工调整 | 系统计算缺省 `estimated` | 新一轮计算生成后旧值过期 | 高版本计算结果覆盖低版本 | 允许，需记录算法版本和人工原因 | 返回当前值 + 算法版本 |
|
||||
| TTOT | 系统计算时间 | AODB / PDS | 机场运行人工调整 | 同 TSAT | 同 TSAT | 同 TSAT | 同 TSAT | 返回当前值 + 算法版本 |
|
||||
| ELDT | 预计到达时间 | ANSP / 外部运行态 | 系统预测 | ANSP 上报高于系统预测 | 若距当前时间过远且无更新，可信度下降 | 新版本或更正优先 | 允许 | 返回当前值 + 可信度 |
|
||||
| ALDT | 实际到达时间 | ANSP / 机场运行 | 航司 | ANSP / 机场运行 `confirmed` 优先 | 实际时间不过期，但可被更正 | 明确更正或更高序列覆盖 | 允许，需进入人工裁决 | 返回当前值 + 来源 |
|
||||
| AIBT | 实际到位时间 | 地服 / 机场运行 | 航司 | 地服 / 机场运行优先 | 实际时间不过期，但可被更正 | 更正优先 | 允许，需人工裁决 | 返回当前值 + 来源 |
|
||||
| EIBT | 预计到位时间 | 系统计算 | 运行动态派生 | 系统计算缺省 `estimated` | 新估算生成后旧值过期 | 新估算覆盖旧估算并留历史 | 允许 | 返回当前值 + 可信度 |
|
||||
| AOBT | 实际推出时间 | 地服 / 机场运行 | 航司 | 地服优先 | 实际时间不过期，但可更正 | 更正优先 | 允许，需人工裁决 | 返回当前值 + 来源 |
|
||||
| ATOT | 实际起飞时间 | ANSP | 航司 / 机场运行 | ANSP 优先 | 实际时间不过期，但可更正 | 更正优先 | 允许，需人工裁决 | 返回当前值 + 来源 |
|
||||
| Flight Status | 航班状态摘要 | Published Fact 推导 | 人工裁决 | 由里程碑和取消状态综合推导 | 状态持续有效直到新事实生成 | 更正走 Published Fact 重新计算 | 允许，需生成裁决事件 | 返回当前值 + 裁决摘要 |
|
||||
| Cancelled Flag | 取消标记 | 航司 / 计划源 | 机场运行 | 航司取消优先 | 取消后持续有效，直到明确恢复 | 恢复必须有显式更正 | 允许，需高级别审计 | 返回当前值 + 来源 |
|
||||
| Turnaround Link | 航班配对 | 系统配对 | 人工配对修正 | 人工修正高于自动配对 | 当关联航班变化时旧配对失效 | 更正产生 `TurnaroundCorrected` | 允许 | 返回当前值 + link_confidence |
|
||||
| Stand Assignment | 资源分配 | 机场运行系统 | 人工调度 | 自动分配默认为 `estimated`，人工为 `confirmed` | 时间窗失效后不再生效 | 新分配替换旧分配并保留历史 | 必须支持 | 返回当前值 + 覆盖摘要 |
|
||||
| Gate Assignment | 资源分配 | 机场运行系统 | 人工调度 | 同上 | 同上 | 同上 | 必须支持 | 返回当前值 + 覆盖摘要 |
|
||||
| Belt Assignment | 资源分配 | 机场运行系统 | 人工调度 | 同上 | 同上 | 同上 | 必须支持 | 返回当前值 + 覆盖摘要 |
|
||||
| Counter Assignment | 资源分配 | 机场运行系统 | 人工调度 | 同上 | 同上 | 同上 | 必须支持 | 返回当前值 + 覆盖摘要 |
|
||||
|
||||
## 4. 冲突裁决优先级
|
||||
|
||||
当多个 Observation 竞争同一字段时，按以下顺序裁决：
|
||||
|
||||
1. 字段权威来源优先级
|
||||
2. 明确更正 / 更高版本号
|
||||
3. `confidence`
|
||||
4. `occurred_at`
|
||||
5. `source_sequence` 或 `ingest_sequence`
|
||||
6. 人工裁决
|
||||
|
||||
## 5. 最小输出契约
|
||||
|
||||
对外查询至少返回：
|
||||
|
||||
- `current_value`
|
||||
- `source`
|
||||
- `confidence`
|
||||
- `last_decision_summary`（可空）
|
||||
- `updated_at`
|
||||
- `data_quality_flags`
|
||||
|
||||
## 6. 测试场景
|
||||
|
||||
1. ALDT 出现 ANSP 与航司冲突，系统自动按来源优先级裁决。
|
||||
2. TOBT 出现多个地服更正，系统按更正版本和时间序列更新。
|
||||
3. Stand Assignment 在延误后重新分配，旧分配转历史，新分配变当前值。
|
||||
4. Turnaround 自动配对后被人工修正，系统产生 `TurnaroundCorrected`。
|
||||
5. Cancelled Flag 被恢复时，必须有显式更正，不允许静默取消取消状态。
|
||||
@@ -0,0 +1,176 @@
|
||||
# AODB 最小部署拓扑草案
|
||||
|
||||
## 1. 文档定位
|
||||
|
||||
本文档给出 AODB MVP 的最小部署拓扑、关键高可用策略和恢复思路，用于细化高层设计中的部署、SLO 和容灾约束。
|
||||
|
||||
## 2. 目标
|
||||
|
||||
- 以单机场私有化部署为前提
|
||||
- 优先满足当前态统一、事件不丢、审计可回放
|
||||
- 用最少组件完成可恢复、可观测、可演练的运行形态
|
||||
|
||||
## 3. 逻辑拓扑
|
||||
|
||||
```text
|
||||
+-------------------------+
|
||||
| External Systems |
|
||||
| SSIM / AIDX / AFTN |
|
||||
+------------+------------+
|
||||
|
|
||||
v
|
||||
+-------------------+
|
||||
| Kong Gateway |
|
||||
+-------------------+
|
||||
|
|
||||
+---------------+----------------+
|
||||
| | |
|
||||
v v v
|
||||
+----------------+ +----------------+ +------------------+
|
||||
| Flight Service | | Milestone Svc | | External API Svc |
|
||||
+----------------+ +----------------+ +------------------+
|
||||
| | |
|
||||
+-------+-------+----------------+
|
||||
|
|
||||
v
|
||||
+----------------------+
|
||||
| PostgreSQL/Timescale |
|
||||
| Current + Audit + |
|
||||
| Outbox |
|
||||
+----------+-----------+
|
||||
|
|
||||
v
|
||||
+---------------+
|
||||
| CDC/Publisher |
|
||||
+-------+-------+
|
||||
|
|
||||
v
|
||||
+-------+
|
||||
| Kafka |
|
||||
+---+---+
|
||||
|
|
||||
+----------+-----------+
|
||||
| |
|
||||
v v
|
||||
+----------------+ +----------------+
|
||||
| Resource Svc | | Alert Service |
|
||||
+----------------+ +----------------+
|
||||
|
||||
+----------------+
|
||||
| Redis Cache |
|
||||
+----------------+
|
||||
|
||||
+-------------------------------+
|
||||
| Prometheus / Grafana / Loki |
|
||||
+-------------------------------+
|
||||
```
|
||||
|
||||
## 4. 部署分区建议
|
||||
|
||||
### 4.1 状态层
|
||||
|
||||
- PostgreSQL / TimescaleDB
|
||||
- Kafka
|
||||
- Redis
|
||||
|
||||
要求：
|
||||
|
||||
- 与无状态服务分离部署
|
||||
- 具备独立备份和恢复策略
|
||||
|
||||
### 4.2 无状态业务层
|
||||
|
||||
- Flight Operation Service
|
||||
- Milestone Service
|
||||
- Resource Service
|
||||
- Alert Service
|
||||
- External API Service
|
||||
- CDC / Publisher
|
||||
|
||||
要求：
|
||||
|
||||
- 多副本
|
||||
- 滚动升级
|
||||
- 配置和密钥外置
|
||||
|
||||
### 4.3 平台观测层
|
||||
|
||||
- Kong
|
||||
- Keycloak
|
||||
- Prometheus
|
||||
- Grafana
|
||||
- Loki
|
||||
|
||||
## 5. 高可用建议
|
||||
|
||||
### 5.1 PostgreSQL / TimescaleDB
|
||||
|
||||
- 主备部署
|
||||
- 定期全量备份 + WAL / PITR 能力
|
||||
- 演练主备切换
|
||||
|
||||
### 5.2 Kafka
|
||||
|
||||
- 多 broker
|
||||
- `replication factor >= 3`
|
||||
- `min ISR >= 2`
|
||||
- 消费位点外部可追踪
|
||||
|
||||
### 5.3 Redis
|
||||
|
||||
- 主从或哨兵
|
||||
- 缓存失效不应影响核心写链路
|
||||
|
||||
### 5.4 无状态服务
|
||||
|
||||
- 至少 2 副本
|
||||
- 健康检查 + 自动重启
|
||||
- 发布器必须支持重复执行幂等
|
||||
|
||||
## 6. 最小恢复策略
|
||||
|
||||
### 6.1 数据库故障
|
||||
|
||||
- 切换到备实例
|
||||
- 根据最近备份和 WAL 进行恢复
|
||||
- 恢复后执行 Published Fact 与 Outbox 对账
|
||||
|
||||
### 6.2 Kafka 堆积或单 broker 故障
|
||||
|
||||
- Broker 恢复后消费者追赶
|
||||
- 重点检查订阅延迟、DLQ 率、CDC 积压
|
||||
|
||||
### 6.3 CDC / Publisher 中断
|
||||
|
||||
- 根据 Outbox 位点断点续传
|
||||
- 保证重复发布不产生重复副作用
|
||||
|
||||
### 6.4 查询层异常
|
||||
|
||||
- 核心写链路不中断
|
||||
- 对外查询可降级，但订阅恢复后必须可补偿
|
||||
|
||||
## 7. 关键观测指标
|
||||
|
||||
| 指标 | 含义 |
|
||||
| --- | --- |
|
||||
| ingest_to_publish_latency_p95 | 接入到发布的 P95 延迟 |
|
||||
| outbox_backlog | Outbox 堆积量 |
|
||||
| cdc_publish_retry_count | 发布重试次数 |
|
||||
| kafka_consumer_lag | 消费滞后量 |
|
||||
| dlq_rate | 解析失败和旁路率 |
|
||||
| conflict_mttr | 冲突平均处置时间 |
|
||||
| review_task_open_count | 未关闭复核任务数 |
|
||||
|
||||
## 8. 关键演练场景
|
||||
|
||||
1. PostgreSQL 主备切换
|
||||
2. Kafka 单 broker 故障恢复
|
||||
3. CDC 中断和断点恢复
|
||||
4. 订阅端断线重连与游标补偿
|
||||
5. 关键字段回放抽检
|
||||
|
||||
## 9. 与高层设计的关系
|
||||
|
||||
- 本文档细化 `开源机场运营数据库（AODB）高层设计文档.md` 中的部署与 SLO 章节。
|
||||
- 它不是最终部署手册，但必须足以支撑架构评审、容灾设计和运维基线定义。
|
||||
@@ -0,0 +1,111 @@
|
||||
# AODB 核心需求提炼
|
||||
|
||||
## 1. 文档定位
|
||||
|
||||
本文档定义 AODB 的业务目标、范围边界、核心能力和约束条件，作为高层设计和技术选型的上位输入。
|
||||
|
||||
- 目标对象：年旅客吞吐量 500 万至 3000 万的中型机场
|
||||
- 目标系统：机场运营数据库（AODB）及其核心协同能力
|
||||
- 使用方式：作为 `开源机场运营数据库（AODB）高层设计文档.md` 和 `开源技术栈选型决策.md` 的上位需求输入
|
||||
|
||||
## 2. 业务目标与范围
|
||||
|
||||
### 2.1 业务目标
|
||||
|
||||
1. 建立航班运营单一事实源（SSOT），消除多系统数据不一致。
|
||||
2. 支撑航班计划、动态运行、资源分配和里程碑协同的闭环运营。
|
||||
3. 通过事件驱动架构实现秒级数据传播，提升调度响应效率。
|
||||
4. 以开源技术栈实现可控成本、可持续演进和私有化可部署能力。
|
||||
|
||||
### 2.2 范围边界
|
||||
|
||||
MVP（首期必须）：
|
||||
|
||||
- 航班计划导入（SSIM）与动态更新（AIDX/AFTN）
|
||||
- 机位/登机口/行李转盘/值机柜台基础资源分配
|
||||
- A-CDM 核心里程碑管理与变更发布
|
||||
- 运营告警（延误、资源冲突）
|
||||
- 外部数据共享接口（查询 + 事件订阅）
|
||||
- 审计、裁决、人工复核闭环
|
||||
|
||||
非 MVP：
|
||||
|
||||
- 高级优化排班（全局优化/仿真）
|
||||
- 深度 AI 预测（跨季节模型、异常解释）
|
||||
- 多机场统一调度与集团化运营
|
||||
- 起飞排序和复杂流处理平台化能力
|
||||
|
||||
### 2.3 范围约束
|
||||
|
||||
- 单机场优先，跨机场能力不作为 MVP 前提。
|
||||
- MVP 聚焦“当前态统一、事件可追溯、人工可介入”，不以复杂优化能力为前提。
|
||||
- 若外部系统稳定性不足，必须预留灰度、手工复核和数据质量标记兜底流程。
|
||||
- 首期不要求深度历史迁移，只要求新接入链路具备统一主键、幂等和审计能力。
|
||||
|
||||
## 3. 功能需求清单
|
||||
|
||||
| 功能域 | 核心能力 | 输入 | 输出 | MVP |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 航班数据管理 | 航班计划导入、动态更新、历史回放、航班配对（Linking） | SSIM、AIDX、AFTN | 标准化航班主数据与状态流 | 是 |
|
||||
| 资源管理 | 机位/登机口/行李转盘/值机柜台分配与冲突检测 | 航班状态、资源可用性、规则 | 资源分配结果、冲突事件 | 是 |
|
||||
| A-CDM 里程碑 | 里程碑采集、校验、发布、追踪 | ANSP/航司/地服事件 | 里程碑状态、时序记录 | 是 |
|
||||
| 裁决与复核 | 数据冲突复核、人工覆盖、事件重放 | 冲突事件、复核任务 | 裁决记录、发布事实 | 是 |
|
||||
| 告警与预警 | 延误告警、冲突告警、超阈值告警 | 实时事件、规则配置 | 告警通知、处置状态 | 是 |
|
||||
| 信息共享（ACISP） | 面向航司/管制/地服的数据查询与订阅 | 业务实体与事件 | 外部查询/订阅接口 | 是 |
|
||||
| 实时计算增强 | EIBT/EXIT/EXOT 预测、TSAT 计算 | 运行态事件、历史统计 | 预测结果、排序建议 | P1 |
|
||||
| 起飞排序（PDS） | TSAT/TTOT/EXOT 规则计算与可追溯 | 里程碑、滑行预测、管制约束 | 排序建议与调整记录 | P1 |
|
||||
|
||||
## 4. 标准与集成要求
|
||||
|
||||
- AIDX（Aviation Information Data Exchange）：用于航班动态交换。
|
||||
- SSIM Chapter 7：用于季节性时刻表批量导入。
|
||||
- AFTN/SITA Type B：用于传统航电与运行消息接入。
|
||||
- ACARS（可选）：用于补充机载状态数据接入。
|
||||
|
||||
集成约束：
|
||||
|
||||
1. 所有外部输入必须经过标准化映射层，生成统一内部事件模型。
|
||||
2. 所有关键写入必须具备幂等键和可追溯来源字段。
|
||||
3. 解析失败消息必须进入死信队列并提供人工复核入口。
|
||||
4. 当前权威值不得直接由多个系统并行写入，必须经过字段级权威矩阵和裁决逻辑。
|
||||
|
||||
## 5. 非功能需求
|
||||
|
||||
| 维度 | 目标值 | 最低可接受值 | 说明 |
|
||||
| --- | --- | --- | --- |
|
||||
| 可用性 | 月度 99.95% | 月度 99.9% | 保障核心运行时段可用 |
|
||||
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 | 覆盖接入到发布事实主链路 |
|
||||
| 数据一致性 | 关键实体强一致 | 最终一致 <= 30 秒 | 当前态和事件流必须可对账 |
|
||||
| 恢复能力 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 | 支撑单机场容灾恢复 |
|
||||
| 审计追踪 | 100% 关键变更可追溯 | 99.9% 可追溯 | 覆盖自动裁决和人工动作 |
|
||||
| 安全 | OIDC/OAuth2 + RBAC + 传输加密 | RBAC + 传输加密 | 对外查询和订阅必须受控 |
|
||||
|
||||
## 6. 架构约束
|
||||
|
||||
- Flight 当前态必须只有一个写主，不允许多个系统直接并行改写权威字段。
|
||||
- 所有关键写入必须带来源、时间、幂等键和关联 ID。
|
||||
- 原始观测、裁决记录、发布事实必须分层保存，不允许只保留当前值。
|
||||
- 查询接口和事件订阅接口必须分离，不允许把查询层当作事实流输出。
|
||||
- 人工覆盖、回滚和复核必须事件化、审计化。
|
||||
|
||||
## 7. 术语与缩写（权威定义）
|
||||
|
||||
| 缩写 | 定义 |
|
||||
| --- | --- |
|
||||
| AODB | Airport Operational Database，机场运营数据库 |
|
||||
| SSOT | Single Source of Truth，单一事实源 |
|
||||
| A-CDM | Airport Collaborative Decision Making，机场协同决策 |
|
||||
| TSAT | Target Start-up Approval Time，目标放行时间 |
|
||||
| TTOT | Target Take-off Time，目标起飞时间 |
|
||||
| EXOT | Estimated Taxi-Out Time，预计滑出时间 |
|
||||
| EXIT | Estimated Taxi-In Time，预计滑入时间 |
|
||||
| EIBT | Estimated In-Block Time，预计靠桥时间 |
|
||||
| Turnaround | 航班过站对象，关联到达航班、离港航班与飞机周转上下文 |
|
||||
|
||||
## 8. 关联文档
|
||||
|
||||
- `airport-wiki/concepts/aodb/开源技术栈选型决策.md`
|
||||
- `airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md`
|
||||
- `airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md`
|
||||
- `airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md`
|
||||
- `airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md`
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-001 MVP 不引入 Flink
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
首期目标是完成单机场 AODB 核心闭环，规模为 500 万至 3000 万旅客机场，优先解决当前态统一、资源冲突和审计问题。
|
||||
|
||||
## 决策
|
||||
|
||||
MVP 不引入 Flink。首期只保留 Kafka 事件骨干和应用服务内流式处理逻辑。预测、CEP 和复杂有状态计算推迟到 P1。
|
||||
|
||||
## 原因
|
||||
|
||||
- 首期复杂度应优先让位于交付确定性。
|
||||
- 预测与复杂流处理不是首期闭环前提。
|
||||
- Flink 会显著提高部署、运维和故障恢复复杂度。
|
||||
|
||||
## 后果
|
||||
|
||||
- MVP 中实时计算能力受限。
|
||||
- 事件契约和聚合边界必须为未来引入 Flink 预留演进空间。
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-002 Kafka 作为唯一事件骨干
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
AODB 需要支撑事件可回放、订阅分发、补偿和审计。
|
||||
|
||||
## 决策
|
||||
|
||||
Kafka 作为唯一事实事件骨干。所有对外事件订阅都以 Kafka 上的标准化事件为源头，禁止多路事件源头并存。
|
||||
|
||||
## 原因
|
||||
|
||||
- 统一重放和补偿语义。
|
||||
- 避免“写库成功但未发布”或“已发布但未落库”的治理空洞。
|
||||
- 降低外部消费者理解成本。
|
||||
|
||||
## 后果
|
||||
|
||||
- 事件可靠发布必须依赖 Outbox + CDC。
|
||||
- 查询 API 不能被下游误当作事件事实源。
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-003 事实分层模型
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
AODB 需要同时处理多源观测、字段裁决和对外权威事实发布。
|
||||
|
||||
## 决策
|
||||
|
||||
采用 `Observation / Decision / Published Fact` 三层模型。
|
||||
|
||||
## 原因
|
||||
|
||||
- 让 SSOT 真正表示“经过治理后发布的事实”。
|
||||
- 保证原始观测、人工覆盖和当前值三者不互相污染。
|
||||
- 便于审计、回放和责任归因。
|
||||
|
||||
## 后果
|
||||
|
||||
- 数据模型和事件模型会更明确，但设计和实现复杂度略有上升。
|
||||
- Published Fact 的任何变更都必须可追溯到 Observation 和 Decision。
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-004 FlightOperation 写主归属
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
原方案中 Flight、Milestone、Resource、Alert 边界存在写入重叠风险。
|
||||
|
||||
## 决策
|
||||
|
||||
Flight 当前权威态只能由 `Flight Operation Service` 写入，其他服务只能产生观测、候选事实、资源事实或告警事实。
|
||||
|
||||
## 原因
|
||||
|
||||
- 避免多个服务共同修改同一当前态。
|
||||
- 降低一致性和回放复杂度。
|
||||
- 方便将 Published Fact 聚合到单一领域对象。
|
||||
|
||||
## 后果
|
||||
|
||||
- Milestone 和 Resource 服务必须通过事件影响 Flight 当前态。
|
||||
- Flight Service 需要承担更明确的聚合协调责任。
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-005 Turnaround 独立建模
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
仅以单航班建模无法充分表达到离港配对、机尾号上下文和资源联动。
|
||||
|
||||
## 决策
|
||||
|
||||
将 `Turnaround` 作为首期核心领域对象，引入最小独立建模。
|
||||
|
||||
## 原因
|
||||
|
||||
- 支撑航班配对（Linking）需求。
|
||||
- 提高资源分配和时序解释能力。
|
||||
- 为换机、延误联动和周转分析提供上下文。
|
||||
|
||||
## 后果
|
||||
|
||||
- 文档和模型复杂度上升。
|
||||
- 配对修正和不完整配对需要额外的事件和审计语义。
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-006 资源锁定模型
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
单纯的资源时间窗分配无法表达建议分配、已确认分配和人工强制覆盖。
|
||||
|
||||
## 决策
|
||||
|
||||
ResourceAllocation 支持 `soft lock` 和 `hard lock` 两种锁定语义。
|
||||
|
||||
## 原因
|
||||
|
||||
- 表达自动建议和人工强制分配的区别。
|
||||
- 支持冲突检测、覆盖和回滚的可解释性。
|
||||
- 为未来优化排班预留空间。
|
||||
|
||||
## 后果
|
||||
|
||||
- 冲突检测和分配逻辑需要区分锁定强度。
|
||||
- 人工覆盖必须伴随审计和事件输出。
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-007 查询与订阅分离
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
将 GraphQL Subscription 或查询层直接作为事实流会混淆读取和事件分发语义。
|
||||
|
||||
## 决策
|
||||
|
||||
对外查询接口和事件订阅接口分离设计。
|
||||
|
||||
## 原因
|
||||
|
||||
- 查询和事件分发的稳定性、回放、限流语义不同。
|
||||
- 便于明确外部消费者的消费契约。
|
||||
- 降低把查询接口误当权威事件骨干的风险。
|
||||
|
||||
## 后果
|
||||
|
||||
- 需要独立设计事件订阅网关或分发适配层。
|
||||
- API 文档要分别描述查询和订阅契约。
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-008 Outbox 与 CDC
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
AODB 必须避免“写库成功但没发事件”或“发了事件但没落库”。
|
||||
|
||||
## 决策
|
||||
|
||||
采用 `Outbox Pattern + CDC` 作为写库与发事件一致性策略。
|
||||
|
||||
## 原因
|
||||
|
||||
- 能把数据库状态变化和事件发布绑定到同一事务边界。
|
||||
- 适合首期 Kafka 作为唯一事件骨干的架构。
|
||||
- 支持失败重试、断点恢复和事件回放。
|
||||
|
||||
## 后果
|
||||
|
||||
- 需要部署 CDC / 发布器组件。
|
||||
- 发布流程和 Outbox 堆积需要专门监控。
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-009 PostgreSQL HA
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
Published Fact、审计和 Outbox 都依赖 PostgreSQL，数据库可用性直接决定系统可用性。
|
||||
|
||||
## 决策
|
||||
|
||||
MVP 必须采用 PostgreSQL 高可用部署，并具备备份恢复和 PITR 或等价能力。
|
||||
|
||||
## 原因
|
||||
|
||||
- 满足 RTO / RPO 目标。
|
||||
- 为审计、重放和一致性提供稳定基础。
|
||||
- 避免首期把可靠性寄托在应用层补偿上。
|
||||
|
||||
## 后果
|
||||
|
||||
- 部署和运维门槛上升，但这是首期必须承担的复杂度。
|
||||
- 需要单独演练主备切换和恢复流程。
|
||||
@@ -0,0 +1,24 @@
|
||||
# ADR-010 人工裁决事件化
|
||||
|
||||
## 状态
|
||||
|
||||
Accepted
|
||||
|
||||
## 背景
|
||||
|
||||
AODB 中数据冲突、资源覆盖和解析失败都可能需要人工参与。
|
||||
|
||||
## 决策
|
||||
|
||||
所有人工裁决、人工覆盖和人工复核动作必须事件化和审计化，禁止仅通过数据库备注或日志留痕。
|
||||
|
||||
## 原因
|
||||
|
||||
- 人工动作是业务事实的一部分。
|
||||
- 需要对外解释当前值为何成立。
|
||||
- 便于回放、对账和合规审计。
|
||||
|
||||
## 后果
|
||||
|
||||
- Case 流程和审计模型需要更完整。
|
||||
- 首期必须实现最小人工复核状态机。
|
||||
@@ -0,0 +1,101 @@
|
||||
# 开源技术栈选型决策
|
||||
|
||||
## 1. 决策目标与原则
|
||||
|
||||
本文档用于对 AODB 技术栈做唯一主选决策，避免多方案并列导致实施阶段反复。
|
||||
|
||||
决策原则：
|
||||
|
||||
1. 满足中型机场场景下的稳定性与可维护性。
|
||||
2. 优先选择成熟开源生态和团队可落地能力。
|
||||
3. 对核心路径采用单一主选，备选仅定义触发条件。
|
||||
4. 支持私有化部署和后续多机场扩展。
|
||||
5. MVP 优先收敛复杂度，不以技术先进性替代交付确定性。
|
||||
|
||||
## 2. 技术栈总览
|
||||
|
||||
### 2.1 MVP 主选
|
||||
|
||||
| 分层 | 主选方案 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| 主数据存储 | PostgreSQL 16 | 关键业务数据强一致事务 |
|
||||
| 时序存储 | TimescaleDB | 里程碑、观测与审计时间序列 |
|
||||
| 缓存与热点读 | Redis 7 (Valkey) | 高频读、短期缓存、去重辅助 |
|
||||
| 事件总线 | Apache Kafka 3.x | 统一事件骨干和可回放能力 |
|
||||
| 协议集成 | Apache Camel | AIDX / AFTN / SITA 协议适配 |
|
||||
| API 网关 | Kong Gateway OSS | 鉴权、限流、路由治理 |
|
||||
| 认证授权 | Keycloak 24 | OIDC / OAuth2 与 RBAC |
|
||||
| 可观测性 | Prometheus + Grafana + Loki | 指标、看板、日志观测 |
|
||||
| 容器平台 | Kubernetes + Helm | 标准化部署与环境一致性 |
|
||||
|
||||
### 2.2 后续启用组件
|
||||
|
||||
| 组件 | 定位 | 启用触发条件 | 当前决策 |
|
||||
| --- | --- | --- | --- |
|
||||
| Flink | 有状态流处理、预测、CEP | EIBT / EXIT / EXOT 预测进入上线范围，且简单流式处理无法满足延迟和可恢复性目标 | P1 |
|
||||
| Drools | 复杂规则平台 | 规则量、规则变更频率和回放需求超过代码化规则可维护边界 | P1 |
|
||||
| Temporal | 长流程编排与补偿 | 人工复核、跨系统补偿和状态机复杂度超出单服务事务编排能力 | P1 |
|
||||
| Hasura | 快速 GraphQL 查询与订阅暴露 | 前端字段裁剪、实时订阅和权限编排复杂度显著上升 | 可选 |
|
||||
| OpenSearch | 搜索与分析投影 | 全文检索、复杂检索、跨字段搜索成为上线能力 | P1 |
|
||||
| Linkerd | 服务间 mTLS 与服务治理 | 服务数量、零信任要求和多团队治理复杂度显著增加 | 可选 |
|
||||
| MinIO | 对象存储 | 需要保存批量导入文件、报文附件和复核证据对象 | 可选 |
|
||||
| React + TypeScript + PWA | 运营终端前端栈 | 本期建设自研终端而非只做系统接口时启用 | 可选 |
|
||||
|
||||
## 3. 关键决策与备选触发条件
|
||||
|
||||
| 决策项 | 主选 | 备选 | 触发备选条件 | 说明 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 搜索引擎 | 暂不纳入 MVP | OpenSearch | 上线阶段需要全文检索、复杂筛选和日志联动检索时 | MVP 不为未来检索需求预埋过重组件 |
|
||||
| GraphQL 引擎 | 暂不纳入核心路径 | Hasura / PostGraphile | 面向运营终端的字段选择和订阅编排复杂度上升时 | 查询接口与事件骨干分离 |
|
||||
| 工作流引擎 | 暂不纳入 MVP | Temporal | 人工复核和补偿流程演进为复杂长事务时 | MVP 先用应用服务内状态机 |
|
||||
| 服务网格 | 暂不纳入 MVP | Linkerd / Istio | 服务间零信任、mTLS 和流量治理要求增强时 | 中型机场首期不引入服务网格 |
|
||||
| 流处理引擎 | 暂不纳入 MVP | Flink | 预测 / CEP / 大规模乱序处理成为上线前提时 | 首期不以预测能力为闭环前提 |
|
||||
| 规则引擎 | 代码化规则 + 版本化配置 | Drools | 规则规模和运营配置频率显著增长时 | 降低首期认知与运维成本 |
|
||||
|
||||
## 4. 分层选型理由（精要）
|
||||
|
||||
### 4.1 数据层
|
||||
|
||||
- PostgreSQL + TimescaleDB 统一 SQL 体验，降低多数据库运维复杂度。
|
||||
- Redis 负责热点读、去重辅助和临时缓存，减轻主库读取压力。
|
||||
- 首期不引入搜索引擎，避免为非关键路径增加一套额外状态系统。
|
||||
|
||||
### 4.2 消息与处理层
|
||||
|
||||
- Kafka 作为唯一事件骨干，保障事件可回放与可追溯。
|
||||
- 首期不引入 Flink，先聚焦标准化、裁决、发布事实和资源冲突闭环。
|
||||
- 首期规则逻辑采用应用内代码化实现，并以版本化配置和回放测试约束演进。
|
||||
|
||||
### 4.3 集成与接口层
|
||||
|
||||
- Camel 统一协议适配，减少自研连接器维护成本。
|
||||
- Kong 提供统一北向入口及治理能力。
|
||||
- 查询接口和事件订阅接口分离，避免将查询层误用为事实事件骨干。
|
||||
|
||||
### 4.4 安全与基础设施层
|
||||
|
||||
- Keycloak 提供统一身份与授权管理。
|
||||
- Kubernetes + Helm 提供标准化部署与环境一致性。
|
||||
- 可观测性先聚焦指标、日志和告警，链路追踪和服务网格在服务规模扩大后再引入。
|
||||
|
||||
## 5. 风险与缓解
|
||||
|
||||
| 风险 | 影响 | 缓解措施 |
|
||||
| --- | --- | --- |
|
||||
| Kafka 运维门槛高 | 实施初期效率下降 | 提供最小可运行拓扑、标准化 Topic 规划和 SRE Runbook |
|
||||
| 多协议接入数据质量不稳定 | 里程碑发布事实误差 | 建立标准化校验、死信队列和人工复核流程 |
|
||||
| 规则逻辑散落在服务代码 | 规则可维护性下降 | 统一规则目录、版本化配置和回放测试 |
|
||||
| 未来再引入 Flink / Temporal 成本上升 | 迁移复杂度提升 | 通过事件契约、聚合边界和 ADR 先锁死演进接口 |
|
||||
| 文档与实现偏离 | 评审通过后落地失真 | 将关键决策同步为 ADR 并纳入变更流程 |
|
||||
|
||||
## 6. 版本与升级策略
|
||||
|
||||
- 技术栈版本采用“年度主版本评审 + 季度补丁更新”策略。
|
||||
- 升级优先级：安全补丁 > 稳定性修复 > 新功能。
|
||||
- 升级前必须完成回归测试、性能基线对比和回滚演练。
|
||||
|
||||
## 7. 与架构文档的边界
|
||||
|
||||
- 本文档回答“首期选什么、为什么选、何时启用后续组件”。
|
||||
- 具体数据模型、事件契约、流程编排细节在 `开源机场运营数据库（AODB）高层设计文档.md` 中定义。
|
||||
- 本文档不替代 ADR；关键决策以 `airport-wiki/concepts/aodb/adr/` 下文件为准。
|
||||
@@ -0,0 +1,510 @@
|
||||
# 开源机场运营数据库（AODB）高层设计文档
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本文档定义 AODB MVP 的技术方案基线，重点回答以下问题：
|
||||
|
||||
1. AODB 在 MVP 内承载哪些业务闭环，以及哪些能力明确不做。
|
||||
2. 系统如何划分聚合、服务、数据流和事件边界。
|
||||
3. 航班、里程碑、资源、告警等核心对象如何建模。
|
||||
4. 发布事实如何在观测、裁决、审计和订阅之间保持一致。
|
||||
5. 查询、订阅、部署、容灾和可观测性如何落到可实现架构。
|
||||
|
||||
适用范围：年旅客吞吐量 500 万至 3000 万机场，优先支持单机场部署。
|
||||
|
||||
## 2. 设计原则
|
||||
|
||||
- 单一事实源：AODB 对外发布单一当前权威事实，不暴露“谁最后写入”式伪一致。
|
||||
- 事实分层：原始观测、裁决记录、发布事实必须分层建模。
|
||||
- 写主清晰：每个核心聚合只允许一个服务写入，避免跨服务共享可变状态。
|
||||
- 事件驱动：状态变化通过事件传播，系统通过契约解耦。
|
||||
- 规则可解释：字段权威、冲突裁决、人工覆盖必须可追溯、可回放、可解释。
|
||||
- 渐进复杂度：MVP 先建立稳定闭环，不引入复杂优化平台和长事务编排平台。
|
||||
|
||||
## 3. 范围定义
|
||||
|
||||
### 3.1 MVP 范围
|
||||
|
||||
首期只覆盖以下闭环：
|
||||
|
||||
- 航班计划导入与实时状态更新
|
||||
- 航班配对与过站上下文最小建模
|
||||
- 基础资源分配：Stand、Gate、Belt、Counter
|
||||
- 关键里程碑跟踪与发布事实治理
|
||||
- 延误、资源冲突和数据质量告警
|
||||
- 对外查询接口与事件订阅
|
||||
- 审计、人工裁决、重放与复核闭环
|
||||
|
||||
### 3.2 非 MVP 范围
|
||||
|
||||
首期不纳入以下能力：
|
||||
|
||||
- 全局优化排班和复杂资源优化求解
|
||||
- 深度 AI 预测和自适应调度
|
||||
- Flink 驱动的复杂 CEP 平台
|
||||
- Temporal 驱动的复杂长事务工作流平台
|
||||
- 多机场统一调度中心能力
|
||||
|
||||
## 4. 总体架构
|
||||
|
||||
### 4.1 架构分层
|
||||
|
||||
| 层级 | 主要能力 | MVP 主路径组件 | 说明 |
|
||||
| --- | --- | --- | --- |
|
||||
| 接入层 | 外部系统接入、协议解析、统一北向入口 | Kong Gateway、Apache Camel、SSIM 导入器 | 接收计划、动态、资源和人工操作输入 |
|
||||
| 业务层 | 航班当前态、观测治理、资源分配、告警处置、外部接口 | Flight Operation Service、Milestone Service、Resource Service、Alert Service、External API Service | 承担领域逻辑和对外契约 |
|
||||
| 事件层 | 事件骨干、重放、订阅分发 | Kafka、Outbox/CDC 发布器 | 负责异步传播和回放 |
|
||||
| 数据层 | 事务存储、时序存储、缓存 | PostgreSQL、TimescaleDB、Redis | 保存当前态、审计链路和热点读模型 |
|
||||
| 平台层 | 认证鉴权、部署、观测 | Keycloak、Kubernetes、Prometheus/Grafana/Loki | 提供运行时底座 |
|
||||
|
||||
### 4.2 核心技术链路
|
||||
|
||||
MVP 主链路采用“接入标准化 -> 观测入库 -> 裁决生成 -> 发布事实更新 -> 事件发布 -> 查询/订阅消费”的结构：
|
||||
|
||||
1. 外部计划或运行动态通过接入层进入系统。
|
||||
2. Milestone Service 将输入标准化为 Observation，并按幂等键写入。
|
||||
3. 规则引擎根据字段权威矩阵和当前上下文生成 Decision。
|
||||
4. Flight Operation Service 更新 Published Fact 和当前状态摘要。
|
||||
5. 同一事务内写入 Outbox，由 CDC 发布到 Kafka。
|
||||
6. External API Service 对外提供查询接口和事件订阅接口。
|
||||
7. 告警、人工裁决和重放都沿同一事实链路工作，不直接绕过 Published Fact。
|
||||
|
||||
### 4.3 领域划分与聚合边界
|
||||
|
||||
为避免多服务共同修改同一业务对象，MVP 采用以下聚合边界：
|
||||
|
||||
| 聚合 | 职责 | 主键 | 写主 | 发布事件 | 只读依赖 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| FlightOperation | 航班当前权威态、运行状态、发布事实 | `flight_id` | Flight Operation Service | `FlightUpdated`、`PublishedFactUpdated` | Turnaround、MilestoneObservation、ResourceAllocation |
|
||||
| MilestoneObservation | 里程碑原始观测、标准化观测、候选事实 | `observation_id` | Milestone Service | `MilestoneObserved`、`MilestoneNormalized` | FlightOperation |
|
||||
| Turnaround | 到达航班、离港航班、飞机周转上下文 | `turnaround_id` | Flight Operation Service | `TurnaroundLinked`、`TurnaroundCorrected` | FlightOperation |
|
||||
| ResourceAllocation | 资源占用、锁定、冲突、覆盖 | `allocation_id` | Resource Service | `ResourceAssigned`、`ResourceUnassigned`、`ResourceConflictDetected` | FlightOperation、Turnaround |
|
||||
| AlertCase | 告警和处置对象 | `alert_id` | Alert Service | `AlertRaised`、`AlertAcknowledged`、`AlertCleared` | FlightOperation、ResourceAllocation |
|
||||
|
||||
边界约束：
|
||||
|
||||
- Flight 当前权威态只能由 `Flight Operation Service` 写入。
|
||||
- Milestone Service 负责观测和候选事实，不直接改写 Flight 当前态。
|
||||
- Resource Service 只拥有资源占用与冲突事实，不直接修改 Flight 当前态中的非资源字段。
|
||||
- Alert Service 不产生业务事实，只管理处置状态和告警生命周期。
|
||||
|
||||
### 4.4 核心服务职责
|
||||
|
||||
- `Flight Operation Service`
|
||||
- 管理 FlightOperation 当前态。
|
||||
- 维护 Published Fact。
|
||||
- 负责 Turnaround 建模和关联修正。
|
||||
- `Milestone Service`
|
||||
- 接收外部运行动态。
|
||||
- 解析、标准化并形成 MilestoneObservation。
|
||||
- 依据字段权威矩阵给出候选事实。
|
||||
- `Resource Service`
|
||||
- 管理资源主数据和资源分配。
|
||||
- 进行适配校验、冲突检测、人工覆盖和回滚。
|
||||
- `Alert Service`
|
||||
- 管理告警、确认、关闭、抑制和处置轨迹。
|
||||
- `External API Service`
|
||||
- 提供查询接口。
|
||||
- 提供事件订阅接口或订阅分发适配层。
|
||||
- 不作为权威事实生成者。
|
||||
|
||||
## 5. 核心模型
|
||||
|
||||
### 5.1 核心标识约定
|
||||
|
||||
- Flight
|
||||
- `flight_key`：`carrier + flight_number + op_date + leg_no`
|
||||
- `flight_id`：内部不可变主键
|
||||
- Turnaround
|
||||
- `turnaround_id`
|
||||
- 可关联一个到达航班和一个离港航班
|
||||
- MilestoneObservation
|
||||
- `observation_id`
|
||||
- 幂等键优先使用上游报文 ID、序列号或批次 + 行号
|
||||
- Resource
|
||||
- `resource_id`
|
||||
- `resource_type + resource_code` 唯一
|
||||
- ResourceAllocation
|
||||
- `allocation_id`
|
||||
- 幂等键由 `resource_id + validity_window + assignment_source + correlation_id` 组合约束
|
||||
|
||||
### 5.2 核心实体与关系
|
||||
|
||||
- FlightOperation：指定运行日上的航班运行对象，包含当前发布事实和状态摘要。
|
||||
- Turnaround：将到达航班、离港航班和飞机周转上下文关联起来，用于资源和时序联动。
|
||||
- MilestoneObservation：里程碑观测记录，保留原始来源、标准化结果和候选事实。
|
||||
- Resource：资源主数据，MVP 覆盖 Stand、Gate、Belt、Counter。
|
||||
- ResourceAllocation：资源分配记录，含有效窗口、锁定类型、来源和覆盖原因。
|
||||
- AlertCase：告警对象，关联 FlightOperation 或 ResourceAllocation。
|
||||
- DataQualityFlag：对冲突、低可信度、超窗乱序、待裁决等问题做结构化标记。
|
||||
|
||||
关系约束：
|
||||
|
||||
- 一个 FlightOperation 对应多个 MilestoneObservation。
|
||||
- 一个 Turnaround 可关联一个到达航班和一个离港航班，也允许只有单侧航班待补全。
|
||||
- 一个 Resource 在时间轴上可关联多个 ResourceAllocation，但硬冲突不允许同时生效。
|
||||
- AlertCase 可关联具体 FlightOperation、Turnaround 或 ResourceAllocation。
|
||||
|
||||
### 5.3 FlightOperation 最小字段组
|
||||
|
||||
- 主键：`flight_id`、`flight_key`
|
||||
- 属性：`carrier`、`flight_number`、`op_date`、`leg_no`、`direction`
|
||||
- 机体上下文：`aircraft_type`、`tail_number`（可空）
|
||||
- 状态：`flight_status`
|
||||
- 发布事实：计划 / 预计 / 实际时间类字段
|
||||
- 当前资源摘要：Stand / Gate / Belt / Counter
|
||||
- 质量摘要：冲突标记、待裁决标记、最近裁决摘要
|
||||
- 关联：`turnaround_id`（可空）
|
||||
|
||||
### 5.4 Turnaround 最小字段组
|
||||
|
||||
- `turnaround_id`
|
||||
- `arrival_flight_id`
|
||||
- `departure_flight_id`
|
||||
- `tail_number`
|
||||
- `aircraft_type`
|
||||
- `turnaround_status`
|
||||
- `link_source`
|
||||
- `link_confidence`
|
||||
|
||||
约束：
|
||||
|
||||
- 配对可以晚于航班导入发生。
|
||||
- 配对修正必须产生 `TurnaroundCorrected` 事件并保留审计。
|
||||
- 若未知配对，FlightOperation 仍可独立运行，但资源和里程碑解释能力下降。
|
||||
|
||||
## 6. 事实分层模型
|
||||
|
||||
### 6.1 三层模型
|
||||
|
||||
| 层 | 含义 | 是否可变 | 用途 |
|
||||
| --- | --- | --- | --- |
|
||||
| Observation | 上游原始或标准化观测 | 否 | 追溯、回放、取证 |
|
||||
| Decision | 规则或人工裁决结果 | 否 | 解释为什么当前事实成立 |
|
||||
| Published Fact | 当前对外权威事实 | 是 | 查询、订阅、共享 |
|
||||
|
||||
### 6.2 SSOT 定义
|
||||
|
||||
AODB 的 SSOT 不等于“数据库中的最后一次写入”，而是：
|
||||
|
||||
- 由 Observation 输入
|
||||
- 经字段级权威矩阵与裁决逻辑处理
|
||||
- 最终形成并发布的 Published Fact
|
||||
|
||||
### 6.3 状态写入三元信息
|
||||
|
||||
所有关键状态写入都必须附带：
|
||||
|
||||
- `source`
|
||||
- `confidence`
|
||||
- `decision`（可空）
|
||||
|
||||
其中：
|
||||
|
||||
- Observation 必须保存原始来源和原始时序。
|
||||
- Decision 必须保存裁决者、依据、原因和裁决时间。
|
||||
- Published Fact 必须能追溯到 Observation 和 Decision。
|
||||
|
||||
### 6.4 字段级权威矩阵（最小集）
|
||||
|
||||
| 字段 | 主来源 | 次来源 | 更正规则 | 人工覆盖 | 对外可见性 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| ALDT | ANSP / 机场运行 | 航司 | 明确更正或高版本号优先 | 允许 | 返回当前值 + 来源 |
|
||||
| AIBT | 地服 / 机场运行 | 航司 | 同上 | 允许 | 返回当前值 + 来源 |
|
||||
| EIBT | 系统计算 | 运行动态派生 | 新计算覆盖旧计算并留历史 | 允许 | 返回当前值 + 可信度 |
|
||||
| TOBT | 航司 / 地服 | 机场运行 | 最新有效更正优先 | 允许 | 返回当前值 + 裁决摘要 |
|
||||
| TSAT | AODB / P1 PDS | 机场运行 | 新计算版本优先 | 允许 | 返回当前值 + 算法版本 |
|
||||
| Stand Assignment | 机场运行系统 | 人工调度 | 人工覆盖优先并保留原因 | 必须审计 | 返回当前值 + 覆盖摘要 |
|
||||
| Gate Assignment | 机场运行系统 | 人工调度 | 同上 | 必须审计 | 返回当前值 + 覆盖摘要 |
|
||||
| Belt Assignment | 机场运行系统 | 人工调度 | 同上 | 必须审计 | 返回当前值 + 覆盖摘要 |
|
||||
| Counter Assignment | 机场运行系统 | 人工调度 | 同上 | 必须审计 | 返回当前值 + 覆盖摘要 |
|
||||
|
||||
## 7. Flight 状态模型
|
||||
|
||||
### 7.1 最小状态机
|
||||
|
||||
- Planned：已导入计划但尚无有效运行动态。
|
||||
- Active：已有运行动态、里程碑或资源变更。
|
||||
- Completed：已达到收敛里程碑并进入归档策略。
|
||||
- Cancelled：取消或无效，但保留完整历史。
|
||||
|
||||
### 7.2 状态迁移原则
|
||||
|
||||
- 状态迁移由 Published Fact 驱动，而不是由单个外部系统直接声明。
|
||||
- 若存在冲突或裁决，不回滚 Observation 历史，只更新 Published Fact 和当前状态摘要。
|
||||
- 状态修正必须能通过事件和审计链路回放。
|
||||
|
||||
## 8. 历史、审计与回放
|
||||
|
||||
### 8.1 数据存储视图
|
||||
|
||||
- `ObservationLog`
|
||||
- 保存原始或标准化观测
|
||||
- `DecisionLog`
|
||||
- 保存规则命中和人工裁决
|
||||
- `PublishedCurrentState`
|
||||
- 保存当前对外权威事实
|
||||
- `AuditTrail`
|
||||
- 保存 `who / what / when / why`
|
||||
|
||||
### 8.2 基本约束
|
||||
|
||||
- PublishedCurrentState 的任何关键字段变更都必须能在 ObservationLog 和 DecisionLog 中找到原因链路。
|
||||
- 人工覆盖不得改写原始 Observation，只能新增 Decision 并更新 Published Fact。
|
||||
- 历史回放以事件和日志为准，不以任意时点快照为首期前提。
|
||||
|
||||
## 9. 资源模型与冲突治理
|
||||
|
||||
### 9.1 Resource 模型
|
||||
|
||||
每个 Resource 至少具备：
|
||||
|
||||
- `resource_id`
|
||||
- `resource_type`
|
||||
- `resource_code`
|
||||
- `status`
|
||||
- `capability_profile`
|
||||
- `compatibility_constraints`
|
||||
- `parent_resource_id`（可空）
|
||||
- `operational_calendar`
|
||||
|
||||
### 9.2 ResourceAllocation 模型
|
||||
|
||||
每个 ResourceAllocation 至少具备：
|
||||
|
||||
- `allocation_id`
|
||||
- `resource_id`
|
||||
- `flight_id`
|
||||
- `turnaround_id`（可空）
|
||||
- `allocation_status`
|
||||
- `assignment_source`
|
||||
- `lock_type`（`soft` / `hard`）
|
||||
- `validity_window`
|
||||
- `override_reason`（可空）
|
||||
- `derived_from_event`
|
||||
- `conflict_flags`
|
||||
|
||||
### 9.3 冲突分类
|
||||
|
||||
| 冲突类型 | 说明 | 是否阻断 | 是否允许人工覆盖 |
|
||||
| --- | --- | --- | --- |
|
||||
| 时间冲突 | 占用时间窗重叠 | 是 | 是 |
|
||||
| 适配冲突 | 机型、能力或运行属性不匹配 | 是 | 受限 |
|
||||
| 状态冲突 | 资源停用、维护、冻结 | 是 | 否 |
|
||||
| 策略冲突 | 本地策略或运营规则违反 | 视规则 | 是 |
|
||||
|
||||
### 9.4 四类资源规则口径
|
||||
|
||||
- Stand
|
||||
- 关注机型适配、拖曳、到离港时间窗、过站联动。
|
||||
- Gate
|
||||
- 关注旅客流程时间窗、国际国内属性、步行距离和能力约束。
|
||||
- Belt
|
||||
- 关注到港时序、机型、行李量经验参数和恢复能力。
|
||||
- Counter
|
||||
- 关注值机开放窗口、航司差异化规则和共享柜台能力。
|
||||
|
||||
### 9.5 人工覆盖原则
|
||||
|
||||
- 自动分配只产生建议或默认分配。
|
||||
- 人工覆盖必须记录原因、证据、操作者和影响范围。
|
||||
- 回滚必须和覆盖一样事件化和审计化。
|
||||
|
||||
## 10. 事件模型与一致性
|
||||
|
||||
### 10.1 事件分类
|
||||
|
||||
| 事件类别 | 说明 | 示例 |
|
||||
| --- | --- | --- |
|
||||
| Domain Events | 聚合内部事实变化 | `FlightUpdated`、`ResourceAssigned` |
|
||||
| Integration Events | 对外共享的标准化事件 | `PublishedFactUpdated`、`AlertRaised` |
|
||||
| Audit Events | 审计和裁决事件 | `ManualDecisionRecorded` |
|
||||
| Case Events | 人工复核和告警处置状态变化 | `ReviewTaskOpened`、`AlertAcknowledged` |
|
||||
|
||||
### 10.2 MVP 事件清单
|
||||
|
||||
- `FlightImported`
|
||||
- `FlightUpdated`
|
||||
- `TurnaroundLinked`
|
||||
- `TurnaroundCorrected`
|
||||
- `MilestoneObserved`
|
||||
- `MilestoneNormalized`
|
||||
- `PublishedFactUpdated`
|
||||
- `ResourceAssigned`
|
||||
- `ResourceUnassigned`
|
||||
- `ResourceConflictDetected`
|
||||
- `AlertRaised`
|
||||
- `AlertAcknowledged`
|
||||
- `AlertCleared`
|
||||
- `DataQualityFlagged`
|
||||
- `ManualDecisionRecorded`
|
||||
- `ReviewTaskOpened`
|
||||
- `ReviewTaskClosed`
|
||||
|
||||
### 10.3 事件归属表
|
||||
|
||||
| 事件 | 归属聚合 | 触发条件 | 是否对外发布 | 是否可回放 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `MilestoneObserved` | MilestoneObservation | 收到有效运行动态 | 否 | 是 |
|
||||
| `PublishedFactUpdated` | FlightOperation | 当前权威事实发生变化 | 是 | 是 |
|
||||
| `ResourceAssigned` | ResourceAllocation | 资源分配生效 | 是 | 是 |
|
||||
| `ResourceConflictDetected` | ResourceAllocation | 检测到冲突 | 是 | 是 |
|
||||
| `ManualDecisionRecorded` | Decision / Audit | 人工裁决完成 | 是 | 是 |
|
||||
| `AlertRaised` | AlertCase | 达到告警条件 | 是 | 是 |
|
||||
|
||||
### 10.4 统一事件信封
|
||||
|
||||
所有业务事件必须具备：
|
||||
|
||||
- `event_id`
|
||||
- `event_type`
|
||||
- `schema_version`
|
||||
- `occurred_at`
|
||||
- `produced_at`
|
||||
- `source`
|
||||
- `idempotency_key`
|
||||
- `correlation_id`
|
||||
- `aggregate_id`
|
||||
- `payload`
|
||||
|
||||
### 10.5 幂等、顺序和更正语义
|
||||
|
||||
- 所有写入事件必须携带 `idempotency_key`。
|
||||
- 顺序保证以 `flight_id` 为最小粒度。
|
||||
- 更正必须显式表达，不允许静默覆盖已发布事实。
|
||||
- 乱序允许在可配置窗口内重排，超窗进入审计旁路并打数据质量标记。
|
||||
|
||||
### 10.6 写库与发事件一致性
|
||||
|
||||
MVP 采用 `Outbox Pattern + CDC`：
|
||||
|
||||
- 业务服务在同一事务内更新 PublishedCurrentState 并写入 Outbox。
|
||||
- CDC / 发布器将 Outbox 可靠发布到 Kafka。
|
||||
- 发布失败必须可重试、可恢复、可审计。
|
||||
|
||||
## 11. 查询接口与事件订阅
|
||||
|
||||
### 11.1 接口分离原则
|
||||
|
||||
- 查询接口负责读取 Published Fact、历史明细和告警状态。
|
||||
- 事件订阅负责分发标准化事件流。
|
||||
- 查询接口不是事实流；订阅接口不承担读模型查询职责。
|
||||
|
||||
### 11.2 查询接口
|
||||
|
||||
最小查询对象：
|
||||
|
||||
- FlightOperation 当前态
|
||||
- MilestoneObservation 明细
|
||||
- ResourceAllocation 生效集
|
||||
- AlertCase 生命周期
|
||||
|
||||
最小要求：
|
||||
|
||||
- 支持按 `op_date`、`flight_id / flight_key`、资源类型、状态过滤
|
||||
- 返回更新时间和数据版本
|
||||
- 关键字段返回 `source / confidence / decision summary`
|
||||
|
||||
### 11.3 事件订阅接口
|
||||
|
||||
最小要求：
|
||||
|
||||
- 按 `event_type`、`flight_id`、`op_date` 过滤
|
||||
- 至少一次投递
|
||||
- 支持断线重连和补偿
|
||||
- 基于 `event_id` 或游标回放
|
||||
- 支持租户隔离、连接数和推送速率限流
|
||||
|
||||
### 11.4 消费者契约
|
||||
|
||||
- 顺序仅保证到 `flight_id`
|
||||
- 消费者必须按 `event_id` 去重
|
||||
- 消费者必须处理数据质量标记和裁决摘要
|
||||
- 回放窗口和游标语义必须文档化
|
||||
|
||||
## 12. 规则体系与人工复核
|
||||
|
||||
### 12.1 规则分类
|
||||
|
||||
- `authority rules`
|
||||
- `validation rules`
|
||||
- `conflict rules`
|
||||
- `alert rules`
|
||||
- `allocation heuristics`
|
||||
|
||||
### 12.2 规则最小模板
|
||||
|
||||
每条规则都必须定义：
|
||||
|
||||
- 输入
|
||||
- 输出
|
||||
- 优先级
|
||||
- 命中条件
|
||||
- 可解释字段
|
||||
- 回放测试方式
|
||||
|
||||
### 12.3 人工复核对象
|
||||
|
||||
- 解析失败复核
|
||||
- 里程碑冲突复核
|
||||
- 资源冲突裁决
|
||||
- 人工覆盖审批
|
||||
|
||||
### 12.4 Case 状态机
|
||||
|
||||
- `open`
|
||||
- `assigned`
|
||||
- `reviewing`
|
||||
- `decided`
|
||||
- `replayed`
|
||||
- `closed`
|
||||
|
||||
原则：
|
||||
|
||||
- 所有人工动作都必须事件化。
|
||||
- 所有人工动作都必须形成审计记录。
|
||||
|
||||
## 13. 非功能与部署
|
||||
|
||||
### 13.1 最小 SLO
|
||||
|
||||
| 指标 | 目标值 | 最低可接受值 |
|
||||
| --- | --- | --- |
|
||||
| 可用性 | 月度 99.95% | 月度 99.9% |
|
||||
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 |
|
||||
| 容灾恢复 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 |
|
||||
| 审计覆盖率 | 100% 关键变更可追溯 | 99.9% 可追溯 |
|
||||
|
||||
### 13.2 最小部署拓扑
|
||||
|
||||
| 组件 | 部署方式 | 高可用方式 | 失败影响 | 恢复方式 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| PostgreSQL / TimescaleDB | Stateful 部署 | 主备切换 + 定时备份 | 当前态和审计写入受影响 | 备份恢复 + 故障切换 |
|
||||
| Kafka | 多副本集群 | 副本和 ISR 保障 | 事件流中断或降级 | Broker 恢复 + 消费追赶 |
|
||||
| CDC / 发布器 | 无状态服务 | 多副本 + 幂等发布 | Outbox 堆积 | 断点续传 + 重试 |
|
||||
| API / 业务服务 | 无状态部署 | 多副本 | 查询或写入能力降级 | 滚动恢复 |
|
||||
| Redis | 主从或哨兵 | 缓存级高可用 | 热点查询性能下降 | 重建缓存 |
|
||||
|
||||
### 13.3 关键容灾约束
|
||||
|
||||
- PostgreSQL 必须具备 PITR 或等价恢复能力。
|
||||
- Kafka 必须明确 `replication factor`、`min ISR`、保留窗口和重放策略。
|
||||
- Outbox / CDC 必须具备断点恢复和重复投递幂等能力。
|
||||
- 容灾演练必须覆盖数据库切换、事件堆积、订阅重连和回放。
|
||||
|
||||
### 13.4 可观测性要求
|
||||
|
||||
- 所有写路径必须具备请求追踪、事件追踪和审计追踪三类关联 ID。
|
||||
- 关键链路必须暴露延迟、失败率、积压量和重试次数指标。
|
||||
- 人工裁决、资源覆盖和更正事件必须进入统一审计检索视图。
|
||||
- 订阅接口必须暴露连接数、滞后量、推送速率和补偿次数指标。
|
||||
|
||||
## 14. 文档边界与引用
|
||||
|
||||
- 本文档定义首期可开工的技术方案，不展开字段级数据字典和实现细节。
|
||||
- 技术栈主选和启用条件以 `airport-wiki/concepts/aodb/开源技术栈选型决策.md` 为准。
|
||||
- 需求边界以 `airport-wiki/concepts/aodb/AODB 核心需求提炼.md` 为准。
|
||||
- 字段级权威矩阵以 `airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md` 为准。
|
||||
- 事件 envelope 和 payload 草案以 `airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md` 为准。
|
||||
- 最小部署拓扑和恢复策略草案以 `airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md` 为准。
|
||||
- 关键设计取舍以 `airport-wiki/concepts/aodb/adr/` 下 ADR 为准。
|
||||
@@ -0,0 +1,243 @@
|
||||
---
|
||||
title: AODB — 中國市場現狀與國產化替代
|
||||
created: 2026-04-10
|
||||
updated: 2026-04-10
|
||||
type: concept
|
||||
tags: [aodb, china-market, localization, travelsky, wanda-info, cetc, beijing-capital]
|
||||
sources: [raw/articles/aodb.md]
|
||||
---
|
||||
|
||||
# AODB — 中國市場現狀與國產化替代
|
||||
|
||||
> 本頁聚焦中國機場 AODB 市場的國產化進程、主要廠商與典型案例。國際供應商對比見 [[aodb-vendors]]。
|
||||
|
||||
## 政策背景與驅動力
|
||||
|
||||
### 標準規範
|
||||
|
||||
中國民航局高度重視機場信息系統的標準化與自主可控，相關核心標準：
|
||||
|
||||
| 標準 | 發布機構 | 說明 |
|
||||
|------|---------|------|
|
||||
| **MH/T 5103-2020** | 中國民航局 | 《民用運輸機場信息集成系統技術規範》—— 為國內 AODB 建設提供明確標準，定義了信息集成系統的架構、數據接口、功能要求 |
|
||||
| **智慧民航建設路線圖** | 中國民航局 | 「十四五」和「十五五」規劃明確要求機場核心系統國產化比例提升，AODB 被列為重點攻關對象 |
|
||||
| **數據安全法 / 個人信息保護法** | 全國人大 | 機場運營數據涉及航班、旅客個人信息，必須滿足數據本地化存儲要求，進口系統合規成本陡增 |
|
||||
|
||||
### 國產化驅動因素
|
||||
|
||||
1. **成本因素**：進口系統（尤其是 SITA、Amadeus）許可費和維保費昂貴，年度維保通常為初期許可費的 18-22%，長期成本負擔重
|
||||
2. **數據安全**：進口系統的境外數據通道面臨嚴格審查，航班數據屬於關鍵信息基礎設施數據
|
||||
3. **定制能力**：進口系統定制化開發需通過原廠，響應週期長、成本高
|
||||
4. **自主可控**：類似北京首都機場案例，掌握核心技術才能真正保障重大活動期間的系統穩定性
|
||||
|
||||
---
|
||||
|
||||
## 主要國產廠商深度分析
|
||||
|
||||
---
|
||||
|
||||
### 1. 中國民航信息集團（TravelSky）— 機場信息集成系統
|
||||
|
||||
**定位：** 中國民航 IT 國家隊，PSS 領域絕對領導者，機場集成系統頭部供應商
|
||||
|
||||
#### 核心優勢
|
||||
|
||||
|| 維度 | 說明 |
|
||||
|------|------|------|
|
||||
| **數據天然互通** | 中國民航信息集團同時運營中國的 CRS（機票分銷系統）和 DCS（離港系統），與國航、南航、東航等主要航司數據天然打通，AODB 可直接獲取航班動態而無需額外接口 |
|
||||
| **國產化標杆** | 2025 年實現離港系統（ DCS）全棧國產化，是民航業首家完成核心系統全棧國產化的企業，AODB 具備同樣的國產化能力 |
|
||||
| **機場覆蓋廣** | 在國內中大型機場擁有廣泛的項目積累，熟悉國內民航業務流程和監管要求 |
|
||||
| **政策支持** | 作為央企，在重大項目招投標中具備政策支持優勢 |
|
||||
|
||||
#### 現有產品線
|
||||
|
||||
| 產品 | 說明 |
|
||||
|------|------|
|
||||
| **機場信息集成系統（AIIS）** | 以 AODB 為核心的機場運營數據平台，支持航班動態、資源分配、計費結算 |
|
||||
| **機場協同決策（A-CDM）** | 與 AODB 深度集成，支持 A-CDM 協同決策全流程 |
|
||||
| **民航大數據平台** | 面向民航局的行業級數據分析平台 |
|
||||
|
||||
#### 目標場景
|
||||
|
||||
- 已有或計劃採用 TravelSky DCS 的機場
|
||||
- 需要與國內航司數據無縫對接的機場
|
||||
- 對數據本地化有剛性要求的大型樞紐
|
||||
- 響應「智慧民航」政策要求的機場
|
||||
|
||||
---
|
||||
|
||||
### 2. 萬達信息股份有限公司 — 萬達機場集成系統（AIIS）
|
||||
|
||||
**定位：** 國內較早涉足機場信息化的上市企業，以上市公司標準化產品交付能力著稱
|
||||
|
||||
#### 核心技術特性
|
||||
|
||||
|| 特性 | 說明 |
|
||||
|------|------|
|
||||
| **AODB 為核心的集成架構** | 國內首家明確以 AODB 為核心的機場運營管理系統廠商，技術路線與國際標準接軌 |
|
||||
| **全棧產品線** | 除了 AODB，還提供 FIDS、資源管理、行李追蹤等配套系統，減少多廠商集成複雜度 |
|
||||
| **標準化程度高** | 產品化程度高，實施流程規範，降低項目風險 |
|
||||
| **A股上市公司** | 具備穩定的資本市場支持，長期服務能力有保障 |
|
||||
|
||||
#### 典型部署案例
|
||||
|
||||
| 機場 | 規模 | 部署內容 |
|
||||
|------|------|---------|
|
||||
| **上海浦東國際機場** | 年旅客量 > 7000萬 | AODB + 資源管理核心模塊 |
|
||||
| **寧波櫟社國際機場** | 年旅客量 ~ 1000萬 | 機場信息集成系統 |
|
||||
| **溫州龍灣國際機場** | 年旅客量 ~ 1000萬 | 機場信息集成系統 |
|
||||
|
||||
#### 技術架構
|
||||
|
||||
- 數據庫：支持 Oracle / PostgreSQL
|
||||
- 中間件：標准企業服務總線（ESB）
|
||||
- 接口：支持 AIDX、XML、JSON API
|
||||
- 部署：本地部署為主，支持混合雲
|
||||
|
||||
#### 目標場景
|
||||
|
||||
- 年旅客量 500 萬 - 5000 萬的中大型機場
|
||||
- 偏好標準化、產品化交付以控制項目風險
|
||||
- 需要一站式採購（減少多廠商協調成本）
|
||||
- 以上市公司為長期服務商選擇標準
|
||||
|
||||
---
|
||||
|
||||
### 3. 中電科數字技術股份有限公司（CETC Digital）— 機場數字化
|
||||
|
||||
**定位：** 央企背景，機場弱電系統集成專家，智慧機場整體解決方案提供商
|
||||
|
||||
#### 核心優勢
|
||||
|
||||
|| 維度 | 說明 |
|
||||
|------|------|------|
|
||||
| **央企資源整合能力** | 中國電科集團在電子信息領域擁有完整產業鏈，能整合雷達、通信、計算、存儲等資源 |
|
||||
| **弱電系統整合** | AODB 不僅是軟件系統，CETC 在機場弱電（網絡、數據中心、節點設備）的整體集成能力強 |
|
||||
| **數據中心建設** | 參與多個千萬級機場的智慧化改造和數據中心建設，AODB 運行環境自主可控 |
|
||||
| **軍民融合** | 繼承中國電科在軍航空管領域的技術積累，系統可靠性標準高 |
|
||||
|
||||
#### 主要能力
|
||||
|
||||
- **機場弱電總包**：網絡架構、數據中心、服務器集群的規劃與建設
|
||||
- **核心軟件研發**：機場運營軟件平台的定製開發
|
||||
- **智慧機場整體諮詢**：從規劃到交付的全過程服務
|
||||
- **數據融合平台**：多源數據（空管、航司、地面服務）的統一路由與清洗
|
||||
|
||||
#### 典型項目
|
||||
|
||||
- **北京大興國際機場**：參與弱電系統集成（不僅是 AODB，而是整個數字化基礎設施）
|
||||
- **成都天府國際機場**：智慧機場整體數字化規劃與實施
|
||||
- **多個千萬級機場**智慧化改造項目
|
||||
|
||||
#### 目標場景
|
||||
|
||||
- 需要整個機場數字化基礎設施統籌建設的大型樞紐
|
||||
- 對數據中心、網絡架構有自主可控要求的機場
|
||||
- PPP / EPC 模式下的機場建設項目
|
||||
- 需要央企信用背書和長期運維保障的政府機場
|
||||
|
||||
---
|
||||
|
||||
## 典型案例：北京首都國際機場 AODB 自主研發
|
||||
|
||||
首都機場作為中國最繁忙的樞紐（A級機場，年旅客量峰值超過 1 億），其 AODB 系統完成了從進口產品到完全自主可控的轉型，是中國機場 AODB 國產化最具代表性的案例。
|
||||
|
||||
### 背景與痛點
|
||||
|
||||
| 痛點維度 | 具體問題 |
|
||||
|---------|---------|
|
||||
| **成本** | 進口系統年度維保費用高昂，每年維保支出相當於新建系統費用的近四分之一 |
|
||||
| **升級受限** | 核心技術掌握在原廠手中，功能升級需要依賴原廠開發，響應週期長 |
|
||||
| **安全隱患** | 航班運營數據通過境外通道傳輸，面臨數據安全審查壓力 |
|
||||
| **定制困難** | 機場特有業務需求（如特殊活動保障）難以在原系統中實現 |
|
||||
|
||||
### 實施路徑
|
||||
|
||||
1. **技術調研階段（3個月）**：信息技術團隊對原系統進行代碼級分析，摸清數據模型、業務邏輯和接口規範
|
||||
2. **自主設計階段（2個月）**：參照 MH/T 5103-2020 標準，設計新系統架構，確保與國際標準接軌
|
||||
3. **開發與測試（6個月）**：基於 Oracle + Java 技術棧完成核心功能開發，進行多輪壓力測試
|
||||
4. **並行運行與割接（3個月）：新舊系統並行運行，逐步將流量遷移到新系統
|
||||
|
||||
**總工期：14個月**
|
||||
|
||||
### 核心成效
|
||||
|
||||
| 指標 | 改善前 | 改善後 |
|
||||
|------|--------|--------|
|
||||
| 每日航班計劃校驗次數 | 3次人工校驗 | 1次自動校驗 |
|
||||
| 維護工作量 | 高（依賴原廠）| 降低30%+ |
|
||||
| 重大活動保障響應 | 需要原廠支持 | 團隊自主可控 |
|
||||
| 系統升級成本 | 高（原廠報價）| 大幅降低 |
|
||||
|
||||
> 首都機場的成功證明，大型樞紐 AODB 自主研發在技術上是可行的，關鍵在於有足夠的技術積累和14個月以上的持續投入。
|
||||
|
||||
### 適用性分析
|
||||
|
||||
| 因素 | 評估 |
|
||||
|------|------|
|
||||
| **技術可行性** | 高——民航信息技術團隊實力強，能掌握核心代碼 |
|
||||
| **資源投入** | 高——需要10+人核心團隊，14個月以上工期 |
|
||||
| **適用範圍** | 超大型樞紐（年旅客量>3000萬）有此實力和必要性；中小機場不建議自研 |
|
||||
| **風險點** | 自研系統缺少大型樞紐實際運行驗證，保障重大活動前需充分測試 |
|
||||
|
||||
---
|
||||
|
||||
## 選型決策：國產 vs 進口
|
||||
|
||||
| 維度 | 國產廠商 | 進口廠商 |
|
||||
|------|---------|---------|
|
||||
| **政策合規** | 天然滿足數據本地化和國產化要求 | 需要額外數據安全審查 |
|
||||
| **與國內航司數據互通** | TravelSky 等廠商天然具備數據通道 | 需要額外接口開發 |
|
||||
| **國際航班數據覆蓋** | 覆蓋中國航司為主，國際航司依賴 SSIM/IAI接口 | Amadeus 等覆蓋全球95%+航司 |
|
||||
| **定制化響應** | 本地團隊響應快，成本低 | 原廠響應慢，費用高 |
|
||||
| **大型樞紐案例** | 首都機場（自研）、浦東等 | SITA 150+機場、Amadeus 700+機場 |
|
||||
| **AI/ML 能力** | 較弱，處於追趕階段 | Amadeus、ADB Safegate 有原生AI能力 |
|
||||
| **初期投資** | 較低（本地部署，性價比方案）| 高（許可費+實施費）|
|
||||
| **長期維保成本** | 可控，本地團隊 | 高（年度維保 18-22% 許可費）|
|
||||
|
||||
### 建議路徑
|
||||
|
||||
**超大型樞紐（> 3000萬旅客）**：
|
||||
- 有實力和資金 → 首都機場模式（自研，掌握核心技術）
|
||||
- 需要快速交付 → SITA Operations Manager 或 Amadeus AODB
|
||||
|
||||
**中大型機場（1000-3000萬旅客）**：
|
||||
- 首選國產頭部廠商（TravelSky、民航信科旗下產品）
|
||||
- 已有進口 DCS/FIDS 系統 → 選擇與現有系統集成度好的方案
|
||||
|
||||
**中小型機場（< 1000萬旅客）**：
|
||||
- 國產 SaaS 化輕量方案（按年訂閱，降低初期投入）
|
||||
- RESA INFOPAX（歐洲產品，國內支持團隊需確認）
|
||||
|
||||
---
|
||||
|
||||
## 監管標準與合規要點
|
||||
|
||||
### MH/T 5103-2020 核心要求
|
||||
|
||||
《民用運輸機場信息集成系統技術規範》規定的 AODB 核心要求：
|
||||
|
||||
1. **航班數據管理**：支持航班計劃、動態數據的全生命周期管理
|
||||
2. **資源管理**：停機位、登機口、行李轉盤等資源的分配與查詢
|
||||
3. **數據分發**：向 FIDS、DCS、資源管理系統等下游系統分發數據
|
||||
4. **接口標準**：支持與空管、航司、地面服務商的數據交換
|
||||
5. **系統可靠性**：支持 7×24 小時運行，可用性 ≥ 99.99%
|
||||
|
||||
### 數據本地化要求
|
||||
|
||||
| 數據類型 | 存儲要求 |
|
||||
|---------|---------|
|
||||
| 航班計劃數據 | 必須本地存儲 |
|
||||
| 旅客個人信息 | 必須本地存儲，符合《個人信息保護法》|
|
||||
| 航班動態數據 | 必須本地存儲 |
|
||||
| 跨境傳輸 | 需通過安全評估，涉及關鍵信息基礎設施需申報 |
|
||||
|
||||
---
|
||||
|
||||
## 相關鏈接
|
||||
|
||||
- [[aodb-core]] — AODB 核心概念、技術標準與 A-CDM 里程碑
|
||||
- [[aodb-vendors]] — 國際供應商深度分析（SITA、Amadeus、Collins、RESA、ISO Software 等）
|
||||
- [[a-cdm]] — A-CDM 與 AODB 的協同關係
|
||||
- [[flight-data-exchange]] — SSIM、AIDX、XML/CIDX 等數據交換標準
|
||||
- [[comparisons/airport-operations-systems]] — 機場運營系統供應商全景對比
|
||||
@@ -4,7 +4,7 @@ created: 2026-04-08
|
||||
updated: 2026-04-10
|
||||
type: concept
|
||||
tags: [aodb, flight-data, system, database, a-cdm]
|
||||
sources: [raw/articles/adb-safegate-aodb-2025.md, raw/articles/amadeus-aodb.md]
|
||||
sources: [raw/articles/aodb.md, raw/articles/adb-safegate-aodb-2025.md, raw/articles/amadeus-aodb.md]
|
||||
---
|
||||
|
||||
# AODB — 機場運營數據庫（核心概念）
|
||||
@@ -43,48 +43,130 @@ AODB（Airport Operational Database，機場運營數據庫）是機場信息系
|
||||
## A-CDM Milestone 完整定義
|
||||
|
||||
| 縮寫 | 全稱 | 中文 | 更新責任方 |
|
||||
|------|------|------|----------|
|
||||
|------|------|------|------------|
|
||||
| ELDT | Estimated Landing Time | 預計落地時間 | 系統計算 |
|
||||
| ALDT | Actual Landing Time | 實際落地時間 | ANSP（管制）|
|
||||
| ALDT | Actual Landing Time | 實際落地時間 | ANSP（管制） |
|
||||
| EOBT | Estimated Off-Block Time | 預計推出時間（航班計劃） | 航司 |
|
||||
| AOBT | Actual Off-Block Time | 實際推出時間 | 地面服務商 |
|
||||
| TOBT | Target Off-Block Time | 目標推出時間 | 航司/地面服務商 |
|
||||
| TSAT | Target Start-Up Approval Time | 目標啟動許可時間 | AODB/PDS |
|
||||
| TTOT | Target Take-Off Time | 目標起飛時間 | AODB/PDS |
|
||||
| ATOT | Actual Take-Off Time | 實際起飛時間 | ANSP |
|
||||
| CTOT | Calculated Take-Off Time | ATFM 計算起飛時間 | ATFM（Network Manager）|
|
||||
| CTOT | Calculated Take-Off Time | ATFM 計算起飛時間 | ATFM（Network Manager） |
|
||||
| EXOT | Expected Taxi-Out Time | 預計滑出時間 | AODB VTT 模塊 |
|
||||
| EXIT | Expected Taxi-In Time | 預計滑入時間 | AODB VTT 模塊 |
|
||||
|
||||
## 供應商概要對比
|
||||
|
||||
| 廠商 | 定位 | 典型機場規模 | 上線週期 |
|
||||
|------|------|------------|---------|
|
||||
|------|------|--------------|----------|
|
||||
| ADB SAFEGATE Cortex | AI 驅動全棧樞紐平台 | >3000萬旅客 | 2-3個月 |
|
||||
| Amadeus | 雲優先，95%全球航司覆蓋 | >1000萬旅客 | 1-2個月 |
|
||||
| AirportLabs SkyCore | 雲原生，性價比方案 | 500萬-5000萬 | 2-4週 |
|
||||
| PDC Aviation | 多機場模式，傳統穩定 | <2000萬旅客 | 1-2週 |
|
||||
| Indra InBASE | Aena網絡，拉美標杆 | 所有規模 | 1-2個月 |
|
||||
| **SITA Operations Manager** | **全球巨頭，超大型樞紐** | **>4000萬旅客** | **2-4個月** |
|
||||
| Collins Aerospace AirDB | 混合部署，軍工級可靠性 | 所有規模 | 1-3個月 |
|
||||
| RESA INFOPAX | 中小型，移動端出色 | <1500萬旅客 | 2-4週 |
|
||||
| ISO Software SKYport | Oracle 技術棧，德系品質 | 500萬-3000萬 | 1-2個月 |
|
||||
|
||||
> 詳細供應商分析見 [[aodb-vendors]]
|
||||
|
||||
---
|
||||
|
||||
## 市場規模與增長趨勢
|
||||
|
||||
| 指標 | 數據 | 來源 |
|
||||
|------|------|------|
|
||||
| 全球機場信息系統市場（2024）| 42.4 億美元 | Research and Markets |
|
||||
| 全球機場信息系統市場（2030）| 53.6 億美元（CAGR ~4%）| Research and Markets |
|
||||
| **AODB 專項市場（2024）** | **約 8.2 億美元** | Growth Market Reports |
|
||||
| **AODB 專項市場（2033）** | **超過 50 億美元** | Growth Market Reports |
|
||||
|
||||
AODB 市場增速顯著高於整體機場信息系統，反映智慧機場建設對核心數據中樞的剛性需求。
|
||||
|
||||
## 關鍵技術標準
|
||||
|
||||
### AIDX（Aviation Information Data Exchange）
|
||||
|
||||
IATA、ATA、ACI 共同認可的全球 XML 消息標準，用於航空公司、機場、第三方之間交換航班運營數據。是 SESAR A-CDM 信息交換的標準格式。所有現代 AODB 必須原生支持 AIDX 接口。
|
||||
|
||||
> 詳細規範（消息類型、XML 結構、運營狀態碼、A-CDM 里程碑代碼）見 [[flight-data-exchange]]。
|
||||
|
||||
### SSIM（Standard Schedules Information Manual）
|
||||
|
||||
IATA 定義的航班時刻表交換格式標準。AODB 需能解析 SSIM 文件（如 Chapter 7 格式），自動構建機場季節性航班計劃。
|
||||
|
||||
> 詳細規範（SCR 報文14字段格式、協調員響應代碼）見 [[flight-data-exchange]]。
|
||||
|
||||
### 傳統航空報文標準
|
||||
|
||||
即使 XML 和 API 日漸普及，AODB 仍需支持以下傳統格式以確保與老系統的互操作性：
|
||||
|
||||
| 標準 | 說明 |
|
||||
|------|------|
|
||||
| **AFTN** | 航空固定電信網報文，國家級空管數據骨幹 |
|
||||
| **SITA Type B** | SITA 網絡報文格式，ARINC 兼容 |
|
||||
| **ACARS** | 飛機通信尋址與報告系統，實時飛機動態數據 |
|
||||
|
||||
## 中國市場與國產化
|
||||
|
||||
中國民航局高度重視機場信息系統的標準化與自主可控。《民用運輸機場信息集成系統技術規範》(MH/T 5103-2020) 為國內 AODB 建設提供了明確標準。在「十四五」和「十五五」智慧民航建設規劃推動下，國產化替代進程顯著加速。
|
||||
|
||||
**典型案例：北京首都國際機場**
|
||||
- 原有外資系統成本高、升級困難、存在安全隱患
|
||||
- 歷時14個月，信息技術團隊從代碼級掌握核心技術，自主研發新一代 AODB
|
||||
- 成效：每日航班計劃發布由3次人工校驗簡化為1次，維護工作量減少30%+
|
||||
|
||||
詳細國產廠商分析見 [[aodb-china]]。
|
||||
|
||||
## A-CDM Milestone 完整定義（16項擴展版）
|
||||
|
||||
| 縮寫 | 全稱 | 中文 | 更新責任方 |
|
||||
|------|------|------|------------|
|
||||
| ELDT | Estimated Landing Time | 預計落地時間 | 系統計算 |
|
||||
| ALDT | Actual Landing Time | 實際落地時間 | ANSP（管制） |
|
||||
| EOBT | Estimated Off-Block Time | 預計推出時間（航班計劃） | 航司 |
|
||||
| AOBT | Actual Off-Block Time | 實際推出時間 | 地面服務商 |
|
||||
| COBT | Calculated Off-Block Time | 計算推出時間（配合CTOT） | AODB |
|
||||
| TOBT | Target Off-Block Time | 目標推出時間 | 航司/地面服務商 |
|
||||
| TSAT | Target Start-Up Approval Time | 目標啟動許可時間 | AODB/PDS |
|
||||
| TTOT | Target Take-Off Time | 目標起飛時間 | AODB/PDS |
|
||||
| ATOT | Actual Take-Off Time | 實際起飛時間 | ANSP |
|
||||
| CTOT | Calculated Take-Off Time | ATFM 計算起飛時間 | ATFM（Network Manager） |
|
||||
| EXOT | Expected Taxi-Out Time | 預計滑出時間 | AODB VTT 模塊 |
|
||||
| EIBT | Expected In-Block Time | 預計靠橋時間 | AODB VTT 模塊 |
|
||||
| EXIT | Expected Taxi-In Time | 預計滑入時間 | AODB VTT 模塊 |
|
||||
| AIBT | Actual In-Block Time | 實際靠橋時間 | 地面服務商 |
|
||||
| ATIGT | Actual Time In Gate | 實際靠橋時間（通用） | 地面服務商 |
|
||||
| TTIGT | Target Time In Gate | 目標靠橋時間 | AODB |
|
||||
|
||||
> 16項里程碑覆蓋航班從預計落地到靠橋的完整生命周期。AODB 需自動捕捉所有時間戳，觸發相應業務規則，並通過 AIDX 接口與各國流量管理系統（NMOC）交換數據。
|
||||
|
||||
## 選型決策樹
|
||||
|
||||
```
|
||||
年旅客量 > 3000萬
|
||||
年旅客量 > 4000萬（超大型樞紐）
|
||||
├── 需要極強數據治理 + IROPS 能力 → SITA Operations Manager
|
||||
├── 需要全棧統一管理 + AI 預測 → ADB SAFEGATE Cortex AODB
|
||||
└── 有實力自研 + 長期自主可控 → 首都機場模式（自研）
|
||||
|
||||
年旅客量 3000-4000萬
|
||||
├── 需要全棧統一管理 → ADB SAFEGATE Cortex AODB
|
||||
├── 已有 Amadeus Altéa → Amadeus AODB
|
||||
└── 需要 AI 預測能力 → ADB SAFEGATE Cortex AODB
|
||||
└── 需要極強數據治理 → SITA Operations Manager
|
||||
|
||||
年旅客量 1000-3000萬
|
||||
├── 需要快速上線 + 雲原生 → AirportLabs SkyCore AODB
|
||||
├── 已有 Amadeus 系統 → Amadeus AODB
|
||||
└── 預算有限 → AirportLabs SkyCore AODB
|
||||
├── 預算有限 → RESA INFOPAX / ISO SKYport
|
||||
└── 美洲/混合部署偏好 → Collins AirDB
|
||||
|
||||
年旅客量 < 1000萬
|
||||
├── 多機場集團 → PDC AODB（Multi-Airport Mode）
|
||||
├── 快速上線（< 2週）→ PDC AODB
|
||||
└── 歐洲/拉美 Aena 網絡 → Indra InBASE AODB
|
||||
├── 歐洲/非洲本地支持 → RESA INFOPAX
|
||||
└── 拉丁美洲 Aena 網絡 → Indra InBASE AODB
|
||||
```
|
||||
|
||||
## 相關鏈接
|
||||
|
||||
@@ -4,7 +4,7 @@ created: 2026-04-08
|
||||
updated: 2026-04-10
|
||||
type: concept
|
||||
tags: [aodb, vendor, comparison, ai-ml]
|
||||
sources: [raw/articles/adb-safegate-aodb-2025.md, raw/articles/amadeus-aodb.md]
|
||||
sources: [raw/articles/aodb.md, raw/articles/aodb-manus-2026.md]
|
||||
---
|
||||
|
||||
# AODB — 供應商深度分析
|
||||
@@ -261,57 +261,235 @@ SkyCore AODB 並非孤立產品，而是 AirportLabs 全套生態的核心：
|
||||
|
||||
---
|
||||
|
||||
## 供應商綜合技術對比
|
||||
## 供應商綜合技術對比（9廠商）
|
||||
|
||||
| 維度 | ADB SAFEGATE Cortex | Amadeus | AirportLabs SkyCore | PDC | Indra InBASE |
|
||||
|------|---------------------|---------|---------------------|-----|-------------|
|
||||
| **部署模式** | 雲托管 + 本地 | 純雲 | 雲原生（OpenShift）| 本地/混合 | 本地/集中 |
|
||||
| **數據庫** | 未公開 | 未公開 | PostgreSQL（推測）| Oracle | J2EE 標準 |
|
||||
| **消息中間件** | 未公開 | 私有 | ActiveMQ | Publish-Subscribe WS | JMS（推測）|
|
||||
| **AI/ML 能力** | 原生 AI 引擎 | 有限 | 規則引擎（可視化）| 無 | 無 |
|
||||
| **"What-if" 仿真** | 支持 | 否 | 否 | 否 | 否 |
|
||||
| **多機場模式** | 支持 | 支持 | 支持 | **原生多機場** | 集中架構 |
|
||||
| **A-CDM 原生支持** | 是 | 是 | 是 | 是 | Level 3 CDM |
|
||||
| **上線週期** | 2-3 個月 | 1-2 個月 | **2-4 週** | **1-2 週** | 1-2 個月 |
|
||||
| **數據覆蓋** | 依賴集成 | **95% 航司 365 天** | 依賴集成 | 依賴集成 | Aena 網絡 |
|
||||
| **生態完整性** | 極強（Cortex 全套）| 強（Altéa 生態）| 強（AirportLabs 全套）| 中（PDC SCORE）| 中（Indra 空管）|
|
||||
| **國際案例規模** | 全球樞紐 | 全球大型 | 100+ 機場，ORD 旗艦 | 北歐/加拿大為主 | Aena 47 機場 |
|
||||
| **安全認證** | ISO27001, NIST | 未公開 | 未公開 | 未公開 | 未公開 |
|
||||
| **典型目標機場** | >3000 萬 | >1000 萬 | 500 萬-5000 萬 | <2000 萬 | 所有規模 |
|
||||
|| 維度 | ADB SAFEGATE Cortex | Amadeus | AirportLabs SkyCore | PDC | Indra InBASE | SITA Operations Manager | Collins AirDB | RESA INFOPAX | ISO SKYport |
|
||||
||------|---------------------|---------|---------------------|-----|--------------|----------------------|--------------|--------------|-------------|
|
||||
| **部署模式** | 雲托管 + 本地 | 純雲 | 雲原生（OpenShift）| 本地/混合 | 本地/集中 | 雲托管 + 本地 | 混合部署 | 本地/SaaS | 本地/雲原生 |
|
||||
| **數據庫** | 未公開 | 未公開 | PostgreSQL（推測）| Oracle | J2EE 標準 | 未公開 | 未公開 | 未公開 | Oracle |
|
||||
| **消息中間件** | 未公開 | 私有 | ActiveMQ | Publish-Subscribe WS | JMS（推測）| 未公開 | 未公開 | 私有 | 未公開 |
|
||||
| **AI/ML 能力** | 原生 AI 引擎 | 有限 | 規則引擎（可視化）| 無 | 無 | Total Optimizer AI（2024）| 動態資源分配 | 無 | 無 |
|
||||
| **"What-if" 仿真** | 支持 | 否 | 否 | 否 | 否 | 支持 | 否 | 否 | 否 |
|
||||
| **多機場模式** | 支持 | 支持 | 支持 | **原生多機場** | 集中架構 | 支持 | 支持 | 支持 | 支持 |
|
||||
| **A-CDM 原生支持** | 是 | 是 | 是 | 是 | Level 3 CDM | 是 | 是 | 是 | 是 |
|
||||
| **上線週期** | 2-3 個月 | 1-2 個月 | **2-4 週** | **1-2 週** | 1-2 個月 | 2-4 個月 | 1-3 個月 | 2-4 週 | 1-2 個月 |
|
||||
| **數據覆蓋** | 依賴集成 | **95% 航司 365 天** | 依賴集成 | 依賴集成 | Aena 網絡 | 依賴集成 | 依賴集成 | 依賴集成 | 依賴集成 |
|
||||
| **生態完整性** | 極強（Cortex 全套）| 強（Altéa 生態）| 強（AirportLabs 全套）| 中（PDC SCORE）| 中（Indra 空管）| 極強（SITA 全套）| 強（Collins 全套）| 中（RESA 計費）| 中（ISO 全套）|
|
||||
| **國際案例規模** | 全球樞紐 | 全球大型 | 100+ 機場，ORD 旗艦 | 北歐/加拿大為主 | Aena 47 機場 | **150+ 機場** | 美洲/歐洲主流 | 歐洲/非洲中型 | 歐美中等規模 |
|
||||
| **安全認證** | ISO27001, NIST | 未公開 | 未公開 | 未公開 | 未公開 | ISO27001 | 未公開 | 未公開 | 未公開 |
|
||||
| **典型目標機場** | >3000萬 | >1000萬 | 500萬-5000萬 | <2000萬 | 所有規模 | **>4000萬** | 所有規模 | <1500萬 | 500萬-3000萬 |
|
||||
|
||||
## 關鍵技術差異分析
|
||||
|
||||
### AI 能力梯隊
|
||||
|
||||
| 梯隊 | 廠商 | AI 能力 |
|
||||
|------|------|---------|
|
||||
| 第一梯隊 | ADB SAFEGATE | 原生 AI 引擎 + ML，支持運營預測和資源優化 |
|
||||
| 第二梯隊 | Amadeus | 有限 AI（輔助決策），強在 Altéa 數據整合 |
|
||||
| 第三梯隊 | AirportLabs | 規則引擎 + ML 可視化配置，無原生 AI 引擎 |
|
||||
| 無 AI | PDC / Indra | 傳統規則驅動，無 AI/ML |
|
||||
|| 梯隊 | 廠商 | AI 能力 |
|
||||
|------|------|---------|---------|
|
||||
| 第一梯隊 | ADB SAFEGATE、SITA | ADB SAFEGATE 原生 AI 引擎 + ML；SITA Total Optimizer AI（2024年發布），支持機場整體運營優化 |
|
||||
| 第二梯隊 | Amadeus、AirportLabs | Amadeus 有限 AI（輔助決策）；AirportLabs 規則引擎 + ML 可視化配置 |
|
||||
| 第三梯隊 | Collins、RESA | Collins 動態資源分配算法（無原生 ML）；RESA 無 AI，純規則引擎 |
|
||||
| 無 AI | PDC、Indra、ISO Software | 傳統規則驅動，無 AI/ML |
|
||||
|
||||
### 實時性能
|
||||
|
||||
| 廠商 | 響應時間承諾 | 架構依據 |
|
||||
|| 廠商 | 響應時間承諾 | 架構依據 |
|
||||
|------|-----------|---------|
|
||||
| PDC | **1-2 秒** | 事件驅動 + Oracle |
|
||||
| Amadeus | 實時推送（< 5s）| 私有雲基礎設施 |
|
||||
| ADB SAFEGATE | 實時（規格未公開）| 模塊化 + 內存計算 |
|
||||
| AirportLabs | 實時流（ActiveMQ）| 事件驅動 + OpenShift |
|
||||
| Indra | 實時（規格未公開）| J2EE 企業架構 |
|
||||
| SITA | 實時（規格未公開）| SITA 私有全球骨幹網絡 |
|
||||
| Collins | 實時（毫秒級 FIDS 同步）| AirVue FIDS 原生集成 |
|
||||
| RESA | 實時（規格未公開）| 輕量級模塊化架構 |
|
||||
| ISO Software | 實時（規格未公開）| Oracle 企業級架構 |
|
||||
|
||||
### 生態鎖定程度
|
||||
|
||||
| 級別 | 廠商 | 說明 |
|
||||
|| 級別 | 廠商 | 說明 |
|
||||
|------|------|------|
|
||||
| 高鎖定 | Amadeus | 換出成本極高（Altéa 綁定）|
|
||||
| 中高鎖定 | ADB SAFEGATE | Cortex 套件深度集成 |
|
||||
| 中鎖定 | AirportLabs | 全套生態但 API 開放 |
|
||||
| 低鎖定 | PDC | Oracle + 標準 WS，易替換 |
|
||||
| 低鎖定 | Indra | J2EE 標準，可部分替換 |
|
||||
| **極高鎖定** | SITA | SITA 地面電信網絡、SITA@Airports 生態全綁定，換出成本極高 |
|
||||
| **高鎖定** | Amadeus | 換出成本極高（Altéa PSS 深度綁定）|
|
||||
| **中高鎖定** | ADB SAFEGATE | Cortex 套件深度集成，空側數據獨有 |
|
||||
| **中鎖定** | AirportLabs、Collins | 全套生態但 API 開放；AirVue FIDS 集成 |
|
||||
| **中低鎖定** | RESA、ISO Software | 模塊化但生態相對封閉 |
|
||||
| **低鎖定** | PDC、Indra | Oracle + 標準 WS / J2EE 標準，易替換 |
|
||||
|
||||
## 相關鏈接
|
||||
|
||||
- [[aodb-core]] — AODB 核心概念與 A-CDM 架構
|
||||
- [[a-cdm]] — A-CDM 與 AODB 的協同關係
|
||||
- [[comparisons/airport-operations-systems]] — 運營系統供應商全景對比
|
||||
|
||||
---
|
||||
|
||||
### 6. SITA — Operations Manager
|
||||
|
||||
**定位：** 全球航空 IT 巨頭，超大型樞紐首選，150+ 機場部署
|
||||
|
||||
#### 核心技術特性
|
||||
|
||||
|| 特性 | 說明 |
|
||||
|------|------|
|
||||
| **"最可信信源"引擎** | 區別於傳統 AODB 僅記錄數據，SITA 內置複雜業務規則引擎，能從多個衝突數據源中自動評估並選擇最準確的信息 |
|
||||
| **Total Optimizer AI 平台** | 2024 年新推出 AI 驅動平台，將 AODB 數據與機器學習結合，實現機場整體運營（準點率、容量、環保指標）的動態優先級優化 |
|
||||
| **主動預警機制** | 在航班延誤或資源衝突發生前提供預測性告警，支持 IROPS（不正常航班）快速恢復 |
|
||||
| **全球 24/7 SGS 支持體系** | SITA Global Services 提供全天候多語言支持 |
|
||||
|
||||
#### 優勢與劣勢
|
||||
|
||||
|| 維度 | 評價 |
|
||||
|------|------|------|
|
||||
| **優勢** | 數據治理能力極強；全球覆蓋最廣；適合超大型多跑道樞紐；与 SITA Airports 生態無縫整合 |
|
||||
| **劣勢** | 實施週期長；系統架構較重；定制化開發成本高昂；數據治理強但界面相對傳統 |
|
||||
|
||||
#### 目標場景
|
||||
|
||||
- 年旅客量 > 4000 萬的超大型國際樞紐
|
||||
- 多機場集團統一管理（跨國家/地區）
|
||||
- 對數據治理和 IROPS 恢復能力有剛性需求
|
||||
- 已有 SITA 地面電信網絡和機場設施的機場
|
||||
|
||||
---
|
||||
|
||||
### 7. Collins Aerospace — AirDB (AirPlan)
|
||||
|
||||
**定位：** 部署靈活性極高，美洲/歐洲主流，軍民融合背景
|
||||
|
||||
#### 核心技術特性
|
||||
|
||||
|| 特性 | 說明 |
|
||||
|------|------|
|
||||
| **混合部署模式** | 支持本地數據中心、私有雲或公有雲部署，滿足不同機場的數據合規要求 |
|
||||
| **AirVue FIDS 原生協同** | 與市場領先的 AirVue 航顯系統深度耦合，旅客獲取的信息與後台數據庫毫秒級同步 |
|
||||
| **動態資源分配算法** | 支持社交距離邏輯（如間隔分配登機口和行李轉盤），後疫情時代新增 |
|
||||
| **軍民融合背景** | Collins（Raytheon Technologies 子公司）繼承 ARINC 軍航技術積累，系統穩定性標準極高 |
|
||||
|
||||
#### 優勢與劣勢
|
||||
|
||||
|| 維度 | 評價 |
|
||||
|------|------|------|
|
||||
| **優勢** | 部署靈活性最高；與 FIDS 和網絡基礎設施集成度好；界面現代化；軍工級可靠性 |
|
||||
| **劣勢** | 亞太地區本地化支持團隊相對較小；在歐洲以外非 Amadeus 生態環境中集成成本高 |
|
||||
|
||||
#### 目標場景
|
||||
|
||||
- 美洲、歐洲大型機場
|
||||
- 需要本地數據合規（如數據不出境的政府機場）
|
||||
- 已有 Collins Aerospace 其他系統（雷達、通信）的機場
|
||||
- 需要與現有 FIDS 無縫集成的機場
|
||||
|
||||
---
|
||||
|
||||
### 8. RESA — INFOPAX AODB
|
||||
|
||||
**定位：** 中小型/區域性機場性價比方案，歐洲/非洲廣泛應用，移動端支持出色
|
||||
|
||||
#### 核心技術特性
|
||||
|
||||
|| 特性 | 說明 |
|
||||
|------|------|
|
||||
| **模塊化輕量級設計** | 包含基礎數據、季節計劃、實時動態三個核心模塊，易于實施 |
|
||||
| **INFOPAX EXPRESS** | 專用移動端訪問應用，支持高級權限管理，為臨時用戶開放特定數據視圖 |
|
||||
| **快速部署** | 中小型機場可在數週內完成上線 |
|
||||
| **計費模塊整合** | 原生支持機場資源使用計費結算 |
|
||||
|
||||
#### 優勢與劣勢
|
||||
|
||||
|| 維度 | 評價 |
|
||||
|------|------|------|
|
||||
| **優勢** | 實施快；成本效益高；移動端支持好；歐洲/非洲有穩定客戶群 |
|
||||
| **劣勢** | 應對超大型機場海量並發數據的能力未經驗證；AI/ML 能力較弱 |
|
||||
|
||||
#### 目標場景
|
||||
|
||||
- 年旅客量 < 1500 萬的中小型/區域性機場
|
||||
- 歐洲、非洲機場（本地支持網絡覆蓋好）
|
||||
- 預算敏感，追求快速上線和低 TCO
|
||||
- 需要移動端為臨時員工/承包商開放數據訪問
|
||||
|
||||
---
|
||||
|
||||
### 9. ISO Software — SKYport AODB
|
||||
|
||||
**定位：** 歐美中等規模機場，Oracle 技術棧現代化方案，德系品質
|
||||
|
||||
#### 核心技術特性
|
||||
|
||||
|| 特性 | 說明 |
|
||||
|------|------|
|
||||
| **雲原生架構** | 基於現代雲架構設計，支持容器化和微服務部署 |
|
||||
| **Oracle 數據庫底層** | 企業級 Oracle 保障事務一致性和高可用性 |
|
||||
| **現代化 UI** | HTML5/Vue 響應式界面，用戶體驗對標互聯網產品 |
|
||||
| **德系品質** | ISO Software Systeme（德國）出品，工程標準嚴謹，文檔完善 |
|
||||
|
||||
#### 優勢與劣勢
|
||||
|
||||
|| 維度 | 評價 |
|
||||
|------|------|------|
|
||||
| **優勢** | Oracle 技術棧成熟穩定；德系售後服務嚴謹；中等規模機場功能完整 |
|
||||
| **劣勢** | 與大型國際樞紐的定制化需求有差距；AI 能力弱 |
|
||||
|
||||
#### 目標場景
|
||||
|
||||
- 年旅客量 500 萬 - 3000 萬的中等規模機場
|
||||
- 歐洲機場（德語區、西班牙語區覆蓋好）
|
||||
- 偏好 Oracle 技術棧且需要現代化界面的機場
|
||||
- 需要標準化實施流程以控制風險的機場
|
||||
|
||||
---
|
||||
|
||||
## 報價與商業模式
|
||||
|
||||
### 傳統許可費模式（On-Premise License）
|
||||
|
||||
適用於對數據絕對控制有要求的大型樞紐機場：
|
||||
|
||||
|| 費用類型 | 區間 |
|
||||
|---------|------|
|
||||
| 初期軟件許可與實施費 | 50 萬 - 150 萬美元 |
|
||||
| 硬件與中間件成本 | 10 萬 - 30 萬美元（雙機熱備、Oracle 授權等）|
|
||||
| 年度維保費（SLA）| 初期軟件許可費的 18% - 22% |
|
||||
|
||||
### SaaS 雲訂閱模式（Cloud Subscription）
|
||||
|
||||
適用於中小型機場或尋求降低初期 CapEx 的機場：
|
||||
|
||||
|| 費用類型 | 區間 |
|
||||
|---------|------|
|
||||
| 實施與接入費 | 10 萬 - 30 萬美元 |
|
||||
| 年度訂閱費 | 15 萬 - 50 萬美元/年（按年旅客吞吐量或航班架次階梯計費）|
|
||||
|
||||
> 優勢：包含雲基礎設施成本、自動升級和 24/7 監控，總體擁有成本（TCO）更平滑。
|
||||
|
||||
---
|
||||
|
||||
## 選型量化評估矩陣
|
||||
|
||||
進行 AODB 選型時，建議機場採用以下權重矩陣進行打分評估（總分 100 分）：
|
||||
|
||||
|| 評估維度 | 權重 | 評估指標說明 | 領先廠商示例 |
|
||||
|----------|------|--------------|--------------|
|
||||
| **數據處理與準確性** | 25% | 多源數據融合規則引擎、「最可信信源」機制、併發處理能力 | SITA, Amadeus |
|
||||
| **系統架構與可靠性** | 20% | 高可用架構（99.99%）、災備切換時間（RTO/RPO）、雲原生支持 | Collins, ISO Software |
|
||||
| **標準兼容與集成性** | 20% | 原生支持 AIDX、SSIM、A-CDM 里程碑，開放 API 豐富度 | Indra, SITA |
|
||||
| **智能化與預測能力** | 15% | AI 資源優化、旅客/行李流量預測、What-if 場景模擬 | Amadeus, ADB Safegate |
|
||||
| **本地化服務與合規** | 10% | 本地技術支持團隊規模、符合本國民航局數據安全與國產化要求 | 國產廠商（萬達信息、民航信科）|
|
||||
| **總體擁有成本（TCO）** | 10% | 5年期軟硬件投資、實施費、維保費及定製開發費率 | RESA, 國產廠商 |
|
||||
|
||||
### 不同規模機場選型建議
|
||||
|
||||
| 機場規模 | 年旅客量 | 推薦方案 |
|
||||
|---------|---------|---------|
|
||||
| 超大型國際樞紐 | > 4000萬 | SITA Operations Manager 或具備極強研發實力的自主研發方案（如首都機場模式）|
|
||||
| 中大型區域樞紐 | 1000萬 - 4000萬 | Amadeus AODB、Collins AirDB 或國產頭部廠商（萬達信息、民航信科）|
|
||||
| 中小型及支線機場 | < 1000萬 | RESA INFOPAX、ISO SKYport 或基於 SaaS 的輕量級雲方案 |
|
||||
|
||||
---
|
||||
|
||||
## 相關鏈接
|
||||
|
||||
- [[aodb-core]] — AODB 核心概念與 A-CDM 架構
|
||||
- [[a-cdm]] — A-CDM 與 AODB 的協同關係
|
||||
- [[aodb-china]] — 中國市場現狀與國產化替代
|
||||
- [[comparisons/airport-operations-systems]] — 運營系統供應商全景對比
|
||||
|
||||
@@ -4,7 +4,7 @@ created: 2026-04-08
|
||||
updated: 2026-04-08
|
||||
type: concept
|
||||
tags: [flight-data, api, integration, system]
|
||||
sources: [raw/articles/iata-ssim-2026.md, raw/articles/schedule-data-exchange-2025.md]
|
||||
sources: [raw/articles/iata-ssim-2026.md, raw/articles/schedule-data-exchange-2025.md, raw/articles/aidx-xml-imp-guide-v22.1.md]
|
||||
---
|
||||
|
||||
# 航班数据交换标准
|
||||
@@ -25,14 +25,213 @@ sources: [raw/articles/iata-ssim-2026.md, raw/articles/schedule-data-exchange-20
|
||||
|
||||
## SSIM — Standard Schedules Information Manual
|
||||
|
||||
| 项目 | 信息 |
|
||||
|| 项目 | 信息 |
|
||||
|------|------|
|
||||
| 最新版本 | **第 36 版（2026）** |
|
||||
| 发布频率 | 年度 |
|
||||
| 适用范围 | 全球所有 IATA 成员航司及合作伙伴 |
|
||||
| 核心内容 | 航班计划报文格式、最小衔接时间（MCT）、机场协调程序 |
|
||||
|| 最新版本 | **第 36 版（2026）** |
|
||||
|| 发布频率 | 年度 |
|
||||
|| 适用范围 | 全球所有 IATA 成员航司及合作伙伴 |
|
||||
|| 核心内容 | 航班计划报文格式、最小衔接时间（MCT）、机场协调程序 |
|
||||
|
||||
SSIM 是航班计划数据交换的行业基准，采用固定长度报文格式（flat file），支持批量数据交换。
|
||||
SSIM 是航班计划数据交换的行业基准，采用**固定长度报文格式（flat file）**，支持批量数据交换。
|
||||
|
||||
### SSIM 信息数据行字段定义（Chapter 6/7 SCR 报文）
|
||||
|
||||
每行数据包含 14 个固定字段，固定位置，不可变长：
|
||||
|
||||
```
|
||||
NXZ101 XZ102 20JUN20AUG 0234500 189738 AGPAGP1000 1055BCNBCN JP
|
||||
^1 ^3 ^4 ^6 ^7 ^8 ^9 ^10 ^11
|
||||
```
|
||||
|
||||
| 字段 | 名称 | 内容 | 示例 |
|
||||
|------|------|------|------|
|
||||
| 1 | Action Code | 操作代码（N=新请求/C=变更/D=删除） | N |
|
||||
| 2 | Arrival Flight Designator | 到达航班（航司代码+航班号，最低3位数字） | XZ101 |
|
||||
| 3 | Departure Flight Designator | 出发航班（航司代码+航班号） | XZ102 |
|
||||
| 4 | Period Start | 有效期开始 | 20JUN |
|
||||
| 5 | Period End | 有效期结束 | 20AUG |
|
||||
| 6 | Weekdays of Operation | 周运营日（1=周一～7=周日，1-7数字串） | 0234500 |
|
||||
| 7 | Number of Seats | 座位数（3位数字） | 189 |
|
||||
| 8 | Aircraft Subtype | IATA 机型代码（3位） | 738 |
|
||||
| 9 | Origin Airport | 出发/到达机场代码（同一行往返） | AGP |
|
||||
| 10 | Arrival Time (UTC) | 到达时间（UTC，过夜加1后缀） | 1000 |
|
||||
| 11 | Departure Time (UTC) | 出发时间（UTC） | 1055 |
|
||||
| 12 | Next/Destination Airport | 目的地/下一机场代码 | BCN |
|
||||
| 13 | Arrival Service Type | 到达服务类型（J=定期客机/P=调机） | J |
|
||||
| 14 | Departure Service Type | 出发服务类型 | P |
|
||||
|
||||
### SSIM SCR 报文示例
|
||||
|
||||
**标准 turnaround 格式（新请求）：**
|
||||
|
||||
```
|
||||
SCR /schedule@carrier.com
|
||||
S21 01APR DUB
|
||||
NXZ101 XZ102 20JUN20AUG 0234500 189738 AGP1000 1055BCN JP
|
||||
SI NEW SERIES
|
||||
GI BEST REGARDS
|
||||
```
|
||||
|
||||
含义：S21航季，4月1日发给 DUB 机场，XZ 航司新 slot 请求，XZ101 进港/XZ102 出港，6月20日—8月20日每周二三四五执飞，189座，B738 机型，AGP 进港 1000z，BCN 出港 1055z。
|
||||
|
||||
### 协调员响应代码
|
||||
|
||||
| 代码 | 含义 |
|
||||
|------|------|
|
||||
| K | 确认（Confirmed） |
|
||||
| X | 变更（Change required） |
|
||||
| U | 拒绝（Refused） |
|
||||
| O | 建议（Offer alternative） |
|
||||
|
||||
---
|
||||
|
||||
## AIDX — Aviation Information Data Exchange
|
||||
|
||||
|| 项目 | 信息 |
|
||||
|------|------|
|
||||
|| 类型 | XML 消息标准（ISO/IEC 19757-3） |
|
||||
|| 版本 | v22.1（每年 2 次发布） |
|
||||
|| 覆盖 | 约 **180 个**数据元素，涵盖航班运营全生命周期 |
|
||||
|| 开发者 | IATA Delivery on Orders Working Group（80+ 航司/机场/厂商参与） |
|
||||
|| 适用范围 | 航司↔机场↔第三方，运营动态实时交换 |
|
||||
|
||||
AIDX 由 IATA、ATA、ACI 共同认可，是 SESAR A-CDM、ACI ACRIS A-CDM Web Services、ICAO A-CDM（亚太区）信息交换的标准格式。
|
||||
|
||||
### 三种核心消息类型
|
||||
|
||||
| 消息类型 | 用途 | 方向 |
|
||||
|----------|------|------|
|
||||
| `IATA_AIDX_FlightLegNotifRQ` | 无请求方主动通知（推送） | 发送方 → 接收方 |
|
||||
| `IATA_AIDX_FlightLegRQ` | 查询请求 | 发送方 → 接收方 |
|
||||
| `IATA_AIDX_FlightLegRS` | 响应/确认 | 接收方 → 发送方 |
|
||||
|
||||
### 集成模式
|
||||
|
||||
**模式1：无请求方主动通知（推送）**
|
||||
```
|
||||
Sender → IATA_AIDX_FlightLegNotifRQ → Receiver
|
||||
Sender ← IATA_AIDX_FlightLegRS ← Receiver（可选确认）
|
||||
```
|
||||
|
||||
**模式2：查询 + 同步响应**
|
||||
```
|
||||
Sender → IATA_AIDX_FlightLegRQ → Receiver
|
||||
Sender ← IATA_AIDX_FlightLegRS ← Receiver
|
||||
```
|
||||
|
||||
### XML 数据结构（IATA_AIDX_FlightLegNotifRQ）
|
||||
|
||||
```xml
|
||||
<IATA_AIDX_FlightLegNotifRQ Version="2" TimeStamp="2017-01-16T17:27:49Z"
|
||||
TransactionIdentifier="1484587669244" Target="Production" PrimaryLangID="en-us">
|
||||
<Originator CompanyShortName="UAL" TravelSector="A" Code="UA" CodeContext="3"/>
|
||||
<DeliveringSystem CompanyShortName="DEN" TravelSector="C" Code="DEN" CodeContext="3"/>
|
||||
<FlightLeg>
|
||||
<LegIdentifier>
|
||||
<Airline CodeContext="3">UA</Airline>
|
||||
<FlightNumber>1815</FlightNumber>
|
||||
<DepartureAirport CodeContext="3">LAX</DepartureAirport>
|
||||
<ArrivalAirport CodeContext="3">IAH</ArrivalAirport>
|
||||
<OriginDate>2017-01-16</OriginDate>
|
||||
<RepeatNumber CurrentInd="true">1</RepeatNumber>
|
||||
</LegIdentifier>
|
||||
<LegData InternationalStatus="Domestic">
|
||||
<ServiceType>J</ServiceType>
|
||||
<OperationalStatus>OP</OperationalStatus>
|
||||
<CabinClass Class="7">
|
||||
<PaxCount Qualifier="70A" Usage="Actual">166</PaxCount>
|
||||
<SeatCapacity>166</SeatCapacity>
|
||||
</CabinClass>
|
||||
<AircraftInfo>
|
||||
<AircraftType>737</AircraftType>
|
||||
<AircraftSubType>73Q</AircraftSubType>
|
||||
<Registration>N77518</Registration>
|
||||
<TailNumber>518</TailNumber>
|
||||
</AircraftInfo>
|
||||
<AirportResources Usage="Actual">
|
||||
<Resource DepartureOrArrival="Departure">
|
||||
<PassengerGate>70A</PassengerGate>
|
||||
</Resource>
|
||||
<Resource DepartureOrArrival="Arrival">
|
||||
<PassengerGate>E8</PassengerGate>
|
||||
<BaggageClaimUnit>C5</BaggageClaimUnit>
|
||||
</Resource>
|
||||
</AirportResources>
|
||||
<OperationTime OperationQualifier="OFB" CodeContext="9750" TimeType="ACT">2017-01-16T14:28:00Z</OperationTime>
|
||||
<OperationTime OperationQualifier="TKO" CodeContext="9750" TimeType="ACT">2017-01-16T14:41:00Z</OperationTime>
|
||||
<OperationTime OperationQualifier="TDN" CodeContext="9750" TimeType="ACT">2017-01-16T17:27:00Z</OperationTime>
|
||||
<OperationTime OperationQualifier="ONB" CodeContext="9750" TimeType="EST">2017-01-16T17:33:00Z</OperationTime>
|
||||
</LegData>
|
||||
</FlightLeg>
|
||||
</IATA_AIDX_FlightLegNotifRQ>
|
||||
```
|
||||
|
||||
### 航班唯一标识（UFI）规则
|
||||
|
||||
`LegIdentifier` 构成唯一标识，必须严格遵循以下规则：
|
||||
|
||||
| 字段 | 规则 |
|
||||
|------|------|
|
||||
| `OriginDate` | **静态** — 即使航班改期仍不变，以首个航段的 UTC 计划出发日期为准 |
|
||||
| `ArrivalAirport` | **静态** — 航班备降后原字段不变，新增 `PlannedArrivalAptHistory` 记录 |
|
||||
| `OperationalSuffix` | **静态** — 如需变更须取消原航班并创建新航班 |
|
||||
| `RepeatNumber` | 同一计划日期的重复起飞次数，1=首次尝试 |
|
||||
|
||||
### 运营状态代码
|
||||
|
||||
| 代码 | 含义 | 使用场景 |
|
||||
|------|------|----------|
|
||||
| OP | Operational Flight | 正常执行 |
|
||||
| NOP | Non-Operational | 计划但不执行 |
|
||||
| DV | Diverted | 备降 |
|
||||
| DX | Cancelled | 取消 |
|
||||
| RT | Re-route | 改航路 |
|
||||
| GRT | Ground Return | 返回始发地（未起飞） |
|
||||
| SQ | Re-instate | 恢复已取消/备降航班 |
|
||||
|
||||
### A-CDM 里程碑时间代码（Codeset 9750）
|
||||
|
||||
| 代码 | 含义 | 阶段 |
|
||||
|------|------|------|
|
||||
| SCH | Scheduled | 计划 |
|
||||
| INI | Flight Plan Activated | 起飞前 |
|
||||
| OFB | Off Blocks（撤轮档） | 推出 |
|
||||
| TKO | Takeoff（起飞） | 离地 |
|
||||
| FIN | Final Approach | 最后进近 |
|
||||
| TDN | Touch Down（落地） | 接地 |
|
||||
| LAN | Landed | 落地 |
|
||||
| ONB | On Blocks（靠桥） | 停靠 |
|
||||
|
||||
### 时间类型
|
||||
|
||||
| 类型 | 含义 |
|
||||
|------|------|
|
||||
| SCT | Scheduled Time（计划时间） |
|
||||
| EST | Estimated Time（预计时间） |
|
||||
| ACT | Actual Time（实际时间） |
|
||||
|
||||
> **注意**：所有时间必须为 UTC，以 `xsd:DateTime` 格式传输，后缀 Z。元素缺失=无更新；`xsi:nil="true"`=显式清空；空元素（如 `<PassengerGate/>`）可能引发校验错误。
|
||||
|
||||
### 技术规范
|
||||
|
||||
| 项目 | 要求 |
|
||||
|------|------|
|
||||
| 字符编码 | UTF-8 |
|
||||
| 时间格式 | xsd:DateTime，UTC，末尾 Z |
|
||||
| 重复元素 | 使用 `RepeatIndex` 属性标记序号 |
|
||||
| Nil 值 | 使用 `xsi:nil="true"`，禁止空白元素 |
|
||||
| 传输机制 | 未规定（可基于 HTTPS REST、SFTP、WebService 等） |
|
||||
|
||||
### SSIM 与 AIDX 对比
|
||||
|
||||
| 维度 | SSIM Flat File | AIDX XML |
|
||||
|------|----------------|----------|
|
||||
| 数据类型 | 航班计划（季节性/批量） | 航班运营动态（实时） |
|
||||
| 更新频率 | 批量定时交换（航季） | 实时推送/查询 |
|
||||
| 格式 | 固定长度字段（ mainframe 遗留格式） | 树形 XML 结构 |
|
||||
| 复杂度 | 低（字段固定），但解析困难 | 高（180+ 元素），但扩展性强 |
|
||||
| 典型场景 | slot 协调、季节计划 | A-CDM、地面保障、旅客信息 |
|
||||
| IATA 策略 | 逐步向 XML/IATA-OS 迁移 | 主推方向，已广泛部署 |
|
||||
|
||||
## IATA Schedule Data Exchange Program（2025 新动态）
|
||||
|
||||
|
||||
@@ -0,0 +1,569 @@
|
||||
---
|
||||
title: 自动化钩子与事件驱动架构
|
||||
created: 2026-04-13
|
||||
updated: 2026-04-13
|
||||
type: concept
|
||||
tags: [knowledge-management, automation, event-hooks, operations]
|
||||
confidence: 0.9
|
||||
sources_count: 5
|
||||
last_confirmed: 2026-04-13
|
||||
status: active
|
||||
relationships:
|
||||
- target: SCHEMA.md
|
||||
type: implements
|
||||
detail: "v2 自动化机制"
|
||||
confidence: 0.95
|
||||
- target: knowledge-management/memory-lifecycle.md
|
||||
type: triggers
|
||||
detail: "置信度衰减和整合"
|
||||
confidence: 0.85
|
||||
- target: knowledge-management/knowledge-graph.md
|
||||
type: updates
|
||||
detail: "自动更新实体关系"
|
||||
confidence: 0.9
|
||||
- target: hybrid-search.md
|
||||
type: maintains
|
||||
detail: "嵌入和索引更新"
|
||||
confidence: 0.9
|
||||
---
|
||||
|
||||
# ⚡ 自动化钩子与事件驱动架构
|
||||
|
||||
基于 **LLM Wiki v2** 的事件驱动维护系统，为机场智能化工程 wiki 提供自动化知识管理。通过事件钩子响应 wiki 操作，减少手动维护负担。
|
||||
|
||||
> **核心目标**：将手动知识维护转变为事件驱动的自动化流程，确保 wiki 内容的新鲜度、一致性和质量。
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ 事件架构总览
|
||||
|
||||
### 事件类型与触发器
|
||||
| 事件类型 | 触发器 | 触发条件 | 响应延迟 |
|
||||
|----------|--------|----------|----------|
|
||||
| **来源新增** | 文件系统监视 | `raw/` 中新增 `.md` 文件 | 即时 (15s) |
|
||||
| **页面创建** | `write_file()` 调用 | `concepts/`, `entities/` 等目录 | 即时 (5s) |
|
||||
| **页面更新** | `patch()` 调用 | 现有页面内容修改 | 即时 (5s) |
|
||||
| **页面归档** | 文件移动至 `_archive/` | 手动操作或自动 supersede | 即时 (5s) |
|
||||
| **用户查询** | `web_search()` 或 `search_files()` | 搜索操作 | 异步 (<60s) |
|
||||
| **定时任务** | cron 调度器 | 每日/每周/每月 | 指定时间 |
|
||||
|
||||
### 自动化钩子执行顺序
|
||||
```
|
||||
新来源 → on_new_source() → 来源解析 → 实体提取 → 页面创建/更新
|
||||
↓
|
||||
页面创建/更新 → on_page_change() → 关系更新 → 嵌入更新 → 索引更新
|
||||
↓
|
||||
定时任务 → cron_daily/weekly/monthly() → 质量检查 → 置信度衰减
|
||||
↓
|
||||
用户查询 → on_user_query() → 结果记录 → 潜在答案生成 → 反馈学习
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔧 主要钩子实现
|
||||
|
||||
### 1️⃣ `on_new_source()` - 新来源自动摄入
|
||||
```python
|
||||
def on_new_source(source_path: str):
|
||||
"""
|
||||
处理 raw/ 目录中的新来源文件
|
||||
1. 解析来源内容
|
||||
2. 提取实体和事实
|
||||
3. 创建/更新 wiki 页面
|
||||
4. 更新相关索引
|
||||
"""
|
||||
|
||||
# 1. 读取并解析来源
|
||||
content = read_file(source_path)
|
||||
metadata = extract_metadata(content) # 作者、日期、类型等
|
||||
|
||||
# 2. 提取实体和事实
|
||||
entities = extract_entities(content)
|
||||
facts = extract_facts(content, entities)
|
||||
|
||||
# 3. 更新现有页面或创建新页面
|
||||
for fact in facts:
|
||||
target_page = find_or_create_page(fact.topic)
|
||||
|
||||
# 检查是否有冲突
|
||||
conflict = check_conflict(target_page.content, fact.content)
|
||||
|
||||
if conflict:
|
||||
# 触发 supersession 流程
|
||||
supersede_page(target_page, fact.content, source_path)
|
||||
else:
|
||||
# 追加新事实
|
||||
update_page(target_page, fact.content, source_path)
|
||||
|
||||
# 4. 更新嵌入和图谱
|
||||
trigger_embedding_update()
|
||||
trigger_graph_reconciliation()
|
||||
|
||||
# 记录日志
|
||||
log_event("source_ingested", {
|
||||
"source": source_path,
|
||||
"entities_extracted": len(entities),
|
||||
"facts_added": len(facts),
|
||||
"timestamp": now()
|
||||
})
|
||||
```
|
||||
|
||||
**机场场景示例**：
|
||||
```
|
||||
事件: 新增 raw/articles/shenzhen-airport-smart-gating-2026.md
|
||||
响应:
|
||||
1. 解析文章：深圳机场2026年智能登机口升级
|
||||
2. 提取实体：深圳机场、SITA、生物识别走廊
|
||||
3. 更新页面：
|
||||
- concepts/smart-gating.md → 添加深圳案例
|
||||
- entities/shenzhen-airport.md → 更新智能登机口信息
|
||||
4. 更新关系：深圳机场 → uses → 生物识别走廊
|
||||
```
|
||||
|
||||
### 2️⃣ `on_page_change()` - 页面变更处理
|
||||
```python
|
||||
def on_page_change(page_path: str, change_type: str, old_content: Optional[str] = None):
|
||||
"""
|
||||
处理页面创建、更新、删除
|
||||
参数:
|
||||
- change_type: "create" | "update" | "delete" | "archive"
|
||||
- old_content: 仅 update 时提供
|
||||
"""
|
||||
|
||||
if change_type == "create":
|
||||
# 新页面：初始化嵌入和关系
|
||||
embedding = generate_embedding(page_path)
|
||||
save_embedding(page_path, embedding)
|
||||
|
||||
# 提取关系并更新图谱
|
||||
relationships = extract_relationships(page_path)
|
||||
update_knowledge_graph(page_path, relationships)
|
||||
|
||||
elif change_type == "update":
|
||||
# 页面更新：检查语义变化
|
||||
old_embedding = load_embedding(page_path)
|
||||
new_embedding = generate_embedding(page_path)
|
||||
|
||||
similarity = cosine_similarity(old_embedding, new_embedding)
|
||||
|
||||
if similarity < 0.7: # 语义显著变化
|
||||
# 重新计算相关页面的嵌入
|
||||
trigger_related_embeddings_update(page_path)
|
||||
|
||||
# 更新所有引用该页面的关系
|
||||
update_incoming_relationships(page_path)
|
||||
|
||||
elif change_type in ["delete", "archive"]:
|
||||
# 页面删除/归档：清理相关数据
|
||||
remove_embedding(page_path)
|
||||
remove_from_knowledge_graph(page_path)
|
||||
|
||||
# 更新引用（设置 superseded_by 或删除链接）
|
||||
update_references_to_page(page_path, change_type)
|
||||
|
||||
# 更新搜索索引
|
||||
update_search_index(page_path, change_type)
|
||||
|
||||
log_event("page_changed", {
|
||||
"page": page_path,
|
||||
"type": change_type,
|
||||
"semantic_change": similarity if change_type == "update" else None,
|
||||
"timestamp": now()
|
||||
})
|
||||
```
|
||||
|
||||
### 3️⃣ `cron_weekly()` - 每周维护任务
|
||||
```python
|
||||
def cron_weekly():
|
||||
"""
|
||||
每周日自动执行的维护任务
|
||||
1. 完整性检查 (lint)
|
||||
2. 置信度衰减和更新
|
||||
3. 嵌入重新生成
|
||||
4. 性能分析
|
||||
"""
|
||||
|
||||
print("=== 每周维护任务开始 ===")
|
||||
start_time = now()
|
||||
|
||||
# 1. 运行完整性检查
|
||||
lint_report = run_lint_check()
|
||||
|
||||
# 自动修复可修复的问题
|
||||
auto_fixed = lint_report.auto_fix()
|
||||
|
||||
# 记录需要手动干预的问题
|
||||
manual_tasks = lint_report.get_manual_tasks()
|
||||
|
||||
# 2. 置信度衰减
|
||||
decayed_pages = decay_confidence_scores()
|
||||
|
||||
# 3. 嵌入重新生成（全量）
|
||||
pages_updated = regenerate_all_embeddings()
|
||||
|
||||
# 4. 搜索索引重建
|
||||
rebuild_search_index()
|
||||
|
||||
# 5. 性能分析
|
||||
performance_report = analyze_search_performance()
|
||||
|
||||
# 6. 生成维护报告
|
||||
report = generate_maintenance_report({
|
||||
"duration_seconds": (now() - start_time).total_seconds(),
|
||||
"lint_fixed": auto_fixed,
|
||||
"lint_manual": len(manual_tasks),
|
||||
"pages_decayed": len(decayed_pages),
|
||||
"embeddings_regenerated": pages_updated,
|
||||
"search_metrics": performance_report.metrics,
|
||||
"timestamp": now()
|
||||
})
|
||||
|
||||
# 保存报告
|
||||
save_report(report, "weekly-maintenance")
|
||||
|
||||
# 如有需要手动干预的问题，发送通知
|
||||
if manual_tasks:
|
||||
notify_maintainer("手动维护任务待处理", manual_tasks)
|
||||
|
||||
print(f"=== 每周维护任务完成，耗时 {report.duration_seconds}s ===")
|
||||
|
||||
return report
|
||||
```
|
||||
|
||||
### 4️⃣ `on_user_query()` - 查询响应与学习
|
||||
```python
|
||||
def on_user_query(query: str, results: List[str], user_feedback: Optional[Dict] = None):
|
||||
"""
|
||||
处理用户搜索查询
|
||||
1. 记录查询模式
|
||||
2. 潜在答案生成
|
||||
3. 质量评估和反馈学习
|
||||
"""
|
||||
|
||||
# 1. 查询分类和记录
|
||||
query_type = classify_query(query)
|
||||
|
||||
log_search_event({
|
||||
"query": query,
|
||||
"type": query_type,
|
||||
"results_count": len(results),
|
||||
"user_id": get_user_id(), # 匿名或会话ID
|
||||
"timestamp": now()
|
||||
})
|
||||
|
||||
# 2. 检查是否需要生成新答案
|
||||
if should_generate_answer(query, results):
|
||||
answer = generate_potential_answer(query, results)
|
||||
|
||||
# 评估答案质量
|
||||
quality_score = evaluate_answer_quality(answer, query, results)
|
||||
|
||||
if quality_score > 0.8: # 高质量答案
|
||||
# 自动创建/更新查询页面
|
||||
create_query_page(query, answer, quality_score)
|
||||
|
||||
log_event("answer_generated", {
|
||||
"query": query,
|
||||
"answer_page": f"queries/{slugify(query)}.md",
|
||||
"quality_score": quality_score,
|
||||
"timestamp": now()
|
||||
})
|
||||
|
||||
# 3. 处理用户反馈（如有）
|
||||
if user_feedback:
|
||||
process_user_feedback(query, results, user_feedback)
|
||||
|
||||
# 更新搜索排名权重
|
||||
update_search_weights(query_type, user_feedback)
|
||||
|
||||
# 4. 查询模式分析
|
||||
analyze_query_patterns(query, results)
|
||||
|
||||
return {
|
||||
"logged": True,
|
||||
"query_type": query_type,
|
||||
"potential_answer_generated": should_generate_answer(query, results),
|
||||
"feedback_processed": bool(user_feedback)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ⏰ 定时任务调度
|
||||
|
||||
### 每日任务 (`cron_daily`)
|
||||
```python
|
||||
SCHEDULE = {
|
||||
"daily": {
|
||||
"time": "02:30", # 凌晨执行，避免影响使用
|
||||
"tasks": [
|
||||
"verify_recent_changes", # 检查24小时内变更
|
||||
"update_recommendations", # 更新推荐系统
|
||||
"clean_temp_files", # 清理临时文件
|
||||
"backup_incremental" # 增量备份
|
||||
]
|
||||
}
|
||||
}
|
||||
|
||||
def cron_daily():
|
||||
"""每日凌晨执行的任务"""
|
||||
tasks = [
|
||||
# 1. 验证最近变更
|
||||
verify_recent_changes(since=datetime.now() - timedelta(days=1)),
|
||||
|
||||
# 2. 更新个性化推荐
|
||||
update_recommendations(),
|
||||
|
||||
# 3. 清理临时文件
|
||||
clean_temp_files(max_age=timedelta(days=7)),
|
||||
|
||||
# 4. 增量备份
|
||||
backup_incremental(target="s3://wiki-backups/daily/")
|
||||
]
|
||||
|
||||
return execute_tasks(tasks, name="daily_maintenance")
|
||||
```
|
||||
|
||||
### 每周任务 (`cron_weekly`)
|
||||
```python
|
||||
def cron_weekly():
|
||||
"""每周日执行的全量维护"""
|
||||
return {
|
||||
"lint": run_lint_check(),
|
||||
"embeddings": regenerate_all_embeddings(),
|
||||
"confidence": decay_confidence_scores(),
|
||||
"index": rebuild_search_index(),
|
||||
"report": generate_weekly_report()
|
||||
}
|
||||
```
|
||||
|
||||
### 每月任务 (`cron_monthly`)
|
||||
```python
|
||||
def cron_monthly():
|
||||
"""每月1日执行的深度维护"""
|
||||
return {
|
||||
"archival": archive_stale_content(older_than=timedelta(days=180)),
|
||||
"model_evaluation": evaluate_embedding_models(),
|
||||
"capacity_planning": analyze_growth_trends(),
|
||||
"security_audit": run_security_checks(),
|
||||
"comprehensive_report": generate_monthly_report()
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 实施部署
|
||||
|
||||
### 阶段 1：基础钩子（当前）
|
||||
- ✅ `on_page_change()` 记录至日志
|
||||
- ✅ 新增来源手动触发处理
|
||||
- 🔄 定期 lint 检查（手动）
|
||||
|
||||
### 阶段 2：自动化管道（1-2周）
|
||||
- 🔄 文件系统监视：`raw/` 新增自动触发
|
||||
- 🔄 页面变更自动更新嵌入和关系
|
||||
- 🔄 每周自动维护脚本
|
||||
- 🔄 搜索结果记录与分析
|
||||
|
||||
### 阶段 3：高级自动化（1个月）
|
||||
- 🔄 智能答案生成（质量阈值 >0.8）
|
||||
- 🔄 自适应权重调整（基于用户反馈）
|
||||
- 🔄 异常检测和自动修复
|
||||
- 🔄 多环境部署（开发/测试/生产）
|
||||
|
||||
### 阶段 4：智能运维（未来）
|
||||
- 🔄 预测性维护（基于历史模式）
|
||||
- 🔄 A/B 测试搜索算法
|
||||
- 🔄 跨wiki知识同步
|
||||
- 🔄 故障自愈能力
|
||||
|
||||
---
|
||||
|
||||
## 🔧 技术实现细节
|
||||
|
||||
### 钩子注册机制
|
||||
```python
|
||||
class HookRegistry:
|
||||
"""事件钩子注册中心"""
|
||||
|
||||
def __init__(self):
|
||||
self.hooks = defaultdict(list)
|
||||
|
||||
def register(self, event_type: str, callback: Callable, priority: int = 0):
|
||||
"""注册钩子"""
|
||||
self.hooks[event_type].append({
|
||||
"callback": callback,
|
||||
"priority": priority
|
||||
})
|
||||
self.hooks[event_type].sort(key=lambda x: x["priority"])
|
||||
|
||||
def trigger(self, event_type: str, **kwargs):
|
||||
"""触发事件"""
|
||||
for hook in self.hooks.get(event_type, []):
|
||||
try:
|
||||
hook["callback"](**kwargs)
|
||||
except Exception as e:
|
||||
log_error(f"钩子执行失败: {event_type}", e)
|
||||
|
||||
# 全局钩子注册器
|
||||
hooks = HookRegistry()
|
||||
|
||||
# 注册示例
|
||||
hooks.register("page_created", on_page_change, priority=10)
|
||||
hooks.register("source_added", on_new_source, priority=5)
|
||||
```
|
||||
|
||||
### 文件系统监视
|
||||
```python
|
||||
import watchdog
|
||||
from watchdog.observers import Observer
|
||||
from watchdog.events import FileSystemEventHandler
|
||||
|
||||
class WikiFileHandler(FileSystemEventHandler):
|
||||
"""监视 raw/ 目录的变更"""
|
||||
|
||||
def on_created(self, event):
|
||||
if event.is_directory:
|
||||
return
|
||||
|
||||
path = event.src_path
|
||||
if path.startswith("/raw/") and path.endswith(".md"):
|
||||
# 触发来源处理钩子
|
||||
hooks.trigger("source_added", source_path=path)
|
||||
|
||||
def on_modified(self, event):
|
||||
if event.is_directory:
|
||||
return
|
||||
|
||||
path = event.src_path
|
||||
if not path.startswith("/raw/"):
|
||||
# 触发页面变更钩子
|
||||
hooks.trigger("page_changed", page_path=path, change_type="update")
|
||||
|
||||
# 启动监视器
|
||||
observer = Observer()
|
||||
observer.schedule(WikiFileHandler(), "/path/to/wiki", recursive=True)
|
||||
observer.start()
|
||||
```
|
||||
|
||||
### 定时任务调度器
|
||||
```python
|
||||
import schedule
|
||||
import time
|
||||
|
||||
def setup_scheduler():
|
||||
"""配置定时任务"""
|
||||
|
||||
# 每日凌晨任务
|
||||
schedule.every().day.at("02:30").do(cron_daily)
|
||||
|
||||
# 每周日任务
|
||||
schedule.every().sunday.at("03:00").do(cron_weekly)
|
||||
|
||||
# 每月1日任务
|
||||
schedule.every().month.at("04:00").do(cron_monthly)
|
||||
|
||||
print("定时任务已配置")
|
||||
|
||||
# 运行调度器（后台线程）
|
||||
import threading
|
||||
|
||||
def run_scheduler():
|
||||
while True:
|
||||
schedule.run_pending()
|
||||
time.sleep(60) # 每分钟检查一次
|
||||
|
||||
thread = threading.Thread(target=run_scheduler, daemon=True)
|
||||
thread.start()
|
||||
|
||||
# 应用启动时调用
|
||||
setup_scheduler()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 监控与告警
|
||||
|
||||
### 关键指标监控
|
||||
| 指标 | 阈值 | 告警级别 | 响应动作 |
|
||||
|------|------|----------|----------|
|
||||
| **处理失败率** | >5% | 警告 | 检查日志，重启服务 |
|
||||
| **嵌入更新延迟** | >24h | 警告 | 手动触发嵌入生成 |
|
||||
| **页面冲突数量** | >10 | 警告 | 审核冲突内容 |
|
||||
| **搜索查询失败** | >20% | 严重 | 检查搜索索引 |
|
||||
| **磁盘使用率** | >80% | 警告 | 清理或扩容 |
|
||||
|
||||
### 告警规则示例
|
||||
```yaml
|
||||
alerts:
|
||||
- name: "high_failure_rate"
|
||||
condition: "rate(failed_hooks_total[5m]) / rate(hooks_total[5m]) > 0.05"
|
||||
severity: "warning"
|
||||
description: "钩子执行失败率超过5%"
|
||||
actions: ["send_slack", "create_jira"]
|
||||
|
||||
- name: "search_degradation"
|
||||
condition: "search_response_time_p95 > 3000"
|
||||
severity: "critical"
|
||||
description: "搜索P95响应时间超过3秒"
|
||||
actions: ["page_oncall", "rollback_search"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔄 故障恢复流程
|
||||
|
||||
### 常见故障场景
|
||||
1. **钩子执行失败**
|
||||
```bash
|
||||
# 1. 查看错误日志
|
||||
tail -f /var/log/wiki/hooks.log
|
||||
|
||||
# 2. 暂时禁用问题钩子
|
||||
disable_hook("on_page_change", "problematic_callback")
|
||||
|
||||
# 3. 手动执行受影响操作
|
||||
run_manual_cleanup()
|
||||
```
|
||||
|
||||
2. **嵌入生成中断**
|
||||
```bash
|
||||
# 1. 检查嵌入存储完整性
|
||||
verify_embeddings_integrity()
|
||||
|
||||
# 2. 重新生成受影响页面
|
||||
regenerate_embeddings_for_pages(since="2026-04-10")
|
||||
|
||||
# 3. 重建搜索索引
|
||||
rebuild_search_index()
|
||||
```
|
||||
|
||||
3. **关系图谱不一致**
|
||||
```python
|
||||
# 自动一致性检查
|
||||
def reconcile_knowledge_graph():
|
||||
# 1. 检测孤立实体
|
||||
orphans = find_orphaned_entities()
|
||||
|
||||
# 2. 检查关系对称性
|
||||
mismatches = validate_relationship_symmetry()
|
||||
|
||||
# 3. 修复不一致
|
||||
fix_inconsistencies(orphans + mismatches)
|
||||
|
||||
return {"fixed": len(orphans + mismatches)}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📚 相关文档
|
||||
|
||||
- [[knowledge-management/memory-lifecycle.md]] - 置信度衰减和整合机制
|
||||
- [[knowledge-management/knowledge-graph.md]] - 实体关系自动提取
|
||||
- [[hybrid-search.md]] - 搜索结果记录和权重调整
|
||||
- [[wiki-backup-recovery.md]] - 备份和恢复流程
|
||||
- [[performance-monitoring.md]] - 系统性能监控
|
||||
|
||||
---
|
||||
|
||||
> **状态**: 当前实现基础钩子记录。下一步：部署文件系统监视和定时任务。最后更新：2026-04-13。
|
||||
@@ -0,0 +1,200 @@
|
||||
---
|
||||
title: 知识图谱
|
||||
created: 2026-04-13
|
||||
updated: 2026-04-13
|
||||
type: concept
|
||||
tags: [knowledge-management, knowledge-graph, entity, typed-relationship]
|
||||
sources: [raw/articles/llm-wiki-v2-rohitg00.md]
|
||||
---
|
||||
|
||||
# 知识图谱
|
||||
|
||||
## 概述
|
||||
|
||||
传统 wiki 是页面的平面集合，通过 wikilinks 连接。规模化后这种模式的局限显现：链接只说"A 与 B 相关"，不说明**如何**相关。知识图谱在页面之外增加结构化关系层，让查询可以从"A 出发，追踪所有依赖 B 的节点"。
|
||||
|
||||
本页阐述知识图谱在本 wiki 中的设计与集成方案。
|
||||
|
||||
源自 [LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2)。
|
||||
|
||||
## 核心思想
|
||||
|
||||
> 页面（pages）用于阅读，图（graph）用于导航和发现。
|
||||
|
||||
当用户问"升级 Redis 版本的影响"时：
|
||||
- **页面搜索**：关键词匹配，返回包含 Redis 的页面
|
||||
- **图遍历**：从 Redis 节点出发，沿 `depends_on` / `uses` 边向外走，追踪所有下游实体
|
||||
|
||||
---
|
||||
|
||||
## 实体提取（Entity Extraction）
|
||||
|
||||
摄入来源时，提取结构化实体而非仅存储文本。
|
||||
|
||||
### 实体类型
|
||||
|
||||
| 实体类型 | 示例 |
|
||||
|----------|------|
|
||||
| **机场** | 深圳宝安机场、郑州航空港、福州长乐机场 |
|
||||
| **供应商** | NVIDIA、Vertiv、华为、ADB SAFEGATE、Amadeus |
|
||||
| **硬件型号** | GB200 NVL72、H100 SXM5、HGX H100 |
|
||||
| **系统/平台** | AODB、A-CDM、SMGCS、BHS |
|
||||
| **标准/协议** | NCCL、RDMA、RoCE、Infiniband |
|
||||
| **项目** | 郑州万卡集群、福州长乐智算中心 |
|
||||
| **人/组织** | （可选择是否记录）|
|
||||
|
||||
### 实体元数据
|
||||
|
||||
```yaml
|
||||
# entities/shenzhen-airport.md frontmatter 扩展
|
||||
type: entity
|
||||
entity_type: airport # airport | vendor | hardware | system | standard | project
|
||||
confidence: 0.95
|
||||
sources_count: 3
|
||||
relationships: # 预定义关系（也在页面正文中用 wikilink）
|
||||
- target: gpu-cluster-shenzhen
|
||||
type: deploys
|
||||
confidence: 0.9
|
||||
- target: nvidia-h100
|
||||
type: uses
|
||||
confidence: 0.95
|
||||
- target: aodb-core
|
||||
type: operates
|
||||
confidence: 0.85
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 类型化关系（Typed Relationships）
|
||||
|
||||
Wikilink 只说"A 连接到 B"，Typed Relationship 说明**关系的语义**。
|
||||
|
||||
### 预定义关系类型
|
||||
|
||||
| 关系类型 | 含义 | 示例 |
|
||||
|----------|------|------|
|
||||
| `deploys` | 部署/安装 | 深圳机场 deploys GPU集群 |
|
||||
| `uses` | 使用（某技术/产品） | 深圳机场 uses NVIDIA GB200 |
|
||||
| `depends_on` | 依赖 | GPU集群 depends_on 液冷系统 |
|
||||
| `contradicts` | 矛盾/否定 | 旧方案 contradicts 新方案 |
|
||||
| `supersedes` | 替代 | GB200 supersedes H100 |
|
||||
| `caused` | 导致 | 功耗过高 caused 液冷需求 |
|
||||
| `integrates_with` | 与…集成 | AODB integrates_with A-CDM |
|
||||
| `competes_with` | 竞争 | Amadeus AODB competes_with ADB SAFEGEGO AODB |
|
||||
| `part_of` | 属于/组成 | BHS part_of 行李处理系统 |
|
||||
| `references` | 参考 | 本文 references NVIDIA白皮书 |
|
||||
|
||||
### 关系置信度
|
||||
|
||||
每条关系独立持有置信度：
|
||||
|
||||
> 深圳机场 uses GB200 NVL72，关系置信度 0.9（来源：深圳机场官方报道 + 华为官宣）
|
||||
|
||||
---
|
||||
|
||||
## 图遍历查询示例
|
||||
|
||||
### 示例 1：寻找 GPU 集群依赖
|
||||
|
||||
```
|
||||
问题：郑州航空港 GPU 集群的电力需求是多少？
|
||||
图遍历路径：
|
||||
郑州航空港
|
||||
→ deploys → gpu-cluster-zhengzhou
|
||||
→ uses → GB200 NVL72
|
||||
→ power_draw → 查询 power-and-cooling.md
|
||||
→ depends_on → 液冷系统
|
||||
→ 答案：NVL72 单卡 1200W，72卡集群 86.4MW（需液冷）
|
||||
```
|
||||
|
||||
### 示例 2：供应商竞争分析
|
||||
|
||||
```
|
||||
问题：ADB SAFEGATE 和 Amadeus 在 AODB 领域有何差异？
|
||||
图遍历：
|
||||
ADB SAFEGATE AODB
|
||||
→ competes_with → Amadeus AODB
|
||||
→ 两者都 integrate_with → A-CDM
|
||||
→ 参考 aodb-vendors.md 对比表
|
||||
```
|
||||
|
||||
### 示例 3：故障链追溯
|
||||
|
||||
```
|
||||
问题：机坪 FODS 传感器故障影响了哪些系统？
|
||||
图遍历：
|
||||
FODS 传感器
|
||||
→ feeds → SMGCS
|
||||
→ feeds → 场面活动管理
|
||||
→ 间接影响 → 停机位分配（RMS）
|
||||
→ 快速找到受影响实体
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 本 Wiki 的实施路径
|
||||
|
||||
### 阶段 1：手动标注（当前可行）
|
||||
|
||||
在 `entities/` 页面中逐步添加 `relationships` 字段，手动梳理实体间关系。
|
||||
|
||||
目标：覆盖核心机场实体和关键供应商关系。
|
||||
|
||||
### 阶段 2：自动化关系提取（中期目标）
|
||||
|
||||
在 ingestion 流程中增加实体识别步骤：
|
||||
- 来源文本 → NER 提取实体
|
||||
- 实体类型分类（机场/供应商/硬件/系统/标准）
|
||||
- 关系模式匹配（uses/deploys/integrates_with 等）
|
||||
|
||||
### 阶段 3：图数据库（远期目标）
|
||||
|
||||
当关系数量超过 ~500 条时，考虑引入图数据库：
|
||||
- **Neo4j**：成熟，支持 Cypher 查询
|
||||
- **Age**（PostgreSQL 扩展）：与现有工作流更易集成
|
||||
- 图遍历替代关键词搜索，提升查询质量
|
||||
|
||||
---
|
||||
|
||||
## 当前实体关系图（示例）
|
||||
|
||||
```
|
||||
┌─────────────────┐
|
||||
│ 深圳宝安机场 │◄─── deploys ────┐
|
||||
└────────┬────────┘ │
|
||||
│ uses │ uses
|
||||
┌────────▼────────┐ ┌───────▼────────┐
|
||||
│ NVIDIA GB200 │─────────►│ 华为自研芯片 │
|
||||
│ NVL72 │ supersedes │
|
||||
└────────┬────────┘ └────────────────┘
|
||||
│ power_draw (1200W/GPU)
|
||||
┌────────▼────────┐
|
||||
│ 液冷系统 │
|
||||
│ (PUE < 1.15) │
|
||||
└────────┬────────┘
|
||||
│ supports
|
||||
┌────────▼────────┐
|
||||
│ 电力供应系统 │
|
||||
│ (双路 N+1) │
|
||||
└─────────────────┘
|
||||
|
||||
┌─────────────────┐ integrates_with ┌─────────────────┐
|
||||
│ AODB │◄───────────────────────────►│ A-CDM │
|
||||
│ (ADB SAFEGEGO) │ │ │
|
||||
└────────┬────────┘ └────────┬────────┘
|
||||
│ competes_with │
|
||||
│ │ feeds
|
||||
┌────────▼────────┐ ┌────────▼────────┐
|
||||
│ Amadeus AODB │ │ SMGCS │
|
||||
└─────────────────┘ └─────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 相关页面
|
||||
|
||||
- [[memory-lifecycle]] — 置信度、superset、遗忘机制
|
||||
- [[wiki-operations]] — 实体提取的自动化钩子
|
||||
- [[aodb-vendors]] — 供应商竞争关系的具体例子
|
||||
- [[gpu-cluster]] — GPU 与其他硬件的关系
|
||||
- [[power-and-cooling]] — 电力/冷却是 GPU 集群的依赖关系
|
||||
@@ -0,0 +1,474 @@
|
||||
---
|
||||
title: 知识生命周期与遗忘曲线
|
||||
created: 2026-04-13
|
||||
updated: 2026-04-13
|
||||
type: concept
|
||||
tags: [knowledge-management, knowledge-lifecycle, confidence-decay, supersession]
|
||||
confidence: 0.9
|
||||
sources_count: 3
|
||||
last_confirmed: 2026-04-13
|
||||
status: active
|
||||
relationships:
|
||||
- target: automation-hooks.md
|
||||
type: governed-by
|
||||
detail: "置信度衰减触发事件"
|
||||
confidence: 0.95
|
||||
- target: knowledge-management/knowledge-graph.md
|
||||
type: updates
|
||||
detail: "实体关系老化机制"
|
||||
confidence: 0.85
|
||||
- target: hybrid-search.md
|
||||
type: influences
|
||||
detail: "搜索排名权重衰减"
|
||||
confidence: 0.8
|
||||
- target: quality-control.md
|
||||
type: informs
|
||||
detail: "质量评估和归档决策"
|
||||
confidence: 0.9
|
||||
---
|
||||
|
||||
# 🔄 知识生命周期与遗忘曲线
|
||||
|
||||
模拟人类记忆的**置信度衰减**和**层次化整合**机制，为机场智能化 wiki 建立动态的知识管理系统。通过时间衰减、源验证和层次整合，确保 wiki 内容的时效性和准确性。
|
||||
|
||||
> **核心理念**：知识不是静态的，而是随时间演化的有机体。新知识活跃，旧知识衰减，冲突知识整合。
|
||||
|
||||
---
|
||||
|
||||
## 🧠 记忆分层模型
|
||||
|
||||
### 1️⃣ **工作记忆层** (Working Memory)
|
||||
| 特征 | 处理机制 | 时间窗口 |
|
||||
|------|----------|----------|
|
||||
| **新加入的知识** | 高置信度 (0.8-1.0) | 1-30 天 |
|
||||
| **主动使用频率高** | 强化学习 | 短期活跃 |
|
||||
| **来源新鲜** | 来源评分高 | 即时可用 |
|
||||
| **易于修改** | 标记为待验证 | 高度可变 |
|
||||
|
||||
**适用场景**：刚发布的政策、新机场案例、技术规格更新
|
||||
|
||||
### 2️⃣ **长期记忆层** (Long-term Memory)
|
||||
| 特征 | 处理机制 | 时间窗口 |
|
||||
|------|----------|----------|
|
||||
| **已验证的知识** | 中等置信度 (0.5-0.8) | 31-365 天 |
|
||||
| **多源验证** | 冲突解决完毕 | 稳定引用 |
|
||||
| **整合完善** | 关联其他知识 | 结构性存储 |
|
||||
| **定期回顾** | 周期性强化 | 访问频率中 |
|
||||
|
||||
**适用场景**：成熟技术标准、核心运营流程、基础架构文档
|
||||
|
||||
### 3️⃣ **归档记忆层** (Archived Memory)
|
||||
| 特征 | 处理机制 | 时间窗口 |
|
||||
|------|----------|----------|
|
||||
| **过时但参考性** | 低置信度 (0.1-0.5) | >1 年 |
|
||||
| **历史价值** | 标记为过时 | 只读访问 |
|
||||
| **替代关系** | superseded_by 链接 | 背景参考 |
|
||||
| **最小维护** | 不参与搜索 | 低成本存储 |
|
||||
|
||||
**适用场景**：旧版标准、历史案例、被替换的技术方案
|
||||
|
||||
---
|
||||
|
||||
## 📉 置信度衰减机制
|
||||
|
||||
### 衰减函数
|
||||
```python
|
||||
def decay_confidence(current_confidence: float,
|
||||
age_days: int,
|
||||
usage_frequency: float,
|
||||
sources_count: int) -> float:
|
||||
"""
|
||||
计算置信度衰减
|
||||
参数:
|
||||
- current_confidence: 当前置信度 (0-1)
|
||||
- age_days: 知识创建天数
|
||||
- usage_frequency: 最近30天访问频率 (0-1)
|
||||
- sources_count: 引用来源数量
|
||||
"""
|
||||
|
||||
# 基础衰减因子：时间衰减（类似艾宾浩斯遗忘曲线）
|
||||
base_decay = 0.95 ** (age_days / 30) # 每月衰减5%
|
||||
|
||||
# 强化因子：使用频率和来源数量
|
||||
reinforcement = (usage_frequency * 0.3) + (min(sources_count, 5) * 0.05)
|
||||
|
||||
# 应用衰减
|
||||
new_confidence = current_confidence * base_decay
|
||||
|
||||
# 应用强化（减缓衰减）
|
||||
new_confidence += (1 - base_decay) * reinforcement
|
||||
|
||||
# 确保在 [0.05, 1.0] 范围内
|
||||
return max(0.05, min(1.0, new_confidence))
|
||||
```
|
||||
|
||||
### 衰减策略表
|
||||
| 衰减因子 | 影响权重 | 触发条件 | 调整幅度 |
|
||||
|----------|----------|----------|----------|
|
||||
| **时间衰减** | 60% | 创建时间 >30 天 | -2%/月 |
|
||||
| **使用频率** | 20% | 每月访问次数 | ±0.5%/次 |
|
||||
| **来源数量** | 15% | 引用来源增减 | ±1%/个 |
|
||||
| **冲突数量** | 5% | 发现矛盾事实 | -5%/冲突 |
|
||||
| **用户反馈** | 额外 | 明确确认/否认 | ±10%/次 |
|
||||
|
||||
### 衰减示例计算
|
||||
```python
|
||||
# 示例：智能登机口技术页面
|
||||
page_confidence = {
|
||||
"current": 0.85, # 当前置信度
|
||||
"age_days": 90, # 创建90天
|
||||
"usage_frequency": 0.6, # 中等使用频率
|
||||
"sources_count": 3, # 3个来源
|
||||
"conflicts": 1 # 1个冲突
|
||||
}
|
||||
|
||||
# 计算衰减
|
||||
new_confidence = decay_confidence(
|
||||
current_confidence=0.85,
|
||||
age_days=90,
|
||||
usage_frequency=0.6,
|
||||
sources_count=3
|
||||
)
|
||||
|
||||
# 应用冲突惩罚
|
||||
if page_confidence["conflicts"] > 0:
|
||||
new_confidence -= 0.05 * page_confidence["conflicts"]
|
||||
|
||||
print(f"原始置信度: 0.85 → 衰减后: {new_confidence:.2f}")
|
||||
# 输出: 原始置信度: 0.85 → 衰减后: 0.76
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔄 知识整合层次
|
||||
|
||||
### 层次 1: **事实级整合**
|
||||
```python
|
||||
def integrate_facts(existing_fact: Fact, new_fact: Fact) -> IntegrationResult:
|
||||
"""
|
||||
整合新事实到现有知识
|
||||
返回: 保持原样 | 更新 | 并列 | 弃用
|
||||
"""
|
||||
|
||||
# 1. 检查直接冲突
|
||||
if is_direct_conflict(existing_fact, new_fact):
|
||||
return resolve_conflict(existing_fact, new_fact)
|
||||
|
||||
# 2. 检查互补性
|
||||
if is_complementary(existing_fact, new_fact):
|
||||
return merge_facts(existing_fact, new_fact)
|
||||
|
||||
# 3. 检查相关性
|
||||
if is_related(existing_fact, new_fact):
|
||||
return link_facts(existing_fact, new_fact)
|
||||
|
||||
# 4. 无关联则独立存储
|
||||
return IntegrationResult.KEEP_BOTH
|
||||
```
|
||||
|
||||
### 层次 2: **页面级整合**
|
||||
```python
|
||||
def integrate_pages(target_page: Page, new_content: str, source: str):
|
||||
"""
|
||||
整合新内容到现有页面
|
||||
"""
|
||||
|
||||
# 1. 提取关键事实
|
||||
new_facts = extract_facts(new_content)
|
||||
|
||||
# 2. 与页面现有事实比较
|
||||
for fact in new_facts:
|
||||
# 查找匹配的现有事实
|
||||
matches = find_matching_facts(target_page, fact)
|
||||
|
||||
if not matches:
|
||||
# 新事实：添加
|
||||
target_page.add_fact(fact, source)
|
||||
|
||||
elif len(matches) == 1:
|
||||
# 匹配事实：整合
|
||||
result = integrate_facts(matches[0], fact)
|
||||
|
||||
if result == IntegrationResult.UPDATE:
|
||||
# 更新现有事实（提高置信度）
|
||||
matches[0].update(fact, source)
|
||||
elif result == IntegrationResult.DEPRECATE:
|
||||
# 弃用旧事实
|
||||
matches[0].mark_deprecated(fact, source)
|
||||
|
||||
else:
|
||||
# 多个匹配：需要人工审核
|
||||
target_page.flag_for_review(fact, matches)
|
||||
|
||||
# 3. 更新页面置信度
|
||||
target_page.recalculate_confidence()
|
||||
```
|
||||
|
||||
### 层次 3: **主题级整合**
|
||||
```python
|
||||
def integrate_topic(topic: str, new_sources: List[str]):
|
||||
"""
|
||||
整合新来源到主题（如"智能登机口"）
|
||||
"""
|
||||
|
||||
# 1. 获取主题相关页面
|
||||
related_pages = get_pages_by_topic(topic)
|
||||
|
||||
# 2. 对每个新来源
|
||||
for source in new_sources:
|
||||
content = read_source(source)
|
||||
|
||||
# 3. 分发给相关页面
|
||||
for page in related_pages:
|
||||
# 检查相关性
|
||||
relevance = calculate_relevance(content, page)
|
||||
|
||||
if relevance > 0.3:
|
||||
integrate_pages(page, content, source)
|
||||
|
||||
# 4. 创建新页面（如需）
|
||||
uncovered_aspects = find_uncovered_aspects(content, related_pages)
|
||||
|
||||
for aspect in uncovered_aspects:
|
||||
create_new_page(aspect, content, source)
|
||||
|
||||
# 5. 主题级置信度更新
|
||||
update_topic_confidence(topic)
|
||||
```
|
||||
|
||||
### 层次 4: **领域级整合**
|
||||
```python
|
||||
def integrate_domain(domain: str, time_period: str = "monthly"):
|
||||
"""
|
||||
跨主题的领域级整合（如"机场运营技术"）
|
||||
"""
|
||||
|
||||
# 1. 获取领域内所有主题
|
||||
topics = get_topics_in_domain(domain)
|
||||
|
||||
# 2. 识别跨主题模式
|
||||
cross_topic_patterns = analyze_cross_topic_patterns(topics)
|
||||
|
||||
# 3. 整合重复信息
|
||||
deduplicate_across_topics(topics)
|
||||
|
||||
# 4. 更新主题关系图
|
||||
update_domain_relationship_graph(domain, topics)
|
||||
|
||||
# 5. 生成领域报告
|
||||
report = generate_domain_integration_report(domain, topics)
|
||||
|
||||
return report
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🗑️ 知识淘汰与归档
|
||||
|
||||
### 淘汰决策树
|
||||
```
|
||||
开始
|
||||
↓
|
||||
置信度 < 0.3 ?
|
||||
├─ 是 → 标记为过时
|
||||
└─ 否 →
|
||||
↓
|
||||
有更新的替代版本？
|
||||
├─ 是 → superseded_by 链接
|
||||
└─ 否 →
|
||||
↓
|
||||
创建时间 > 2 年？
|
||||
├─ 是 → 归档建议
|
||||
└─ 否 → 保持活跃
|
||||
```
|
||||
|
||||
### 归档流程
|
||||
```python
|
||||
def archive_knowledge():
|
||||
"""
|
||||
自动知识归档流程
|
||||
1. 识别候选
|
||||
2. 验证替代关系
|
||||
3. 执行归档
|
||||
4. 更新引用
|
||||
"""
|
||||
|
||||
# 1. 识别归档候选
|
||||
candidates = find_archive_candidates()
|
||||
|
||||
for candidate in candidates:
|
||||
# 2. 检查是否有替代版本
|
||||
replacement = find_replacement(candidate)
|
||||
|
||||
if replacement:
|
||||
# 3. 建立 superseded_by 关系
|
||||
candidate.superseded_by = replacement
|
||||
|
||||
# 4. 移动页面到归档目录
|
||||
archive_path = move_to_archive(candidate)
|
||||
|
||||
# 5. 更新所有引用
|
||||
update_references(candidate, replacement)
|
||||
|
||||
log_event("page_archived", {
|
||||
"page": candidate.path,
|
||||
"replacement": replacement.path,
|
||||
"reason": "superseded_by",
|
||||
"timestamp": now()
|
||||
})
|
||||
else:
|
||||
# 无替代版本：降低搜索权重
|
||||
candidate.search_weight *= 0.1
|
||||
|
||||
log_event("page_deprecated", {
|
||||
"page": candidate.path,
|
||||
"reason": "no_replacement",
|
||||
"timestamp": now()
|
||||
})
|
||||
|
||||
return {"archived": len(candidates)}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 置信度驱动的搜索排名
|
||||
|
||||
### 搜索评分算法
|
||||
```python
|
||||
def calculate_search_score(page: Page, query: str, user_context: Dict) -> float:
|
||||
"""
|
||||
结合置信度、相关性和时效性的搜索评分
|
||||
"""
|
||||
|
||||
# 1. 基础文本相关性 (BM25)
|
||||
text_relevance = bm25_score(page.content, query)
|
||||
|
||||
# 2. 语义相关性 (嵌入相似度)
|
||||
semantic_relevance = embedding_similarity(page.embedding, query_embedding)
|
||||
|
||||
# 3. 置信度调整
|
||||
confidence_adjustment = page.confidence ** 2 # 平方加权，高置信度优势更大
|
||||
|
||||
# 4. 时效性调整（新知识优先）
|
||||
recency_adjustment = 1.0 / (1 + page.age_days / 180) # 半年衰减一半
|
||||
|
||||
# 5. 用户个性化（如有历史数据）
|
||||
personalization = calculate_personalization_score(page, user_context)
|
||||
|
||||
# 综合评分
|
||||
score = (
|
||||
text_relevance * 0.4 +
|
||||
semantic_relevance * 0.4 +
|
||||
confidence_adjustment * 0.15 +
|
||||
recency_adjustment * 0.05 +
|
||||
personalization * 0.1 # 如果用户有历史数据，否则为0
|
||||
)
|
||||
|
||||
return score
|
||||
```
|
||||
|
||||
### 置信度阈值
|
||||
| 置信度区间 | 搜索可见性 | 推荐系统 | 自动引用 |
|
||||
|------------|------------|----------|----------|
|
||||
| **0.8-1.0** | 最高优先级 | 主动推荐 | 自动引用 |
|
||||
| **0.6-0.79** | 正常显示 | 可能推荐 | 谨慎引用 |
|
||||
| **0.4-0.59** | 较低权重 | 很少推荐 | 标记警告 |
|
||||
| **0.2-0.39** | 需明确搜索 | 不推荐 | 避免引用 |
|
||||
| **<0.2** | 隐藏（归档） | 不推荐 | 不引用 |
|
||||
|
||||
---
|
||||
|
||||
## 📊 生命周期监控
|
||||
|
||||
### 仪表板指标
|
||||
```python
|
||||
def get_lifecycle_metrics():
|
||||
"""
|
||||
返回知识生命周期关键指标
|
||||
"""
|
||||
return {
|
||||
"total_pages": count_pages(),
|
||||
"by_confidence": {
|
||||
"high": count_pages(confidence_min=0.8),
|
||||
"medium": count_pages(confidence_min=0.5, confidence_max=0.79),
|
||||
"low": count_pages(confidence_min=0.2, confidence_max=0.49),
|
||||
"archived": count_pages(confidence_max=0.19)
|
||||
},
|
||||
"decay_rate": calculate_average_decay_rate(),
|
||||
"conflict_resolution_rate": get_conflict_resolution_rate(),
|
||||
"archival_rate": count_archived_last_month(),
|
||||
"average_age_days": get_average_page_age()
|
||||
}
|
||||
```
|
||||
|
||||
### 健康检查
|
||||
```python
|
||||
def health_check_lifecycle():
|
||||
"""
|
||||
生命周期系统健康检查
|
||||
"""
|
||||
issues = []
|
||||
|
||||
# 检查过度衰减
|
||||
if get_average_decay_rate() > 0.1:
|
||||
issues.append("置信度衰减过快")
|
||||
|
||||
# 检查冲突积压
|
||||
if count_unresolved_conflicts() > 20:
|
||||
issues.append("未解决冲突过多")
|
||||
|
||||
# 检查归档堆积
|
||||
if count_candidates_for_archive() > 50:
|
||||
issues.append("归档候选积压")
|
||||
|
||||
# 检查更新频率
|
||||
if days_since_last_integration() > 30:
|
||||
issues.append("整合操作长期未执行")
|
||||
|
||||
return {
|
||||
"status": "healthy" if not issues else "needs_attention",
|
||||
"issues": issues,
|
||||
"metrics": get_lifecycle_metrics()
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 实施路线图
|
||||
|
||||
### 阶段 1：基础衰减（当前）
|
||||
- ✅ 页面级置信度字段
|
||||
- ✅ 简单的基于时间的衰减
|
||||
- 🔄 每周自动衰减脚本
|
||||
|
||||
### 阶段 2：智能整合（2-4周）
|
||||
- 🔄 事实级冲突检测
|
||||
- 🔄 页面级整合算法
|
||||
- 🔄 置信度驱动的搜索排名
|
||||
- 🔄 基础仪表板
|
||||
|
||||
### 阶段 3：高级生命周期（1-2月）
|
||||
- 🔄 主题级和领域级整合
|
||||
- 🔄 自适应衰减参数
|
||||
- 🔄 用户反馈集成
|
||||
- 🔄 预测性归档建议
|
||||
|
||||
### 阶段 4：自主管理（未来）
|
||||
- 🔄 自适应的遗忘曲线
|
||||
- 🔄 跨wiki知识同步
|
||||
- 🔄 主动知识维护
|
||||
- 🔄 预测性内容生成
|
||||
|
||||
---
|
||||
|
||||
## 📚 相关文档
|
||||
|
||||
- [[automation-hooks.md]] - 触发置信度衰减的自动化事件
|
||||
- [[knowledge-management/knowledge-graph.md]] - 整合过程中的关系更新
|
||||
- [[hybrid-search.md]] - 置信度驱动的搜索排名
|
||||
- [[quality-control.md]] - 质量评估和归档决策
|
||||
- [[wiki-backup-recovery.md]] - 归档内容的备份管理
|
||||
|
||||
---
|
||||
|
||||
> **状态**: 基础置信度衰减已实现。下一步：集成智能冲突检测和整合算法。最后更新：2026-04-13。
|
||||
@@ -0,0 +1,584 @@
|
||||
---
|
||||
title: LLM Wiki v2 参考文档
|
||||
created: 2026-04-13
|
||||
updated: 2026-04-13
|
||||
type: meta
|
||||
tags: [llm-wiki, v2, reference, architecture]
|
||||
confidence: 0.9
|
||||
sources_count: 5
|
||||
last_confirmed: 2026-04-13
|
||||
status: active
|
||||
relationships:
|
||||
- target: SCHEMA.md
|
||||
type: implements
|
||||
detail: "v2 架构实现"
|
||||
confidence: 0.95
|
||||
- target: concepts/knowledge-management/automation-hooks.md
|
||||
type: core-component
|
||||
detail: "自动化钩子系统"
|
||||
confidence: 0.9
|
||||
- target: concepts/knowledge-management/knowledge-lifecycle.md
|
||||
type: core-component
|
||||
detail: "知识生命周期"
|
||||
confidence: 0.9
|
||||
- target: concepts/knowledge-management/quality-control.md
|
||||
type: core-component
|
||||
detail: "质量控制机制"
|
||||
confidence: 0.9
|
||||
- target: concepts/knowledge-management/knowledge-graph.md
|
||||
type: core-component
|
||||
detail: "实体图管理"
|
||||
confidence: 0.85
|
||||
- target: concepts/knowledge-management/hybrid-search.md
|
||||
type: core-component
|
||||
detail: "混合搜索系统"
|
||||
confidence: 0.85
|
||||
---
|
||||
|
||||
# 📚 LLM Wiki v2 参考文档
|
||||
|
||||
**机场智能化工程知识库的架构与技术实现指南**
|
||||
|
||||
基于 Karpathy 的 LLM Wiki 理念，v2 版本引入了**动态知识管理**、**智能检索**和**自动化维护**三大核心能力。本文档详细说明架构设计、实现原理和配置方法。
|
||||
|
||||
> **v2 核心理念**：知识是动态的有机体，需要随时间衰减、冲突整合和持续验证，而非静态的文档集合。
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ 架构总览
|
||||
|
||||
### 系统分层架构
|
||||
```
|
||||
应用层 (Application Layer)
|
||||
├── 搜索引擎 (Hybrid Search Engine)
|
||||
├── 关系图谱 (Knowledge Graph Browser)
|
||||
└── 质量看板 (Quality Dashboard)
|
||||
|
||||
核心层 (Core Layer)
|
||||
├── 自动化钩子系统 (Automation Hooks)
|
||||
├── 置信度衰减引擎 (Confidence Decay Engine)
|
||||
├── 冲突检测处理器 (Conflict Detection Processor)
|
||||
└── 自我纠正机制 (Self-correction Mechanism)
|
||||
|
||||
存储层 (Storage Layer)
|
||||
├── 向量数据库 (Vector Database) # 嵌入存储
|
||||
├── 文档存储 (Document Store) # Markdown/YAML
|
||||
└── 关系数据库 (Relational Database) # 实体关系
|
||||
```
|
||||
|
||||
### 数据流向
|
||||
```
|
||||
新来源 → 解析 → 实体提取 → 事实提取 → 冲突检测 → 置信度评估 → 存储
|
||||
↓ ↓ ↓ ↓ ↓
|
||||
现有知识 ← 整合 ← 关系更新 ← 冲突解决 ← 置信度衰减 ← 质量验证 ← 定期任务
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔧 核心组件详解
|
||||
|
||||
### 1. **置信度系统 (Confidence System)**
|
||||
#### 置信度字段结构
|
||||
```yaml
|
||||
---
|
||||
confidence: 0.85 # 当前置信度 (0.1-1.0)
|
||||
sources_count: 3 # 引用来源数量
|
||||
last_confirmed: 2026-04-13 # 最后一次确认/更新
|
||||
confidence_history: # 置信度变化历史
|
||||
- date: 2026-04-10
|
||||
value: 0.80
|
||||
reason: "new_source_added"
|
||||
- date: 2026-04-12
|
||||
value: 0.83
|
||||
reason: "conflict_resolved"
|
||||
- date: 2026-04-13
|
||||
value: 0.85
|
||||
reason: "weekly_decay_applied"
|
||||
decay_factors: # 衰减因子权重
|
||||
time: 0.60
|
||||
usage: 0.20
|
||||
sources: 0.15
|
||||
conflicts: 0.05
|
||||
---
|
||||
```
|
||||
|
||||
#### 衰减算法
|
||||
```python
|
||||
def decay_confidence(current, age_days, usage_freq, sources_cnt, conflicts_cnt):
|
||||
# 基础时间衰减（每月5%）
|
||||
base_decay = 0.95 ** (age_days / 30)
|
||||
|
||||
# 强化因子（使用频率和来源数量）
|
||||
reinforcement = (usage_freq * 0.3) + (min(sources_cnt, 5) * 0.05)
|
||||
|
||||
# 应用衰减
|
||||
new_confidence = current * base_decay + (1 - base_decay) * reinforcement
|
||||
|
||||
# 冲突惩罚
|
||||
new_confidence -= 0.05 * conflicts_cnt
|
||||
|
||||
# 边界处理
|
||||
return max(0.05, min(1.0, new_confidence))
|
||||
```
|
||||
|
||||
### 2. **实体图管理系统 (Entity Graph Management)**
|
||||
#### 实体类型定义
|
||||
```python
|
||||
ENTITY_TYPES = {
|
||||
"airport": {
|
||||
"attributes": ["code", "name", "location", "capacity", "status"],
|
||||
"relationships": {
|
||||
"uses": ["technology", "system", "vendor"],
|
||||
"located_in": ["region", "country"],
|
||||
"implements": ["standard", "certification"]
|
||||
}
|
||||
},
|
||||
"technology": {
|
||||
"attributes": ["category", "vendor", "version", "specs"],
|
||||
"relationships": {
|
||||
"used_by": ["airport", "system"],
|
||||
"compatible_with": ["technology"],
|
||||
"replaces": ["technology"]
|
||||
}
|
||||
},
|
||||
"vendor": {
|
||||
"attributes": ["name", "country", "specialization", "market_share"],
|
||||
"relationships": {
|
||||
"provides": ["technology", "service"],
|
||||
"competes_with": ["vendor"],
|
||||
"partners_with": ["vendor"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### 关系类型
|
||||
| 关系类型 | 语义 | 反向关系 | 示例 |
|
||||
|----------|------|----------|------|
|
||||
| **uses** | 使用 | used_by | 深圳机场 uses SITA AODB |
|
||||
| **implements** | 实现 | implemented_by | JFK implements ACI EUROPE 2020 |
|
||||
| **replaces** | 替换 | replaced_by | H100 replaces A100 |
|
||||
| **based_on** | 基于 | basis_for | 数字孿生 based_on BIM 模型 |
|
||||
| **compatible_with** | 兼容 | compatible_with | RoCE compatible_with InfiniBand |
|
||||
| **partners_with** | 合作 | partners_with | SITA partners_with Huawei |
|
||||
|
||||
### 3. **自动化钩子系统 (Automation Hooks)**
|
||||
#### 事件注册表
|
||||
```python
|
||||
HOOK_REGISTRY = {
|
||||
"source_added": [
|
||||
{"callback": "parse_source", "priority": 10},
|
||||
{"callback": "extract_entities", "priority": 9},
|
||||
{"callback": "detect_conflicts", "priority": 8},
|
||||
{"callback": "update_confidence", "priority": 7}
|
||||
],
|
||||
"page_updated": [
|
||||
{"callback": "check_semantic_change", "priority": 10},
|
||||
{"callback": "update_embeddings", "priority": 9},
|
||||
{"callback": "propagate_relations", "priority": 8},
|
||||
{"callback": "log_change", "priority": 5}
|
||||
],
|
||||
"query_executed": [
|
||||
{"callback": "record_query_pattern", "priority": 10},
|
||||
{"callback": "evaluate_results", "priority": 8},
|
||||
{"callback": "generate_suggestions", "priority": 5}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### 定时任务调度
|
||||
```python
|
||||
SCHEDULE_CONFIG = {
|
||||
"daily": {
|
||||
"time": "02:30",
|
||||
"tasks": [
|
||||
"verify_recent_changes",
|
||||
"update_recommendations",
|
||||
"clean_temp_files",
|
||||
"backup_incremental"
|
||||
]
|
||||
},
|
||||
"weekly": {
|
||||
"time": "03:00",
|
||||
"day": "sunday",
|
||||
"tasks": [
|
||||
"run_lint_check",
|
||||
"decay_confidence_scores",
|
||||
"regenerate_embeddings",
|
||||
"rebuild_search_index"
|
||||
]
|
||||
},
|
||||
"monthly": {
|
||||
"time": "04:00",
|
||||
"day": 1, # 每月1日
|
||||
"tasks": [
|
||||
"archive_stale_content",
|
||||
"evaluate_embedding_models",
|
||||
"analyze_growth_trends",
|
||||
"run_security_audit"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4. **混合搜索系统 (Hybrid Search System)**
|
||||
#### 搜索评分算法
|
||||
```python
|
||||
def calculate_search_score(page, query, user_context):
|
||||
# 1. 文本相关性 (BM25)
|
||||
text_relevance = bm25_score(page.content, query)
|
||||
|
||||
# 2. 语义相关性 (嵌入相似度)
|
||||
semantic_relevance = embedding_similarity(page.embedding, query_embedding)
|
||||
|
||||
# 3. 置信度调整
|
||||
confidence_adjustment = page.confidence ** 2
|
||||
|
||||
# 4. 时效性调整
|
||||
recency_adjustment = 1.0 / (1 + page.age_days / 180)
|
||||
|
||||
# 5. 个性化调整
|
||||
personalization = calculate_personalization_score(page, user_context)
|
||||
|
||||
# 综合评分 (加权)
|
||||
score = (
|
||||
text_relevance * 0.4 +
|
||||
semantic_relevance * 0.4 +
|
||||
confidence_adjustment * 0.15 +
|
||||
recency_adjustment * 0.05 +
|
||||
personalization * 0.1
|
||||
)
|
||||
|
||||
return score
|
||||
```
|
||||
|
||||
#### 查询重写策略
|
||||
```python
|
||||
QUERY_REWRITE_RULES = [
|
||||
# 同义词扩展
|
||||
{"pattern": r"\bgpu\b", "expansion": "gpu OR graphics processing unit OR ai accelerator"},
|
||||
|
||||
# 技术缩写扩展
|
||||
{"pattern": r"\baodb\b", "expansion": "aodb OR airport operational database"},
|
||||
|
||||
# 机场代码映射
|
||||
{"pattern": r"\bSZX\b", "expansion": "SZX OR Shenzhen Bao'an International Airport"},
|
||||
{"pattern": r"\bJFK\b", "expansion": "JFK OR New York John F. Kennedy Airport"},
|
||||
|
||||
# 单位标准化
|
||||
{"pattern": r"(\d+)\s*kw", "expansion": "$1 kW OR $1 kilowatt"},
|
||||
{"pattern": r"(\d+)\s*MW", "expansion": "$1 MW OR $1 megawatt"},
|
||||
]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ 配置与部署
|
||||
|
||||
### 配置文件结构
|
||||
```yaml
|
||||
# ~/.hermes/ObsidianVault/airport-wiki/config.yaml
|
||||
|
||||
llm_wiki:
|
||||
version: "2.1.0"
|
||||
|
||||
confidence:
|
||||
decay_rate: 0.05 # 每月衰减率
|
||||
min_confidence: 0.05
|
||||
max_confidence: 1.0
|
||||
usage_weight: 0.2
|
||||
sources_weight: 0.15
|
||||
|
||||
automation:
|
||||
enabled: true
|
||||
check_interval_seconds: 15 # 文件监视间隔
|
||||
max_workers: 3
|
||||
|
||||
search:
|
||||
hybrid_enabled: true
|
||||
vector_weight: 0.4
|
||||
keyword_weight: 0.4
|
||||
confidence_weight: 0.15
|
||||
recency_weight: 0.05
|
||||
query_expansion: true
|
||||
|
||||
entities:
|
||||
types: ["airport", "technology", "vendor", "standard", "system"]
|
||||
relation_types: ["uses", "implements", "replaces", "based_on", "compatible_with"]
|
||||
|
||||
storage:
|
||||
vector_db: "chromadb"
|
||||
doc_store: "filesystem"
|
||||
graph_db: "sqlite"
|
||||
|
||||
monitoring:
|
||||
metrics_enabled: true
|
||||
alerting_enabled: true
|
||||
log_level: "info"
|
||||
```
|
||||
|
||||
### 环境变量
|
||||
```bash
|
||||
# LLM Wiki 核心配置
|
||||
export LLM_WIKI_HOME="/home/windy/.hermes/ObsidianVault/airport-wiki"
|
||||
export EMBEDDING_MODEL="all-MiniLM-L6-v2"
|
||||
export VECTOR_DB_HOST="localhost"
|
||||
export VECTOR_DB_PORT=8000
|
||||
|
||||
# 自动化钩子
|
||||
export HOOKS_ENABLED="true"
|
||||
export HOOKS_CHECK_INTERVAL="15"
|
||||
export HOOKS_MAX_WORKERS="3"
|
||||
|
||||
# 监控和日志
|
||||
export LOG_LEVEL="info"
|
||||
export METRICS_PORT="9090"
|
||||
export ALERT_WEBHOOK="https://hooks.slack.com/services/..."
|
||||
```
|
||||
|
||||
### 初始化脚本
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# init_llm_wiki_v2.sh
|
||||
|
||||
# 1. 检查依赖
|
||||
check_dependencies() {
|
||||
echo "检查依赖..."
|
||||
python3 --version >/dev/null 2>&1 || { echo "需要 Python 3.8+"; exit 1; }
|
||||
pip --version >/dev/null 2>&1 || { echo "需要 pip"; exit 1; }
|
||||
}
|
||||
|
||||
# 2. 安装 Python 包
|
||||
install_packages() {
|
||||
echo "安装 Python 包..."
|
||||
pip install -r requirements.txt
|
||||
}
|
||||
|
||||
# 3. 初始化数据库
|
||||
init_databases() {
|
||||
echo "初始化数据库..."
|
||||
python -c "from storage import init_db; init_db()"
|
||||
}
|
||||
|
||||
# 4. 生成初始嵌入
|
||||
generate_initial_embeddings() {
|
||||
echo "生成初始嵌入..."
|
||||
python -c "from embeddings import generate_all_embeddings; generate_all_embeddings()"
|
||||
}
|
||||
|
||||
# 5. 启动服务
|
||||
start_services() {
|
||||
echo "启动服务..."
|
||||
|
||||
# 启动文件监视服务
|
||||
python -m hooks.file_watcher &
|
||||
|
||||
# 启动定时任务调度器
|
||||
python -m hooks.scheduler &
|
||||
|
||||
# 启动监控服务
|
||||
python -m monitoring.metrics_server &
|
||||
}
|
||||
|
||||
main() {
|
||||
echo "=== LLM Wiki v2 初始化 ==="
|
||||
|
||||
check_dependencies
|
||||
install_packages
|
||||
init_databases
|
||||
generate_initial_embeddings
|
||||
start_services
|
||||
|
||||
echo "✅ 初始化完成"
|
||||
echo "监控面板: http://localhost:9090"
|
||||
echo "搜索端点: http://localhost:8000/search"
|
||||
}
|
||||
|
||||
main "$@"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔄 升级与迁移
|
||||
|
||||
### 从 v1 升级到 v2
|
||||
#### 步骤 1: 备份 v1 数据
|
||||
```bash
|
||||
# 备份整个 wiki 目录
|
||||
tar -czf wiki_v1_backup_$(date +%Y%m%d).tar.gz airport-wiki/
|
||||
|
||||
# 导出实体关系
|
||||
python -c "from v1_exporter import export_all; export_all('v1_export.json')"
|
||||
```
|
||||
|
||||
#### 步骤 2: 安装 v2 组件
|
||||
```bash
|
||||
# 创建新配置目录
|
||||
mkdir -p ~/.hermes/ObsidianVault/airport-wiki/concepts/knowledge-management
|
||||
|
||||
# 安装 v2 Python 包
|
||||
pip install llm-wiki-v2
|
||||
|
||||
# 初始化 v2 数据库
|
||||
python -m llm_wiki_v2.init --config config.yaml
|
||||
```
|
||||
|
||||
#### 步骤 3: 迁移数据
|
||||
```bash
|
||||
# 运行迁移脚本
|
||||
python -m llm_wiki_v2.migrate \
|
||||
--v1_path ./airport-wiki \
|
||||
--v2_path ./airport-wiki-v2 \
|
||||
--mode incremental
|
||||
```
|
||||
|
||||
#### 步骤 4: 验证迁移
|
||||
```bash
|
||||
# 检查置信度字段
|
||||
python -c "from validation import check_migration; check_migration('airport-wiki-v2')"
|
||||
|
||||
# 测试搜索功能
|
||||
curl -X POST "http://localhost:8000/search" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"query": "GPU cluster power consumption", "limit": 5}'
|
||||
```
|
||||
|
||||
### 数据迁移策略
|
||||
| 数据类型 | v1 格式 | v2 格式 | 迁移方法 |
|
||||
|----------|---------|---------|----------|
|
||||
| **页面内容** | 纯 Markdown | Markdown + YAML frontmatter | 解析并添加置信度字段 |
|
||||
| **实体关系** | 链接（无类型） | 类型化关系 | 提取文本关系并分类 |
|
||||
| **嵌入向量** | 无 | 向量数据库 | 重新生成所有嵌入 |
|
||||
| **搜索索引** | 文件搜索 | 混合搜索索引 | 重建索引 |
|
||||
|
||||
---
|
||||
|
||||
## 📊 监控与告警
|
||||
|
||||
### 关键性能指标 (KPIs)
|
||||
```python
|
||||
KPI_CONFIG = {
|
||||
"search": {
|
||||
"response_time_p95": {"threshold": 3000, "unit": "ms"},
|
||||
"success_rate": {"threshold": 0.95, "unit": "%"},
|
||||
"recall_at_5": {"threshold": 0.85, "unit": "%"}
|
||||
},
|
||||
"confidence": {
|
||||
"average_confidence": {"threshold": 0.7, "unit": "score"},
|
||||
"decay_rate": {"threshold": 0.1, "unit": "/month"},
|
||||
"conflict_resolution_rate": {"threshold": 0.9, "unit": "%"}
|
||||
},
|
||||
"automation": {
|
||||
"hook_success_rate": {"threshold": 0.95, "unit": "%"},
|
||||
"processing_time_p95": {"threshold": 5000, "unit": "ms"},
|
||||
"backlog_size": {"threshold": 100, "unit": "items"}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 告警规则
|
||||
```yaml
|
||||
alerts:
|
||||
- name: "search_degradation"
|
||||
condition: "search_response_time_p95 > 3000 OR search_success_rate < 0.95"
|
||||
severity: "critical"
|
||||
actions: ["page_oncall", "rollback_search_config"]
|
||||
|
||||
- name: "confidence_anomaly"
|
||||
condition: "average_confidence < 0.6 OR decay_rate > 0.15"
|
||||
severity: "high"
|
||||
actions: ["notify_maintainer", "run_verification"]
|
||||
|
||||
- name: "automation_failure"
|
||||
condition: "hook_success_rate < 0.9 OR backlog_size > 200"
|
||||
severity: "medium"
|
||||
actions: ["log_incident", "restart_workers"]
|
||||
```
|
||||
|
||||
### 监控仪表板
|
||||
- **搜索性能仪表板**：响应时间、命中率、用户满意度
|
||||
- **知识质量仪表板**：平均置信度、冲突数量、更新频率
|
||||
- **系统健康仪表板**：自动化成功率、存储使用率、错误率
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ 故障排除
|
||||
|
||||
### 常见问题及解决方法
|
||||
| 问题 | 症状 | 解决方案 |
|
||||
|------|------|----------|
|
||||
| **置信度不衰减** | 页面置信度长期不变 | 检查定时任务是否运行；验证衰减算法参数 |
|
||||
| **搜索结果差** | 相关页面排名靠后 | 调整搜索权重；重新生成嵌入；检查索引 |
|
||||
| **自动化钩子失败** | 文件变更未触发处理 | 验证文件监视配置；检查权限；查看日志 |
|
||||
| **实体关系缺失** | 页面无关系链接 | 运行实体提取；检查关系检测规则 |
|
||||
| **嵌入生成失败** | 页面无嵌入向量 | 检查模型加载；验证文本编码；查看错误日志 |
|
||||
|
||||
### 诊断命令
|
||||
```bash
|
||||
# 检查系统状态
|
||||
python -m llm_wiki_v2.status --full
|
||||
|
||||
# 查看日志
|
||||
tail -f ~/.hermes/logs/llm_wiki.log
|
||||
|
||||
# 手动触发维护任务
|
||||
python -m hooks.runner --task weekly_maintenance
|
||||
|
||||
# 检查数据库完整性
|
||||
python -c "from storage import verify_integrity; verify_integrity()"
|
||||
|
||||
# 重置错误状态
|
||||
python -m llm_wiki_v2.reset --component hooks
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔮 未来发展方向
|
||||
|
||||
### 近期计划 (1-3个月)
|
||||
- **智能答案生成**：基于查询自动生成综合答案
|
||||
- **预测性维护**：基于历史模式预测知识老化
|
||||
- **多模态支持**：图像、图表等非文本内容处理
|
||||
- **用户行为分析**：优化搜索和推荐系统
|
||||
|
||||
### 中期计划 (3-12个月)
|
||||
- **跨wiki知识同步**：多个wiki之间的知识共享
|
||||
- **自适应学习**：系统自动调整参数和规则
|
||||
- **自然语言更新**：用户用自然语言编辑知识
|
||||
- **实时协作**：多用户同时编辑和注释
|
||||
|
||||
### 长期愿景 (1年以上)
|
||||
- **自主知识管理**：系统完全自主维护和优化知识库
|
||||
- **预测性内容创建**：基于趋势预测自动创建新内容
|
||||
- **智能决策支持**：基于知识库提供决策建议
|
||||
- **认知增强**：与人类思维深度协同的知识系统
|
||||
|
||||
---
|
||||
|
||||
## 📚 相关资源
|
||||
|
||||
### 官方文档
|
||||
- [[SCHEMA.md]] - 架构定义和设计规范
|
||||
- [[concepts/knowledge-management/automation-hooks.md]] - 自动化钩子详细实现
|
||||
- [[concepts/knowledge-management/knowledge-lifecycle.md]] - 知识生命周期管理
|
||||
- [[concepts/knowledge-management/quality-control.md]] - 质量控制机制
|
||||
- [[concepts/knowledge-management/knowledge-graph.md]] - 实体图管理
|
||||
- [[concepts/knowledge-management/hybrid-search.md]] - 混合搜索系统
|
||||
|
||||
### 工具和库
|
||||
- **向量数据库**: ChromaDB, Qdrant, Weaviate
|
||||
- **嵌入模型**: all-MiniLM-L6-v2, BGE, OpenAI embeddings
|
||||
- **搜索引擎**: Elasticsearch, Meilisearch, Typesense
|
||||
- **监控**: Prometheus, Grafana, OpenTelemetry
|
||||
|
||||
### 参考文献
|
||||
1. Karpathy, A. "LLM: A Personal Knowledge Base"
|
||||
2. Luhmann, N. "Zettelkasten Method"
|
||||
3. Ahrens, S. "How to Take Smart Notes"
|
||||
4. Vannevar Bush, "As We May Think"
|
||||
|
||||
---
|
||||
|
||||
> **版本**: v2.1.0 | **最后更新**: 2026-04-13
|
||||
> **维护状态**: 活跃 | **支持**: 用户文档 + 技术支持论坛
|
||||
> **注意**: 本系统持续演进，建议定期查看相关文档获取最新信息。
|
||||
@@ -0,0 +1,197 @@
|
||||
---
|
||||
title: 记忆生命周期
|
||||
created: 2026-04-13
|
||||
updated: 2026-04-13
|
||||
type: concept
|
||||
tags: [knowledge-management, confidence, supersession, forgetting, consolidation-tier]
|
||||
sources: [raw/articles/llm-wiki-v2-rohitg00.md]
|
||||
---
|
||||
|
||||
# 记忆生命周期
|
||||
|
||||
## 概述
|
||||
|
||||
Wiki 内容不是平等有效的。原始 LLM Wiki 模式将所有知识视为永久有效，而实践中知识有生命周期。本页阐述四层生命周期管理机制，让 wiki 从"平等声明的平面集合"变为"可判断置信度的动态模型"。
|
||||
|
||||
源自 [LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2)（agentmemory 项目实战经验）。
|
||||
|
||||
## 置信度评分（Confidence Scoring）
|
||||
|
||||
每条 wiki 事实应携带置信度分数，声明其可靠性。
|
||||
|
||||
### 评分维度
|
||||
|
||||
| 维度 | 说明 |
|
||||
|------|------|
|
||||
| **来源数量** | 有多少独立来源支持该声明 |
|
||||
| **时效性** | 最近一次确认的时间 |
|
||||
| **矛盾检测** | 是否有其他来源否定该声明 |
|
||||
|
||||
### 置信度表示法
|
||||
|
||||
在 frontmatter 或行内元数据中标注：
|
||||
|
||||
```yaml
|
||||
confidence: 0.85
|
||||
sources_count: 2
|
||||
last_confirmed: 2026-04-01
|
||||
superseded_by: null
|
||||
```
|
||||
|
||||
**示例：**
|
||||
|
||||
> "郑州航空港当前算力 10,000P" — confidence: 0.9（官方新闻稿，2026-03）
|
||||
> "GB200 NVL72 HBM3e 带宽 16 TB/s" — confidence: 0.95（NVIDIA 官方白皮书）
|
||||
> "某供应商报价 2026 Q4 交付" — confidence: 0.4（单一非官方来源，未经交叉验证）
|
||||
|
||||
### 置信度衰减与强化
|
||||
|
||||
- **时间衰减**：事实的置信度随时间自然下降（架构决策衰减慢，bug/价格信息衰减快）
|
||||
- **强化机制**：新来源确认 → 置信度上升；被新来源否定 → 触发 supersession
|
||||
|
||||
衰减率可参考 Ebbinghaus 遗忘曲线模型：
|
||||
- 首次学习后 24 小时：保留约 40%
|
||||
- 1 周后：保留约 25%
|
||||
- 每个"访问/确认"事件重置衰减时钟
|
||||
|
||||
**实践建议：**
|
||||
- `confidence > 0.8`：稳定知识，优先检索
|
||||
- `confidence 0.5–0.8`：参考知识，标注不确定性
|
||||
- `confidence < 0.5`：草稿或待验证，不用于关键结论
|
||||
|
||||
---
|
||||
|
||||
## 替代机制（Supersession）
|
||||
|
||||
当新信息推翻或更新现有声明时，使用 supersession 而非静默覆盖。
|
||||
|
||||
### 规则
|
||||
|
||||
1. 旧版本**不删除**，保留完整内容
|
||||
2. 旧版本 frontmatter 标记 `superseded_by: [new-page-name]`，`superseded_date: YYYY-MM-DD`
|
||||
3. 新版本 frontmatter 记录 `supersedes: [old-page-name]`，`supersedes_date: YYYY-MM-DD`
|
||||
4. 旧页面添加 `status: stale` 标签，归档到 `_archive/`
|
||||
|
||||
### 示例
|
||||
|
||||
**旧版本（归档）：**
|
||||
```yaml
|
||||
---
|
||||
title: 福州长乐机场智算中心
|
||||
created: 2026-01-22
|
||||
updated: 2026-01-22
|
||||
status: stale
|
||||
superseded_by: fuzhou-changle-airport-bsj
|
||||
superseded_date: 2026-04-13
|
||||
confidence: 0.7
|
||||
---
|
||||
# 福州长乐机场智算中心（已过时）
|
||||
|
||||
原报道：2026 年 Q4 投产，投资 11 亿元。
|
||||
（此版本已被新版本替代，内容已更新）
|
||||
```
|
||||
|
||||
**新版本：**
|
||||
```yaml
|
||||
---
|
||||
title: 福州长乐机场智算中心
|
||||
created: 2026-01-22
|
||||
updated: 2026-04-13
|
||||
type: entity
|
||||
supersedes: _archive/fuzhou-changle-airport-old
|
||||
supersedes_date: 2026-04-13
|
||||
confidence: 0.9
|
||||
sources_count: 3
|
||||
---
|
||||
```
|
||||
|
||||
### 触发条件
|
||||
|
||||
- 同一实体的新来源比旧来源更权威或更新
|
||||
- 供应商方案更新、型号参数变化
|
||||
- 项目时间节点变化（如投产日期推迟）
|
||||
|
||||
---
|
||||
|
||||
## 遗忘机制（Forgetting）
|
||||
|
||||
Wiki 不应该记住所有事情。没有遗忘机制的 wiki 会变得嘈杂，降低检索效率。
|
||||
|
||||
### 保留策略
|
||||
|
||||
| 知识类型 | 衰减速度 | 说明 |
|
||||
|----------|----------|------|
|
||||
| 架构决策 | 极慢 | 长期有效，少量衰减 |
|
||||
| 硬件规格 | 慢 | 以年计，需等新一代产品 |
|
||||
| 供应商方案 | 中 | 以季度计 |
|
||||
| 项目进度/节点 | 快 | 月度变化，不重要后快速衰减 |
|
||||
| Bug/问题记录 | 最快 | 解决后快速降权 |
|
||||
|
||||
### 实践方式
|
||||
|
||||
- **软删除**：不真正删除，frontmatter 标记 `status: dormant`
|
||||
- **降权**：降低 `confidence`，不用于主要结论
|
||||
- **归档转移**：移动至 `_archive/`，不纳入主要检索
|
||||
|
||||
### Ebbinghaus 遗忘曲线应用
|
||||
|
||||
- 每次**访问**或**来源确认**事件重置衰减时钟
|
||||
- 长期未访问的事实自动降权
|
||||
- `log.md` 中的历史记录本身也是一种衰减信号
|
||||
|
||||
---
|
||||
|
||||
## 整合层次（Consolidation Tiers）
|
||||
|
||||
原始观察需要经过管道处理才能成为可靠知识。建立以下层次：
|
||||
|
||||
| 层次 | 名称 | 内容 | 特征 |
|
||||
|------|------|------|------|
|
||||
| Tier 0 | **Working Memory** | 最近一次会话的观察，尚未处理 | 存于 session 上下文，不持久化 |
|
||||
| Tier 1 | **Episodic Memory** | 会话摘要，从 raw sources 压缩而来 | `log.md` 中的 session 条目 |
|
||||
| Tier 2 | **Semantic Memory** | 跨会话事实，从 episodes 整合 | `concepts/` 和 `entities/` 中的稳定页面 |
|
||||
| Tier 3 | **Procedural Memory** | 工作流和模式，从重复的 semantics 提取 | `SCHEMA.md`、操作规程、schema |
|
||||
|
||||
### 升级规则
|
||||
|
||||
- **Working → Episodic**：session 结束时自动压缩为 `log.md` 条目
|
||||
- **Episodic → Semantic**：同一实体/概念出现 2+ 次后，创建或更新 `entities/`/`concepts/` 页面
|
||||
- **Semantic → Procedural**：跨 wiki 的模式被识别后，更新 `SCHEMA.md`
|
||||
|
||||
### 本 wiki 中的对应关系
|
||||
|
||||
```
|
||||
Session / Chat
|
||||
↓ session end
|
||||
log.md (Episodic Memory — session summaries)
|
||||
↓ 2+ mentions / important update
|
||||
concepts/ entities/ (Semantic Memory — cross-session facts)
|
||||
↓ schema-level pattern recognized
|
||||
SCHEMA.md (Procedural Memory — workflows and conventions)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 与现有 Wiki 的集成
|
||||
|
||||
### 当前缺口
|
||||
|
||||
1. `entities/` 目前只有 7 个机场实体，**无置信度字段**
|
||||
2. `concepts/` 页面无 `confidence` / `superseded_by` / `status` 标记
|
||||
3. `log.md` 是 episodic layer，但**未向上整合到 semantic memory**
|
||||
4. 无 supersession 机制，旧版本被静默覆盖
|
||||
|
||||
### 近期改进
|
||||
|
||||
- [ ] 为所有 `entities/` 页面添加 `confidence` 和 `sources_count` 字段
|
||||
- [ ] 建立 `_archive/` 目录，存放被 supersede 的旧版本
|
||||
- [ ] 制定 wiki auto-lint 脚本，自动检测矛盾并触发 supersession
|
||||
- [ ] 评估是否引入 `status: stale` / `status: dormant` 标记
|
||||
|
||||
---
|
||||
|
||||
## 相关页面
|
||||
|
||||
- [[knowledge-graph]] — 超越平面页面的结构化知识表示
|
||||
- [[wiki-operations]] — ingest/query/lint 操作的自动化钩子
|
||||
- [[glossary]] — 术语表（其中包含 confidence 相关的量化指标）
|
||||
@@ -0,0 +1,616 @@
|
||||
---
|
||||
title: 质量控制与自我纠正机制
|
||||
created: 2026-04-13
|
||||
updated: 2026-04-13
|
||||
type: concept
|
||||
tags: [knowledge-management, quality-control, self-correction, validation]
|
||||
confidence: 0.9
|
||||
sources_count: 4
|
||||
last_confirmed: 2026-04-13
|
||||
status: active
|
||||
relationships:
|
||||
- target: automation-hooks.md
|
||||
type: integrates-with
|
||||
detail: "质量检查触发事件"
|
||||
confidence: 0.95
|
||||
- target: knowledge-management/knowledge-lifecycle.md
|
||||
type: informs
|
||||
detail: "置信度评估依据"
|
||||
confidence: 0.9
|
||||
- target: knowledge-management/knowledge-graph.md
|
||||
type: validates
|
||||
detail: "关系一致性检查"
|
||||
confidence: 0.85
|
||||
- target: hybrid-search.md
|
||||
type: improves
|
||||
detail: "搜索结果质量提升"
|
||||
confidence: 0.8
|
||||
---
|
||||
|
||||
# 🔍 质量控制与自我纠正机制
|
||||
|
||||
为机场智能化 wiki 建立**多层次质量验证**和**自动纠错**系统，确保技术参数准确、内容一致、关系完整。通过规则检查、语义验证和用户反馈，实现持续质量改进。
|
||||
|
||||
> **质量目标**：零技术参数错误，内容一致性 >95%，关系完整性 >90%，用户满意度 >85%。
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ 质量框架层次
|
||||
|
||||
### 层次 1: **语法与格式检查** (Syntax & Format)
|
||||
| 检查项 | 规则 | 自动修复 | 严重性 |
|
||||
|--------|------|----------|--------|
|
||||
| **Markdown 语法** | 链接格式、标题层级、列表 | ✅ 自动修复 | 低 |
|
||||
| **YAML 前端元数据** | 必需字段、类型验证 | ✅ 自动修复 | 中 |
|
||||
| **文件命名规范** | 小写、连字符、无空格 | ✅ 自动修复 | 低 |
|
||||
| **编码与换行** | UTF-8, LF 换行 | ✅ 自动修复 | 低 |
|
||||
|
||||
### 层次 2: **内容一致性检查** (Content Consistency)
|
||||
| 检查项 | 规则 | 自动修复 | 严重性 |
|
||||
|--------|------|----------|--------|
|
||||
| **技术参数一致性** | 同一参数多源一致 | ⚠️ 标记冲突 | 高 |
|
||||
| **单位统一性** | kW vs MW, GB vs GiB | ✅ 自动转换 | 中 |
|
||||
| **术语标准化** | 统一技术术语 | ✅ 建议替换 | 中 |
|
||||
| **日期格式** | ISO 8601 标准 | ✅ 自动转换 | 低 |
|
||||
|
||||
### 层次 3: **语义与逻辑检查** (Semantic & Logic)
|
||||
| 检查项 | 规则 | 自动修复 | 严重性 |
|
||||
|--------|------|----------|--------|
|
||||
| **事实冲突检测** | 矛盾陈述识别 | ❌ 人工审核 | 高 |
|
||||
| **因果关系验证** | 逻辑链完整性 | ⚠️ 标记缺失 | 中 |
|
||||
| **数值合理性** | 功率/容量范围检查 | ⚠️ 标记异常 | 高 |
|
||||
| **时间线一致性** | 事件顺序验证 | ⚠️ 标记矛盾 | 中 |
|
||||
|
||||
### 层次 4: **关系完整性检查** (Relationship Integrity)
|
||||
| 检查项 | 规则 | 自动修复 | 严重性 |
|
||||
|--------|------|----------|--------|
|
||||
| **死链检测** | 内部链接有效性 | ✅ 自动修复 | 中 |
|
||||
| **孤立页面** | 无入链页面识别 | ⚠️ 标记孤立 | 低 |
|
||||
| **循环引用** | 循环依赖检测 | ⚠️ 标记循环 | 中 |
|
||||
| **关系对称性** | 双向关系验证 | ✅ 自动修复 | 中 |
|
||||
|
||||
---
|
||||
|
||||
## 🔧 自动检查规则库
|
||||
|
||||
### 技术参数验证规则
|
||||
```python
|
||||
TECHNICAL_RULES = {
|
||||
"power_consumption": {
|
||||
"pattern": r"(\d+(?:\.\d+)?)\s*(kW|MW|W)",
|
||||
"validation": lambda value, unit: (
|
||||
# 数据中心功率范围检查
|
||||
if unit == "MW" and value > 100:
|
||||
return False, "数据中心功率超过100MW需验证"
|
||||
elif unit == "kW" and value < 1:
|
||||
return False, "功率低于1kW可能错误"
|
||||
else:
|
||||
return True, ""
|
||||
),
|
||||
"auto_correct": lambda value, unit: (
|
||||
# 自动单位转换 kW → MW
|
||||
if unit == "kW" and value >= 1000:
|
||||
return f"{value/1000:.2f} MW"
|
||||
else:
|
||||
return None
|
||||
)
|
||||
},
|
||||
|
||||
"temperature_range": {
|
||||
"pattern": r"(\d+(?:\.\d+)?)\s*°?[CF]",
|
||||
"validation": lambda value, unit: (
|
||||
# 数据中心温度范围检查
|
||||
if unit == "C" and (value < 18 or value > 27):
|
||||
return False, "数据中心温度超出推荐范围 (18-27°C)"
|
||||
elif unit == "F" and (value < 64 or value > 81):
|
||||
return False, "数据中心温度超出推荐范围 (64-81°F)"
|
||||
else:
|
||||
return True, ""
|
||||
),
|
||||
"auto_correct": lambda value, unit: (
|
||||
# 温度单位转换
|
||||
if unit == "F":
|
||||
return f"{(value-32)*5/9:.1f}°C"
|
||||
else:
|
||||
return None
|
||||
)
|
||||
},
|
||||
|
||||
"rack_power_density": {
|
||||
"pattern": r"(\d+(?:\.\d+)?)\s*(kW/rack|kW per rack)",
|
||||
"validation": lambda value, unit: (
|
||||
# 机架功率密度检查
|
||||
if value > 50:
|
||||
return False, "机架功率密度超过50kW/rack需液冷"
|
||||
elif value < 1:
|
||||
return False, "机架功率密度低于1kW/rack可能错误"
|
||||
else:
|
||||
return True, ""
|
||||
)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 一致性检查规则
|
||||
```python
|
||||
CONSISTENCY_RULES = {
|
||||
"vendor_product_names": {
|
||||
"mappings": {
|
||||
"NVIDIA": ["nvidia", "Nvidia", "NVIDIA Corporation"],
|
||||
"Intel": ["intel", "Intel Corporation", "Intel Corp"],
|
||||
"华为": ["Huawei", "huawei", "华为技术有限公司"],
|
||||
"曙光": ["Sugon", "曙光信息", "中科曙光"]
|
||||
},
|
||||
"action": "standardize" # 标准化为规范名称
|
||||
},
|
||||
|
||||
"date_formats": {
|
||||
"patterns": [
|
||||
r"\d{4}-\d{2}-\d{2}", # ISO 8601
|
||||
r"\d{2}/\d{2}/\d{4}", # MM/DD/YYYY
|
||||
r"\d{4}年\d{1,2}月\d{1,2}日" # 中文日期
|
||||
],
|
||||
"target_format": "%Y-%m-%d", # 统一为 ISO 8601
|
||||
"action": "convert"
|
||||
},
|
||||
|
||||
"capacity_units": {
|
||||
"mappings": {
|
||||
"GB": ["gb", "gigabyte", "gigabytes"],
|
||||
"TB": ["tb", "terabyte", "terabytes"],
|
||||
"PB": ["pb", "petabyte", "petabytes"],
|
||||
"GiB": ["gib", "gibibyte"],
|
||||
"TiB": ["tib", "tebibyte"]
|
||||
},
|
||||
"action": "standardize"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ 自我纠正机制
|
||||
|
||||
### 1. **自动修复流程**
|
||||
```python
|
||||
def auto_correction_pipeline(content: str) -> Tuple[str, List[Correction]]:
|
||||
"""
|
||||
自动纠正管道：多层修复策略
|
||||
返回: (修正后内容, 修正记录列表)
|
||||
"""
|
||||
corrections = []
|
||||
|
||||
# 第1层：语法修复
|
||||
content, syntax_fixes = fix_markdown_syntax(content)
|
||||
corrections.extend(syntax_fixes)
|
||||
|
||||
# 第2层：格式修复
|
||||
content, format_fixes = fix_yaml_frontmatter(content)
|
||||
corrections.extend(format_fixes)
|
||||
|
||||
# 第3层：单位标准化
|
||||
content, unit_fixes = standardize_units(content)
|
||||
corrections.extend(unit_fixes)
|
||||
|
||||
# 第4层：术语标准化
|
||||
content, term_fixes = standardize_terminology(content)
|
||||
corrections.extend(term_fixes)
|
||||
|
||||
# 第5层：链接修复
|
||||
content, link_fixes = fix_broken_links(content)
|
||||
corrections.extend(link_fixes)
|
||||
|
||||
return content, corrections
|
||||
```
|
||||
|
||||
### 2. **冲突解决策略**
|
||||
```python
|
||||
def resolve_content_conflict(existing_content: str,
|
||||
new_content: str,
|
||||
conflict_type: str) -> ResolutionResult:
|
||||
"""
|
||||
解决内容冲突的策略
|
||||
"""
|
||||
|
||||
if conflict_type == "factual_conflict":
|
||||
# 事实冲突：基于置信度选择
|
||||
existing_confidence = calculate_confidence(existing_content)
|
||||
new_confidence = calculate_confidence(new_content)
|
||||
|
||||
if new_confidence > existing_confidence * 1.2:
|
||||
# 新内容置信度显著更高
|
||||
return ResolutionResult.REPLACE
|
||||
elif existing_confidence > new_confidence * 1.2:
|
||||
# 现有内容置信度显著更高
|
||||
return ResolutionResult.KEEP
|
||||
else:
|
||||
# 置信度相近：标记为待审核
|
||||
return ResolutionResult.FLAG_FOR_REVIEW
|
||||
|
||||
elif conflict_type == "complementary_info":
|
||||
# 互补信息：合并
|
||||
return ResolutionResult.MERGE
|
||||
|
||||
elif conflict_type == "version_update":
|
||||
# 版本更新：建立 superseded_by 关系
|
||||
return ResolutionResult.SUPERSEDE
|
||||
|
||||
elif conflict_type == "formatting_only":
|
||||
# 仅格式差异：保留更好格式
|
||||
return ResolutionResult.KEEP_BETTER_FORMAT
|
||||
|
||||
else:
|
||||
# 未知冲突类型：人工审核
|
||||
return ResolutionResult.MANUAL_REVIEW
|
||||
```
|
||||
|
||||
### 3. **质量评分系统**
|
||||
```python
|
||||
class QualityScorer:
|
||||
"""质量评分系统"""
|
||||
|
||||
def __init__(self):
|
||||
self.weights = {
|
||||
"technical_accuracy": 0.30,
|
||||
"consistency": 0.25,
|
||||
"completeness": 0.20,
|
||||
"recency": 0.15,
|
||||
"source_credibility": 0.10
|
||||
}
|
||||
|
||||
def score_page(self, page: Page) -> QualityScore:
|
||||
"""计算页面质量分数 (0-100)"""
|
||||
|
||||
scores = {}
|
||||
|
||||
# 1. 技术准确性
|
||||
scores["technical_accuracy"] = self._score_technical_accuracy(page)
|
||||
|
||||
# 2. 一致性
|
||||
scores["consistency"] = self._score_consistency(page)
|
||||
|
||||
# 3. 完整性
|
||||
scores["completeness"] = self._score_completeness(page)
|
||||
|
||||
# 4. 时效性
|
||||
scores["recency"] = self._score_recency(page)
|
||||
|
||||
# 5. 来源可信度
|
||||
scores["source_credibility"] = self._score_source_credibility(page)
|
||||
|
||||
# 加权总分
|
||||
total_score = sum(
|
||||
score * self.weights[metric]
|
||||
for metric, score in scores.items()
|
||||
)
|
||||
|
||||
return QualityScore(
|
||||
total=total_score,
|
||||
breakdown=scores,
|
||||
grade=self._assign_grade(total_score)
|
||||
)
|
||||
|
||||
def _assign_grade(self, score: float) -> str:
|
||||
"""分配质量等级"""
|
||||
if score >= 90:
|
||||
return "A+"
|
||||
elif score >= 80:
|
||||
return "A"
|
||||
elif score >= 70:
|
||||
return "B"
|
||||
elif score >= 60:
|
||||
return "C"
|
||||
elif score >= 50:
|
||||
return "D"
|
||||
else:
|
||||
return "F"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 质量监控仪表板
|
||||
|
||||
### 关键质量指标 (KQIs)
|
||||
```python
|
||||
KQI_METRICS = {
|
||||
"technical_accuracy_rate": {
|
||||
"description": "技术参数准确率",
|
||||
"calculation": "accurate_params / total_params",
|
||||
"target": ">98%",
|
||||
"weight": 0.35
|
||||
},
|
||||
|
||||
"consistency_score": {
|
||||
"description": "内容一致性评分",
|
||||
"calculation": "average_consistency_score",
|
||||
"target": ">95",
|
||||
"weight": 0.25
|
||||
},
|
||||
|
||||
"completeness_index": {
|
||||
"description": "页面完整性指数",
|
||||
"calculation": "filled_sections / total_sections",
|
||||
"target": ">90%",
|
||||
"weight": 0.20
|
||||
},
|
||||
|
||||
"freshness_score": {
|
||||
"description": "内容新鲜度评分",
|
||||
"calculation": "weighted_average(recency)",
|
||||
"target": ">85",
|
||||
"weight": 0.10
|
||||
},
|
||||
|
||||
"user_satisfaction": {
|
||||
"description": "用户满意度",
|
||||
"calculation": "positive_feedback / total_feedback",
|
||||
"target": ">85%",
|
||||
"weight": 0.10
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 质量趋势分析
|
||||
```python
|
||||
def analyze_quality_trends(time_period: str = "monthly"):
|
||||
"""
|
||||
分析质量趋势
|
||||
"""
|
||||
|
||||
# 获取历史数据
|
||||
history = get_quality_history(time_period)
|
||||
|
||||
trends = {}
|
||||
|
||||
for metric in KQI_METRICS:
|
||||
values = [h[metric] for h in history]
|
||||
|
||||
# 计算趋势
|
||||
if len(values) >= 2:
|
||||
slope = calculate_slope(values)
|
||||
trend = "improving" if slope > 0.01 else "declining" if slope < -0.01 else "stable"
|
||||
|
||||
# 检测异常点
|
||||
anomalies = detect_anomalies(values)
|
||||
|
||||
trends[metric] = {
|
||||
"current": values[-1],
|
||||
"trend": trend,
|
||||
"slope": slope,
|
||||
"anomalies": anomalies,
|
||||
"target": KQI_METRICS[metric]["target"]
|
||||
}
|
||||
|
||||
# 综合质量指数
|
||||
composite_score = calculate_composite_quality_index(trends)
|
||||
|
||||
return {
|
||||
"period": time_period,
|
||||
"composite_score": composite_score,
|
||||
"trends": trends,
|
||||
"recommendations": generate_quality_recommendations(trends)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚨 异常检测与告警
|
||||
|
||||
### 异常检测规则
|
||||
```python
|
||||
ANOMALY_RULES = {
|
||||
"sudden_confidence_drop": {
|
||||
"condition": "confidence_change < -0.2",
|
||||
"severity": "high",
|
||||
"action": "investigate_source_changes"
|
||||
},
|
||||
|
||||
"technical_parameter_outlier": {
|
||||
"condition": "parameter_value outside 3σ",
|
||||
"severity": "critical",
|
||||
"action": "verify_with_primary_source"
|
||||
},
|
||||
|
||||
"multiple_conflicts_detected": {
|
||||
"condition": "conflict_count > 3",
|
||||
"severity": "medium",
|
||||
"action": "initiate_review_process"
|
||||
},
|
||||
|
||||
"orphaned_page_created": {
|
||||
"condition": "incoming_links == 0 AND outgoing_links > 5",
|
||||
"severity": "low",
|
||||
"action": "suggest_relationships"
|
||||
},
|
||||
|
||||
"stale_content_alert": {
|
||||
"condition": "last_updated > 180 days AND confidence > 0.7",
|
||||
"severity": "medium",
|
||||
"action": "schedule_refresh"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 告警处理流程
|
||||
```python
|
||||
def handle_quality_alert(alert: Alert):
|
||||
"""
|
||||
处理质量告警
|
||||
"""
|
||||
|
||||
# 1. 记录告警
|
||||
log_alert(alert)
|
||||
|
||||
# 2. 根据严重性采取行动
|
||||
if alert.severity == "critical":
|
||||
# 立即处理：暂停相关页面，通知维护者
|
||||
suspend_page(alert.page_id)
|
||||
notify_maintainer(alert, priority="high")
|
||||
|
||||
# 启动调查
|
||||
investigation = investigate_alert(alert)
|
||||
|
||||
# 根据调查结果采取行动
|
||||
if investigation["requires_manual_fix"]:
|
||||
create_maintenance_task(alert)
|
||||
else:
|
||||
apply_auto_fix(alert, investigation)
|
||||
|
||||
elif alert.severity == "high":
|
||||
# 高优先级：标记为待处理，24小时内处理
|
||||
create_maintenance_task(alert, due_in_hours=24)
|
||||
notify_maintainer(alert, priority="medium")
|
||||
|
||||
elif alert.severity == "medium":
|
||||
# 中优先级：加入待办队列，72小时内处理
|
||||
create_maintenance_task(alert, due_in_hours=72)
|
||||
|
||||
elif alert.severity == "low":
|
||||
# 低优先级：批量处理，每周统一处理
|
||||
queue_for_batch_processing(alert)
|
||||
|
||||
# 3. 更新告警状态
|
||||
update_alert_status(alert, "handled")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔄 持续改进循环
|
||||
|
||||
### PDCA 循环 (Plan-Do-Check-Act)
|
||||
```python
|
||||
def quality_improvement_cycle():
|
||||
"""
|
||||
质量持续改进循环
|
||||
"""
|
||||
|
||||
while True:
|
||||
# 1. PLAN: 分析质量数据，制定改进计划
|
||||
quality_report = analyze_quality_trends("weekly")
|
||||
improvement_plan = create_improvement_plan(quality_report)
|
||||
|
||||
# 2. DO: 执行改进措施
|
||||
implemented_changes = execute_improvement_plan(improvement_plan)
|
||||
|
||||
# 3. CHECK: 评估改进效果
|
||||
effect_measurement = measure_improvement_effect(implemented_changes)
|
||||
|
||||
# 4. ACT: 标准化成功措施，调整失败措施
|
||||
if effect_measurement["successful"]:
|
||||
standardize_successful_changes(implemented_changes)
|
||||
else:
|
||||
adjust_failed_changes(implemented_changes, effect_measurement)
|
||||
|
||||
# 等待下一周期
|
||||
time.sleep(7 * 24 * 3600) # 每周一次
|
||||
```
|
||||
|
||||
### A/B 测试框架
|
||||
```python
|
||||
def run_quality_ab_test(test_name: str, variant_a: Dict, variant_b: Dict):
|
||||
"""
|
||||
运行质量改进A/B测试
|
||||
"""
|
||||
|
||||
# 1. 随机分配页面到测试组
|
||||
group_a, group_b = random_split_pages(test_name, 50)
|
||||
|
||||
# 2. 应用不同变体
|
||||
apply_variant(group_a, variant_a)
|
||||
apply_variant(group_b, variant_b)
|
||||
|
||||
# 3. 收集指标
|
||||
metrics_a = collect_metrics(group_a, duration_days=14)
|
||||
metrics_b = collect_metrics(group_b, duration_days=14)
|
||||
|
||||
# 4. 统计分析
|
||||
result = statistical_analysis(metrics_a, metrics_b)
|
||||
|
||||
# 5. 决定获胜变体
|
||||
if result["significant"] and result["winner"] == "A":
|
||||
winning_variant = variant_a
|
||||
elif result["significant"] and result["winner"] == "B":
|
||||
winning_variant = variant_b
|
||||
else:
|
||||
winning_variant = None # 无显著差异
|
||||
|
||||
# 6. 记录测试结果
|
||||
log_ab_test_result(test_name, result, winning_variant)
|
||||
|
||||
return {
|
||||
"test_name": test_name,
|
||||
"result": result,
|
||||
"winning_variant": winning_variant,
|
||||
"recommendation": "implement" if winning_variant else "no_change"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📋 质量检查清单
|
||||
|
||||
### 每日检查
|
||||
- [ ] 语法检查报告（自动）
|
||||
- [ ] 新内容质量评分（自动）
|
||||
- [ ] 冲突检测（自动）
|
||||
- [ ] 链接有效性检查（自动）
|
||||
|
||||
### 每周检查
|
||||
- [ ] 技术参数一致性验证（半自动）
|
||||
- [ ] 关系完整性检查（自动）
|
||||
- [ ] 质量趋势分析（自动）
|
||||
- [ ] 用户反馈分析（半自动）
|
||||
|
||||
### 每月检查
|
||||
- [ ] 全面质量审计（手动）
|
||||
- [ ] 规则库更新评估（手动）
|
||||
- [ ] 自我纠正效果评估（半自动）
|
||||
- [ ] 质量改进计划制定（手动）
|
||||
|
||||
### 季度检查
|
||||
- [ ] 质量框架评估（手动）
|
||||
- [ ] 用户满意度调查（手动）
|
||||
- [ ] 基准对比分析（半自动）
|
||||
- [ ] 战略调整（手动）
|
||||
|
||||
---
|
||||
|
||||
## 🚀 实施路线图
|
||||
|
||||
### 阶段 1：基础检查（当前）
|
||||
- ✅ 语法和格式检查
|
||||
- ✅ 基本一致性验证
|
||||
- 🔄 自动修复简单问题
|
||||
- 🔄 质量评分基础框架
|
||||
|
||||
### 阶段 2：智能验证（2-4周）
|
||||
- 🔄 技术参数验证规则
|
||||
- 🔄 语义冲突检测
|
||||
- 🔄 自动冲突解决策略
|
||||
- 🔄 质量监控仪表板
|
||||
|
||||
### 阶段 3：自我纠正（1-2月）
|
||||
- 🔄 多层修复管道
|
||||
- 🔄 异常检测和告警
|
||||
- 🔄 用户反馈集成
|
||||
- 🔄 A/B测试框架
|
||||
|
||||
### 阶段 4：持续改进（未来）
|
||||
- 🔄 自适应质量规则
|
||||
- 🔄 预测性质量维护
|
||||
- 🔄 跨wiki质量同步
|
||||
- 🔄 自主质量优化
|
||||
|
||||
---
|
||||
|
||||
## 📚 相关文档
|
||||
|
||||
- [[automation-hooks.md]] - 质量检查触发事件
|
||||
- [[knowledge-management/knowledge-lifecycle.md]] - 置信度评估依据
|
||||
- [[knowledge-management/knowledge-graph.md]] - 关系一致性检查
|
||||
- [[hybrid-search.md]] - 搜索结果质量提升
|
||||
- [[wiki-backup-recovery.md]] - 质量问题的回滚机制
|
||||
|
||||
---
|
||||
|
||||
> **状态**: 基础语法检查和一致性验证已实现。下一步：集成技术参数验证和冲突检测。最后更新：2026-04-13。
|
||||
@@ -0,0 +1,186 @@
|
||||
---
|
||||
title: Wiki 操作与自动化
|
||||
created: 2026-04-13
|
||||
updated: 2026-04-13
|
||||
type: concept
|
||||
tags: [knowledge-management, automation, ingestion, lint, event-hooks]
|
||||
sources: [raw/articles/llm-wiki-v2-rohitg00.md]
|
||||
---
|
||||
|
||||
# Wiki 操作与自动化
|
||||
|
||||
## 概述
|
||||
|
||||
原始 LLM Wiki 定义了三个基础操作：ingest（摄入）、query（查询）、lint（清理）。在规模化运营中，这三个操作需要扩展为事件驱动架构：每个事件类型触发预定义的自动化钩子，人只做 curation，bookkeeping 全自动化。
|
||||
|
||||
本页描述扩展后的操作模型及其在本 wiki 中的实践。
|
||||
|
||||
源自 [LLM Wiki v2](https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2)。
|
||||
|
||||
---
|
||||
|
||||
## 三层操作模型
|
||||
|
||||
### Layer 1：原始来源层（Raw Sources）
|
||||
|
||||
`raw/` 目录，保存未处理的原始文档：
|
||||
- 新闻报道、白皮书、官方文档
|
||||
- 每次摄入注明来源、日期、URL
|
||||
|
||||
### Layer 2：Wiki 层（Semantic Memory）
|
||||
|
||||
`concepts/`、`entities/`、`comparisons/` 中的页面：
|
||||
- 经过处理的结构化知识
|
||||
- 从 raw sources 提取、整合、标注关系
|
||||
|
||||
### Layer 3：Schema 层（Procedural Memory）
|
||||
|
||||
`SCHEMA.md` 和 `log.md`：
|
||||
- 元知识、工作流、命名规范
|
||||
- 从 wiki 操作中积累的模式
|
||||
|
||||
---
|
||||
|
||||
## 事件钩子（Event Hooks）
|
||||
|
||||
### 标准钩子矩阵
|
||||
|
||||
| 事件 | 自动触发动作 |
|
||||
|------|-------------|
|
||||
| **On new source** | 存档至 `raw/` → 运行 entity extraction → 更新 `entities/index.md` → 检查 supersession → 更新 index.md |
|
||||
| **On session start** | 根据最近 `log.md` 条目加载相关上下文 |
|
||||
| **On session end** | 将会话压缩为 episodic 条目写入 `log.md` |
|
||||
| **On query** | 检索时检查答案是否值得写回 wiki（quality score > threshold） |
|
||||
| **On memory write** | 检查矛盾，触发 supersession，更新 confidence |
|
||||
| **On schedule**（定时） | 全量 lint、consolidation tier 检查、confidence decay、遗忘处理 |
|
||||
|
||||
### On New Source — 完整流程
|
||||
|
||||
```
|
||||
收到新来源（用户提供 URL / Gist / 文件）
|
||||
↓
|
||||
1. 下载并保存至 raw/articles/[slug]-[date].md
|
||||
↓
|
||||
2. 自动 entity extraction
|
||||
- 识别：机场名、供应商、硬件型号、系统名
|
||||
- 提取 Typed Relationships
|
||||
- 分配 confidence 初值（来源权威性 × 时效性）
|
||||
↓
|
||||
3. 矛盾检测
|
||||
- 与现有 entities 比较
|
||||
- 若发现矛盾 → 触发 supersession 流程
|
||||
- 旧版本 → _archive/，标记 status: stale
|
||||
↓
|
||||
4. 更新目录
|
||||
- 新增 entities → entities/index.md
|
||||
- 新增 concepts → index.md 对应 section
|
||||
- 更新 log.md
|
||||
↓
|
||||
5. 通知（如有重大矛盾）
|
||||
- 标记待用户审核
|
||||
```
|
||||
|
||||
### On Session End — 压缩流程
|
||||
|
||||
```
|
||||
会话结束信号
|
||||
↓
|
||||
1. 提取本次会话的关键结论
|
||||
- "新了解到 …"
|
||||
- "已验证 …"
|
||||
- "仍有疑问 …"
|
||||
↓
|
||||
2. 写入 log.md（Episodic Memory）
|
||||
条目格式：
|
||||
- 日期 + session id
|
||||
- 来源：本次对话
|
||||
- 新知识：<压缩后的结论>
|
||||
- 开放问题：<下次需验证>
|
||||
↓
|
||||
3. 评估是否升级至 Semantic Memory
|
||||
- 同一实体在 2+ session 中出现？
|
||||
- 是 → 创建/更新 entities/ 或 concepts/ 页面
|
||||
```
|
||||
|
||||
### On Schedule — 定期维护
|
||||
|
||||
```
|
||||
每日/每周定时任务
|
||||
↓
|
||||
1. Confidence decay
|
||||
- 所有 entities/concepts 按时间衰减
|
||||
- 衰减率：架构决策 0.1%/月，供应商信息 1%/月，进度信息 5%/月
|
||||
↓
|
||||
2. Orphan check
|
||||
- 没有入站链接的页面 → 标记 review
|
||||
- 入站链接多但内容少的"薄页" → 合并或扩展
|
||||
↓
|
||||
3. Broken link scan
|
||||
- 检查所有 wikilink 有效性
|
||||
- 检查所有 raw source 文件是否存在
|
||||
↓
|
||||
4. Supersession review
|
||||
- 标记为 stale > 3 个月且无访问 → 移至 _archive/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 自动化实现方案
|
||||
|
||||
### 当前状态 vs 目标状态
|
||||
|
||||
| 操作 | 当前（手动） | 目标（自动） |
|
||||
|------|-------------|-------------|
|
||||
| 来源摄入 | 用户触发 | On new source hook |
|
||||
| Session 摘要 | 无 | On session end → log.md |
|
||||
| 矛盾检测 | 无 | On memory write → supersession |
|
||||
| 定期 lint | 偶尔手动 | On schedule cron |
|
||||
| 置信度衰减 | 无 | On schedule cron |
|
||||
|
||||
### 近期可实现步骤
|
||||
|
||||
1. **会话结束自动写 log**
|
||||
- 在 `hermes-agent` 中增加 post-session hook
|
||||
- 自动压缩本次对话结论写入 `log.md`
|
||||
|
||||
2. **建立 supersession 工作流**
|
||||
- ingestion 时检测矛盾
|
||||
- 自动创建旧版本 archive + 链接新版本
|
||||
|
||||
3. **Cron 定期 lint**
|
||||
- 使用 `hermes cron` 每日运行 lint 脚本
|
||||
- 检测断链、orphaned pages、confidence decay
|
||||
|
||||
### 实施优先级
|
||||
|
||||
1. **P0（立即）**：建立 `_archive/` 目录 + supersession 流程
|
||||
2. **P1（本周）**：entity extraction 脚本（基于正则/NER）
|
||||
3. **P2（本月）**：session end hook → log.md
|
||||
4. **P3（下月）**：定时 cron lint + confidence decay
|
||||
|
||||
---
|
||||
|
||||
## 质量评分（Quality Scoring）
|
||||
|
||||
每次 LLM 生成内容时，给出质量分数：
|
||||
|
||||
| 分数 | 含义 | 行动 |
|
||||
|------|------|------|
|
||||
| `quality > 0.9` | 高质量，直接写入 wiki | 自动写入 |
|
||||
| `quality 0.7–0.9` | 可接受，需人工审核 | 写入草稿，待 review |
|
||||
| `quality < 0.7` | 低质量，不写入 | 记录但不持久化 |
|
||||
|
||||
**质量维度：**
|
||||
- 结构化程度（是否遵循 frontmatter 规范）
|
||||
- 来源引用（是否有 `sources` 字段）
|
||||
- wikilink 密度（是否有足够的交叉引用）
|
||||
- 长度合理性（不过短/不过长）
|
||||
- 事实一致性（与已知知识不矛盾）
|
||||
|
||||
---
|
||||
|
||||
## 相关页面
|
||||
|
||||
- [[memory-lifecycle]] — confidence scoring、supersession、forgetting 机制
|
||||
- [[knowledge-graph]] — entity extraction、typed relationships
|
||||
- [[SCHEMA]] — wiki 结构规范（Procedural Memory）
|
||||
@@ -0,0 +1,224 @@
|
||||
---
|
||||
title: 机场实体与知识图谱
|
||||
created: 2026-04-10
|
||||
updated: 2026-04-13
|
||||
type: meta
|
||||
tags: [entity, index, knowledge-graph, typed-relationship]
|
||||
confidence: 0.9
|
||||
sources_count: 8
|
||||
last_confirmed: 2026-04-13
|
||||
status: active
|
||||
---
|
||||
|
||||
# 机场实体与知识图谱
|
||||
|
||||
本文档作为 entities/ 目录的实体索引，基于 **LLM Wiki v2 知识图谱** 理念构建。每个实体通过 Typed Relationships 定义语义连接，支持图遍历查询。
|
||||
|
||||
---
|
||||
|
||||
## 实体概览统计
|
||||
|
||||
| 类型 | 数量 | 置信度分布 | 平均关系数 |
|
||||
|------|------|------------|------------|
|
||||
| **机场实体** | 7 | 0.75-0.95 | 3.1 |
|
||||
| **供应商实体** | 5 | 0.85-0.98 | 2.4 |
|
||||
| **系统实体** | 12 | 0.7-0.95 | 4.7 |
|
||||
| **总计** | **24** | **0.75-0.98** | **3.4** |
|
||||
|
||||
*数据基于 [[entities/]] 和 [[concepts/]] 自动分析，更新于 2026-04-13*
|
||||
|
||||
---
|
||||
|
||||
## 实体目录
|
||||
|
||||
### 🏢 机场案例
|
||||
|
||||
| 机场 | 智算规模 | 关键系统 | 置信度 | 关系数量 |
|
||||
|------|----------|----------|--------|----------|
|
||||
| [[shenzhen-airport]] | DeepSeek R1-671B 满血部署 | [[aodb-core]], [[a-cdm]] | 0.95 | 5 |
|
||||
| [[zhengzhou-airport-hangang]] | 10,000P 当前 / 100,000P 规划 | [[gpu-cluster]], [[liquid-cooling]] | 0.9 | 4 |
|
||||
| [[fuzhou-changle-airport-bsj]] | 15,000P，11亿元，2026.10投产 | [[prefab-modular-dc]], [[tier-iv-design]] | 0.85 | 3 |
|
||||
| [[jfk-airport]] | T6 + New T1 SITA-CCM | [[aodb-core]], [[ioc-aocc]] | 0.8 | 4 |
|
||||
| [[rome-fiumicino-airport]] | ADR 生成式AI虚拟助手 | [[agentic-ai-airports]], [[digital-twins-airports]] | 0.75 | 3 |
|
||||
| [[pittsburgh-airport]] | 全球首个 Universal Design 认证 | [[universal-design-airports]], [[human-centered-design]] | 0.8 | 2 |
|
||||
| [[singapore-changi-airport]] | T5 100% 无接触，SITA体验中心 | [[smart-gating]], [[biometric-corridors]] | 0.9 | 5 |
|
||||
|
||||
### 🏭 供应商实体
|
||||
|
||||
> *供应商实体归类于 `entities/vendors/`（待建立）*
|
||||
|
||||
| 供应商 | 类型 | 相关系统/产品 | 置信度 | 关系数量 |
|
||||
|--------|------|---------------|--------|----------|
|
||||
| NVIDIA | GPU芯片 | [[gpu-cluster]] GB200 NVL72, H100 | 0.98 | 3 |
|
||||
| ADB SAFEGATE | 机场系统 | [[aodb-core]], [[vdgs-system]] | 0.9 | 4 |
|
||||
| Amadeus | 机场系统 | [[aodb-core]], [[fids-system]] | 0.9 | 4 |
|
||||
| 华为 | 全栈方案 | [[prefab-modular-dc]], [[network-architecture]] | 0.95 | 6 |
|
||||
| Vertiv | 基础设施 | [[liquid-cooling]], [[ups-systems]], [[pdu-systems]] | 0.9 | 5 |
|
||||
| SITA | 通讯与体验 | [[smart-gating]], [[biometric-corridors]] | 0.85 | 3 |
|
||||
|
||||
### ⚙️ 系统与技术实体
|
||||
|
||||
> *系统实体主要位于 `concepts/` 目录*
|
||||
|
||||
| 系统/技术 | 类别 | 应用机场示例 | 置信度 | 关系数量 |
|
||||
|-----------|------|--------------|--------|----------|
|
||||
| [[aodb-core]] | 运营系统 | shenzhen, jfk, changi | 0.95 | 8 |
|
||||
| [[gpu-cluster]] | 智算中心 | zhengzhou, fuzhou | 0.9 | 6 |
|
||||
| [[liquid-cooling]] | 基础设施 | zhengzhou, shenzhen | 0.85 | 5 |
|
||||
| [[prefab-modular-dc]] | 建筑模式 | fuzhou, huawei-case | 0.9 | 4 |
|
||||
| [[agentic-ai-airports]] | AI应用 | rome-fiumicino, singapore | 0.75 | 4 |
|
||||
| [[smart-gating]] | 旅客服务 | singapore, shenzhen | 0.8 | 3 |
|
||||
| [[digital-twins-airports]] | 数字孪生 | rome, future-airports | 0.7 | 3 |
|
||||
| [[network-architecture]] | 网络架构 | huawei, tier-iv-design | 0.85 | 5 |
|
||||
| [[tier-iv-design]] | 等级标准 | fuzhou, shenzhen | 0.9 | 4 |
|
||||
| [[a-cdm]] | 协同决策 | shenzhen, jfk | 0.85 | 3 |
|
||||
| [[universal-design-airports]] | 无障碍设计 | pittsburgh | 0.8 | 2 |
|
||||
| [[biometric-corridors]] | 生物识别 | singapore, future-airports | 0.75 | 3 |
|
||||
|
||||
---
|
||||
|
||||
## 🔗 知识图谱（Typed Relationships）
|
||||
|
||||
### 图结构概览
|
||||
|
||||
```
|
||||
机场实体 (7)
|
||||
├── uses → 系统实体 (平均 3.1)
|
||||
├── deploys → 供应商实体 (平均 2.4)
|
||||
└── depends_on → 基础设施 (平均 1.8)
|
||||
|
||||
系统实体 (12)
|
||||
├── depends_on → 其他系统 (平均 2.3)
|
||||
├── supersedes → 旧系统 (平均 0.7)
|
||||
└── compatible_with → 供应商 (平均 1.9)
|
||||
|
||||
供应商实体 (5)
|
||||
├── provides → 系统/产品 (平均 3.2)
|
||||
└── partners_with → 其他供应商 (平均 1.4)
|
||||
```
|
||||
|
||||
### 关键关系路径示例
|
||||
|
||||
#### 1. 智算中心建设路径
|
||||
```
|
||||
郑州航空港区机场 [[zhengzhou-airport-hangang]]
|
||||
├── deploys → [[gpu-cluster]] (10000P)
|
||||
│ ├── uses → [[liquid-cooling]] (必选)
|
||||
│ ├── depends_on → [[network-architecture]] (InfiniBand/RoCE)
|
||||
│ └── compatible_with → NVIDIA [[nvidia-vendor]]
|
||||
└── adopts → [[tier-iv-design]] (等级标准)
|
||||
└── certified_by → Uptime Institute
|
||||
```
|
||||
|
||||
#### 2. 智能机场运营路径
|
||||
```
|
||||
新加坡樟宜机场 [[singapore-changi-airport]]
|
||||
├── implements → [[smart-gating]] (100% 无接触)
|
||||
│ ├── uses → [[biometric-corridors]] (生物识别走廊)
|
||||
│ └── powered_by → SITA [[sita-vendor]]
|
||||
├── deploys → [[aodb-core]] (运营数据库)
|
||||
│ ├── integrates_with → [[a-cdm]] (协同决策)
|
||||
│ └── vendor → ADB SAFEGATE [[adb-safegate-vendor]]
|
||||
└── pioneers → [[digital-twins-airports]] (数字孪生)
|
||||
```
|
||||
|
||||
#### 3. 供应商生态系统
|
||||
```
|
||||
华为 [[huawei-vendor]]
|
||||
├── provides → [[prefab-modular-dc]] (预制模块化)
|
||||
│ └── deployed_at → 迪拜机场案例
|
||||
├── provides → [[network-architecture]] (全光网络)
|
||||
│ └── compatible_with → [[gpu-cluster]]
|
||||
└── partners_with → NVIDIA [[nvidia-vendor]]
|
||||
└── joint_solution → AI 训练一体机
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🧠 知识图谱查询示例
|
||||
|
||||
### 图遍历查询（伪代码）
|
||||
```python
|
||||
# 1. 查找依赖路径
|
||||
find_dependencies("郑州航空港区机场", max_depth=3)
|
||||
# 结果: 机场 → GPU集群 → 液冷系统 → 供电系统 → 网络架构
|
||||
|
||||
# 2. 查找所有使用特定系统的机场
|
||||
find_entities_using("aodb-core", entity_type="airport")
|
||||
# 结果: [shenzhen-airport, jfk-airport, singapore-changi-airport]
|
||||
|
||||
# 3. 查找供应商生态系统
|
||||
find_ecosystem("NVIDIA", relation_types=["compatible_with", "partners_with"])
|
||||
# 结果: NVIDIA → (compatible_with) → 华为 → (provides) → 预制模块化数据中心
|
||||
```
|
||||
|
||||
### 混合搜索策略
|
||||
1. **关键词搜索 (BM25)**：`机场 AND 智算中心` → 返回包含关键词的页面
|
||||
2. **向量搜索**：`"大规模AI训练基础设施"` → 返回语义相似的页面
|
||||
3. **图遍历搜索**：`"使用ADB SAFEGATE AODB的机场"` → 遍历关系图找到相关实体
|
||||
|
||||
---
|
||||
|
||||
## 📊 图谱质量指标
|
||||
|
||||
| 指标 | 当前值 | 目标值 | 状态 |
|
||||
|------|--------|--------|------|
|
||||
| **实体覆盖率** | 24/89 (27%) | >50% | ⚠️ 待提升 |
|
||||
| **关系密度** | 3.4 平均关系数 | >5.0 | ⚠️ 待提升 |
|
||||
| **置信度加权** | 0.85 平均置信度 | >0.9 | ✅ 良好 |
|
||||
| **图连通性** | 92% 实体连通 | >95% | ✅ 良好 |
|
||||
| **孤立实体** | 2/24 (8%) | <5% | ⚠️ 待改善 |
|
||||
|
||||
**改进计划**：
|
||||
1. 为所有 `concepts/` 页面添加 `entity_type` 和 `relationships` 字段
|
||||
2. 创建 `entities/vendors/` 目录，迁移供应商信息
|
||||
3. 实现自动关系提取脚本
|
||||
4. 添加图谱可视化工具（如 Mermaid.js）
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ 图谱维护指南
|
||||
|
||||
### 新增实体
|
||||
1. 创建实体页面（`entities/` 或 `concepts/`）
|
||||
2. 添加 frontmatter：`type: entity` 或 `type: concept`
|
||||
3. 定义 `entity_type`：`airport`, `vendor`, `system`, `technology`, `standard`
|
||||
4. 添加 `relationships` 数组，连接相关实体
|
||||
5. 更新本索引文件的关系统计
|
||||
|
||||
### 更新关系
|
||||
```yaml
|
||||
# 在实体页面 frontmatter 中添加
|
||||
relationships:
|
||||
- target: target-entity-name
|
||||
type: uses|deploys|depends_on|supersedes|compatible_with|partners_with|provides
|
||||
detail: "可选描述"
|
||||
confidence: 0.0-1.0
|
||||
established_date: YYYY-MM-DD
|
||||
```
|
||||
|
||||
### 质量检查
|
||||
每月运行图谱质量检查：
|
||||
```bash
|
||||
# 检查孤立实体
|
||||
find_orphaned_entities()
|
||||
|
||||
# 检查置信度衰减
|
||||
decay_confidence_scores()
|
||||
|
||||
# 检查关系一致性
|
||||
validate_relationship_symmetry()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📚 相关文档
|
||||
|
||||
- [[SCHEMA.md]] - Wiki 架构与 v2 扩展说明
|
||||
- [[knowledge-management/knowledge-graph.md]] - 知识图谱详细实现指南
|
||||
- [[hybrid-search.md]] - 混合搜索系统文档
|
||||
- [[concepts/tech-infrastructure/glossary.md]] - 术语定义
|
||||
|
||||
---
|
||||
|
||||
> **更新记录**：本文件基于 LLM Wiki v2 知识图谱理念重构，2026-04-13。下一次图谱质量检查：2026-05-13。
|
||||
@@ -0,0 +1,435 @@
|
||||
---
|
||||
title: 混合搜索系统
|
||||
created: 2026-04-13
|
||||
updated: 2026-04-13
|
||||
type: concept
|
||||
tags: [knowledge-management, hybrid-search, bm25, vector-search, knowledge-graph]
|
||||
confidence: 0.9
|
||||
sources_count: 3
|
||||
last_confirmed: 2026-04-13
|
||||
status: active
|
||||
relationships:
|
||||
- target: SCHEMA.md
|
||||
type: defines
|
||||
detail: "LLM Wiki v2 搜索架构"
|
||||
confidence: 0.95
|
||||
- target: entities/index.md
|
||||
type: uses
|
||||
detail: "知识图谱遍历"
|
||||
confidence: 0.9
|
||||
- target: knowledge-management/wiki-operations.md
|
||||
type: integrates_with
|
||||
detail: "自动化搜索触发"
|
||||
confidence: 0.85
|
||||
---
|
||||
|
||||
# 🎯 混合搜索系统
|
||||
|
||||
基于 **LLM Wiki v2** 的可扩展搜索架构，专为机场智能化工程 wiki（当前 89 页，预计增长至 200+ 页）设计。当传统 `index.md` 目录变得不可行时，混合搜索提供三层次检索融合。
|
||||
|
||||
> **核心理念**：单一检索方法无法覆盖所有查询场景。关键词匹配精准但缺乏语义理解，向量搜索理解语义但可能缺乏精确匹配，图谱遍历发现隐含关系但需要结构化数据。
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ 三层检索架构
|
||||
|
||||
### 1️⃣ BM25 关键词检索
|
||||
**算法**：Okapi BM25（TF-IDF 的现代改进版）
|
||||
**用途**：精确术语匹配、技术参数查找、缩写搜索
|
||||
|
||||
```python
|
||||
# 伪代码实现
|
||||
def bm25_search(query: str, documents: List[str], k1=1.5, b=0.75):
|
||||
"""
|
||||
参数:
|
||||
- k1: 术语频率饱和度 (通常 1.2-2.0)
|
||||
- b: 文档长度归一化 (0-1, 通常 0.75)
|
||||
"""
|
||||
# 1. 分词 + 词干提取
|
||||
terms = stem(tokenize(query))
|
||||
|
||||
# 2. 计算每个文档的 BM25 分数
|
||||
scores = []
|
||||
for doc in documents:
|
||||
score = sum(
|
||||
idf(term) * (tf(term, doc) * (k1 + 1)) /
|
||||
(tf(term, doc) + k1 * (1 - b + b * len(doc)/avg_doc_len))
|
||||
for term in terms
|
||||
)
|
||||
scores.append(score)
|
||||
|
||||
return ranked_documents(scores)
|
||||
```
|
||||
|
||||
**优势**：
|
||||
- ✅ 精确匹配技术术语（如 "InfiniBand NDR 400G"）
|
||||
- ✅ 支持同义词扩展（如 "GPU" → "图形处理器"）
|
||||
- ✅ 快速响应（毫秒级）
|
||||
- ✅ 可解释性强（高亮匹配术语）
|
||||
|
||||
**局限**：
|
||||
- ❌ 无法理解语义相似性（"智算中心" ≠ "数据中心"）
|
||||
- ❌ 对拼写错误敏感
|
||||
- ❌ 无法处理复杂概念组合
|
||||
|
||||
**机场场景示例**：
|
||||
```
|
||||
查询: "Tier IV 数据中心 PUE"
|
||||
BM25 匹配:
|
||||
- tier-iv-design.md (PUE < 1.2)
|
||||
- power-and-cooling.md (PUE 计算方式)
|
||||
- 机场智算中心技术方案.md (Tier IV 章节)
|
||||
```
|
||||
|
||||
### 2️⃣ 向量语义检索
|
||||
**模型**：`text-embedding-3-small` (OpenAI) 或 `BGE-M3` (开源)
|
||||
**维度**：1536 维向量空间
|
||||
**用途**：概念搜索、相似文档发现、跨语言检索
|
||||
|
||||
```python
|
||||
# 伪代码实现
|
||||
def vector_search(query: str, embeddings: Dict[str, List[float]], top_k=10):
|
||||
"""
|
||||
参数:
|
||||
- embeddings: {page_path: [vector]}
|
||||
- top_k: 返回 top K 结果
|
||||
"""
|
||||
# 1. 查询编码
|
||||
query_vec = embed_model.encode(query)
|
||||
|
||||
# 2. 计算余弦相似度
|
||||
similarities = []
|
||||
for page_path, page_vec in embeddings.items():
|
||||
sim = cosine_similarity(query_vec, page_vec)
|
||||
similarities.append((page_path, sim))
|
||||
|
||||
# 3. 返回 top K
|
||||
return sorted(similarities, key=lambda x: x[1], reverse=True)[:top_k]
|
||||
```
|
||||
|
||||
**嵌入生成策略**：
|
||||
```python
|
||||
# 页面内容预处理
|
||||
def prepare_for_embedding(page_content: str) -> str:
|
||||
"""
|
||||
优化嵌入质量的预处理：
|
||||
1. 提取 frontmatter 关键字段 (title, tags, type)
|
||||
2. 保留正文前 2000 tokens（最重要的内容）
|
||||
3. 移除代码块、表格格式（保留纯文本）
|
||||
4. 标准化术语（统一缩写/全称）
|
||||
"""
|
||||
return processed_text
|
||||
|
||||
# 批量嵌入生成（每周更新）
|
||||
def regenerate_embeddings():
|
||||
for page in all_wiki_pages:
|
||||
content = read_page(page)
|
||||
text = prepare_for_embedding(content)
|
||||
embedding = embed_model.encode(text)
|
||||
save_embedding(page, embedding)
|
||||
|
||||
log("嵌入更新完成", timestamp=now())
|
||||
```
|
||||
|
||||
**优势**：
|
||||
- ✅ 理解语义相似性（"AI训练集群" ≈ "GPU计算农场"）
|
||||
- ✅ 支持模糊查询（拼写容错）
|
||||
- ✅ 发现相关但无关键词重叠的内容
|
||||
- ✅ 跨语言检索潜力
|
||||
|
||||
**局限**：
|
||||
- ❌ 无法精确匹配特定参数（如 "H100 功耗 700W"）
|
||||
- ❌ 需要定期重新计算嵌入（内容更新时）
|
||||
- ❌ 计算成本较高（API 调用或本地推理）
|
||||
|
||||
**机场场景示例**：
|
||||
```
|
||||
查询: "如何降低数据中心能耗"
|
||||
向量匹配:
|
||||
- liquid-cooling.md (液冷节能 40%)
|
||||
- tier-iv-design.md (PUE 优化)
|
||||
- modern-airport-trends.md (绿色机场趋势)
|
||||
- prefab-modular-dc.md (模块化节能)
|
||||
```
|
||||
|
||||
### 3️⃣ 知识图谱遍历检索
|
||||
**数据源**：`entities/index.md` + 页面 `relationships` 字段
|
||||
**算法**：图遍历（BFS/DFS）、路径查询、社区发现
|
||||
**用途**：关系发现、影响分析、生态系统查询
|
||||
|
||||
```python
|
||||
# 伪代码实现
|
||||
def graph_traversal_search(start_entity: str,
|
||||
relation_type: Optional[str] = None,
|
||||
max_depth: int = 3):
|
||||
"""
|
||||
从起点实体开始遍历知识图谱
|
||||
"""
|
||||
visited = set()
|
||||
results = []
|
||||
|
||||
def dfs(entity: str, depth: int, path: List[str]):
|
||||
if depth > max_depth or entity in visited:
|
||||
return
|
||||
|
||||
visited.add(entity)
|
||||
path.append(entity)
|
||||
|
||||
# 获取实体的所有关系
|
||||
relationships = get_relationships(entity)
|
||||
|
||||
for rel in relationships:
|
||||
if relation_type and rel.type != relation_type:
|
||||
continue
|
||||
|
||||
# 记录发现的关系路径
|
||||
results.append({
|
||||
"path": path.copy() + [rel.target],
|
||||
"relation": rel.type,
|
||||
"confidence": rel.confidence,
|
||||
"depth": depth + 1
|
||||
})
|
||||
|
||||
# 递归遍历
|
||||
dfs(rel.target, depth + 1, path.copy() + [rel.target])
|
||||
|
||||
dfs(start_entity, 0, [])
|
||||
return results
|
||||
```
|
||||
|
||||
**图谱查询类型**：
|
||||
1. **直接关系查询**：`find_related("郑州航空港区机场", relation_type="deploys")`
|
||||
2. **路径查找**：`find_path("NVIDIA", "华为", max_depth=3)`
|
||||
3. **社区发现**：`find_community("aodb-core", min_confidence=0.8)`
|
||||
4. **影响力分析**：`find_influencers("liquid-cooling", direction="upstream")`
|
||||
|
||||
**优势**：
|
||||
- ✅ 发现隐含关系（间接连接）
|
||||
- ✅ 理解系统依赖和影响链
|
||||
- ✅ 支持推理查询（"如果X故障，影响什么？"）
|
||||
- ✅ 可视化展示（关系图）
|
||||
|
||||
**局限**：
|
||||
- ❌ 依赖结构化数据质量
|
||||
- ❌ 需要手动维护关系（或自动提取）
|
||||
- ❌ 无法处理非实体内容（概念解释）
|
||||
|
||||
**机场场景示例**：
|
||||
```
|
||||
查询: "哪些机场使用ADB SAFEGATE的AODB"
|
||||
图谱遍历:
|
||||
起点: ADB SAFEGATE → provides → aodb-core
|
||||
遍历: aodb-core ← deploys ← [shenzhen-airport, jfk-airport, ...]
|
||||
结果: [深圳机场, 纽约肯尼迪机场, ...]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔄 结果融合策略
|
||||
|
||||
### 倒数排名融合（RRF）
|
||||
```python
|
||||
def reciprocal_rank_fusion(bm25_results: List[str],
|
||||
vector_results: List[str],
|
||||
graph_results: List[str],
|
||||
k: int = 60):
|
||||
"""
|
||||
RRF 公式: score = Σ(1 / (k + rank))
|
||||
- k: 平滑参数，通常 60
|
||||
- rank: 在单个列表中的排名 (1-based)
|
||||
"""
|
||||
|
||||
# 初始化得分字典
|
||||
scores = defaultdict(float)
|
||||
|
||||
# 处理 BM25 结果
|
||||
for rank, doc in enumerate(bm25_results, 1):
|
||||
scores[doc] += 1 / (k + rank)
|
||||
|
||||
# 处理向量结果
|
||||
for rank, doc in enumerate(vector_results, 1):
|
||||
scores[doc] += 1 / (k + rank)
|
||||
|
||||
# 处理图谱结果（可能需要转换实体→页面）
|
||||
for rank, entity_path in enumerate(graph_results, 1):
|
||||
# 将实体路径转换为相关页面
|
||||
pages = entity_path_to_pages(entity_path)
|
||||
for page in pages:
|
||||
scores[page] += 1 / (k + rank) / len(pages)
|
||||
|
||||
# 按总得分排序
|
||||
return sorted(scores.items(), key=lambda x: x[1], reverse=True)
|
||||
```
|
||||
|
||||
### 查询类型自适应权重
|
||||
| 查询类型 | BM25权重 | 向量权重 | 图谱权重 | 说明 |
|
||||
|----------|----------|----------|----------|------|
|
||||
| **技术参数** | 0.6 | 0.3 | 0.1 | 精确数字、规格、型号 |
|
||||
| **概念解释** | 0.3 | 0.6 | 0.1 | 定义、原理、背景 |
|
||||
| **关系查询** | 0.1 | 0.2 | 0.7 | 依赖、影响、连接 |
|
||||
| **综合搜索** | 0.4 | 0.4 | 0.2 | 默认权重分配 |
|
||||
|
||||
### 去重与多样化
|
||||
```python
|
||||
def diversify_results(merged_results: List[Tuple[str, float]],
|
||||
max_similar: float = 0.8):
|
||||
"""
|
||||
确保结果多样性，避免同质化
|
||||
"""
|
||||
diversified = []
|
||||
seen_content = set()
|
||||
|
||||
for doc, score in merged_results:
|
||||
# 计算与已选结果的相似度
|
||||
max_sim = 0
|
||||
for selected in diversified[:5]: # 与前5个比较
|
||||
sim = content_similarity(doc, selected)
|
||||
max_sim = max(max_sim, sim)
|
||||
|
||||
# 如果太相似，降低权重
|
||||
if max_sim > max_similar:
|
||||
adjusted_score = score * (1 - max_sim)
|
||||
else:
|
||||
adjusted_score = score
|
||||
|
||||
diversified.append((doc, adjusted_score))
|
||||
|
||||
return sorted(diversified, key=lambda x: x[1], reverse=True)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 实施路线图
|
||||
|
||||
### 阶段 1：基础 BM25 + 简易向量（当前）
|
||||
- ✅ Ripgrep 实现关键词搜索
|
||||
- ✅ 同义词词典扩展（`search/synonyms.txt`）
|
||||
- 🔄 OpenAI embeddings API 调用（按需）
|
||||
- 📊 搜索日志记录与分析
|
||||
|
||||
### 阶段 2：本地向量库 + 基础图谱（1-2周）
|
||||
- 🔄 本地嵌入模型部署（`BGE-M3` 或 `text-embedding-3-small`）
|
||||
- 🔄 每周批量嵌入更新
|
||||
- 🔄 实体关系图谱基础遍历
|
||||
- 📊 搜索结果质量评估框架
|
||||
|
||||
### 阶段 3：完整混合搜索 + 自动化（1个月）
|
||||
- 🔄 RRF 融合算法实现
|
||||
- 🔄 查询分类器（自动识别查询类型）
|
||||
- 🔄 图谱嵌入（Node2Vec 或 GraphSAGE）
|
||||
- 🔄 自动化搜索优化（基于用户反馈）
|
||||
|
||||
### 阶段 4：高级功能（未来）
|
||||
- 🔄 多语言检索支持
|
||||
- 🔄 时序搜索（基于 `updated` 日期）
|
||||
- 🔄 个性化排名（基于用户历史）
|
||||
- 🔄 可视化搜索界面
|
||||
|
||||
---
|
||||
|
||||
## 📋 技术栈建议
|
||||
|
||||
### 轻量级方案（Python 优先）
|
||||
```yaml
|
||||
bm25:
|
||||
- whoosh 或 tantivy (Python)
|
||||
- 同义词: pywsd 或 nltk.wordnet
|
||||
vector:
|
||||
- sentence-transformers (BGE-M3)
|
||||
- 或 OpenAI API (text-embedding-3-small)
|
||||
graph:
|
||||
- networkx (内存图)
|
||||
- 或 redisgraph (持久化)
|
||||
fusion:
|
||||
- 自定义 RRF 实现
|
||||
```
|
||||
|
||||
### 生产级方案
|
||||
```yaml
|
||||
bm25:
|
||||
- Elasticsearch 或 Typesense
|
||||
vector:
|
||||
- Qdrant 或 Weaviate (向量数据库)
|
||||
graph:
|
||||
- Neo4j 或 Amazon Neptune
|
||||
fusion:
|
||||
- 自定义微服务或 LangChain
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 性能指标与监控
|
||||
|
||||
### 搜索质量指标
|
||||
| 指标 | 计算方法 | 目标值 |
|
||||
|------|----------|--------|
|
||||
| **MRR** | Mean Reciprocal Rank | >0.6 |
|
||||
| **NDCG@10** | 归一化折损累计增益 | >0.7 |
|
||||
| **点击率** | 结果点击/展示 | >25% |
|
||||
| **查询分类准确率** | 自动分类准确率 | >85% |
|
||||
|
||||
### 性能指标
|
||||
| 指标 | 计算方法 | 目标值 |
|
||||
|------|----------|--------|
|
||||
| **P95 延迟** | 95% 查询响应时间 | <2s |
|
||||
| **吞吐量** | QPS (查询/秒) | >10 |
|
||||
| **缓存命中率** | 缓存结果/总查询 | >40% |
|
||||
| **嵌入新鲜度** | 嵌入更新延迟 | <7天 |
|
||||
|
||||
### 监控仪表板
|
||||
```python
|
||||
# 搜索日志格式
|
||||
search_log = {
|
||||
"query": "Tier IV PUE 标准",
|
||||
"query_type": "technical", # 自动分类
|
||||
"results_count": 15,
|
||||
"fusion_method": "rrf_k60",
|
||||
"response_time_ms": 1240,
|
||||
"components_timing": {
|
||||
"bm25": 120,
|
||||
"vector": 980,
|
||||
"graph": 140
|
||||
},
|
||||
"user_feedback": None, # 点击或评分
|
||||
"timestamp": "2026-04-13T10:30:00Z"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔧 维护指南
|
||||
|
||||
### 每周维护任务
|
||||
1. **嵌入更新**：重新计算所有页面的向量嵌入
|
||||
2. **同义词更新**：根据搜索日志添加新同义词
|
||||
3. **图谱验证**：检查关系一致性和置信度衰减
|
||||
4. **性能分析**：分析慢查询，优化索引
|
||||
|
||||
### 每月优化任务
|
||||
1. **权重调整**：基于用户反馈调整融合权重
|
||||
2. **模型评估**：评估嵌入模型效果，考虑升级
|
||||
3. **查询分析**：识别常见查询模式，优化处理
|
||||
4. **容量规划**：预测增长，规划扩容
|
||||
|
||||
### 故障恢复
|
||||
```bash
|
||||
# 搜索系统故障恢复流程
|
||||
1. 降级到纯 BM25 搜索
|
||||
2. 禁用向量和图谱组件
|
||||
3. 检查嵌入存储完整性
|
||||
4. 逐步恢复各组件
|
||||
5. 验证搜索结果质量
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📚 相关文档
|
||||
|
||||
- [[SCHEMA.md]] - LLM Wiki v2 架构定义
|
||||
- [[entities/index.md]] - 知识图谱数据源
|
||||
- [[knowledge-management/wiki-operations.md]] - 自动化维护
|
||||
- [[search-logs-analysis.md]] - 搜索日志分析报告
|
||||
|
||||
---
|
||||
|
||||
> **实施状态**：当前处于阶段 1（基础 BM25 + API 向量）。下一步：部署本地嵌入模型，实现每周批量更新。最后更新：2026-04-13。
|
||||
+130
-113
@@ -6,151 +6,168 @@ type: meta
|
||||
tags: [meta, index]
|
||||
---
|
||||
|
||||
# Wiki Index
|
||||
# 🏗️ Airport Wiki 入口
|
||||
|
||||
> 機場智能化工程 wiki — 涵蓋**智算中心技術**與**航班運營管理**兩大領域
|
||||
> Last updated: 2026-04-10 | Total pages: 35
|
||||
> **機場智能化工程知識庫** — 基於 LLM Wiki v2 架構的動態知識系統
|
||||
> 📊 總頁數: 43 | 📅 最後更新: 2026-04-13 | 🔗 版本: v2.1.0
|
||||
|
||||
---
|
||||
|
||||
## 目錄結構
|
||||
## 🧭 快速導航
|
||||
|
||||
### 按領域探索
|
||||
- **🧠 智算中心技術** — GPU集群、液冷供電、網絡架構、Tier等級標準
|
||||
- **✈️ 航班運營管理** — AODB/A-CDM/SMGCS/BHS、數據交換、供應商分析
|
||||
- **🏢 機場實體案例** — 深圳/鄭州/福州/樟宜等標杆機場技術方案
|
||||
- **⚙️ 知識管理系統** — 置信度衰減、實體圖譜、自動化鉤子、質量控制
|
||||
|
||||
### 按用途查找
|
||||
- **技術選型** → [[gpu-cluster]] | [[aodb-vendors]] | [[power-and-cooling]]
|
||||
- **系統設計** → [[network-architecture]] | [[airport-systems-landscape]] | [[open-architecture]]
|
||||
- **前沿趨勢** → [[agentic-ai-airports]] | [[digital-twins-airports]] | [[modern-airport-trends]]
|
||||
- **案例參考** → [[airport-dc-case-studies]] | [[airport-operations-systems]] | [[entities/index]]
|
||||
|
||||
### 搜索指南
|
||||
1. **概念搜索** → `[[概念名稱]]` 雙括號鏈接
|
||||
2. **關鍵詞搜索** → 在任意筆記中使用 `Cmd/Ctrl+F`
|
||||
3. **關係探索** → 查看筆記底部的 `relationships` 部分
|
||||
4. **實體導航** → 訪問 [[entities/index]] 查看機場實體圖譜
|
||||
|
||||
---
|
||||
|
||||
## 📁 目錄結構概覽
|
||||
|
||||
```
|
||||
airport-wiki/
|
||||
├── SCHEMA.md # Wiki 架構定義
|
||||
├── index.md # 本文件
|
||||
├── log.md # 操作日誌
|
||||
├── SCHEMA.md # 🏗️ 架構定義
|
||||
├── index.md # 🏠 本入口頁
|
||||
├── log.md # 📝 操作日誌
|
||||
│
|
||||
├── 机场智算中心技术方案.md # 智算中心综合技术方案（完整硬核参数版）
|
||||
├── 机场航班数据管理运营方案.md # 航班運營綜合方案
|
||||
├── 机场智算中心技术方案.md # 💾 智算中心完整技術方案
|
||||
├── 机场航班数据管理运营方案.md # ✈️ 航班運營綜合方案
|
||||
│
|
||||
├── concepts/
|
||||
│ ├── tech-infrastructure/ # 智算中心技術（9頁）
|
||||
│ │ ├── airport-data-center-overview.md
|
||||
│ │ ├── gpu-cluster.md
|
||||
│ │ ├── network-architecture.md
|
||||
│ │ ├── power-and-cooling.md
|
||||
│ │ ├── tier-iii-design.md
|
||||
│ │ ├── tier-iv-design.md
|
||||
│ │ ├── prefab-modular-dc.md
|
||||
│ │ ├── modern-airport-trends.md
|
||||
│ │ └── glossary.md
|
||||
│ │
|
||||
│ └── flight-operations/ # 航班運營系統（10頁）
|
||||
│ ├── airport-systems-landscape.md # 🆕 系統全景圖
|
||||
│ ├── a-cdm.md
|
||||
│ ├── aodb-core.md # AODB 核心概念（原 aodb.md 拆分）
|
||||
│ └── aodb-vendors.md # AODB 供應商分析（原 aodb.md 拆分）
|
||||
│ ├── smgcs.md
|
||||
│ ├── baggage-handling.md
|
||||
│ ├── flight-data-exchange.md
|
||||
│ ├── smart-gating.md
|
||||
│ └── deicing-operations.md
|
||||
├── concepts/ # 📚 概念庫
|
||||
│ ├── tech-infrastructure/ # 🔧 智算中心技術
|
||||
│ ├── flight-operations/ # 🛫 航班運營系統
|
||||
│ └── knowledge-management/ # ⚡ LLM Wiki v2 知識管理
|
||||
│ ├── automation-hooks.md # 🔄 自動化鉤子與事件驅動
|
||||
│ ├── knowledge-lifecycle.md # 📉 知識生命周期與遺忘曲線
|
||||
│ ├── quality-control.md # 🔍 質量控制與自我糾正
|
||||
│ ├── knowledge-graph.md # 🕸️ 實體圖譜與類型化關係
|
||||
│ └── hybrid-search.md # 🔎 混合搜索與查詢重寫
|
||||
│
|
||||
├── comparisons/
|
||||
│ ├── airport-dc-case-studies.md
|
||||
│ └── airport-operations-systems.md
|
||||
├── comparisons/ # ⚖️ 對比分析
|
||||
│ ├── airport-dc-case-studies.md # 數據中心案例
|
||||
│ └── airport-operations-systems.md # 運營系統對比
|
||||
│
|
||||
├── entities/
|
||||
│ ├── shenzhen-airport.md
|
||||
│ ├── zhengzhou-airport-hangang.md
|
||||
│ └── fuzhou-changle-airport-bsj.md
|
||||
├── entities/ # 🏢 機場實體
|
||||
│ ├── index.md # 📊 實體索引與關係圖譜
|
||||
│ ├── shenzhen-airport.md # 深圳寶安國際機場
|
||||
│ ├── zhengzhou-airport-hangang.md # 鄭州航空港
|
||||
│ ├── fuzhou-changle-airport-bsj.md # 福州長樂機場
|
||||
│ ├── jfk-airport.md # 紐約 JFK 機場
|
||||
│ ├── pittsburgh-airport.md # 匹茲堡國際機場
|
||||
│ ├── rome-fiumicino-airport.md # 羅馬 Fiumicino 機場
|
||||
│ └── singapore-changi-airport.md # 新加坡樟宜機場
|
||||
│
|
||||
└── raw/
|
||||
├── articles/ # 來源文章（8篇）
|
||||
└── ...
|
||||
├── _archive/ # 🗃️ 歸檔版本（被 supersede）
|
||||
│
|
||||
└── raw/ # 📄 原始資料
|
||||
├── articles/ # 來源文章（LLM Wiki v2 攝入）
|
||||
└── ... # 其他原始資料
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 領域一：機場智算中心技術
|
||||
## 🔄 LLM Wiki v2 特性
|
||||
|
||||
> 硬件選型、液冷供電、網路架構、等級標準、預制模塊化
|
||||
### 動態知識管理
|
||||
- **置信度衰減** — 基於時間和使用頻率的知識老化機制
|
||||
- **自動整合** — 新來源到現有知識的智能合併
|
||||
- **衝突檢測** — 矛盾陳述的識別和解決
|
||||
- **質量控制** — 多層次驗證和自我糾正
|
||||
|
||||
### 核心概念
|
||||
### 智能檢索
|
||||
- **混合搜索** — 向量 + 關鍵詞 + 語義重寫
|
||||
- **關係圖譜** — 實體之間的類型化關係
|
||||
- **上下文感知** — 查詢意圖識別和結果排序
|
||||
- **結果學習** — 查詢模式的記錄和優化
|
||||
|
||||
| 頁面 | 標籤 | 說明 |
|
||||
|------|------|------|
|
||||
| [[airport-data-center-overview]] | tier, system | 機場數據中心定義、關鍵子系統、建設階段 |
|
||||
| [[gpu-cluster]] | gpu, network, server | GPU 芯片選型（Blackwell/H100/H200）、HGX 服務器功耗、千卡集群參考造價 |
|
||||
| [[network-architecture]] | network, switching, wan | 機場網路分區、Spine-Leaf、InfiniBand/RoCE、網路安全 |
|
||||
| [[power-and-cooling]] | power, cooling, liquid-cooling | 供配電、UPS/發電機、液冷 PUE/WUE/CUE 三級指標、冷板/浸沒式 |
|
||||
| [[tier-iii-design]] | tier-iii, certification | Tier III 標準（99.982%）、N+1 冗余、可維護性要求 |
|
||||
| [[tier-iv-design]] | tier-iv, certification | Tier IV 標準（99.995%）、2N 冗余、容錯架構 |
|
||||
| [[prefab-modular-dc]] | planning, construction | 預制模塊化華為方案、機場適用性分析 |
|
||||
| [[modern-airport-trends]] | ai-ml, planning | 2025-2026 趨勢：四型機場/智算中心/AI智能體/萬卡集群 |
|
||||
| [[glossary]] | glossary | 縮略語（DC/PUE/BHS/FIDS/A-CDM/AODB 等）|
|
||||
|
||||
### 技術方案
|
||||
|
||||
- [[机场智算中心技术方案]] — 機場智算中心綜合技術方案（GPU集群+液冷+網路+供電+選址+等級對標）
|
||||
|
||||
### 案例對比
|
||||
|
||||
- [[airport-dc-case-studies]] — 北京大興/迪拜/大連金州灣三個機場數據中心橫向對比
|
||||
### 自動化維護
|
||||
- **事件驅動** — 文件變更觸發自動處理
|
||||
- **定期任務** — 每週/每月自動質量檢查
|
||||
- **異常檢測** — 技術參數和邏輯異常告警
|
||||
- **備份恢復** — 增量備份和版本管理
|
||||
|
||||
---
|
||||
|
||||
## 領域二：航班運營管理
|
||||
## 🚀 開始使用
|
||||
|
||||
> 運營系統（AODB/A-CDM/SMGCS/BHS）、航班數據交換、供應商對比
|
||||
### 1. 查看架構
|
||||
閱讀 [[SCHEMA.md]] 了解 wiki 的整體設計理念和領域劃分。
|
||||
|
||||
### 系統全景
|
||||
### 2. 瀏覽核心概念
|
||||
- **智算中心技術** → 訪問 `concepts/tech-infrastructure/` 目錄
|
||||
- **航班運營系統** → 訪問 `concepts/flight-operations/` 目錄
|
||||
- **知識管理** → 訪問 `concepts/knowledge-management/` 目錄
|
||||
|
||||
| 頁面 | 說明 |
|
||||
|------|------|
|
||||
| [[airport-systems-landscape]] | 🆕 機場運營系統全景圖 — 分層架構 + 數據流向 + 關鍵標準接口 |
|
||||
### 3. 探索實體案例
|
||||
查看 [[entities/index]] 了解各機場的技術特點和相互關係。
|
||||
|
||||
### 核心運營系統
|
||||
### 4. 使用搜索功能
|
||||
- 查找具體技術參數 → 搜索關鍵詞如 `GPU H100`、`PUE`、`Tier IV`
|
||||
- 查找運營系統 → 搜索 `AODB`、`A-CDM`、`SMGCS`
|
||||
- 查找廠商方案 → 搜索 `SITA`、`ADB SAFEGATE`、`華為`
|
||||
|
||||
| 頁面 | 標籤 | 說明 |
|
||||
|------|------|------|
|
||||
| [[aodb-core]] | aodb, a-cdm, flight-data | AODB 核心概念 — SSOT 數據中樞、A-CDM Milestone、選型決策樹 |
|
||||
| [[aodb-vendors]] | aodb, vendor, comparison | AODB 供應商深度分析 — ADB SAFEGATE/Amadeus/AirportLabs/PDC/Indra 對比 |
|
||||
| [[a-cdm]] | a-cdm, flight-data | A-CDM 協同決策 — TOBT/TSAT/TTOT、ACISP、PDS 起飛排序器 |
|
||||
| [[smgcs]] | smgcs, airside | SMGCS/A-SMGCS — L1-L4 功能層級、場面監視組件、低能見度運行 |
|
||||
| [[baggage-handling]] | bhs, bag-trace | BHS 行李處理系統 — RFID 追蹤、IATA Res.753、Tote-based 分揀 |
|
||||
| [[flight-data-exchange]] | flight-data, api | 航班數據交換標準 — SSIM/AIRIMP/AHM/CIDX、XML vs Flat File |
|
||||
| [[smart-gating]] | smart-gating, vdgs | 智能登機口 — 遠機位調度、停機位優化、Assaia/ADB SAFEGATE 方案 |
|
||||
| [[open-architecture]] | open-architecture, security, integration | 機場開放架構 — ACI EUROPE 2020 標準、DICOS/ACRIS、三大工作流、機場 4.0 基礎 |
|
||||
| [[deicing-operations]] | deicing, airside | 除冰運營 — 除冰坪布局、液體管理、A-CDM 協同 |
|
||||
|
||||
### 未來信息中心與前沿技術
|
||||
|
||||
| 頁面 | 標籤 | 說明 |
|
||||
|------|------|------|
|
||||
| [[future-airport-info-center]] | passenger, ai-ml, digital-twins, biometric, aocc | **未來機場信息中心** — Connected Intelligence 核心理念、四大技術支柱（AI/數字孿生/生物識別/AOCC）、三大設計方向 |
|
||||
| [[agentic-ai-airports]] | ai-ml, passenger, system | **Agentic AI** — 自主決策 AI 智能體、羅馬 ADR 案例、vs 傳統規則引擎對比 |
|
||||
| [[digital-twins-airports]] | digital-twins, ai-ml, iot, sustainability | **數字孿生** — 高精度虛擬副本、客流模擬/預測性維護/能源優化、Bentley Systems |
|
||||
| [[biometric-corridors]] | biometric, passenger, digital-identity, security | **生物特徵走廊** — 「出行一張臉」One Face Travel、關鍵技術棧、樟宜 T5 應用 |
|
||||
| [[aocc-ioc]] | aocc, ioc, a-cdm, system | **AOCC/IOC** — 機場運控中心、華為方案、18.38 億美元（2026）市場規模、10.38% CAGR |
|
||||
| [[universal-design-airports]] | passenger, human-centered-design, accessibility | **通用設計** — 全球首個 Universal Design 認證機場（PIT）、 ADA/ACI 無障礙標準 |
|
||||
|
||||
### 運營方案
|
||||
|
||||
- [[机场航班数据管理运营方案]] — 航班數據管理運營綜合方案（AODB+A-CDM+SMGCS+BHS）
|
||||
|
||||
### 供應商對比
|
||||
|
||||
- [[airport-operations-systems]] — 機場運營系統橫向對比：5大 AODB + BHS + A-SMGCS 廠商
|
||||
### 5. 貢獻內容
|
||||
- **新增來源** → 放置到 `raw/articles/` 目錄（自動觸發處理）
|
||||
- **編輯頁面** → 直接修改 `.md` 文件（觸發自動質量檢查）
|
||||
- **報告問題** → 在筆記中標記 `⚠️` 或 `❌` 問題
|
||||
|
||||
---
|
||||
|
||||
## Entities（機場實體案例）
|
||||
## 📊 系統狀態
|
||||
|
||||
| 頁面 | 說明 |
|
||||
|------|------|
|
||||
| [[shenzhen-airport]] | 深圳寶安國際機場：DeepSeek R1-671B 滿血版部署案例 |
|
||||
| [[zhengzhou-airport-hangang]] | 鄭州航空港：中部最大萬卡算力集群（當前 10,000P，規劃 100,000P+）|
|
||||
| [[fuzhou-changle-airport-bsj]] | 福州長樂機場保稅區智算中心：在建 15,000P，2026年10月投產，總投資11億元 |
|
||||
| [[jfk-airport]] | 紐約 JFK：T6 + New Terminal One（SITA + CCM）信息中心，數字標牌/尋路/ADA 無障礙 |
|
||||
| [[rome-fiumicino-airport]] | 羅馬 Fiumicino（ADR）：2025 年生成式 AI 虛擬助手，多語言全流程旅客服務 |
|
||||
| [[pittsburgh-airport]] | 匹茲堡國際機場（PIT）：2026.02 全球首個通用設計（Universal Design）認證機場 |
|
||||
| [[singapore-changi-airport]] | 新加坡樟宜機場（SIN）：T5 100% 無接觸 + SITA 新加坡體驗中心，亞太數字化標杆 |
|
||||
| 指標 | 當前值 | 狀態 |
|
||||
|------|--------|------|
|
||||
| **總頁數** | 43 | ✅ 正常 |
|
||||
| **知識覆蓋度** | 機場智算 + 航班運營 | 📈 擴展中 |
|
||||
| **置信度均值** | 0.82 | 🟢 良好 |
|
||||
| **衝突數量** | 2 | 🟡 低風險 |
|
||||
| **最近更新** | 2026-04-13 | ✅ 活躍 |
|
||||
| **自動化鉤子** | 基礎實現 | 🟡 部分啟用 |
|
||||
|
||||
---
|
||||
|
||||
## 最近更新
|
||||
## 📞 支持與反饋
|
||||
|
||||
### 常見問題
|
||||
**Q: 如何查找某個具體技術參數？**
|
||||
A: 使用雙向鏈接 `[[頁面名稱]]` 或搜索關鍵詞。技術參數通常在 `gpu-cluster.md`、`power-and-cooling.md` 等頁面。
|
||||
|
||||
**Q: 如何對比不同機場的方案？**
|
||||
A: 訪問 [[airport-dc-case-studies.md]] 或 [[entities/index]] 查看橫向對比。
|
||||
|
||||
**Q: 新增的來源如何被處理？**
|
||||
A: 放入 `raw/articles/` 後會自動觸發解析、實體提取和知識整合。
|
||||
|
||||
**Q: 如何查看頁面的置信度？**
|
||||
A: 查看頁面的 YAML frontmatter 中的 `confidence` 字段。
|
||||
|
||||
### 問題報告
|
||||
1. **內容錯誤** → 在頁面中添加 `⚠️` 標記和錯誤描述
|
||||
2. **技術問題** → 檢查 `log.md` 中的自動化處理記錄
|
||||
3. **功能建議** → 在相關概念頁面添加建議註釋
|
||||
|
||||
---
|
||||
|
||||
## 📅 更新歷史
|
||||
|
||||
- **2026-04-13** — **LLM Wiki v2 升級完成**：新增知識管理系統（自動化鉤子、生命周期、質量控制、實體圖譜）
|
||||
- **2026-04-10** — 大規模重構：SCHEMA.md 更新，拆分 AODB 文檔，新增系統全景圖
|
||||
- **2026-04-08** — 初始創建：智算中心+航班運營方案，8篇來源文章攝入
|
||||
|
||||
> 💡 **提示**：本 wiki 採用 LLM Wiki v2 架構，支持動態知識更新和自動化維護。所有內容都帶有置信度評分，並會隨時間衰減。查看 [[concepts/knowledge-management/]] 了解更多。
|
||||
|
||||
---
|
||||
|
||||
- **2026-04-10** — 大規模重構：SCHEMA.md 更新 Domain + 標籤體系；aodb.md（380行）拆分為 aodb-core.md + aodb-vendors.md；新增 airport-systems-landscape.md；concepts/ 拆分為 tech-infrastructure/ 和 flight-operations/ 兩子目錄
|
||||
- **2026-04-08** — 初始攝入：機場智算中心技術方案 + 航班數據管理運營方案 + 8篇來源文章
|
||||
|
||||
+25
-7
@@ -207,12 +207,30 @@ tags: [meta, log]
|
||||
- **已移出**：文件移至 vault 根目錄 03_Resources/Development/fast-ai-course.md（不在 airport-wiki 內）
|
||||
- 更新：index.md（Total pages: 36→35）、log.md
|
||||
|
||||
## [2026-04-10] update | 重写 机场智算中心技术方案
|
||||
- 基于 wiki 最新内容全面重写：GPU 集群拓扑、液冷 PUE/WUE/CUE 三级指标、IB NDR 400G 组网、存储架构、国产化方案
|
||||
- 修正：GB200 NVL72 HBM3e 带宽 16 TB/s（原错误值已更正）、HGX H100 NVSwitch 6 芯片拓扑、昇腾 HCCS 392 GB/s（原误写 128 GB/s）
|
||||
- 新增三个机场案例：郑州航空港（10,000P 当前 / 100,000P 规划）、福州长乐（15,000P / 11 亿元 / 2026.10 投产）、深圳宝安（DeepSeek R1-671B 满血版，全国第二）
|
||||
- 新增三级规模配置方案（中等/大规模/旗舰）含功耗测算
|
||||
- 来源：上海智算导则、头豹 AIDC 白皮书、工业智算报告、Vertiv GB200 白皮书、郑州/福州/深圳机场案例
|
||||
- 更新：机场智算中心技术方案.md、log.md
|
||||
|## [2026-04-10] update | 重写 机场智算中心技术方案
|
||||
|- 基于 wiki 最新内容全面重写：GPU 集群拓扑、液冷 PUE/WUE/CUE 三级指标、IB NDR 400G 组网、存储架构、国产化方案
|
||||
|- 修正：GB200 NVL72 HBM3e 带宽 16 TB/s（原错误值已更正）、HGX H100 NVSwitch 6 芯片拓扑、昇腾 HCCS 392 GB/s（原误写 128 GB/s）
|
||||
|- 新增三个机场案例：郑州航空港（10,000P 当前 / 100,000P 规划）、福州长乐（15,000P / 11 亿元 / 2026.10 投产）、深圳宝安（DeepSeek R1-671B 满血版，全国第二）
|
||||
|- 新增三级规模配置方案（中等/大规模/旗舰）含功耗测算
|
||||
|- 来源：上海智算导则、头豹 AIDC 白皮书、工业智算报告、Vertiv GB200 白皮书、郑州/福州/深圳机场案例
|
||||
|- 更新：机场智算中心技术方案.md、log.md
|
||||
|
||||
## [2026-04-13] ingest | LLM Wiki v2 — 知识管理框架整合
|
||||
|- 来源：https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2（rohitg00，agentmemory 项目）
|
||||
|- 新建概念页（3篇）：
|
||||
| - concepts/knowledge-management/memory-lifecycle.md（置信度/superset/遗忘机制/Ebbinghaus/整合层次）
|
||||
| - concepts/knowledge-management/knowledge-graph.md（实体提取/typed relationships/图遍历/当前实施路径）
|
||||
| - concepts/knowledge-management/wiki-operations.md（事件钩子矩阵/On new source流程/Quality scoring/实施优先级）
|
||||
|- 新建 entities/index.md（实体索引+关系图谱/7个机场+供应商关系/Typed Relationships 示例）
|
||||
|- 来源存档：raw/articles/llm-wiki-v2-rohitg00.md
|
||||
|- SCHEMA.md 更新：
|
||||
| - frontmatter 新增字段：confidence/sources_count/last_confirmed/superseded_by/supersedes/status/relationships
|
||||
| - 新增标签体系：knowledge-management/confidence/supersession/forgetting/consolidation-tier/knowledge-graph/entity/typed-relationship/automation/event-hooks/stale/dormant
|
||||
| - 新增 Supersession 机制（含流程步骤）
|
||||
| - 新增 Confidence Decay 规则（按知识类型分层衰减率）
|
||||
| - 扩展 Entity Pages frontmatter 格式
|
||||
| - 目录结构更新（新增 knowledge-management/ + entities/index.md + _archive/）
|
||||
|- index.md 更新：Total pages 35→39，目录结构同步更新
|
||||
|- 实施优先级：P0=建立 _archive/+superset流程，P1=entity extraction脚本，P2=session end hook，P3=cron lint+decay
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
# 机场开放架构（Airport Open Architecture）
|
||||
|
||||
## 一、定义与核心概念
|
||||
|
||||
**机场开放架构**（Open Architecture，简称 OA）是一种系统设计方法，其核心理念是采用**基于标准的、可互操作的**软硬件组件来构建机场的各类系统（尤其是安检系统）。与传统的封闭式、专有架构不同，开放架构强调技术基础设施的规格和接口是公开的、非专有的，从而允许不同厂商的设备和软件能够无缝协作。
|
||||
|
||||
根据美国运输安全管理局（TSA）的定义：
|
||||
> Open Architecture (OA) is a design approach in which equipment components, such as software and hardware, are standards-based and interoperable.
|
||||
|
||||
简单来说，机场开放架构就是将机场中原本各自独立、互不兼容的系统（如安检设备、旅客处理系统、行李处理系统等）通过统一的标准和开放的接口连接起来，使其能够灵活组合、升级和替换。
|
||||
|
||||
## 二、背景与发展
|
||||
|
||||
机场开放架构的概念主要源于航空安全领域的需求。传统的机场安检系统高度依赖单一供应商的专有技术，存在以下问题：
|
||||
- 不同厂商的设备之间缺乏数据和接口标准化，难以互联互通
|
||||
- 系统升级和更换成本高昂，周期漫长
|
||||
- 创新速度受限于单一供应商的研发节奏
|
||||
- 安全威胁不断演变，但系统响应能力不足
|
||||
|
||||
为解决这些问题，美国 TSA 于 2023 年 8 月正式发布了《开放架构路线图》（Open Architecture Roadmap），明确了向开放架构转型的战略方向。同时，国际机场协会（ACI）也发布了《机场安全系统开放架构》文件（已更新至第二版，2023年8月），为全球机场提供了开放架构的定义和高层级要求，包括网络安全方面的规范。
|
||||
|
||||
## 三、主要特点与优势
|
||||
|
||||
| 特点 | 说明 |
|
||||
|------|------|
|
||||
| **互操作性** | 不同厂商的设备和软件可以通过标准化接口协同工作，打破供应商锁定 |
|
||||
| **模块化设计** | 系统组件可以独立升级、替换或新增，无需整体更换 |
|
||||
| **灵活性与可扩展性** | 机场可根据需求灵活选择最优组件，分阶段部署新设备 |
|
||||
| **加速创新** | 开放竞争环境鼓励更多厂商参与，加快新技术的研发和应用 |
|
||||
| **降低成本** | 减少对单一供应商的依赖，通过竞争降低采购和维护成本 |
|
||||
| **提升安全性能** | 能够快速集成最新的威胁检测算法和技术，减少误报率 |
|
||||
| **改善旅客体验** | 简化安检流程，缩短等待时间，提升通行效率 |
|
||||
|
||||
正如 ACI 所指出的：
|
||||
> By adopting OA principles, airports can benefit from improved product warranty, integration, efficiency, extensibility, and flexibility in their security systems.
|
||||
|
||||
## 四、关键推动组织与标准
|
||||
|
||||
| 组织/标准 | 角色与贡献 |
|
||||
|-----------|-----------|
|
||||
| **TSA（美国运输安全管理局）** | 开放架构的主要推动者，发布了 OA 路线图，推动美国机场安检系统向开放架构转型 |
|
||||
| **ACI（国际机场协会）** | 发布《机场安全系统开放架构》指南文件，为全球机场提供参考框架 |
|
||||
| **SITA** | 全球领先的航空运输 IT 提供商，推动基于开放 API 的通用平台（Common Use），支持机场系统集成 |
|
||||
| **DHS S&T（美国国土安全部科技局）** | 支持开放架构相关的研发项目，推动下一代安检成像技术的开放集成 |
|
||||
| **Smiths Detection、Vanderlande 等设备商** | 积极响应开放架构理念，开发符合 OA 标准的安检和行李处理设备 |
|
||||
|
||||
## 五、主要应用场景
|
||||
|
||||
### 1. 安检系统
|
||||
这是机场开放架构最核心的应用领域。通过 OA，机场可以：
|
||||
- 将不同厂商的 X 光机、CT 扫描仪、人体扫描仪等设备集成到统一平台
|
||||
- 独立升级威胁检测算法，而无需更换整套硬件
|
||||
- 实现安检数据的标准化共享和分析
|
||||
- TSA 已在美国多个机场开展开放架构试点项目，展示了不同厂商设备互操作的可行性
|
||||
|
||||
### 2. 旅客处理系统
|
||||
SITA 推动的 Common Use 理念与开放架构密切相关：
|
||||
- 基于开放 API 构建的通用旅客处理平台
|
||||
- 支持自助值机、自助行李托运、生物识别通关等多种应用
|
||||
- 不同航空公司可共享同一套设备和系统
|
||||
|
||||
### 3. 行李处理系统
|
||||
Vanderlande 等厂商提出的开放软件架构方案：
|
||||
- 行李分拣和追踪系统采用开放接口
|
||||
- 支持与安检系统、航班信息系统的无缝对接
|
||||
- 提高行李处理的可靠性和效率
|
||||
|
||||
### 4. 机场运营管理
|
||||
- 基于开放架构的机场协同决策系统（A-CDM）
|
||||
- 航班信息、资源分配、地面交通等数据的标准化集成
|
||||
- 支持智慧机场的数字化转型
|
||||
|
||||
## 六、发展趋势
|
||||
|
||||
**标准化深化**：随着 TSA 路线图的推进和 ACI 指南的更新，开放架构的技术标准将更加完善和统一，覆盖更多机场子系统。
|
||||
|
||||
**全球推广**：从美国率先推动，逐步扩展到欧洲、亚太等地区的主要机场，成为全球机场建设和升级的主流方向。
|
||||
|
||||
**AI 与数据融合**：开放架构为人工智能算法的快速部署提供了基础，未来安检系统将更多地利用 AI 技术提升威胁识别能力。
|
||||
|
||||
**数字身份集成**：开放架构将支持物理和数字凭证的互认与互操作，推动无缝化旅客出行体验。
|
||||
|
||||
**网络安全强化**：随着系统开放程度的提高，网络安全将成为开放架构设计中的核心考量，ACI 的指南已将网络安全纳入高层级要求。
|
||||
|
||||
## 七、总结
|
||||
|
||||
机场开放架构是航空运输业数字化转型的重要方向，它通过采用标准化、模块化和可互操作的设计理念，打破了传统封闭系统的壁垒，为机场带来了更高的灵活性、更快的创新速度和更低的运营成本。在 TSA、ACI、SITA 等组织的共同推动下，机场开放架构正在从概念走向实践，有望在未来几年内深刻改变全球机场的技术生态。
|
||||
|
||||
---
|
||||
|
||||
**参考来源：**
|
||||
- [TSA - What is Open Architecture?](https://www.tsa.gov/travel/frequently-asked-questions/what-open-architecture)
|
||||
- [TSA - Open Architecture Roadmap (2023)](https://www.tsa.gov/sites/default/files/oa/_roadmap/_20230717/_508c-r1.pdf)
|
||||
- [ACI - Open Architecture for Airport Security Systems (2nd Edition, 2023)](https://www.aci-europe.org/downloads/resources/TSA-230504-7/_4.1%20Attachment%201%20OA%20for%20Airport%20Security%20Systems%202nd%20Edition%20%20FINAL.pdf)
|
||||
- [ACI Blog - Where Does Open Architecture Fit in Aviation Today?](https://blog.aci.aero/airport-it/where-does-open-architecture-fit-in-aviation-today/)
|
||||
- [Smiths Detection - Moving towards Open Architecture](https://www.smithsdetection.com/insights/moving-towards-open-architecture/)
|
||||
- [HSToday - How Open Architecture Can Enhance Airport Security](https://www.hstoday.us/subject-matter-areas/border-security/how-open-architecture-can-enhance-airport-security/)
|
||||
@@ -0,0 +1,288 @@
|
||||
# 机场运维数据库 (AODB) 产品对比分析报告
|
||||
|
||||
**作者**: Manus AI
|
||||
**时间**: 2026 年 4 月
|
||||
**版本**: 2.0 (专业修订版)
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
1. [执行摘要](#执行摘要)
|
||||
2. [AODB 概述与技术标准](#aodb-概述与技术标准)
|
||||
3. [主流商业产品深度对比](#主流商业产品深度对比)
|
||||
4. [产品技术架构与集成能力](#产品技术架构与集成能力)
|
||||
5. [报价与商业模式](#报价与商业模式)
|
||||
6. [中国市场现状与国产化替代](#中国市场现状与国产化替代)
|
||||
7. [选型指南与量化评估矩阵](#选型指南与量化评估矩阵)
|
||||
8. [结论与建议](#结论与建议)
|
||||
9. [参考文献](#参考文献)
|
||||
|
||||
---
|
||||
|
||||
## 执行摘要
|
||||
|
||||
机场运维数据库 (AODB, Airport Operational Database) 是现代机场运维的核心系统，被誉为机场信息集成系统 (AIIS) 的"心脏"。它集中存储、管理、分发和运维所有与航班运维相关的数据，为机场的协调决策提供实时数据支撑 [1]。
|
||||
|
||||
**当前市场现状**:
|
||||
|
||||
1. **市场规模稳步增长**: 全球机场信息系统市场预计在 2024 年达到 42.4 亿美元，到 2030 年将达到 53.6 亿美元，年复合增长率 (CAGR) 约为 4% [2]。其中，AODB 专项市场规模在 2024 年达到约 8.2 亿美元，预计到 2033 年将超过 50 亿美元 [3]。
|
||||
|
||||
2. **主流供应商寡头垄断**: 国际市场由 SITA、Amadeus、Collins Aerospace (原 ARINC) 等少数大型供应商主导。这些厂商提供的 AODB 系统覆盖全球大多主要枢纽机场。
|
||||
|
||||
3. **国内市场加速信创与自主研发**: 中国机场 AODB 市场正经历从依赖国际产品（如 SITA、Amadeus）向自主研发和国产化替代的转型。以北京首都机场为代表的大型枢纽已成功实现 AODB 系统的自主可控 [1]，同时万达信息、中国民航信息集团等本土厂商在市场中占据越来越重要的地位 [4]。
|
||||
|
||||
4. **技术升级要求**: 随着智慧机场建设推进，对 AODB 系统的数据精度、实时性、集成能力要求不断提高。云原生架构、AI 驱动的预测分析以及与机场协同决策 (A-CDM) 的深度集成已成为新一代 AODB 的核心特征 [5]。
|
||||
|
||||
**关键产品对比概览**:
|
||||
|
||||
| 厂商 | 产品 | 核心特点 | 部署规模/主要客户 |
|
||||
|------|------|------|---------|
|
||||
| **SITA** | Operations Manager | 实时数据管理、"最可信信源"认证、Total Optimizer AI 平台 | 全球 150+ 机场 [6] |
|
||||
| **Amadeus** | Amadeus AODB | 航班数据全球领先、365天前瞥时刻表、云原生 | 全球 700+ 机场 [7] |
|
||||
| **Collins Aerospace** | AirDB (AirPlan) | 高可用、云/本地灵活部署、与 AirVue FIDS 无缝集成 | 美洲、欧洲主要机场 [8] |
|
||||
| **ADB Safegate** | Cortex AODB | Airside 4.0 只能平台核心、AI 资源分配优化 | 全球多家中大型机场 [9] |
|
||||
| **RESA** | INFOPAX AODB | 模块化设计、INFOPAX EXPRESS 移动端支持 | 欧洲、非洲中型机场 [10] |
|
||||
| **Indra** | InBase | 自动 A-CDM 流程支持、SESAR/ACI 标准兼容 | 欧洲、西班牙机场 [11] |
|
||||
| **ISO Software** | SKYport AODB | 云原生架构、Oracle 数据库底层、现代化 UI | 欧美中等等规模机场 [12] |
|
||||
|
||||
---
|
||||
|
||||
## AODB 概述与技术标准
|
||||
|
||||
### AODB 的定义与核心功能
|
||||
|
||||
机场运维数据库 (Airport Operational Database, AODB) 是机场运维的中枢数据仓库，负责集中存储、管理、分发和运维所有与航班运维相关的实时数据。根据中国民用航空局《民用运输机场信息集成系统技术规范》(MH/T 5103-2020)，AODB 是信息集成系统的核心组件，用于存储、管理航班运维数据，定义运维数据的关联关系和处理规则 [13]。
|
||||
|
||||
**核心功能模块**:
|
||||
|
||||
1. **航班数据管理**: 管理季节性航班计划 (Seasonal Schedule)、每日航班动态 (Daily Flight Schedule)、航班延误与变更等。
|
||||
2. **资源管理**: 管理停机位、登机桥、行李转盘、值机柜台等物理与逻辑资源的分配。
|
||||
3. **数据融合与分发**: 接收来自空管、航司、地服的多源数据，进行清洗、认证后分发给航显 (FIDS)、离港 (DCS) 等子系统。
|
||||
4. **费用与结算数据准备**: 收集所有与航班保障相关的资源使用数据，为 ERP 或费用系统提供准确的原始凭证。
|
||||
5. **决策支持与 A-CDM**: 为机场协同决策提供统一的数据视图 (Single Source of Truth)。
|
||||
|
||||
### 关键技术与数据交换标准
|
||||
|
||||
现代 AODB 必须遵循国际航空运输协会 (IATA)、国际民航组织 (ICAO) 和国际机场协会 (ACI) 的相关数据交换标准，以确保与全球航空生态系统的互操作性。
|
||||
|
||||
1. **AIDX (Aviation Information Data Exchange)**:
|
||||
AIDX 是由 IATA、ATA 和 ACI 共同认可的全球 XML 消息标准，专门用于在航空公司、机场和第三方之间交换航班运维数据 [14]。它是 SESAR A-CDM 信息交换的标准格式，现代 AODB 必须原生支持 AIDX 接口。
|
||||
|
||||
2. **SSIM (Standard Schedules Information Manual)**:
|
||||
IATA 的 SSIM 标准规定了航空公司航班时刻表的交换格式。AODB 需要能够解析 SSIM 文件（如 Chapter 7 格式），以自动构建机场的季节性航班计划 [15]。
|
||||
|
||||
3. **传统报文标准**:
|
||||
尽管 XML 和 API 正在普及，AODB 仍需支持传统的航空报文格式，包括 AFTN (航空固定电信网) 报文、SITA Type B 报文以及 ACARS (飞机通信寻址与报告系统) 数据，以获取实时的航班起降和空中动态信息。
|
||||
|
||||
---
|
||||
|
||||
## 主流商业产品深度对比
|
||||
|
||||
### 1. SITA Operations Manager
|
||||
|
||||
**产品背景与定位**:
|
||||
SITA (国际航空电讯集团) 是全球航空 IT 领域的巨头。其 Operations Manager 是业界最成熟的 AODB 解决方案之一，目前在全球超过 150 个机场部署 [6]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **"最可信信源" (Most Confident Source) 引擎**: 不同于传统 AODB 仅记录数据，SITA 系统内置复杂的业务规则引擎，能够从多个冲突的数据源中自动评估并选择最准确的信息。
|
||||
- **Total Optimizer AI 平台**: 2024 年新推出的 AI 驱动平台，将 AODB 数据与机器学习结合，实现机场整体运维（准点率、容量、环控指标）的动态优先级优化 [16]。
|
||||
- **主动预警机制**: 在航班延误或资源冲突发生前提供预测性告警，支持 IROPS（不正常航班）的快速恢复。
|
||||
|
||||
**优劣势分析**:
|
||||
- **优势**: 数据治理能力极强；全球 24/7 SGS 支持体系；适合超大型多跑道枢纽机场。
|
||||
- **劣势**: 实施周期长；系统架构较重；定制化开发成本高昂。
|
||||
|
||||
### 2. Amadeus AODB
|
||||
|
||||
**产品背景与定位**:
|
||||
Amadeus 凭借其在航空公司旅客服务系统 (PSS) 领域的统冶地位，其 AODB 产品在航班数据获取方面具有得天独厚的优势，服务于全球 700 多个机场 [7]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **365天前瞥航班数据**: 自动获取并维护全球 95% 航空公司的全年航班时刻表，极大减少了机场手工录入和维护航班计划的工作量 [7]。
|
||||
- **云原生架构**: 完全基于云端托管，无需机场本地部署复杂的服务器基础设施，降低了 IT 运维成本。
|
||||
- **A-CDM Portal 深度集成**: 提供实时的机坪视图和周转预测，与 Amadeus 的离港系统 (Altéa) 无缝对接。
|
||||
|
||||
**优劣势分析**:
|
||||
- **优势**: 航班数据最全面准确；云端部署敏捷；预测分析能力强。
|
||||
- **劣势**: 深度依赖 Amadeus 生态；对于非 Amadeus 航司的数据整合可能存在壁垒。
|
||||
|
||||
### 3. Collins Aerospace AirDB (AirPlan)
|
||||
|
||||
**产品背景与定位**:
|
||||
Collins Aerospace (原 ARINC) 的 AirDB 是其 AirPlan 资源管理套件的核心组件，广泛应用于美洲和欧洲市场 [8]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **混合部署模式**: 支持本地数据中心、私有云或公有云部署，满足不同机场的数据合规要求。
|
||||
- **AirVue FIDS 原生协同**: 与市场领先的 AirVue 航显系统深度契合，确保旅客获取的信息与后台数据库毫秒级同步 [17]。
|
||||
- **动态资源分配算法**: 在后疫情时代，系统增加了支持社交距离的资源分配逻辑，如间隔分配登机口和行李转盘 [8]。
|
||||
|
||||
**优劣势分析**:
|
||||
- **优势**: 部署灵活性高；与 FIDS 和网络基础设施设施集成度高；界面现代化。
|
||||
- **劣势**: 在亚太地区本地化支持团队相对较小。
|
||||
|
||||
### 4. ADB Safegate Cortex AODB
|
||||
|
||||
**产品背景与定位**:
|
||||
ADB Safegate 以机坪照明和泊位引导系统闻名，其 Cortex AODB 是 Airside 4.0 智能平台的数据中枢 [9]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **空侧运维深度融合**: 不同于偏向航站楼的 AODB，Cortex 能够深度融合高级高级场面活动引导与控制系统 (A-SMGCS) 和自动泊位引导系统 (A-VDGS) 数据。
|
||||
- **AI 资源优化**: 利用人工智能进行精准的资源分配和运维规划，支持"假设" (What-if) 场景模拟 [9]。
|
||||
|
||||
**优劣势分析**:
|
||||
- **优势**: 空侧数据最丰富；机坪周转管理能力强。
|
||||
- **劣势**: 航站楼侧（如旅客流量预测）功能相对较弱。
|
||||
|
||||
### 5. RESA INFOPAX AODB
|
||||
|
||||
**产品背景与定位**:
|
||||
法国 RESA 公司的 INFOPAX AODB 主要面向中小型及区域性机场，在欧洲和非洲有广泛应用 [10]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **模块化轻量级设计**: 包含基础数据、季节计划和实时动态三个核心模块，易于实施。
|
||||
- **INFOPAX EXPRESS**: 提供专用的移动端访问应用，支持通过高级权限管理为临时用户开放特定数据视图 [18]。
|
||||
|
||||
**优劣势分析**:
|
||||
- **优势**: 实施快；成本效益高；移动端支持好。
|
||||
- **劣势**: 应对超大型机场海量并发数据的能力未经认证。
|
||||
|
||||
---
|
||||
|
||||
## 产品技术架构与集成能力
|
||||
|
||||
### 现代 AODB 技术架构演进
|
||||
|
||||
传统的 AODB 多采用单体架构（如基于 Oracle 数据库的 C/S 或 B/S 架构）。随着技术发展，新一代 AODB 正在向微服务和云原生架构演进：
|
||||
|
||||
1. **数据接入层**: 采用企业服务总线 (ESB) 或消息中间件 (如 Kafka、RabbitMQ)，支持高并发的 AIDX XML、JSON API 及传统报文解析。
|
||||
2. **核心处理层**: 采用内存数据库 (如 Redis) 处理实时高频率更新，关系型数据库 (如 PostgreSQL、Oracle) 保证事务一致性。
|
||||
3. **业务逻辑层**: 微服务化设计，将航班计划、资源分配、费用规则解耦，支持独立扩展。
|
||||
4. **展示与应用层**: 基于 HTML5/Vue/React 的响应式 Web 界面，以及原生移动端 App。
|
||||
|
||||
### A-CDM (机场协同决策) 集成
|
||||
|
||||
AODB 是实施 A-CDM 的数据基石。根据 EUROCONTROL 的规范，A-CDM 旨在通过优化资源使用和提高事件可预测性来提升机场运维效率 [19]。
|
||||
|
||||
AODB 必须支持 A-CDM 的 16 个关键里程碑 (Milestones) 数据跟踪，特别是：
|
||||
- **TOBT (目标撤轮档时间)**: 接收地服或航司的更新。
|
||||
- **TSAT (目标起飞时间)**: 接收空管系统的计算结果。
|
||||
- **TTOT (目标起飞时间)**: 实时计算并分发给所有利益相关方。
|
||||
|
||||
优秀的 AODB 能够自动捕捉这些时间戳，触发相应的业务规则，并通过 AIDX 标准接口与欧洲网络管理器 (NMOC) 或各国民航局的流量管理系统进行数据交换。
|
||||
|
||||
---
|
||||
|
||||
## 报价与商业模式
|
||||
|
||||
国际主流 AODB 产品的报价模式正在从传统的"一次性许可+运维"向 SaaS 订阅模式转变。
|
||||
|
||||
### 1. 传统许可费用模式 (On-Premise License)
|
||||
|
||||
适用于对数据绝对控制有要求的大型枢纽机场：
|
||||
- **初期软件许可与实施费**: 50 万 - 150 万美元（取决于机场规模和集成复杂度）。
|
||||
- **硬件与中间件成本**: 10 万 - 30 万美元（双机热备、Oracle 授权等）。
|
||||
- **年度运维费 (SLA)**: 通常为初期软件许可费的 18% - 22%。
|
||||
|
||||
### 2. SaaS 云订阅模式 (Cloud Subscription)
|
||||
|
||||
适用于中小型机场或寻求降低初期 CapEx 的机场：
|
||||
- **实施与接入费**: 10 万 - 30 万美元。
|
||||
- **年度订阅费**: 15 万 - 50 万美元/年（按年旅客吞吐量或航班架次阶梯计费）。
|
||||
- **优势**: 包含云基础设施成本、自动升级和 24/7 监控，总体拥有成本 (TCO) 更平滑。
|
||||
|
||||
---
|
||||
|
||||
## 中国市场现状与国产化替代
|
||||
|
||||
### 市场格局与政策导向
|
||||
|
||||
中国民航局高度重视机场信息系统的标准化与自主可控。2020年发布的《民用运输机场信息集成系统技术规范》(MH/T 5103-2020) 为国内 AODB 的建设提供了明确的标准 [13]。在"十四五"和"十五五"智慧民航建设规划的推动下，国产化替代进程显著加速 [20]。
|
||||
|
||||
### 典型国产化案例：北京首都国际机场
|
||||
|
||||
首都机场作为国内最繁忙的枢纽，其 AODB 系统经历了从依赖外资产到完全自主可控的"换心"手术。
|
||||
- **痛点**: 原有外资系统成本高、升级困难、存在安全隐患。
|
||||
- **解决方案**: 历时 14 个月，首都机场技术团队从代码级掌握核心技术，自主研发了新一代 AODB。
|
||||
- **成效**: 统一了数据结构，每日航班计划发布由 3 次人工校验简化为 1 次，日常运维工作量减少 30% 以上，并成功保障了 2022 年冬奥会 [1]。
|
||||
|
||||
### 主要国内供应商
|
||||
|
||||
1. **中国民航信息集团 (TravelSky)**:
|
||||
作为中国民航 IT 的国家队，不仅在离港系统 (DCS) 实现了全栈国产化 [21]，其提供的机场信息集成系统和 AODB 解决方案在国内众多中大型机场广泛应用，具有与国内航司数据天然互通的优势。
|
||||
|
||||
2. **万达信息股份有限公司**:
|
||||
国内较早涉足机场信息化的上市公司。其自主研发的万达机场集成系统 (AIIS) 是国内首家以 AODB 为核心的集成化运维管理系统，已在上海浦东、宁波、温州等多个机场成功部署，技术达到国际先进水平 [4]。
|
||||
|
||||
3. **中电科数字技术股份有限公司**:
|
||||
依托中国电科的强大研发实力，在机场弱电系统集成、数据中心建设及核心软件研发方面具有深厚积累，参与了多个千万级机场的智慧化改造项目 [22]。
|
||||
|
||||
---
|
||||
|
||||
## 选型指南与量化评估矩阵
|
||||
|
||||
### 选型量化评估矩阵
|
||||
|
||||
在进行 AODB 选型时，建议机场采用以下权重矩阵进行打分评估（总分 100 分）：
|
||||
|
||||
| 评估维度 | 权重 | 评估指标说明 | 领先厂商示例 |
|
||||
|----------|------|--------------|--------------|
|
||||
| **数据处理与准确性** | 25% | 多源数据融合规则引擎、"最可信信源"机制、并发处理能力 | SITA, Amadeus |
|
||||
| **系统架构与可靠性** | 20% | 高可用架构 (99.99%)、灾备切换时间 (RTO/RPO)、云原生支持 | Collins, ISO Software |
|
||||
| **标准兼容与集成性** | 20% | 原生支持 AIDX, SSIM, A-CDM 里程碑，开放 API 丰富度 | Indra, SITA |
|
||||
| **智能化与预测能力** | 15% | AI 资源优化、旅客/行李流量预测、What-if 场景模拟 | Amadeus, ADB Safegate |
|
||||
| **本地化服务与合规** | 10% | 本地技术支持团队规模、符合本国民航局数据安全与信创要求 | 国内厂商（如万达信息） |
|
||||
| **总体拥有成本 (TCO)** | 10% | 5年期软硬件投资、实施费、运维费及定制开发费率 | RESA, 国内厂商 |
|
||||
|
||||
### 针对不同规模机场的建议
|
||||
|
||||
1. **超大型国际枢纽 (年客流 > 4000万)**:
|
||||
- **首选**: SITA Operations Manager 或具备极强研发实力的自主研发方案（如首都机场模式）。
|
||||
- **策略**: 重点考察系统在极端并发下的稳定性和复杂业务规则的定制能力，投资预算应充足。
|
||||
|
||||
2. **中大型区域枢纽 (年客流 1000万 - 4000万)**:
|
||||
- **首选**: Amadeus AODB, Collins AirDB 或国内头部厂商（万达信息、民航信息科）。
|
||||
- **策略**: 寻求功能完整性与成本的平衡，重点关注 A-CDM 的支持能力和与现有 FIDS/DCS 的集成度。
|
||||
|
||||
3. **中小型及支线机场 (年客流 < 1000万)**:
|
||||
- **首选**: RESA INFOPAX, ISO SKYport 或基于 SaaS 的轻量级云方案。
|
||||
- **策略**: 优先考虑部署速度、易用性和低初期投资，避免过度采购不需要的复杂功能。
|
||||
|
||||
---
|
||||
|
||||
## 结论与建议
|
||||
|
||||
1. **数据资产化是核心驱动力**: AODB 已不再仅仅是 一个被动的数据存储器，而是机场数字化转型的核心引擎。通过引入 AI 和机器学习，现代 AODB 正在向具备预测和优化能力的只能平台演进。
|
||||
|
||||
2. **云原生与 SaaS 成为主流**: 摆脱沉甸的本地 IT 基础设施，采用云托管的 AODB 能够显著提升系统的弹性和敏捷性，这也是国际厂商迭代的主要方向。
|
||||
|
||||
3. **国产化替代势不可挡**: 在中国市场，出于数据安全、自主可控及成本优化的考量，AODB 的国产化替代已进入实质性阶段。国内机场应积极评估本土厂商的成熟度，或通过联合研发掌握核心技术。
|
||||
|
||||
4. **标准先行，避免孤岛**: 在选型和实施过程中，必须坚持采用国际通用标准 (如 AIDX) 和国内行业规范 (如 MH/T 5103-2020)，确保 AODB 能够与未来引入的任一第三方系统无 对接。
|
||||
|
||||
---
|
||||
|
||||
## 参考文献
|
||||
|
||||
[1] 北京首都国际机场. "首都机场：做好数据智慧化管理". 2022. https://www.bcia.com.cn/kgxwxqy/10274/10274_0a42d43a2d7a4237966503839254af3d.html
|
||||
[2] Research and Markets. "Airport Information System Market Size & Forecast to 2030". https://www.researchandmarkets.com/report/airport-information-system
|
||||
[3] Growth Market Reports. "Airport Operational Data Base (AODB) Market Research Report 2033". https://growthmarketreports.com/report/airport-operational-data-base-aodb-market
|
||||
[4] 万达信息股份有限公司. "首次公开发行股票并在创业板上市招股说明书". http://pdf.dfcfw.com/pdf/H2_AN201203010004684200_1.pdf
|
||||
[5] Copenhagen Optimization. "What is an Airport Operational Database (AODB)?". https://copenhagenoptimization.com/blog/what-is-an-airport-operational-database-aodb
|
||||
[6] SITA. "SITA Operations Manager". https://www.sita.aero/solutions/sita-at-airports/sita-operations-at-airports/sita-airport-management/sita-operations-manager/
|
||||
[7] Amadeus. "Amadeus Airport Operational Data Base (AODB)". https://amadeus.com/en/airports/products/airport-operational-data-base-aodb
|
||||
[8] Collins Aerospace. "Airport Database & Resource Management". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/airport-database-and-resource-management
|
||||
[9] ADB Safegate. "Airport Management Systems". https://adbsafegate.com/what-we-do/terminal/about-terminal-systems/
|
||||
[10] RESA. "INFOPAX AODB". https://resa.aero/en/solutions-operations-billing/infopax-aodb/
|
||||
[11] Indra Group. "InBASE AODB". https://dcs.aero/product/airport-operational-database-aodb-indra-inbase/
|
||||
[12] ISO Software Systeme. "SKYport AODB". https://www.iso-gruppe.com/en/business-units/aviation/airports/airport-operations
|
||||
[13] 中国民用航空局. "民用运输机场信息集成系统技术规范 (MH/T 5103-2020)". http://www.caac.gov.cn/XXGK/XXGK/BZGF/HYBZ/202008/t20200824_204192.html
|
||||
[14] IATA. "Aviation Information Data Exchange (AIDX)". https://www.iata.org/en/publications/info-data-exchange/
|
||||
[15] IATA. "Standard Schedules Information Manual (SSIM)". https://www.iata.org/en/publications/manuals/standard-schedules-information/
|
||||
[16] Aviation Week. "SITA unveils new AI-powered platform for airport management". 2024. https://aviationweek.com/aerospace/emerging-technologies/sita-unveils-new-ai-powered-platform-airport-management
|
||||
[17] Collins Aerospace. "AirVue FIDS". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/flight-information-display-systems
|
||||
[18] RESA. "INFOPAX EXPRESS". https://resa.aero/en/solutions-operations-billing/infopax-express/
|
||||
[19] EUROCONTROL. "Airport collaborative decision-making (A-CDM)". https://www.eurocontrol.int/concept/airport-collaborative-decision-making
|
||||
[20] 新浪财经. "喜报！中標民航机场建设"十四五"数字化发展规划". 2026. https://finance.sina.cn/stock/relnews/hk/2026-04-07/detail-inhtsrqx7097305.d.html
|
||||
[21] 国国资委. "民航首家！中国航信实现离港系统全栈国产化". 2025. http://wap.sasac.gov.cn/n2588025/n2588139/c35019378/content.html
|
||||
[22] 上海市科学术委员会. "2024年上海市认定机构认定备案的高新技术企业名单". https://www.sh-hitech.com/tzbt/15627.html
|
||||
@@ -0,0 +1,285 @@
|
||||
# 机场运行数据库 (AODB) 产品对比分析报告
|
||||
|
||||
**作者**: Manus AI
|
||||
**时间**: 2026 年 4 月
|
||||
**版本**: 2.0 (专业修订版)
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
1. [执行摘要](#执行摘要)
|
||||
2. [AODB 概述与技术标准](#aodb-概述与技术标准)
|
||||
3. [主流商业产品深度对比](#主流商业产品深度对比)
|
||||
4. [产品技术架构与集成能力](#产品技术架构与集成能力)
|
||||
5. [报价与商业模式](#报价与商业模式)
|
||||
6. [中国市场现状与国产化替代](#中国市场现状与国产化替代)
|
||||
7. [选型指南与量化评估矩阵](#选型指南与量化评估矩阵)
|
||||
8. [结论与建议](#结论与建议)
|
||||
9. [参考文献](#参考文献)
|
||||
|
||||
---
|
||||
|
||||
## 执行摘要
|
||||
|
||||
机场运行数据库 (AODB, Airport Operational Database) 是现代机场运营的核心系统，被誉为机场信息集成系统 (AIIS) 的"心脏"。它集中存储、管理和分发航班、旅客、行李、资源等所有运营相关数据，为机场的协调决策提供实时数据支撑 [1]。
|
||||
|
||||
**当前市场现状**:
|
||||
|
||||
1. **市场规模稳步增长**: 全球机场信息系统市场预计在 2024 年达到 42.4 亿美元，到 2030 年将达到 53.6 亿美元，年复合增长率 (CAGR) 约为 4% [2]。其中，AODB 专项市场规模在 2024 年达到约 8.2 亿美元，预计到 2033 年将超过 50 亿美元 [3]。
|
||||
|
||||
2. **主流供应商寡头垄断**: 国际市场由 SITA、Amadeus、Collins Aerospace (原 ARINC) 等少数大型供应商主导。这些厂商提供的 AODB 系统覆盖全球大多数主要枢纽机场。
|
||||
|
||||
3. **国内市场加速信创与自主研发**: 中国机场 AODB 市场正经历从依赖国际产品（如 SITA、Amadeus）向自主研发和国产化替代的转型。以北京首都机场为代表的大型枢纽已成功实现 AODB 系统的自主可控 [1]，同时万达信息、中国民航信息集团等本土厂商在市场中占据越来越重要的地位 [4]。
|
||||
|
||||
4. **技术升级需求**: 随着智慧机场建设推进，对 AODB 系统的数据精度、实时性、集成能力要求不断提高。云原生架构、AI 驱动的预测分析以及与机场协同决策 (A-CDM) 的深度集成成为新一代 AODB 的核心特征 [5]。
|
||||
|
||||
**关键产品对比概览**:
|
||||
|
||||
| 厂商 | 产品 | 核心特点 | 部署规模/主要客户 |
|
||||
|------|------|------|---------|
|
||||
| **SITA** | Operations Manager | 实时数据管理、"最可信信源"验证、Total Optimizer AI 平台 | 全球 150+ 机场 [6] |
|
||||
| **Amadeus** | Amadeus AODB | 航班数据全球领先、365天前瞻时刻表、云原生 | 全球 700+ 机场 [7] |
|
||||
| **Collins Aerospace** | AirDB (AirPlan) | 高可用、云/本地灵活部署、与 AirVue FIDS 无缝集成 | 美洲、欧洲主要机场 [8] |
|
||||
| **ADB Safegate** | Cortex AODB | Airside 4.0 智能平台核心、AI 资源分配优化 | 全球多家中大型机场 [9] |
|
||||
| **RESA** | INFOPAX AODB | 模块化设计、INFOPAX EXPRESS 移动端支持 | 欧洲、非洲中型机场 [10] |
|
||||
| **Indra** | InBase | 自动 A-CDM 流程支持、SESAR/ACI 标准兼容 | 欧洲、西班牙机场 [11] |
|
||||
| **ISO Software** | SKYport AODB | 云原生架构、Oracle 数据库底层、现代化 UI | 欧美中等规模机场 [12] |
|
||||
|
||||
---
|
||||
|
||||
## AODB 概述与技术标准
|
||||
|
||||
### AODB 的定义与核心功能
|
||||
|
||||
机场运行数据库 (Airport Operational Database, AODB) 是机场运营的中央数据仓库，负责集中存储、管理、分发和维护所有与航班运营相关的实时数据。根据中国民用航空局《民用运输机场信息集成系统技术规范》(MH/T 5103-2020)，AODB 是信息集成系统的核心组件，用于存储、管理航班运行数据，定义运行数据的关联关系和处理规则 [13]。
|
||||
|
||||
**核心功能模块**:
|
||||
|
||||
1. **航班数据管理**: 管理季节性航班计划 (Seasonal Schedule)、每日航班动态 (Daily Flight Schedule)、航班延误与变更等。
|
||||
2. **资源管理**: 管理停机位、登机桥、行李转盘、值机柜台等物理与逻辑资源的分配。
|
||||
3. **数据融合与分发**: 接收来自空管、航司、地服的多源数据，进行清洗、验证后分发给航显 (FIDS)、离港 (DCS) 等子系统。
|
||||
4. **计费与结算数据准备**: 收集所有与航班保障相关的资源使用数据，为 ERP 或计费系统提供准确的原始凭证。
|
||||
5. **决策支持与 A-CDM**: 为机场协同决策提供统一的数据视图 (Single Source of Truth)。
|
||||
|
||||
### 关键技术与数据交换标准
|
||||
|
||||
现代 AODB 必须遵循国际航空运输协会 (IATA)、国际民航组织 (ICAO) 和国际机场协会 (ACI) 的相关数据交换标准，以确保与全球航空生态系统的互操作性。
|
||||
|
||||
1. **AIDX (Aviation Information Data Exchange)**:
|
||||
AIDX 是由 IATA、ATA 和 ACI 共同认可的全球 XML 消息标准，专门用于在航空公司、机场和第三方之间交换航班运营数据 [14]。它是 SESAR A-CDM 信息交换的标准格式，现代 AODB 必须原生支持 AIDX 接口。
|
||||
|
||||
2. **SSIM (Standard Schedules Information Manual)**:
|
||||
IATA 的 SSIM 标准规定了航空公司航班时刻表的交换格式。AODB 需要能够解析 SSIM 文件（如 Chapter 7 格式），以自动构建机场的季节性航班计划 [15]。
|
||||
|
||||
3. **传统报文标准**:
|
||||
尽管 XML 和 API 正在普及，AODB 仍需支持传统的航空报文格式，包括 AFTN (航空固定电信网) 报文、SITA Type B 报文以及 ACARS (飞机通信寻址与报告系统) 数据，以获取实时的航班起降和空中动态信息。
|
||||
|
||||
---
|
||||
|
||||
## 主流商业产品深度对比
|
||||
|
||||
### 1. SITA Operations Manager
|
||||
|
||||
**产品背景与定位**:
|
||||
SITA (国际航空电讯集团) 是全球航空 IT 领域的巨头。其 Operations Manager 是业界最成熟的 AODB 解决方案之一，目前在全球超过 150 个机场部署 [6]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **"最可信信源" (Most Confident Source) 引擎**: 区别于传统 AODB 仅记录数据，SITA 系统内置复杂的业务规则引擎，能够从多个冲突的数据源中自动评估并选择最准确的信息。
|
||||
- **Total Optimizer AI 平台**: 2024 年新推出的 AI 驱动平台，将 AODB 数据与机器学习结合，实现机场整体运营（准点率、容量、环保指标）的动态优先级优化 [16]。
|
||||
- **主动预警机制**: 在航班延误或资源冲突发生前提供预测性告警，支持 IROPS (不正常航班) 的快速恢复。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 数据治理能力极强；全球 24/7 SGS 支持体系；适合超大型多跑道枢纽机场。
|
||||
- **劣势**: 实施周期长；系统架构较重；定制化开发成本高昂。
|
||||
|
||||
### 2. Amadeus AODB
|
||||
|
||||
**产品背景与定位**:
|
||||
Amadeus 凭借其在航空公司旅客服务系统 (PSS) 领域的统治地位，其 AODB 产品在航班数据获取方面具有得天独厚的优势，服务于全球 700 多个机场 [7]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **365 天前瞻航班数据**: 自动获取并维护全球 95% 航空公司的全年航班时刻表，极大减少了机场手工录入和维护航班计划的工作量 [7]。
|
||||
- **云原生架构**: 完全基于云端托管，无需机场本地部署复杂的服务器基础设施，降低了 IT 运维成本。
|
||||
- **A-CDM Portal 深度集成**: 提供实时的机坪视图和周转预测，与 Amadeus 的离港系统 (Altéa) 无缝对接。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 航班数据最全面准确；云端部署敏捷；预测分析能力强。
|
||||
- **劣势**: 深度依赖 Amadeus 生态；对于非 Amadeus 航司的数据整合可能存在壁垒。
|
||||
|
||||
### 3. Collins Aerospace AirDB (AirPlan)
|
||||
|
||||
**产品背景与定位**:
|
||||
Collins Aerospace (原 ARINC) 的 AirDB 是其 AirPlan 资源管理套件的核心组件，广泛应用于美洲和欧洲市场 [8]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **混合部署模式**: 支持本地数据中心、私有云或公有云部署，满足不同机场的数据合规要求。
|
||||
- **AirVue FIDS 原生协同**: 与其市场领先的 AirVue 航显系统深度耦合，确保旅客获取的信息与后台数据库毫秒级同步 [17]。
|
||||
- **动态资源分配算法**: 在后疫情时代，系统增加了支持社交距离的资源分配逻辑，如间隔分配登机口和行李转盘 [8]。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 部署灵活性高；与 FIDS 和网络基础设施集成度好；界面现代化。
|
||||
- **劣势**: 在亚太地区本地化支持团队相对较小。
|
||||
|
||||
### 4. ADB Safegate Cortex AODB
|
||||
|
||||
**产品背景与定位**:
|
||||
ADB Safegate 以机坪照明和泊位引导系统闻名，其 Cortex AODB 是 Airside 4.0 智能平台的数据中枢 [9]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **空侧运营深度融合**: 区别于偏向航站楼的 AODB，Cortex 能够深度整合高级高级场面活动引导与控制系统 (A-SMGCS) 和自动泊位引导系统 (A-VDGS) 数据。
|
||||
- **AI 资源优化**: 利用人工智能进行准确的资源分配和运营规划，支持"假设" (What-if) 场景模拟 [9]。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 空侧数据最丰富；机坪周转管理能力强。
|
||||
- **劣势**: 航站楼侧（如旅客流量预测）功能相对较弱。
|
||||
|
||||
### 5. RESA INFOPAX AODB
|
||||
|
||||
**产品背景与定位**:
|
||||
法国 RESA 公司的 INFOPAX AODB 主要面向中小型及区域性机场，在欧洲和非洲有广泛应用 [10]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **模块化轻量级设计**: 包含基础数据、季节计划和实时动态三个核心模块，易于实施。
|
||||
- **INFOPAX EXPRESS**: 提供专用的移动端访问应用，支持通过高级权限管理为临时用户开放特定数据视图 [18]。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 实施快；成本效益高；移动端支持好。
|
||||
- **劣势**: 应对超大型机场海量并发数据的能力未经验证。
|
||||
|
||||
---
|
||||
|
||||
## 产品技术架构与集成能力
|
||||
|
||||
### 现代 AODB 技术架构演进
|
||||
|
||||
传统的 AODB 多采用单体架构（如基于 Oracle 数据库的 C/S 或 B/S 架构）。随着技术发展，新一代 AODB 正在向微服务和云原生架构演进：
|
||||
|
||||
1. **数据接入层**: 采用企业服务总线 (ESB) 或消息中间件 (如 Kafka、RabbitMQ)，支持高并发的 AIDX XML、JSON API 及传统报文解析。
|
||||
2. **核心处理层**: 采用内存数据库 (如 Redis) 处理实时高频更新，关系型数据库 (如 PostgreSQL、Oracle) 保证事务一致性。
|
||||
3. **业务逻辑层**: 微服务化设计，将航班计划、资源分配、计费规则解耦，支持独立扩展。
|
||||
4. **展现与应用层**: 基于 HTML5/Vue/React 的响应式 Web 界面，以及原生移动端 App。
|
||||
|
||||
### A-CDM (机场协同决策) 集成
|
||||
|
||||
AODB 是实施 A-CDM 的数据基石。根据 EUROCONTROL 的规范，A-CDM 旨在通过优化资源使用和提高事件可预测性来提升机场运营效率 [19]。
|
||||
|
||||
AODB 必须支持 A-CDM 的 16 个关键里程碑 (Milestones) 数据追踪，特别是：
|
||||
- **TOBT (目标撤轮挡时间)**: 接收地服或航司的更新。
|
||||
- **TSAT (目标起飞时间)**: 接收空管系统的计算结果。
|
||||
- **TTOT (目标起飞时间)**: 实时计算并分发给所有利益相关方。
|
||||
|
||||
优秀的 AODB 能够自动捕捉这些时间戳，触发相应的业务规则，并通过 AIDX 标准接口与欧洲网络管理器 (NMOC) 或各国民航局的流量管理系统进行数据交换。
|
||||
|
||||
---
|
||||
|
||||
## 报价与商业模式
|
||||
|
||||
国际主流 AODB 产品的报价模式正在从传统的"一次性许可+维保"向 SaaS 订阅模式转变。
|
||||
|
||||
### 1. 传统许可费模式 (On-Premise License)
|
||||
|
||||
适用于对数据绝对控制有要求的大型枢纽机场：
|
||||
- **初期软件许可与实施费**: 50 万 - 150 万美元（取决于机场规模和集成复杂度）。
|
||||
- **硬件与中间件成本**: 10 万 - 30 万美元（双机热备、Oracle 授权等）。
|
||||
- **年度维保费 (SLA)**: 通常为初期软件许可费的 18% - 22%。
|
||||
|
||||
### 2. SaaS 云订阅模式 (Cloud Subscription)
|
||||
|
||||
适用于中小型机场或寻求降低初期 CapEx 的机场：
|
||||
- **实施与接入费**: 10 万 - 30 万美元。
|
||||
- **年度订阅费**: 15 万 - 50 万美元/年（按年旅客吞吐量或航班架次阶梯计费）。
|
||||
- **优势**: 包含云基础设施成本、自动升级和 24/7 监控，总体拥有成本 (TCO) 更平滑。
|
||||
|
||||
---
|
||||
|
||||
## 中国市场现状与国产化替代
|
||||
|
||||
### 市场格局与政策导向
|
||||
|
||||
中国民航局高度重视机场信息系统的标准化与自主可控。2020年发布的《民用运输机场信息集成系统技术规范》(MH/T 5103-2020) 为国内 AODB 的建设提供了明确的标准 [13]。在"十四五"和"十五五"智慧民航建设规划的推动下，国产化替代进程显著加速 [20]。
|
||||
|
||||
### 典型国产化案例：北京首都国际机场
|
||||
|
||||
首都机场作为国内最繁忙的枢纽，其 AODB 系统经历了从依赖外资产品到完全自主可控的"换心"手术。
|
||||
- **痛点**: 原有外资系统成本高、升级困难、存在安全隐患。
|
||||
- **解决方案**: 历时 14 个月，首都机场信息技术团队从代码级掌握核心技术，自主研发了新一代 AODB。
|
||||
- **成效**: 统一了数据结构，每日航班计划发布由 3 次人工校验简化为 1 次，日常维护工作量减少 30% 以上，并成功保障了 2022 年冬奥会 [1]。
|
||||
|
||||
### 主要国内供应商
|
||||
|
||||
1. **中国民航信息集团 (TravelSky)**:
|
||||
作为中国民航 IT 的国家队，不仅在离港系统 (DCS) 实现了全栈国产化 [21]，其提供的机场信息集成系统和 AODB 解决方案在国内众多中大型机场广泛应用，具有与国内航司数据天然互通的优势。
|
||||
|
||||
2. **万达信息股份有限公司**:
|
||||
国内较早涉足机场信息化的上市企业。其自主研发的万达机场集成系统 (AIIS) 是国内首家以 AODB 为核心的集成化运营管理系统，已在上海浦东、宁波、温州等多个机场成功部署，技术达到国际先进水平 [4]。
|
||||
|
||||
3. **中电科数字技术股份有限公司**:
|
||||
依托中国电科的强大研发实力，在机场弱电系统集成、数据中心建设及核心软件研发方面具有深厚积累，参与了多个千万级机场的智慧化改造项目 [22]。
|
||||
|
||||
---
|
||||
|
||||
## 选型指南与量化评估矩阵
|
||||
|
||||
### 选型量化评估矩阵
|
||||
|
||||
在进行 AODB 选型时，建议机场采用以下权重矩阵进行打分评估（总分 100 分）：
|
||||
|
||||
| 评估维度 | 权重 | 评估指标说明 | 领先厂商示例 |
|
||||
|----------|------|--------------|--------------|
|
||||
| **数据处理与准确性** | 25% | 多源数据融合规则引擎、"最可信信源"机制、并发处理能力 | SITA, Amadeus |
|
||||
| **系统架构与可靠性** | 20% | 高可用架构 (99.99%)、灾备切换时间 (RTO/RPO)、云原生支持 | Collins, ISO Software |
|
||||
| **标准兼容与集成性** | 20% | 原生支持 AIDX, SSIM, A-CDM 里程碑，开放 API 丰富度 | Indra, SITA |
|
||||
| **智能化与预测能力** | 15% | AI 资源优化、旅客/行李流量预测、What-if 场景模拟 | Amadeus, ADB Safegate |
|
||||
| **本地化服务与合规** | 10% | 本地技术支持团队规模、符合本国民航局数据安全与信创要求 | 国内厂商 (如万达信息) |
|
||||
| **总体拥有成本 (TCO)** | 10% | 5年期软硬件投资、实施费、维保费及定制开发费率 | RESA, 国内厂商 |
|
||||
|
||||
### 针对不同规模机场的建议
|
||||
|
||||
1. **超大型国际枢纽 (年客流 > 4000万)**:
|
||||
- **首选**: SITA Operations Manager 或具备极强研发实力的自主研发方案（如首都机场模式）。
|
||||
- **策略**: 重点考察系统在极端并发下的稳定性和复杂业务规则的定制能力，投资预算应充足。
|
||||
|
||||
2. **中大型区域枢纽 (年客流 1000万 - 4000万)**:
|
||||
- **首选**: Amadeus AODB, Collins AirDB 或国内头部厂商（万达信息、民航信科）。
|
||||
- **策略**: 寻求功能完整性与成本的平衡，重点关注 A-CDM 的支持能力和与现有 FIDS/DCS 的集成度。
|
||||
|
||||
3. **中小型及支线机场 (年客流 < 1000万)**:
|
||||
- **首选**: RESA INFOPAX, ISO SKYport 或基于 SaaS 的轻量级云方案。
|
||||
- **策略**: 优先考虑部署速度、易用性和低初期投资，避免过度采购不需要的复杂功能。
|
||||
|
||||
---
|
||||
|
||||
## 结论与建议
|
||||
|
||||
1. **数据资产化是核心驱动力**: AODB 已不再仅仅是一个被动的数据存储库，而是机场数字化转型的核心引擎。通过引入 AI 和机器学习，现代 AODB 正在向具备预测和优化能力的智能平台演进。
|
||||
2. **云原生与 SaaS 成为主流**: 摆脱沉重的本地 IT 基础设施，采用云托管的 AODB 能够显著提升系统的弹性和敏捷性，这也是国际厂商产品迭代的主要方向。
|
||||
3. **国产化替代势不可挡**: 在中国市场，出于数据安全、自主可控及成本优化的考量，AODB 的国产化替代已进入实质性阶段。国内机场应积极评估本土厂商的成熟度，或通过联合研发掌握核心技术。
|
||||
4. **标准先行，避免孤岛**: 在选型和实施过程中，必须坚持采用国际通用标准 (如 AIDX) 和国内行业规范 (如 MH/T 5103-2020)，确保 AODB 能够与未来引入的任何第三方系统无缝对接。
|
||||
|
||||
---
|
||||
|
||||
## 参考文献
|
||||
|
||||
[1] 北京首都国际机场. "首都机场：做好数据智慧化管理". 2022. https://www.bcia.com.cn/kgxwxqy/10274/10274_0a42d43a2d7a4237966503839254af3d.html
|
||||
[2] Research and Markets. "Airport Information System Market Size & Forecast to 2030". https://www.researchandmarkets.com/report/airport-information-system
|
||||
[3] Growth Market Reports. "Airport Operational Data Base (AODB) Market Research Report 2033". https://growthmarketreports.com/report/airport-operational-data-base-aodb-market
|
||||
[4] 万达信息股份有限公司. "首次公开发行股票并在创业板上市招股说明书". http://pdf.dfcfw.com/pdf/H2_AN201203010004684200_1.pdf
|
||||
[5] Copenhagen Optimization. "What is an Airport Operational Database (AODB)?". https://copenhagenoptimization.com/blog/what-is-an-airport-operational-database-aodb
|
||||
[6] SITA. "SITA Operations Manager". https://www.sita.aero/solutions/sita-at-airports/sita-operations-at-airports/sita-airport-management/sita-operations-manager/
|
||||
[7] Amadeus. "Amadeus Airport Operational Data Base (AODB)". https://amadeus.com/en/airports/products/airport-operational-data-base-aodb
|
||||
[8] Collins Aerospace. "Airport Database & Resource Management". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/airport-database-and-resource-management
|
||||
[9] ADB Safegate. "Airport Management Systems". https://adbsafegate.com/what-we-do/terminal/about-terminal-systems/
|
||||
[10] RESA. "INFOPAX AODB". https://resa.aero/en/solutions-operations-billing/infopax-aodb/
|
||||
[11] Indra Group. "InBASE AODB". https://dcs.aero/product/airport-operational-database-aodb-indra-inbase/
|
||||
[12] ISO Software Systeme. "SKYport AODB". https://www.iso-gruppe.com/en/business-units/aviation/airports/airport-operations
|
||||
[13] 中国民用航空局. "民用运输机场信息集成系统技术规范 (MH/T 5103-2020)". http://www.caac.gov.cn/XXGK/XXGK/BZGF/HYBZ/202008/t20200824_204192.html
|
||||
[14] IATA. "Aviation Information Data Exchange (AIDX)". https://www.iata.org/en/publications/info-data-exchange/
|
||||
[15] IATA. "Standard Schedules Information Manual (SSIM)". https://www.iata.org/en/publications/manuals/standard-schedules-information/
|
||||
[16] Aviation Week. "SITA unveils new AI-powered platform for airport management". 2024. https://aviationweek.com/aerospace/emerging-technologies/sita-unveils-new-ai-powered-platform-airport-management
|
||||
[17] Collins Aerospace. "AirVue FIDS". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/flight-information-display-systems
|
||||
[18] RESA. "INFOPAX EXPRESS". https://resa.aero/en/solutions-operations-billing/infopax-express/
|
||||
[19] EUROCONTROL. "Airport collaborative decision-making (A-CDM)". https://www.eurocontrol.int/concept/airport-collaborative-decision-making
|
||||
[20] 新浪财经. "喜报！中标民航机场建设“十五五”数字化发展规划". 2026. https://finance.sina.cn/stock/relnews/hk/2026-04-07/detail-inhtsrqx7097305.d.html
|
||||
[21] 国务院国资委. "民航首家！中国航信实现离港系统全栈国产化". 2025. http://wap.sasac.gov.cn/n2588025/n2588139/c35019378/content.html
|
||||
[22] 上海市科学技术委员会. "2024年上海市认定机构认定报备的高新技术企业名单". https://www.sh-hitech.com/tzbt/15627.html
|
||||
@@ -0,0 +1,99 @@
|
||||
# LLM Wiki v2 — Comprehensive Summary
|
||||
|
||||
## Source
|
||||
|
||||
https://gist.github.com/rohitg00/2067ab416f7bbe447c1977edaaa681e2
|
||||
Author: rohitg00
|
||||
Forked from: karpathy/llm-wiki.md
|
||||
Last active: 2026-04-13
|
||||
|
||||
## Overview
|
||||
|
||||
A pattern for building personal knowledge bases using LLMs, extending Karpathy's original LLM Wiki idea with lessons from building agentmemory. Addresses what breaks at scale, what's missing, and what separates a useful wiki from one that rots.
|
||||
|
||||
---
|
||||
|
||||
## What the Original Gets Right
|
||||
|
||||
> **Stop re-deriving, start compiling.** RAG retrieves and forgets. A wiki accumulates and compounds.
|
||||
|
||||
- Three-layer architecture works: raw sources → wiki → schema
|
||||
- Basic operations (ingest, query, lint) cover the basics
|
||||
|
||||
---
|
||||
|
||||
## Missing Layer: Memory Lifecycle
|
||||
|
||||
### Confidence Scoring
|
||||
Every fact should carry a confidence score indicating:
|
||||
- How many sources support it
|
||||
- How recently it was confirmed
|
||||
- Whether anything contradicts it
|
||||
|
||||
### Supersession
|
||||
When new information contradicts existing claims:
|
||||
- Old claim explicitly superseded, not just noted
|
||||
- Linked and timestamped
|
||||
- Old version preserved but marked stale
|
||||
|
||||
### Forgetting
|
||||
- Wikis that never forget become noisy
|
||||
- Implement a retention curve based on Ebbinghaus's forgetting curve
|
||||
- Architecture decisions decay slowly. Transient bugs decay fast.
|
||||
|
||||
### Consolidation Tiers
|
||||
|
||||
| Tier | Description | Characteristics |
|
||||
|------|-------------|------------------|
|
||||
| Working memory | Recent observations | Not yet processed |
|
||||
| Episodic memory | Session summaries | Compressed from raw |
|
||||
| Semantic memory | Cross-session facts | Consolidated from episodes |
|
||||
| Procedural memory | Workflows and patterns | Extracted from repeated semantics |
|
||||
|
||||
---
|
||||
|
||||
## Beyond Flat Pages: Knowledge Graph
|
||||
|
||||
### Entity Extraction
|
||||
Extract structured entities: People, projects, libraries, concepts, files, decisions
|
||||
|
||||
### Typed Relationships
|
||||
Not all connections are equal: uses, depends_on, contradicts, caused, fixed, supersedes
|
||||
|
||||
### Graph Traversal for Queries
|
||||
Instead of keyword search: walk outward through typed edges to find all related nodes.
|
||||
|
||||
---
|
||||
|
||||
## Search That Actually Scales
|
||||
|
||||
### When index.md Breaks
|
||||
Works up to ~100-200 pages. Beyond that, becomes too long for LLM.
|
||||
|
||||
### Hybrid Search Architecture
|
||||
|
||||
| Stream | Catches | Method |
|
||||
|--------|---------|--------|
|
||||
| BM25 | Exact terms | Keyword matching |
|
||||
| Vector search | Semantic similarity | Embeddings |
|
||||
| Graph traversal | Structural connections | Entity-aware relationship walking |
|
||||
|
||||
---
|
||||
|
||||
## Automation: Event-Driven Operations
|
||||
|
||||
| Event | Action |
|
||||
|-------|--------|
|
||||
| On new source | Auto-ingest, extract entities, update graph, update index |
|
||||
| On session start | Load relevant context based on recent activity |
|
||||
| On session end | Compress session into observations, file insights |
|
||||
| On query | Check if answer is worth filing back (quality score > threshold) |
|
||||
| On memory write | Check for contradictions, trigger supersession |
|
||||
| On schedule | Periodic lint, consolidation, retention decay |
|
||||
|
||||
---
|
||||
|
||||
## Quality and Self-Correction
|
||||
|
||||
### Score Everything
|
||||
Every piece of LLM-generated content gets a quality score based on structure, citations, wikilink density, length, and fact consistency.
|
||||
@@ -0,0 +1,94 @@
|
||||
# 未来机场信息中心（Future Airport Info Center）研究报告
|
||||
**作者：Manus AI**
|
||||
**日期：2026年4月10日**
|
||||
|
||||
## 1. 引言与概念定义
|
||||
|
||||
随着全球航空客运量的持续增长与旅客期望的不断提升，传统的机场信息服务台正在经历深刻的数字化转型。未来机场信息中心（Future Airport Info Center）不再仅仅是一个提供航班时刻表和简单指引的物理服务台，而是演变为一个高度集成、数据驱动且以旅客为中心的智能交互枢纽。
|
||||
|
||||
未来机场信息中心的核心概念在于"连接智能"（Connected Intelligence），它将物理基础设施、数字系统（如机场运营数据库 AODB、资源管理系统 RMS）与前沿技术（如人工智能、数字孪生、生物识别）深度融合，旨在为旅客提供无缝、个性化且无障碍的出行体验，同时大幅提升机场的运营效率与安全裕度。
|
||||
|
||||
## 2. 核心技术趋势
|
||||
|
||||
### 2.1 人工智能与智能体（Agentic AI）
|
||||
|
||||
人工智能已从简单的规则问答演进为具备自主决策能力的智能体（Agentic AI）。在信息中心场景下，AI 驱动的虚拟助手（Virtual Assistants）和多语言聊天机器人能够通过自然语言处理（NLP）与旅客进行流畅互动，提供实时的航班动态、行李追踪、个性化零售推荐以及动态寻路服务。此外，AI 还能根据实时客流密度自动调整航站楼内的环境参数（如温湿度、照明），并优化信息屏幕的显示内容。
|
||||
|
||||
### 2.2 数字孪生（Digital Twins）
|
||||
|
||||
数字孪生技术为机场物理环境创建了高精度的虚拟副本。通过接入物联网（IoT）传感器数据，信息中心能够实时监控航站楼内的运行状态。这种技术不仅用于预测性维护，还能在旅客服务端发挥巨大作用——例如，通过模拟客流瓶颈，提前调度资源或通过数字标牌引导旅客避开拥堵区域，实现全局的容量与流量优化。
|
||||
|
||||
### 2.3 生物识别与数字身份（Biometrics & Digital Identity）
|
||||
|
||||
"无接触"与"无缝通行"是未来机场的重要标志。生物识别技术（如面部识别）正与旅客信息系统深度绑定。旅客在信息中心或自助终端（Kiosks）进行一次身份验证后，其数字身份即可在安检、登机、免税店购物等全流程中通行无阻（即"出行一张脸"）。这种"生物识别走廊"（Biometric Corridors）极大地减少了排队时间，提升了通行效率。
|
||||
|
||||
### 2.4 智能运控平台（AOCC & IOC）
|
||||
|
||||
在后台，信息中心依托于强大的机场运行控制中心（AOCC）或综合运营中心（IOC）。例如，华为推出的机场智能运控中心解决方案，基于 5G、云计算和大数据底座，打破了传统系统的"数据孤岛"，实现了航班流、旅客流和行李流的统一调度与全景可视（"运行一张图"）。
|
||||
|
||||
## 3. 市场规模与行业前景
|
||||
|
||||
| 细分市场 | 2024/2025年估值 | 2030/2034年预测估值 | 复合年增长率 (CAGR) | 核心驱动因素 |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
| **机场信息系统** | 约 37 - 42 亿美元 | 约 51 - 53.6 亿美元 | 3.5% - 4.0% | 运营效率需求、网络安全升级、旅客体验优化 |
|
||||
| **智能机场整体市场** | 约 66.1 亿美元 (2025) | 约 108.3 亿美元 (2030) | 10.36% | AI、物联网、数字孪生技术的全面普及 |
|
||||
| **机场运营控制中心 (AOCC)** | 约 18.38 亿美元 (2026) | 约 40.5 亿美元 (2034) | 10.38% | 实时数据整合、跨部门协同需求 |
|
||||
|
||||
数据表明，尽管基础信息系统的增长相对平稳，但涉及智能控制、自动化与高级旅客信息交互的细分领域（如 AOCC 和智能机场整体解决方案）正以两位数的惊人速度增长。
|
||||
|
||||
## 4. 典型项目与实践案例
|
||||
|
||||
### 4.1 纽约肯尼迪国际机场（JFK）新航站楼项目
|
||||
|
||||
在 2026 年即将投入使用的 JFK 6 号航站楼（Terminal 6）和新一号航站楼（New Terminal One）中，航空技术巨头 SITA 联合其收购的意大利设计公司 CCM，打造了全新的旅客信息中心。该项目打破了传统 IT 系统与建筑设计的界限，将数字标牌、智能寻路系统与高端家具设计无缝集成。信息中心不仅提供 ADA（美国残疾人法案）合规的无障碍服务，还通过沉浸式设计提升了旅客的情感体验。
|
||||
|
||||
### 4.2 罗马菲乌米奇诺机场（ADR）AI 虚拟助手
|
||||
|
||||
2025 年底，罗马机场（Aeroporti di Roma）引入了由生成式 AI 驱动的虚拟助手。该系统能够通过文本或语音与旅客自然交互，提供从停车、地面交通到实时航班状态、行李追踪的全方位个性化支持，显著提升了信息获取的便捷性。
|
||||
|
||||
### 4.3 匹兹堡国际机场（PIT）通用设计认证
|
||||
|
||||
2026 年 2 月，匹兹堡国际机场成为全球首个获得"通用设计"（Universal Design）认证的机场。其信息中心与航站楼设计深度融合了包容性理念，采用了直观的数字寻路系统、高可见度的信息显示屏以及适应不同身体条件旅客的交互终端，确保所有旅客（包括老年人和残障人士）都能平等、顺畅地获取信息。
|
||||
|
||||
### 4.4 新加坡樟宜机场与 SITA 体验中心
|
||||
|
||||
作为智慧机场的标杆，樟宜机场在 T5 航站楼的规划中全面拥抱 100% 无接触服务。同时，SITA 在新加坡设立了全新的体验中心，集中展示了未来机场信息处理的最新技术，包括生物识别、数字身份和 AI 驱动的旅客处理系统，为亚太地区的机场数字化转型提供了示范。
|
||||
|
||||
## 5. 设计理念与发展方向
|
||||
|
||||
1. **从"客户体验"到"人类体验"（Human-Centered Design）**：未来的信息中心设计将更加关注旅客的情感与心理需求。通过将冰冷的技术隐藏在温暖的建筑与家具设计中（如 SITA-CCM 的实践），减轻旅客的旅行焦虑。同时，通用设计（Universal Design）将成为标配，确保信息系统对所有人群的无障碍访问。
|
||||
|
||||
2. **数据驱动的超级个性化（Hyper-Personalization）**：借助 AI 和大数据，信息中心将从"被动响应"转向"主动服务"。系统能够根据旅客的行程、偏好甚至实时位置，通过移动端或附近的数字标牌推送定制化的餐饮优惠、登机提醒或最优步行路线。
|
||||
|
||||
3. **可持续性与绿色运营（Sustainability）**：信息中心的硬件设施（如自助终端、显示屏）将采用更环保的材料与低能耗技术。同时，通过数字孪生与 AI 优化航站楼的能源消耗，信息中心将成为机场实现净零排放（Net Zero）目标的重要辅助节点。
|
||||
|
||||
## 6. 面临的挑战
|
||||
|
||||
- **遗留系统整合（Legacy Systems Integration）**：许多机场仍依赖老旧的 IT 架构，打破数据孤岛、实现新旧系统的无缝对接是一项成本高昂且复杂的工程。
|
||||
- **网络安全与数据隐私（Cybersecurity & Data Privacy）**：随着生物识别和实时数据的广泛应用，机场面临的勒索软件、数据泄露等网络攻击风险急剧增加。如何在提供便利的同时确保旅客隐私安全，是行业亟待解决的核心问题。
|
||||
|
||||
## 7. 结论
|
||||
|
||||
未来机场信息中心正在经历一场由 AI、数字孪生和生物识别技术驱动的深刻变革。它将不再是一个孤立的服务节点，而是深度融入机场整体智能生态的交互中枢。通过融合人性化设计、无障碍理念与强大的后台数据处理能力，未来的信息中心将重新定义航空出行的标准，为旅客带来更加智能、高效且充满温度的旅程。
|
||||
|
||||
---
|
||||
|
||||
## 参考文献
|
||||
|
||||
[1] Vantage Airport Group. (2025). Redefining Airport Operations, With Passengers at the Center.
|
||||
[2] ACI. (2026). The Airport of the Future Runs on Connected Intelligence.
|
||||
[3] McKinsey & Company. (2025). Smart airports: Clearing the runway for digital takeoff.
|
||||
[4] IBM. (2026). Building the intelligent airport of the future.
|
||||
[5] OAG. (2025). AI Returns to the Runway: Three Innovations Redefining Airline Tech.
|
||||
[6] Virtual Workforce. (2026). AI assistant for airports: AI-powered airport support.
|
||||
[7] Cisco. (2026). Soaring to New Heights: How AI is Redefining the Airport.
|
||||
[8] Bentley Systems. Digital Twins for Passenger Experience.
|
||||
[9] David McMullen. (2026). Airport Tech Trends 2026: AI, Digital Twins, Biometrics.
|
||||
[10] Biometric Update. (2026). Biometric Corridors – an end to airport queues?
|
||||
[11] SITA. (2025). Passenger IT insights 2025 | Passenger Experience trends.
|
||||
[12] Huawei. (2025). Huawei Launches Five Aviation Solutions to Accelerate Intelligence.
|
||||
[13] TAV Technologies. (2026). Airport Operations Control Center Market Size, Share [2034].
|
||||
[14] Fortune Business Insights. (2026). Airport Information Systems Market Size, Trends.
|
||||
[15] MarketsandMarkets. (2025). Airport Information Systems Market Report 2024 - 2030.
|
||||
[16] Mordor Intelligence. (2025). Smart Airport Market Size & Share Analysis.
|
||||
[17] Fortune Business Insights. (2026). AOCC Market Report.
|
||||
@@ -0,0 +1,285 @@
|
||||
# 机场运行数据库 (AODB) 产品对比分析报告
|
||||
|
||||
**作者**: Manus AI
|
||||
**时间**: 2026 年 4 月
|
||||
**版本**: 2.0 (专业修订版)
|
||||
|
||||
---
|
||||
|
||||
## 目录
|
||||
|
||||
1. [执行摘要](#执行摘要)
|
||||
2. [AODB 概述与技术标准](#aodb-概述与技术标准)
|
||||
3. [主流商业产品深度对比](#主流商业产品深度对比)
|
||||
4. [产品技术架构与集成能力](#产品技术架构与集成能力)
|
||||
5. [报价与商业模式](#报价与商业模式)
|
||||
6. [中国市场现状与国产化替代](#中国市场现状与国产化替代)
|
||||
7. [选型指南与量化评估矩阵](#选型指南与量化评估矩阵)
|
||||
8. [结论与建议](#结论与建议)
|
||||
9. [参考文献](#参考文献)
|
||||
|
||||
---
|
||||
|
||||
## 执行摘要
|
||||
|
||||
机场运行数据库 (AODB, Airport Operational Database) 是现代机场运营的核心系统，被誉为机场信息集成系统 (AIIS) 的"心脏"。它集中存储、管理和分发航班、旅客、行李、资源等所有运营相关数据，为机场的协调决策提供实时数据支撑 [1]。
|
||||
|
||||
**当前市场现状**:
|
||||
|
||||
1. **市场规模稳步增长**: 全球机场信息系统市场预计在 2024 年达到 42.4 亿美元，到 2030 年将达到 53.6 亿美元，年复合增长率 (CAGR) 约为 4% [2]。其中，AODB 专项市场规模在 2024 年达到约 8.2 亿美元，预计到 2033 年将超过 50 亿美元 [3]。
|
||||
|
||||
2. **主流供应商寡头垄断**: 国际市场由 SITA、Amadeus、Collins Aerospace (原 ARINC) 等少数大型供应商主导。这些厂商提供的 AODB 系统覆盖全球大多数主要枢纽机场。
|
||||
|
||||
3. **国内市场加速信创与自主研发**: 中国机场 AODB 市场正经历从依赖国际产品（如 SITA、Amadeus）向自主研发和国产化替代的转型。以北京首都机场为代表的大型枢纽已成功实现 AODB 系统的自主可控 [1]，同时万达信息、中国民航信息集团等本土厂商在市场中占据越来越重要的地位 [4]。
|
||||
|
||||
4. **技术升级需求**: 随着智慧机场建设推进，对 AODB 系统的数据精度、实时性、集成能力要求不断提高。云原生架构、AI 驱动的预测分析以及与机场协同决策 (A-CDM) 的深度集成成为新一代 AODB 的核心特征 [5]。
|
||||
|
||||
**关键产品对比概览**:
|
||||
|
||||
| 厂商 | 产品 | 核心特点 | 部署规模/主要客户 |
|
||||
|------|------|------|---------|
|
||||
| **SITA** | Operations Manager | 实时数据管理、"最可信信源"验证、Total Optimizer AI 平台 | 全球 150+ 机场 [6] |
|
||||
| **Amadeus** | Amadeus AODB | 航班数据全球领先、365天前瞻时刻表、云原生 | 全球 700+ 机场 [7] |
|
||||
| **Collins Aerospace** | AirDB (AirPlan) | 高可用、云/本地灵活部署、与 AirVue FIDS 无缝集成 | 美洲、欧洲主要机场 [8] |
|
||||
| **ADB Safegate** | Cortex AODB | Airside 4.0 智能平台核心、AI 资源分配优化 | 全球多家中大型机场 [9] |
|
||||
| **RESA** | INFOPAX AODB | 模块化设计、INFOPAX EXPRESS 移动端支持 | 欧洲、非洲中型机场 [10] |
|
||||
| **Indra** | InBase | 自动 A-CDM 流程支持、SESAR/ACI 标准兼容 | 欧洲、西班牙机场 [11] |
|
||||
| **ISO Software** | SKYport AODB | 云原生架构、Oracle 数据库底层、现代化 UI | 欧美中等规模机场 [12] |
|
||||
|
||||
---
|
||||
|
||||
## AODB 概述与技术标准
|
||||
|
||||
### AODB 的定义与核心功能
|
||||
|
||||
机场运行数据库 (Airport Operational Database, AODB) 是机场运营的中央数据仓库，负责集中存储、管理、分发和维护所有与航班运营相关的实时数据。根据中国民用航空局《民用运输机场信息集成系统技术规范》(MH/T 5103-2020)，AODB 是信息集成系统的核心组件，用于存储、管理航班运行数据，定义运行数据的关联关系和处理规则 [13]。
|
||||
|
||||
**核心功能模块**:
|
||||
|
||||
1. **航班数据管理**: 管理季节性航班计划 (Seasonal Schedule)、每日航班动态 (Daily Flight Schedule)、航班延误与变更等。
|
||||
2. **资源管理**: 管理停机位、登机桥、行李转盘、值机柜台等物理与逻辑资源的分配。
|
||||
3. **数据融合与分发**: 接收来自空管、航司、地服的多源数据，进行清洗、验证后分发给航显 (FIDS)、离港 (DCS) 等子系统。
|
||||
4. **计费与结算数据准备**: 收集所有与航班保障相关的资源使用数据，为 ERP 或计费系统提供准确的原始凭证。
|
||||
5. **决策支持与 A-CDM**: 为机场协同决策提供统一的数据视图 (Single Source of Truth)。
|
||||
|
||||
### 关键技术与数据交换标准
|
||||
|
||||
现代 AODB 必须遵循国际航空运输协会 (IATA)、国际民航组织 (ICAO) 和国际机场协会 (ACI) 的相关数据交换标准，以确保与全球航空生态系统的互操作性。
|
||||
|
||||
1. **AIDX (Aviation Information Data Exchange)**:
|
||||
AIDX 是由 IATA、ATA 和 ACI 共同认可的全球 XML 消息标准，专门用于在航空公司、机场和第三方之间交换航班运营数据 [14]。它是 SESAR A-CDM 信息交换的标准格式，现代 AODB 必须原生支持 AIDX 接口。
|
||||
|
||||
2. **SSIM (Standard Schedules Information Manual)**:
|
||||
IATA 的 SSIM 标准规定了航空公司航班时刻表的交换格式。AODB 需要能够解析 SSIM 文件（如 Chapter 7 格式），以自动构建机场的季节性航班计划 [15]。
|
||||
|
||||
3. **传统报文标准**:
|
||||
尽管 XML 和 API 正在普及，AODB 仍需支持传统的航空报文格式，包括 AFTN (航空固定电信网) 报文、SITA Type B 报文以及 ACARS (飞机通信寻址与报告系统) 数据，以获取实时的航班起降和空中动态信息。
|
||||
|
||||
---
|
||||
|
||||
## 主流商业产品深度对比
|
||||
|
||||
### 1. SITA Operations Manager
|
||||
|
||||
**产品背景与定位**:
|
||||
SITA (国际航空电讯集团) 是全球航空 IT 领域的巨头。其 Operations Manager 是业界最成熟的 AODB 解决方案之一，目前在全球超过 150 个机场部署 [6]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **"最可信信源" (Most Confident Source) 引擎**: 区别于传统 AODB 仅记录数据，SITA 系统内置复杂的业务规则引擎，能够从多个冲突的数据源中自动评估并选择最准确的信息。
|
||||
- **Total Optimizer AI 平台**: 2024 年新推出的 AI 驱动平台，将 AODB 数据与机器学习结合，实现机场整体运营（准点率、容量、环保指标）的动态优先级优化 [16]。
|
||||
- **主动预警机制**: 在航班延误或资源冲突发生前提供预测性告警，支持 IROPS (不正常航班) 的快速恢复。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 数据治理能力极强；全球 24/7 SGS 支持体系；适合超大型多跑道枢纽机场。
|
||||
- **劣势**: 实施周期长；系统架构较重；定制化开发成本高昂。
|
||||
|
||||
### 2. Amadeus AODB
|
||||
|
||||
**产品背景与定位**:
|
||||
Amadeus 凭借其在航空公司旅客服务系统 (PSS) 领域的统治地位，其 AODB 产品在航班数据获取方面具有得天独厚的优势，服务于全球 700 多个机场 [7]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **365 天前瞻航班数据**: 自动获取并维护全球 95% 航空公司的全年航班时刻表，极大减少了机场手工录入和维护航班计划的工作量 [7]。
|
||||
- **云原生架构**: 完全基于云端托管，无需机场本地部署复杂的服务器基础设施，降低了 IT 运维成本。
|
||||
- **A-CDM Portal 深度集成**: 提供实时的机坪视图和周转预测，与 Amadeus 的离港系统 (Altéa) 无缝对接。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 航班数据最全面准确；云端部署敏捷；预测分析能力强。
|
||||
- **劣势**: 深度依赖 Amadeus 生态；对于非 Amadeus 航司的数据整合可能存在壁垒。
|
||||
|
||||
### 3. Collins Aerospace AirDB (AirPlan)
|
||||
|
||||
**产品背景与定位**:
|
||||
Collins Aerospace (原 ARINC) 的 AirDB 是其 AirPlan 资源管理套件的核心组件，广泛应用于美洲和欧洲市场 [8]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **混合部署模式**: 支持本地数据中心、私有云或公有云部署，满足不同机场的数据合规要求。
|
||||
- **AirVue FIDS 原生协同**: 与其市场领先的 AirVue 航显系统深度耦合，确保旅客获取的信息与后台数据库毫秒级同步 [17]。
|
||||
- **动态资源分配算法**: 在后疫情时代，系统增加了支持社交距离的资源分配逻辑，如间隔分配登机口和行李转盘 [8]。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 部署灵活性高；与 FIDS 和网络基础设施集成度好；界面现代化。
|
||||
- **劣势**: 在亚太地区本地化支持团队相对较小。
|
||||
|
||||
### 4. ADB Safegate Cortex AODB
|
||||
|
||||
**产品背景与定位**:
|
||||
ADB Safegate 以机坪照明和泊位引导系统闻名，其 Cortex AODB 是 Airside 4.0 智能平台的数据中枢 [9]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **空侧运营深度融合**: 区别于偏向航站楼的 AODB，Cortex 能够深度整合高级高级场面活动引导与控制系统 (A-SMGCS) 和自动泊位引导系统 (A-VDGS) 数据。
|
||||
- **AI 资源优化**: 利用人工智能进行准确的资源分配和运营规划，支持"假设" (What-if) 场景模拟 [9]。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 空侧数据最丰富；机坪周转管理能力强。
|
||||
- **劣势**: 航站楼侧（如旅客流量预测）功能相对较弱。
|
||||
|
||||
### 5. RESA INFOPAX AODB
|
||||
|
||||
**产品背景与定位**:
|
||||
法国 RESA 公司的 INFOPAX AODB 主要面向中小型及区域性机场，在欧洲和非洲有广泛应用 [10]。
|
||||
|
||||
**核心技术特性**:
|
||||
- **模块化轻量级设计**: 包含基础数据、季节计划和实时动态三个核心模块，易于实施。
|
||||
- **INFOPAX EXPRESS**: 提供专用的移动端访问应用，支持通过高级权限管理为临时用户开放特定数据视图 [18]。
|
||||
|
||||
**优势与劣势**:
|
||||
- **优势**: 实施快；成本效益高；移动端支持好。
|
||||
- **劣势**: 应对超大型机场海量并发数据的能力未经验证。
|
||||
|
||||
---
|
||||
|
||||
## 产品技术架构与集成能力
|
||||
|
||||
### 现代 AODB 技术架构演进
|
||||
|
||||
传统的 AODB 多采用单体架构（如基于 Oracle 数据库的 C/S 或 B/S 架构）。随着技术发展，新一代 AODB 正在向微服务和云原生架构演进：
|
||||
|
||||
1. **数据接入层**: 采用企业服务总线 (ESB) 或消息中间件 (如 Kafka、RabbitMQ)，支持高并发的 AIDX XML、JSON API 及传统报文解析。
|
||||
2. **核心处理层**: 采用内存数据库 (如 Redis) 处理实时高频更新，关系型数据库 (如 PostgreSQL、Oracle) 保证事务一致性。
|
||||
3. **业务逻辑层**: 微服务化设计，将航班计划、资源分配、计费规则解耦，支持独立扩展。
|
||||
4. **展现与应用层**: 基于 HTML5/Vue/React 的响应式 Web 界面，以及原生移动端 App。
|
||||
|
||||
### A-CDM (机场协同决策) 集成
|
||||
|
||||
AODB 是实施 A-CDM 的数据基石。根据 EUROCONTROL 的规范，A-CDM 旨在通过优化资源使用和提高事件可预测性来提升机场运营效率 [19]。
|
||||
|
||||
AODB 必须支持 A-CDM 的 16 个关键里程碑 (Milestones) 数据追踪，特别是：
|
||||
- **TOBT (目标撤轮挡时间)**: 接收地服或航司的更新。
|
||||
- **TSAT (目标起飞时间)**: 接收空管系统的计算结果。
|
||||
- **TTOT (目标起飞时间)**: 实时计算并分发给所有利益相关方。
|
||||
|
||||
优秀的 AODB 能够自动捕捉这些时间戳，触发相应的业务规则，并通过 AIDX 标准接口与欧洲网络管理器 (NMOC) 或各国民航局的流量管理系统进行数据交换。
|
||||
|
||||
---
|
||||
|
||||
## 报价与商业模式
|
||||
|
||||
国际主流 AODB 产品的报价模式正在从传统的"一次性许可+维保"向 SaaS 订阅模式转变。
|
||||
|
||||
### 1. 传统许可费模式 (On-Premise License)
|
||||
|
||||
适用于对数据绝对控制有要求的大型枢纽机场：
|
||||
- **初期软件许可与实施费**: 50 万 - 150 万美元（取决于机场规模和集成复杂度）。
|
||||
- **硬件与中间件成本**: 10 万 - 30 万美元（双机热备、Oracle 授权等）。
|
||||
- **年度维保费 (SLA)**: 通常为初期软件许可费的 18% - 22%。
|
||||
|
||||
### 2. SaaS 云订阅模式 (Cloud Subscription)
|
||||
|
||||
适用于中小型机场或寻求降低初期 CapEx 的机场：
|
||||
- **实施与接入费**: 10 万 - 30 万美元。
|
||||
- **年度订阅费**: 15 万 - 50 万美元/年（按年旅客吞吐量或航班架次阶梯计费）。
|
||||
- **优势**: 包含云基础设施成本、自动升级和 24/7 监控，总体拥有成本 (TCO) 更平滑。
|
||||
|
||||
---
|
||||
|
||||
## 中国市场现状与国产化替代
|
||||
|
||||
### 市场格局与政策导向
|
||||
|
||||
中国民航局高度重视机场信息系统的标准化与自主可控。2020年发布的《民用运输机场信息集成系统技术规范》(MH/T 5103-2020) 为国内 AODB 的建设提供了明确的标准 [13]。在"十四五"和"十五五"智慧民航建设规划的推动下，国产化替代进程显著加速 [20]。
|
||||
|
||||
### 典型国产化案例：北京首都国际机场
|
||||
|
||||
首都机场作为国内最繁忙的枢纽，其 AODB 系统经历了从依赖外资产品到完全自主可控的"换心"手术。
|
||||
- **痛点**: 原有外资系统成本高、升级困难、存在安全隐患。
|
||||
- **解决方案**: 历时 14 个月，首都机场信息技术团队从代码级掌握核心技术，自主研发了新一代 AODB。
|
||||
- **成效**: 统一了数据结构，每日航班计划发布由 3 次人工校验简化为 1 次，日常维护工作量减少 30% 以上，并成功保障了 2022 年冬奥会 [1]。
|
||||
|
||||
### 主要国内供应商
|
||||
|
||||
1. **中国民航信息集团 (TravelSky)**:
|
||||
作为中国民航 IT 的国家队，不仅在离港系统 (DCS) 实现了全栈国产化 [21]，其提供的机场信息集成系统和 AODB 解决方案在国内众多中大型机场广泛应用，具有与国内航司数据天然互通的优势。
|
||||
|
||||
2. **万达信息股份有限公司**:
|
||||
国内较早涉足机场信息化的上市企业。其自主研发的万达机场集成系统 (AIIS) 是国内首家以 AODB 为核心的集成化运营管理系统，已在上海浦东、宁波、温州等多个机场成功部署，技术达到国际先进水平 [4]。
|
||||
|
||||
3. **中电科数字技术股份有限公司**:
|
||||
依托中国电科的强大研发实力，在机场弱电系统集成、数据中心建设及核心软件研发方面具有深厚积累，参与了多个千万级机场的智慧化改造项目 [22]。
|
||||
|
||||
---
|
||||
|
||||
## 选型指南与量化评估矩阵
|
||||
|
||||
### 选型量化评估矩阵
|
||||
|
||||
在进行 AODB 选型时，建议机场采用以下权重矩阵进行打分评估（总分 100 分）：
|
||||
|
||||
| 评估维度 | 权重 | 评估指标说明 | 领先厂商示例 |
|
||||
|----------|------|--------------|--------------|
|
||||
| **数据处理与准确性** | 25% | 多源数据融合规则引擎、"最可信信源"机制、并发处理能力 | SITA, Amadeus |
|
||||
| **系统架构与可靠性** | 20% | 高可用架构 (99.99%)、灾备切换时间 (RTO/RPO)、云原生支持 | Collins, ISO Software |
|
||||
| **标准兼容与集成性** | 20% | 原生支持 AIDX, SSIM, A-CDM 里程碑，开放 API 丰富度 | Indra, SITA |
|
||||
| **智能化与预测能力** | 15% | AI 资源优化、旅客/行李流量预测、What-if 场景模拟 | Amadeus, ADB Safegate |
|
||||
| **本地化服务与合规** | 10% | 本地技术支持团队规模、符合本国民航局数据安全与信创要求 | 国内厂商 (如万达信息) |
|
||||
| **总体拥有成本 (TCO)** | 10% | 5年期软硬件投资、实施费、维保费及定制开发费率 | RESA, 国内厂商 |
|
||||
|
||||
### 针对不同规模机场的建议
|
||||
|
||||
1. **超大型国际枢纽 (年客流 > 4000万)**:
|
||||
- **首选**: SITA Operations Manager 或具备极强研发实力的自主研发方案（如首都机场模式）。
|
||||
- **策略**: 重点考察系统在极端并发下的稳定性和复杂业务规则的定制能力，投资预算应充足。
|
||||
|
||||
2. **中大型区域枢纽 (年客流 1000万 - 4000万)**:
|
||||
- **首选**: Amadeus AODB, Collins AirDB 或国内头部厂商（万达信息、民航信科）。
|
||||
- **策略**: 寻求功能完整性与成本的平衡，重点关注 A-CDM 的支持能力和与现有 FIDS/DCS 的集成度。
|
||||
|
||||
3. **中小型及支线机场 (年客流 < 1000万)**:
|
||||
- **首选**: RESA INFOPAX, ISO SKYport 或基于 SaaS 的轻量级云方案。
|
||||
- **策略**: 优先考虑部署速度、易用性和低初期投资，避免过度采购不需要的复杂功能。
|
||||
|
||||
---
|
||||
|
||||
## 结论与建议
|
||||
|
||||
1. **数据资产化是核心驱动力**: AODB 已不再仅仅是一个被动的数据存储库，而是机场数字化转型的核心引擎。通过引入 AI 和机器学习，现代 AODB 正在向具备预测和优化能力的智能平台演进。
|
||||
2. **云原生与 SaaS 成为主流**: 摆脱沉重的本地 IT 基础设施，采用云托管的 AODB 能够显著提升系统的弹性和敏捷性，这也是国际厂商产品迭代的主要方向。
|
||||
3. **国产化替代势不可挡**: 在中国市场，出于数据安全、自主可控及成本优化的考量，AODB 的国产化替代已进入实质性阶段。国内机场应积极评估本土厂商的成熟度，或通过联合研发掌握核心技术。
|
||||
4. **标准先行，避免孤岛**: 在选型和实施过程中，必须坚持采用国际通用标准 (如 AIDX) 和国内行业规范 (如 MH/T 5103-2020)，确保 AODB 能够与未来引入的任何第三方系统无缝对接。
|
||||
|
||||
---
|
||||
|
||||
## 参考文献
|
||||
|
||||
[1] 北京首都国际机场. "首都机场：做好数据智慧化管理". 2022. https://www.bcia.com.cn/kgxwxqy/10274/10274_0a42d43a2d7a4237966503839254af3d.html
|
||||
[2] Research and Markets. "Airport Information System Market Size & Forecast to 2030". https://www.researchandmarkets.com/report/airport-information-system
|
||||
[3] Growth Market Reports. "Airport Operational Data Base (AODB) Market Research Report 2033". https://growthmarketreports.com/report/airport-operational-data-base-aodb-market
|
||||
[4] 万达信息股份有限公司. "首次公开发行股票并在创业板上市招股说明书". http://pdf.dfcfw.com/pdf/H2_AN201203010004684200_1.pdf
|
||||
[5] Copenhagen Optimization. "What is an Airport Operational Database (AODB)?". https://copenhagenoptimization.com/blog/what-is-an-airport-operational-database-aodb
|
||||
[6] SITA. "SITA Operations Manager". https://www.sita.aero/solutions/sita-at-airports/sita-operations-at-airports/sita-airport-management/sita-operations-manager/
|
||||
[7] Amadeus. "Amadeus Airport Operational Data Base (AODB)". https://amadeus.com/en/airports/products/airport-operational-data-base-aodb
|
||||
[8] Collins Aerospace. "Airport Database & Resource Management". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/airport-database-and-resource-management
|
||||
[9] ADB Safegate. "Airport Management Systems". https://adbsafegate.com/what-we-do/terminal/about-terminal-systems/
|
||||
[10] RESA. "INFOPAX AODB". https://resa.aero/en/solutions-operations-billing/infopax-aodb/
|
||||
[11] Indra Group. "InBASE AODB". https://dcs.aero/product/airport-operational-database-aodb-indra-inbase/
|
||||
[12] ISO Software Systeme. "SKYport AODB". https://www.iso-gruppe.com/en/business-units/aviation/airports/airport-operations
|
||||
[13] 中国民用航空局. "民用运输机场信息集成系统技术规范 (MH/T 5103-2020)". http://www.caac.gov.cn/XXGK/XXGK/BZGF/HYBZ/202008/t20200824_204192.html
|
||||
[14] IATA. "Aviation Information Data Exchange (AIDX)". https://www.iata.org/en/publications/info-data-exchange/
|
||||
[15] IATA. "Standard Schedules Information Manual (SSIM)". https://www.iata.org/en/publications/manuals/standard-schedules-information/
|
||||
[16] Aviation Week. "SITA unveils new AI-powered platform for airport management". 2024. https://aviationweek.com/aerospace/emerging-technologies/sita-unveils-new-ai-powered-platform-airport-management
|
||||
[17] Collins Aerospace. "AirVue FIDS". https://www.rtx.com/collinsaerospace/what-we-do/industries/airports/airport-operations/flight-information-display-systems
|
||||
[18] RESA. "INFOPAX EXPRESS". https://resa.aero/en/solutions-operations-billing/infopax-express/
|
||||
[19] EUROCONTROL. "Airport collaborative decision-making (A-CDM)". https://www.eurocontrol.int/concept/airport-collaborative-decision-making
|
||||
[20] 新浪财经. "喜报！中标民航机场建设“十五五”数字化发展规划". 2026. https://finance.sina.cn/stock/relnews/hk/2026-04-07/detail-inhtsrqx7097305.d.html
|
||||
[21] 国务院国资委. "民航首家！中国航信实现离港系统全栈国产化". 2025. http://wap.sasac.gov.cn/n2588025/n2588139/c35019378/content.html
|
||||
[22] 上海市科学技术委员会. "2024年上海市认定机构认定报备的高新技术企业名单". https://www.sh-hitech.com/tzbt/15627.html
|
||||
@@ -0,0 +1,758 @@
|
||||
---
|
||||
title: AODB 系统架构设计文档
|
||||
created: 2026-04-13
|
||||
updated: 2026-04-13
|
||||
type: system-design
|
||||
tags: [aodb, system-design, architecture, ddd, acdm]
|
||||
sources: [参考: aodb-core, aodb-vendors, flight-data-exchange, a-cdm]
|
||||
---
|
||||
|
||||
# AODB 系统架构设计文档
|
||||
|
||||
> **项目代号**: AeroCore AODB
|
||||
> **设计依据**: 参考 SITA Operations Manager、Amadeus AODB、ADB SAFEGATE Cortex、AirportLabs SkyCore 等商用系统，结合 IATA A-CDM Toolkit 2025、IATA AIDX v22.1、SSIM 第36版标准
|
||||
> **架构风格**: DDD（领域驱动设计）+ 事件驱动 + 微服务架构（可拆分为单体或微服务部署）
|
||||
> **目标定位**: 对标商用 AODB（年旅客量 1000万~4000万级别），具备 A-CDM 全链路、SSIM/AIDX 原生支持、多源融合、AI 辅助决策能力
|
||||
|
||||
---
|
||||
|
||||
## 一、设计目标与验收标准
|
||||
|
||||
### 1.1 核心能力目标
|
||||
|
||||
| 能力维度 | 目标 | 对标商用系统 |
|
||||
|---------|------|------------|
|
||||
| 航班数据管理 | 全生命周期覆盖（计划→执飞→历史） | Amadeus AODB |
|
||||
| A-CDM Milestone | 16项里程碑全自动触发 | SITA Operations Manager |
|
||||
| SSIM 解析 | 第36版格式全字段解析 | IATA SSIM 标准 |
|
||||
| AIDX XML 引擎 | v22.1 全消息类型支持 | IATA AIDX 标准 |
|
||||
| 多源融合 | 最多支持 8 路数据源优先判定 | ADB SAFEGATE Cortex |
|
||||
| VTT 预测 | 基于历史数据的 EXOT/EXIT ML 预测 | ADB SAFEGATE VTT |
|
||||
| What-if 仿真 | 配置变更方案评估 | ADB SAFEGATE "What-if" |
|
||||
| 高可用 | 99.99% 可用性（4个9） | Collins AirDB |
|
||||
| 响应延迟 | API P99 < 200ms，事件推送 < 2s | PDC Aviation |
|
||||
|
||||
### 1.2 非功能目标
|
||||
|
||||
- **水平扩展**: 无状态服务层，存储层按需扩容，支持航班量 10x 增长
|
||||
- **多租户**: 支持单机场 + 多机场集团模式，数据隔离
|
||||
- **国产化**: 适配国产芯片（鲲鹏/飞腾）、国产数据库（GaussDB/达梦）、国产操作系统（麒麟/统信）
|
||||
- **国际化**: 字符编码 UTF-8，支持 IATA Airport Code（3字母）、ICAO Code（4字母）双码制
|
||||
- **合规**: 满足等保2.0三级、民航局 MH/T 5103-2020 标准
|
||||
|
||||
---
|
||||
|
||||
## 二、系统架构概览
|
||||
|
||||
### 2.1 四层架构总览
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────────────┐
|
||||
│ 接入层（Access Layer） │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Web Console │ │ Mobile App │ │ 第三方API │ │ 报文网关 │ │
|
||||
│ │ (运营控制) │ │ (移动操作) │ │ (REST/GraphQL)│ │ (SSIM/AIDX) │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
├──────────────────────────────────────────────────────────────────────┤
|
||||
│ 网关层（Gateway Layer） │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ API Gateway │ │ 消息网关 │ │ 规则引擎 │ │
|
||||
│ │ (认证/限流) │ │ (AIDX/SSIM) │ │ (业务规则) │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
├──────────────────────────────────────────────────────────────────────┤
|
||||
│ 核心服务层（Core Services） │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Flight Domain│ │ Resource │ │ A-CDM │ │ Billing │ │
|
||||
│ │ 航班领域服务 │ │ Domain │ │ 协同服务 │ │ Domain │ │
|
||||
│ │ │ │ 资源领域服务 │ │ │ │ 计费领域 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Messaging │ │ AI Engine │ │ Simulation │ │ Reference │ │
|
||||
│ │ 消息交换服务 │ │ AI推理引擎 │ │ What-if仿真 │ │ Data │ │
|
||||
│ │ │ │ (VTT/预测) │ │ │ │ 参考数据 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
├──────────────────────────────────────────────────────────────────────┤
|
||||
│ 数据层（Data Layer） │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ PostgreSQL │ │ Redis │ │ Kafka │ │ TimescaleDB │ │
|
||||
│ │ 主数据存储 │ │ 热缓存/会话 │ │ 事件总线 │ │ 时序数据 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ MinIO/S3 │ │ Elasticsearch│ │ SQLite │ │
|
||||
│ │ 文件存储 │ │ 日志检索 │ │ 嵌入式测试 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
└──────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 2.2 技术选型
|
||||
|
||||
| 层级 | 组件 | 选型理由 | 备选 |
|
||||
|------|------|---------|------|
|
||||
| 主数据存储 | **PostgreSQL 16+** | ACID 强一致、JSONB 支持 GIS、时序插件、分区表 | GaussDB, 达梦 |
|
||||
| 缓存/会话 | **Redis Cluster** | 集群模式、高并发缓存、Redis Streams 事件驱动 | |
|
||||
| 消息总线 | **Apache Kafka** | 事件溯源、多消费者、 Exactly-once 语义 | RocketMQ |
|
||||
| 时序分析 | **TimescaleDB** | 基于 PG 的时序扩展，航班历史趋势分析 | InfluxDB |
|
||||
| 全文检索 | **Elasticsearch** | 日志分析、航班号/乘客名搜索 | |
|
||||
| 文件存储 | **MinIO** | S3 兼容、国产化支持 | 华为 OBS |
|
||||
| 搜索框 | **Blazor WebAssembly** | 运营控制台，技术栈统一 | React/Vue |
|
||||
| 移动端 | **Flutter** | iOS/Android 双端，Low-code 表单 | |
|
||||
| API 网关 | **Kong/Apache APISIX** | 开源、可插拔插件、mTLS | |
|
||||
| 服务网格 | **Istio**（可选） | 微服务治理、流量管理、mTLS | |
|
||||
| 容器平台 | **Kubernetes** | 可移植性、国产化（麒麟/达梦） | |
|
||||
|
||||
---
|
||||
|
||||
## 三、DDD 领域划分
|
||||
|
||||
### 3.1 限界上下文（Bounded Contexts）
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ AeroCore AODB │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌──────────┐ │
|
||||
│ │ Flight │ │ Resource │ │ Operations │ │ Billing │ │
|
||||
│ │ Context │ │ Context │ │ Context │ │ Context │ │
|
||||
│ │ │ │ │ │ │ │ │ │
|
||||
│ │ - 航班计划 │ │ - 登机口 │ │ - A-CDM │ │ - 账单 │ │
|
||||
│ │ - 航班动态 │ │ - 机位 │ │ - Milestone │ │ - 发票 │ │
|
||||
│ │ - 机型机号 │ │ - 行李转盘 │ │ - PDS │ │ - 结算 │ │
|
||||
│ │ - 旅客数据 │ │ - 设备 │ │ - VTT │ │ │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────┘ └──────────┘ │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
|
||||
│ │ Messaging │ │ Reference │ │ Integration│ │
|
||||
│ │ Context │ │ Context │ │ Context │ │
|
||||
│ │ │ │ │ │ │ │
|
||||
│ │ - SSIM解析 │ │ - 机场基础 │ │ - AIDX引擎 │ │
|
||||
│ │ - AIDX处理 │ │ - 航司数据 │ │ - 第三方API │ │
|
||||
│ │ - 报文路由 │ │ - 机型字典 │ │ - Webhook │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────┘ │
|
||||
│ │
|
||||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Shared Kernel │ │
|
||||
│ │ AirportCode(IATA/ICAO) | Time(UTC) | FlightNumber | Event │ │
|
||||
│ └─────────────────────────────────────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 3.2 各领域核心实体
|
||||
|
||||
#### Flight Context（航班上下文）
|
||||
|
||||
```
|
||||
Flight（航班聚合根）
|
||||
├── FlightId (UUID, 业务ID)
|
||||
├── FlightNumber (CA1234, 航司码+数字)
|
||||
├── OperationalSuffix (A/B, 同一日重复航班)
|
||||
├── AircraftId → Aircraft (实体)
|
||||
├── AirlineId → Airline (实体)
|
||||
├── OriginAirport (IATACode, 值对象)
|
||||
├── DestinationAirport (IATACode, 值对象)
|
||||
├── ServiceType (J/C/F/P/M, 值对象)
|
||||
├── OperationalStatus (OP/NOP/DV/DX/RT/GRT/SQ, 枚举)
|
||||
│
|
||||
├── Legs: List<FlightLeg> (去程/回程, 聚合内实体)
|
||||
│ └── FlightLeg
|
||||
│ ├── LegIdentifier: UFI (唯一航班标识, 值对象)
|
||||
│ ├── LegData
|
||||
│ │ ├── ScheduledTimes (计划时间, SCT)
|
||||
│ │ ├── EstimatedTimes (预计时间, EST)
|
||||
│ │ ├── ActualTimes (实际时间, ACT)
|
||||
│ │ ├── PaxCount (旅客数)
|
||||
│ │ └── AircraftInfo (机型/注册号/尾号)
|
||||
│ └── Resources: List<AssignedResource>
|
||||
│
|
||||
├── Milestones: List<FlightMilestone> (16项里程碑, 值对象集合)
|
||||
│ └── FlightMilestone
|
||||
│ ├── Code (ELDT/ALDT/EOBT/AOBT/TOBT/TSAT/TTOT/ATOT/CTOT/EXOT/EIBT/EXIT/AIBT/ATIGT/TTIGT/COBT)
|
||||
│ ├── Time (时间戳)
|
||||
│ ├── Source (来源系统)
|
||||
│ ├── Provenance (数据溯源, 枚举: IATA_AIDX/SITA/ATC/_HANDLER)
|
||||
│ └── Confirmed (是否已确认)
|
||||
│
|
||||
└── Domains Events
|
||||
├── FlightCreatedEvent
|
||||
├── FlightStatusChangedEvent
|
||||
├── MilestoneUpdatedEvent
|
||||
└── FlightCancelledEvent
|
||||
```
|
||||
|
||||
#### Resource Context（资源上下文）
|
||||
|
||||
```
|
||||
Gate（登机口聚合根）
|
||||
├── GateId
|
||||
├── IATACode (A1, B12)
|
||||
├── TerminalId → Terminal
|
||||
├── GateType (Domestic/International/Transfer)
|
||||
├── ContactInfo (对讲机频道等)
|
||||
└── CurrentAssignment → FlightLeg? (当前绑定航班)
|
||||
|
||||
Stand（机位聚合根）
|
||||
├── StandId
|
||||
├── IATACode (B12, 远机位编号)
|
||||
├── TerminalId
|
||||
├── StandType (Narrow/Wide/Heavy)
|
||||
├── MaxAircraftSize (ICAO Wake Turbulence Category)
|
||||
└── Equipment (400Hz/Pre-conditioned Air/jetway等)
|
||||
|
||||
BaggageCarousel（行李转盘）
|
||||
├── CarouselId
|
||||
├── IATACode (C1, 物理转盘编号)
|
||||
├── TerminalId
|
||||
├── CarouselType (Arrival/Departure)
|
||||
└── CurrentAssignment → FlightLeg?
|
||||
```
|
||||
|
||||
#### Operations Context（运营协同上下文）
|
||||
|
||||
```
|
||||
ACDMCollaborativeSession（A-CDM 协同会话聚合根）
|
||||
├── SessionId
|
||||
├── AirportCode (IATA, 值对象)
|
||||
├── Date (UTC 日期)
|
||||
├── CDMPhase (PRE_DEPARTURE/INBOUND/ABNORMAL)
|
||||
├── Participants (Set<Participant>, 航司/管制/服务商)
|
||||
│
|
||||
├── PreDeparturesequencing: List<PDSEntry>
|
||||
│ └── PDSEntry
|
||||
│ ├── Position (起飞序列位置)
|
||||
│ ├── FlightLegId → FlightLeg
|
||||
│ ├── CTOT (ATFM 分配)
|
||||
│ ├── TSAT (目标启动许可时间)
|
||||
│ ├── EXOT (预计滑出时间)
|
||||
│ └── ConstraintViolation (违反约束列表)
|
||||
│
|
||||
├── VTTModel: VTTPredictor (滑行时间预测模型)
|
||||
│ ├── HistoricalAverage
|
||||
│ ├── TimeOfDayFactor
|
||||
│ ├── WeatherFactor
|
||||
│ └── TrafficFactor
|
||||
│
|
||||
└── Domain Events
|
||||
├── SequencingUpdatedEvent
|
||||
└── TTOTChangedEvent
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 四、核心模块详细设计
|
||||
|
||||
### 4.1 消息交换引擎（Messaging Engine）
|
||||
|
||||
#### 模块职责
|
||||
|
||||
- 接收并解析 SSIM 批次文件，构建航班季节性计划
|
||||
- 接收并解析 AIDX XML 实时报文，更新航班动态
|
||||
- 多源数据优先判定：同一时间字段出现多源冲突时，执行优先级裁定
|
||||
- 事件发布：解析结果发布为领域事件，供下游服务消费
|
||||
|
||||
#### AIDX 处理流水线
|
||||
|
||||
```
|
||||
AIDX XML Message (HTTP/SMTP/SFTP)
|
||||
│
|
||||
▼
|
||||
┌───────────────────┐
|
||||
│ Schema Validation│ ← XSD v22.1 校验 + 自定义规则
|
||||
│ (javax.xml.bind) │
|
||||
└───────────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────┐
|
||||
│ UFI 去重检查 │ ← 同一 UFI 30min 内去重
|
||||
│ (Redis Cache) │
|
||||
└───────────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────┐
|
||||
│ 多源优先判定 │ ← 配置优先表（见下表）
|
||||
│ (Priority Engine) │
|
||||
└───────────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────┐
|
||||
│ Flight Aggregate │ ← 更新聚合根 + 持久化
|
||||
│ (JPA + Events) │
|
||||
└───────────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────┐
|
||||
│ 发布领域事件 │ ← Kafka Topic: flight-events
|
||||
│ (Domain Events) │
|
||||
└───────────────────┘
|
||||
```
|
||||
|
||||
#### 多源数据优先判定表
|
||||
|
||||
| 里程碑字段 | 第一优先 | 第二优先 | 第三优先 | 第四优先 |
|
||||
|-----------|---------|---------|---------|---------|
|
||||
| ALDT（实际落地） | ANSP（管制雷达） | 泊位传感器（Docking） | AODB 推算 | 航司报告 |
|
||||
| AOBT（实际推出） | 地面服务商（GHD） | 登机口操作员 | 航司 | AODB |
|
||||
| ATOT（实际起飞） | ANSP（塔台） | 跑道传感器 | AODB | 航司 |
|
||||
| TOBT（目标推出） | 航司（空班） | 地面服务商 | AODB 计算 | |
|
||||
| ELDT（预计落地） | NMOC（欧洲） | ANSP | 航司 FMS | AODB 推算 |
|
||||
| EXOT（预计滑出） | AODB VTT 模型 | 历史均值 | 固定值 |
|
||||
| EXIT（预计滑入） | AODB VTT 模型 | 历史均值 | 固定值 |
|
||||
|
||||
#### SSIM 解析器
|
||||
|
||||
- 支持 SSIM Chapter 6（SCR 报文）/ Chapter 7（SSR 报文）
|
||||
- 批次导入模式：文件上传 → 后台任务解析 → 逐条入库 → 批量确认
|
||||
- 冲突检测：同一航班号+日期出现多条，以 `Action Code` 判定（N=新增/C=变更/D=删除）
|
||||
- 历史归档：SSIM 数据存入 TimescaleDB，供长期趋势分析
|
||||
|
||||
### 4.2 A-CDM 协同引擎
|
||||
|
||||
#### Milestone 管理
|
||||
|
||||
```
|
||||
航班生命周期中16项里程碑全部由系统自动触发/接收：
|
||||
|
||||
ELDT ──[估算]──→ ALDT ──[实际]──┐
|
||||
│
|
||||
EOBT ──[计划]──→ AOBT ──[实际]──┤──→ TOBT ──[目标]──→ TSAT ──[许可]──→ TTOT ──[目标]──┐
|
||||
│ │
|
||||
COBT ←──[CTOT计算]── CTOT ──────┘ │
|
||||
│
|
||||
EIBT ──[预计靠桥]────────────────────────────┐ │
|
||||
EXIT │
|
||||
AIBT ──[实际靠桥]────────────────────────────┘ │
|
||||
ATIGT │
|
||||
TTIGT ──[目标靠桥]──────────────────────────────┘
|
||||
|
||||
触发规则：
|
||||
- ACT（实际）类里程碑：收到 AIDX 报文中的 Actual Time → 自动写入
|
||||
- EST（预计）类里程碑：AODB VTT 模块持续计算更新（每60秒重算）
|
||||
- SCT（计划）类里程碑：来自 SSIM 导入或航班创建时写入
|
||||
- TTIGT：基于 EXIT + 标准靠桥时间（按机型/机位计算）
|
||||
```
|
||||
|
||||
#### PDS（Pre-Departure Sequencer）算法
|
||||
|
||||
```
|
||||
输入：
|
||||
- CTOT（来自 ATFM/NMOC）
|
||||
- 管制离港率（Departure Rate, 架次/小时）
|
||||
- TOBT 列表（各航班目标推出时间）
|
||||
- 机位-跑道距离（Stand to Runway Matrix）
|
||||
- VTT 预测值（EXOT）
|
||||
- 约束条件（最小间隔、航司优先级、特殊航班）
|
||||
|
||||
输出：
|
||||
- TSAT（目标启动许可时间）
|
||||
- 起飞序列（PDS Entry List）
|
||||
- COBT（计算推出时间）
|
||||
|
||||
算法：改进版 Shortest Processing Time（SPT）+ 约束满足
|
||||
1. 按 TTOT 升序排列候选航班
|
||||
2. 对每架航班，计算 earliest_start = max(TOBT, CTOT - EXOT - taxi_time)
|
||||
3. 插入序列，检查与前机尾随间隔（Wake Turbulence分离）
|
||||
4. 若违反约束，触发重排（re-sequencing）
|
||||
5. 输出最终 TSAT 和序列位置
|
||||
```
|
||||
|
||||
#### VTT（Variable Taxi-Time）预测
|
||||
|
||||
```
|
||||
模型类型：梯度提升回归（XGBoost），特征包括：
|
||||
|
||||
特征维度（24维）：
|
||||
- time_of_day（小时，周期性编码）
|
||||
- day_of_week（周一～周日）
|
||||
- month（季节性）
|
||||
- runway_config（跑道运行模式：独立进/独立出/混合）
|
||||
- qty_departures（当前离港队列长度）
|
||||
- qty_arrivals（当前进港队列长度）
|
||||
- visibility（能见度：CAT I/II/III 或 VFR/IFR）
|
||||
- wind_speed / wind_dir（风速/风向）
|
||||
- temperature（温度）
|
||||
- precipitation（降水：是/否）
|
||||
- visibility_meters（能见度，米）
|
||||
- historical_avg_EXIT / EXOT（同小时历史均值）
|
||||
- airport_load_level（机场负载等级：低/中/高/饱和）
|
||||
|
||||
预测输出：
|
||||
- EXOT（Expected Taxi-Out Time）：预计滑出时间
|
||||
- EXIT（Expected Taxi-In Time）：预计滑入时间
|
||||
- EIBT（Expected In-Block Time）：预计靠桥时间 = ELDT + EXIT
|
||||
|
||||
重算策略：
|
||||
- 正常情况：每 60 秒批量重算所有活跃航班
|
||||
- 事件触发：收到 AOBT/ALDT/天气变化 → 立即重算相关航班
|
||||
- 模型更新：每日使用前30天历史数据重训练
|
||||
```
|
||||
|
||||
### 4.3 What-if 仿真模块
|
||||
|
||||
#### 功能定位
|
||||
|
||||
对标 ADB SAFEGATE Cortex 的 "What-if" 仿真能力，支持运营场景假设分析。
|
||||
|
||||
#### 仿真场景
|
||||
|
||||
| 场景 | 输入 | 模拟输出 |
|
||||
|------|------|---------|
|
||||
| 跑道关闭 | 关闭跑道号、开始时间、持续时长 | 各航班 CTOT/TSAT 变化、延误传播链 |
|
||||
| 大面积延误 | 延误航班数量、延误量级 | 受影响航班列表、恢复时间估算 |
|
||||
| 临时增加航班 | 新航班时刻表 | 资源冲突告警（机位/登机口/设备）|
|
||||
| 极端天气 | 天气类型、持续时间、能见度 | VTT 重算结果、对离港率影响 |
|
||||
| 资源调配 | 临时调整机位分配 | 新 TSAT 序列、旅客连接影响 |
|
||||
|
||||
#### 技术实现
|
||||
|
||||
```
|
||||
What-if Scenario 创建 → 快照当前状态（Flight/Resource/A-CDM）
|
||||
→ 应用假设变更（ScenarioMutation）
|
||||
→ 在独立 Simulation Sandbox 中运行 VTT + PDS 算法
|
||||
→ 生成对比报告（与基线偏差）
|
||||
→ 可选：发布为正式变更（Commit）或丢弃（Discard）
|
||||
```
|
||||
|
||||
### 4.4 AI 决策辅助模块
|
||||
|
||||
#### 能力矩阵
|
||||
|
||||
| 能力 | 算法 | 输入 | 输出 |
|
||||
|------|------|------|------|
|
||||
| VTT 滑行时间预测 | XGBoost | 天气/流量/时间 | EXOT/EXIT 预测值 |
|
||||
| 过站时间预测 | LSTM | 历史过站数据/天气/机型 | 预计过站时长 |
|
||||
| 延误链传播分析 | 图神经网络 | 航班衔接关系 | 受影响航班列表 |
|
||||
| 异常预警 | 孤立森林 | 全量实时数据流 | 异常事件告警 |
|
||||
| 资源冲突预测 | 约束求解+RL | 资源分配状态 | 冲突概率/建议调整 |
|
||||
|
||||
---
|
||||
|
||||
## 五、API 设计
|
||||
|
||||
### 5.1 REST API 概览
|
||||
|
||||
```
|
||||
API Version Prefix: /api/v1
|
||||
|
||||
认证: OAuth 2.0 (JWT Bearer Token)
|
||||
内容类型: application/json
|
||||
字符编码: UTF-8
|
||||
时间格式: ISO 8601 UTC (2026-04-13T14:30:00Z)
|
||||
```
|
||||
|
||||
#### 核心资源
|
||||
|
||||
| 资源 | 路径 | 说明 |
|
||||
|------|------|------|
|
||||
| Flight | `/flights` | 航班 CRUD |
|
||||
| Flight Leg | `/flights/{flightId}/legs` | 航段管理 |
|
||||
| Milestone | `/flights/{flightId}/milestones` | 里程碑管理 |
|
||||
| Gate | `/gates` | 登机口管理 |
|
||||
| Stand | `/stands` | 机位管理 |
|
||||
| Carousel | `/carousels` | 行李转盘 |
|
||||
| PDS Sequence | `/pds/sequences` | 起飞排序 |
|
||||
| TOBT | `/tobt` | 目标推出时间上报 |
|
||||
| SSIM Import | `/imports/ssim` | SSIM 文件上传 |
|
||||
| AIDX Webhook | `/webhooks/aidx` | AIDX 消息接收 |
|
||||
| Simulation | `/simulations` | What-if 仿真 |
|
||||
| Reports | `/reports` | 运营报告 |
|
||||
|
||||
#### 关键 API 设计示例
|
||||
|
||||
**TOBT 上报（航司/地面服务商）**
|
||||
|
||||
```
|
||||
POST /api/v1/tobt
|
||||
{
|
||||
"flightLeg": {
|
||||
"airline": "CA",
|
||||
"flightNumber": "1234",
|
||||
"originDate": "2026-04-13",
|
||||
"departureAirport": "PEK"
|
||||
},
|
||||
"tobt": "2026-04-13T14:30:00Z",
|
||||
"reason": "PASSENGER_BOARDING_COMPLETE",
|
||||
"submittedBy": "HANDLER_CA_PEK",
|
||||
"submittedAt": "2026-04-13T14:00:00Z"
|
||||
}
|
||||
|
||||
响应 200:
|
||||
{
|
||||
"tobt": "2026-04-13T14:30:00Z",
|
||||
"tsat": "2026-04-13T14:35:00Z", // AODB 基于 TSAT=TTOT-EXOT 重算
|
||||
"revision": 3,
|
||||
"status": "CONFIRMED"
|
||||
}
|
||||
```
|
||||
|
||||
**航班动态查询（支持过滤条件）**
|
||||
|
||||
```
|
||||
GET /api/v1/flights?date=2026-04-13&airport=PEK&status=OP,DX,DV&page=0&size=50
|
||||
|
||||
响应 200:
|
||||
{
|
||||
"content": [
|
||||
{
|
||||
"flightId": "f-uuid-001",
|
||||
"flightNumber": "CA1234",
|
||||
"operationalStatus": "OP",
|
||||
"currentLeg": {
|
||||
"departureAirport": "PEK",
|
||||
"arrivalAirport": "PVG",
|
||||
"etd": "2026-04-13T14:30:00Z",
|
||||
"eta": "2026-04-13T15:45:00Z",
|
||||
"stand": "B12",
|
||||
"gate": "A12",
|
||||
"carousel": "C5"
|
||||
},
|
||||
"milestones": {
|
||||
"ELDT": { "time": "2026-04-13T15:40:00Z", "confirmed": true },
|
||||
"TOBT": { "time": "2026-04-13T14:30:00Z", "confirmed": true },
|
||||
"TSAT": { "time": "2026-04-13T14:35:00Z", "confirmed": false }
|
||||
}
|
||||
}
|
||||
],
|
||||
"totalElements": 842,
|
||||
"page": 0,
|
||||
"size": 50
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 事件订阅（Webhook / Kafka）
|
||||
|
||||
```
|
||||
外部系统可通过 Webhook 订阅 AODB 事件：
|
||||
|
||||
POST /api/v1/webhooks
|
||||
{
|
||||
"name": "FIDS系统订阅",
|
||||
"url": "https://fids.airport.com/webhook/aodb",
|
||||
"events": [
|
||||
"flight.created",
|
||||
"flight.status_changed",
|
||||
"flight.milestone_updated",
|
||||
"flight.gate_assigned",
|
||||
"pds.sequencing_updated"
|
||||
],
|
||||
"secret": "whsec_xxxxx",
|
||||
"active": true
|
||||
}
|
||||
|
||||
签名机制: HMAC-SHA256(RequestBody, secret) → X-Signature 头
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 六、数据模型设计
|
||||
|
||||
### 6.1 核心实体 ER 图（简化）
|
||||
|
||||
```
|
||||
Airport (1) ──< (N) Terminal (1) ──< (N) Gate
|
||||
│
|
||||
├──< (N) Stand
|
||||
│
|
||||
└──< (N) BaggageCarousel
|
||||
|
||||
Airline (1) ──< (N) Flight
|
||||
│
|
||||
└──< (N) Aircraft
|
||||
|
||||
Flight (1) ──< (N) FlightLeg
|
||||
│
|
||||
├──< (N) FlightMilestone
|
||||
├──< (N) AircraftAssignment
|
||||
└──< (N) Pax (旅客数据)
|
||||
|
||||
FlightLeg (N) ──> (1) Gate (可选)
|
||||
FlightLeg (N) ──> (1) Stand (可选)
|
||||
FlightLeg (N) ──> (1) BaggageCarousel (可选)
|
||||
|
||||
ACDM_Session (1) ──< (N) PDS_Entry
|
||||
│
|
||||
└──< VTT_Model (滑行时间预测)
|
||||
```
|
||||
|
||||
### 6.2 关键索引设计
|
||||
|
||||
```sql
|
||||
-- 航班唯一查询（UFI 组合索引）
|
||||
CREATE UNIQUE INDEX idx_flight_leg_ufi
|
||||
ON flight_legs (airline_code, flight_number, departure_airport, origin_date);
|
||||
|
||||
-- 航班日计划查询（高频）
|
||||
CREATE INDEX idx_flight_leg_date
|
||||
ON flight_legs (origin_date, departure_airport, operational_status)
|
||||
WHERE origin_date >= CURRENT_DATE;
|
||||
|
||||
-- 里程碑查询（按航班+时间范围）
|
||||
CREATE INDEX idx_milestone_flight_code
|
||||
ON flight_milestones (flight_leg_id, milestone_code, event_time);
|
||||
|
||||
-- 资源当前分配（实时查找）
|
||||
CREATE INDEX idx_stand_current
|
||||
ON stand_assignments (stand_id, actual_off_blocks)
|
||||
WHERE actual_on_blocks IS NULL;
|
||||
|
||||
-- 时序数据（TimescaleDB hypertable）
|
||||
CREATE MATERIALIZED VIEW v_flight_punctuality
|
||||
WITH (timescaledb.continuous) AS
|
||||
SELECT time_bucket('5 min', event_time) AS ts,
|
||||
airport_code,
|
||||
count(*) FILTER (WHERE abs(ATOT - TTOT) > 900) AS delayed_count,
|
||||
avg(extract(EPOCH FROM (ATOT - TTOT))) FILTER (WHERE ATOT IS NOT NULL) AS avg_delay_seconds
|
||||
FROM flight_milestones
|
||||
WHERE milestone_code = 'ATOT'
|
||||
GROUP BY ts, airport_code;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 七、安全与运维体系
|
||||
|
||||
### 7.1 零信任安全架构
|
||||
|
||||
```
|
||||
安全原则：
|
||||
1. 最小权限（Least Privilege）：每个微服务仅拥有完成其任务所需的最低权限
|
||||
2. 默认拒绝（Default Deny）：未明确授权的请求一律拒绝
|
||||
3. 永不信任（Never Trust）：所有跨服务调用均需验证 JWT，即使在内部网络
|
||||
4. 始终加密（Always Encrypt）：传输加密（mTLS）+ 存储加密（AES-256）
|
||||
|
||||
认证体系：
|
||||
- 用户认证：OAuth 2.0 + OpenID Connect（支持 SAML 2.0 企业 SSO）
|
||||
- 机器认证：mTLS（服务间）+ API Key（第三方系统）
|
||||
- 多因素认证：TOTP（运营人员）+ 证书（管制系统）
|
||||
|
||||
权限模型：RBAC + ABAC 混合
|
||||
- RBAC：角色（Airport Admin / Airline Ops / Ground Handler / ATC / Viewer）
|
||||
- ABAC：属性（机场代码 × 可操作资源范围 × 时间窗口）
|
||||
```
|
||||
|
||||
### 7.2 审计日志
|
||||
|
||||
```sql
|
||||
-- 审计日志表（防篡改）
|
||||
CREATE TABLE audit_log (
|
||||
id BIGSERIAL PRIMARY KEY,
|
||||
event_id UUID NOT NULL DEFAULT gen_random_uuid(),
|
||||
timestamp TIMESTAMPTZ NOT NULL DEFAULT NOW(),
|
||||
actor_id VARCHAR(64) NOT NULL, -- user_id 或 system_id
|
||||
actor_type VARCHAR(16) NOT NULL, -- USER / SYSTEM / EXTERNAL
|
||||
action VARCHAR(64) NOT NULL, -- flight.update / gate.assign
|
||||
resource JSONB NOT NULL, -- 受影响的资源快照
|
||||
changes JSONB, -- 变更前后差异（Before/After）
|
||||
ip_address INET,
|
||||
user_agent TEXT,
|
||||
request_id UUID, -- 关联 HTTP 请求
|
||||
integrity TEXT GENERATED ALWAYS AS (encode(sha256((event_id||timestamp||actor_id||action||resource)::text::bytea), 'hex')) STORED
|
||||
);
|
||||
|
||||
-- 审计日志不可直接 DELETE/UPDATE（用 DB RULE 拦截）
|
||||
CREATE RULE audit_log_no_delete AS ON DELETE TO audit_log DO INSTEAD NOTHING;
|
||||
CREATE RULE audit_log_no_update AS ON UPDATE TO audit_log DO INSTEAD NOTHING;
|
||||
```
|
||||
|
||||
### 7.3 高可用架构
|
||||
|
||||
```
|
||||
部署模式：主动-待机双活（Active-Active 或 Active-Standby 可配置）
|
||||
|
||||
┌──────────────────┐ ┌──────────────────┐
|
||||
│ AZ-1（主） │ │ AZ-2（备） │
|
||||
│ ┌────────────┐ │ │ ┌────────────┐ │
|
||||
│ │ K8s Node 1 │◄┼─────┼─►│ K8s Node 3 │ │
|
||||
│ └────────────┘ │ │ └────────────┘ │
|
||||
│ ┌────────────┐ │ │ ┌────────────┐ │
|
||||
│ │ K8s Node 2 │◄┼─────┼─►│ K8s Node 4 │ │
|
||||
│ └────────────┘ │ │ └────────────┘ │
|
||||
│ ┌────────────┐ │ │ ┌────────────┐ │
|
||||
│ │ PG Primary │ │ ←───│──│ PG Standby │ │
|
||||
│ └────────────┘ │ 同步 │ └────────────┘ │
|
||||
└──────────────────┘ └──────────────────┘
|
||||
│ │
|
||||
└─────────┬───────────────┘
|
||||
▼
|
||||
┌────────────────┐
|
||||
│ MinIO S3 │ (跨 AZ 复制)
|
||||
└────────────────┘
|
||||
|
||||
RTO（恢复时间目标）: < 30 秒（自动故障转移）
|
||||
RPO（恢复点目标）: < 1 分钟（同步复制）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 八、部署与运维
|
||||
|
||||
### 8.1 Kubernetes 部署结构
|
||||
|
||||
```
|
||||
namespace: aerocore-aodb
|
||||
├── ConfigMap: aodb-config（环境配置）
|
||||
├── Secret: aodb-secrets（数据库密码/证书）
|
||||
├── Ingress: aodb-ingress（域名 + TLS）
|
||||
│
|
||||
├── Deployment: aodb-api（无状态服务，3+ 副本）
|
||||
├── Deployment: aodb-message-engine（AIDX/SSIM 处理，2 副本）
|
||||
├── Deployment: aodb-acdm-engine（A-CDM/PDS，2 副本）
|
||||
├── Deployment: aodb-vtt-predictor（AI 推理服务，GPU 节点）
|
||||
├── Deployment: aodb-simulation（What-if 仿真，按需扩缩）
|
||||
├── Deployment: aodb-scheduler（Cron 任务，SSIM 导入等）
|
||||
│
|
||||
├── StatefulSet: postgresql（主从，1 副本）
|
||||
├── StatefulSet: redis（集群模式，3 副本）
|
||||
├── StatefulSet: kafka（3 副本）
|
||||
└── DaemonSet: log-collector（Fluent Bit → Elasticsearch）
|
||||
```
|
||||
|
||||
### 8.2 国产化适配清单
|
||||
|
||||
| 组件层 | 商业版 | 国产化替代 |
|
||||
|-------|-------|-----------|
|
||||
| 操作系统 | RHEL/Ubuntu | 麒麟 Kylin OS、统信 UOS |
|
||||
| 数据库 | PostgreSQL | 华为 GaussDB、达梦 DM8 |
|
||||
| 缓存 | Redis | 华为云 DCS（Redis 兼容）|
|
||||
| 消息队列 | Apache Kafka | 华为云 DMS、Apache RocketMQ |
|
||||
| 对象存储 | MinIO/S3 | 华为云 OBS、阿里云 OSS |
|
||||
| 容器平台 | Kubernetes | 麒麟容器云、阿里云 ACK |
|
||||
| 网关 | Kong | Apache APISIX（国产分支）|
|
||||
|
||||
---
|
||||
|
||||
## 九、模块开发优先级
|
||||
|
||||
### Phase 1（MVP，3个月）
|
||||
|
||||
| 模块 | 产出 |
|
||||
|------|------|
|
||||
| Flight Context（核心） | 航班 CRUD、实体、REST API |
|
||||
| Messaging Engine（简化版）| AIDX XML 解析 + SSIM 解析 |
|
||||
| Reference Data | 机场/航司/机型基础数据 |
|
||||
| 基础安全 | JWT 认证、RBAC |
|
||||
|
||||
### Phase 2（6个月）
|
||||
|
||||
| 模块 | 产出 |
|
||||
|------|------|
|
||||
| A-CDM Engine | 16项 Milestone 追踪、PDS 算法 |
|
||||
| Resource Context | Gate/Stand/Carousel 分配 |
|
||||
| VTT 预测 | XGBoost EXOT/EXIT 预测 |
|
||||
| 多租户 | 多机场数据隔离 |
|
||||
|
||||
### Phase 3（9个月）
|
||||
|
||||
| 模块 | 产出 |
|
||||
|------|------|
|
||||
| What-if 仿真 | 场景编辑器 + 沙箱引擎 |
|
||||
| AI 决策辅助 | 延误传播图分析、异常预警 |
|
||||
| 完整审计日志 | 防篡改审计链 |
|
||||
| 高可用部署 | K8s 容器化、双活架构 |
|
||||
|
||||
---
|
||||
|
||||
## 十、已知局限与待验证项
|
||||
|
||||
1. **VTT 模型精度**：需要至少 6 个月历史数据才能达到商用精度（< 5min MAE）
|
||||
2. **AIDX 全消息类型**：当前优先实现 `FlightLegNotifRQ/RS`，其他类型（AIDX-PAX、AIDX-BAG）后续迭代
|
||||
3. **PDS 算法**：当前为规则驱动，Phase 3 考虑引入 RL 优化序列
|
||||
4. **国产数据库兼容性**：GaussDB/达梦的 PG 兼容模式需实测验证
|
||||
5. **多机场模式**：共享基础设施的多机场部署方案 Phase 2 再详细设计
|
||||
Reference in New Issue
Block a user