AWS neptune-analytics documentation change
Summary
Added detailed documentation for Personalized PageRank algorithm including use cases, configuration parameters (sourceNodes/sourceWeights), and security-related application examples for network security prioritization
Security assessment
The changes introduce security-focused documentation through the organizational network security example showing how to prioritize monitoring of sensitive systems. While this demonstrates security applications, there is no evidence of addressing a specific vulnerability or security incident. The documentation addition describes security feature usage rather than patching a weakness.
Diff
diff --git a/neptune-analytics/latest/userguide/page-rank.md b/neptune-analytics/latest/userguide/page-rank.md index d52d7389e..7df1788c6 100644 --- a//neptune-analytics/latest/userguide/page-rank.md +++ b//neptune-analytics/latest/userguide/page-rank.md @@ -5 +5 @@ -SyntaxInputsOutputsQuery examplesSample output +Personalized PageRankSyntaxInputsOutputsQuery examplesQuery examplesSample output @@ -14,0 +15,94 @@ The space complexity is O(|V|), where |V| is the number of vertices in the graph +## Personalized PageRank + +Personalized PageRank is a variation of the original PageRank algorithm. It is generally used to measure the importance of vertices in a graph. It tailors the ranking process to individual users or specific topics. Compared to PageRank, the result of personalized pagerank is a more customized ranking of web pages or nodes in a graph, reflecting individual interests or specific areas of focus. This approach is particularly useful in recommendation systems, personalized search results, and analyzing large-scale networks with diverse content for a specific focus. + +### Example scenario: Online retail platform + +Imagine an online retail platform where each product is a node, and customer purchases (or views) between products are edges. + +###### Regular PageRank + + * Objective: Rank products based on their general popularity across all customers. + + * Result: Products that are frequently purchased or viewed by many customers will receive higher PageRank scores. This helps identify the most popular products across the entire platform. + + + + +###### Personalized PageRank + + * Objective: Rank products based on their relevance to a specific customer's shopping behavior. + + * Inputs: + + * Source Nodes: A list of products that the customer has previously purchased or shown interest in. + + * Source Weights: Optional weights indicating the relative importance of each source product (e.g., higher weight for recently purchased items). + + * Result: Products that are not only popular but also closely related to the customer's specific shopping behavior will receive higher scores. This helps the platform recommend new products that are more likely to interest the customer. + + + + +### Example scenario: Organizational network security + +Imagine a network of computers within an organization where each computer is a node, and communication paths (like data transfers or network connections) between computers are edges. + +###### Regular PageRank + + * Objective: Rank computers based on their general importance within the organizational network. + + * Result: Computers that have a high number of connections to other computers will receive higher PageRank scores. This helps identify critical nodes in the network that, if compromised, could have a significant impact on the entire network. + + + + +###### Personalized PageRank + + * Objective: Rank computers based on their relevance to a specific security concern or department within the organization. + + * Inputs: + + * Source Nodes: A list of computers that are known to handle sensitive data or are critical to a specific department (e.g., HR, Finance). + + * Source Weights: Optional weights indicating the relative importance of each source computer (e.g., higher weight for computers handling more sensitive data). + + * Result: Computers that are not only well-connected but also closely related to the specific security concern or department will receive higher scores. This helps the cybersecurity team prioritize monitoring and protection efforts on the most critical nodes. + + + + +### Example scenario: Insurance policyholder network + +Imagine a network of policyholders where each policyholder is a node, and the relationships (like shared claims, referrals, or common risk factors) between policyholders are edges. + +###### Regular PageRank + + * Objective: Rank policyholders based on their general importance within the insurance network. + + * Result: Policyholders who have a high number of connections to other policyholders (e.g., through shared claims or referrals) will receive higher PageRank scores. This helps identify influential policyholders who may have a significant impact on the network. + + + + +###### Personalized PageRank + + * Objective: Rank policyholders based on their relevance to a specific risk profile or insurance product. + + * Inputs: + + * Source Nodes: A list of policyholders that fit a specific risk profile or are relevant to a particular insurance product (e.g., high-risk drivers for auto insurance). + + * Source Weights: Optional weights indicating the relative importance of each source policyholder (e.g., higher weight for policyholders with more recent claims). + + * Result: Policyholders who are not only well-connected but also closely related to the specific risk profile or insurance product will receive higher scores. This helps the insurance company tailor its risk assessment and underwriting processes more effectively. + + + + +The additional inputs to the algorithm are a list of vertices to be personalized on (`sourceNodes`) and optionally the weight distribution among those vertices (`sourceWeights`). If given, the weights are normalized before pagerank computation. + +###### Note + +Neptune Analytics allows up 8192 vertices in the personalization vector, sourceNodes. + @@ -29 +123,3 @@ The space complexity is O(|V|), where |V| is the number of vertices in the graph - edgeWeightType: The type of values associated with the edgeWeightProperty argument (optional) + edgeWeightType: The type of values associated with the edgeWeightProperty argument (optional), + sourceNodes: [A list of node IDs to personalize on (optional)], + sourceWeights: [A list of non-negative weights for the sourceNodes (optional)] @@ -88,0 +185,22 @@ The type of values associated with the edgeWeightProperty argument, specified as + * **sourceNodes** _(optional) - required if running personalized PageReank_ – _type:_ `list`; _default: none_. + +A personalization vertex list ["101", ...] + + * Can include 1 to 8192 vertices. + + * If a `vertexLabel` is provided, nodes that do not have the given `vertexLabel` are ignored. + + * **sourceWeights** _(optional)_ – _type:_ `list`; _default: none_. + +A personalization weight list. The weight distribution among the personalized vertices. + + * If not provided, the default behavior is uniform distribution among the vertices given in `sourceNodes`. + + * There must be at least one non-zero weight in the list. + + * The length of the sourceWeights list must match the `sourceNodes` list. + + * The mapping of personalization vertex and weight lists are one to one. The first value in the weight list corresponds to the weight of first vertex in the vertex list, second value is for the second vertex, etc. + + * The weights can be one of `int`, `long`, `float`, or `double` types. + @@ -105 +223 @@ If the input nodes list is empty, the output is empty. -This is a standalone example, where the source vertex list is explicitly specified in the query. +This is a standalone example, where the input vertex list is explicitly specified in the query. @@ -117 +235 @@ This is a standalone example, where the source vertex list is explicitly specifi -This is a query integration examples, where `.pageRank` follows a `MATCH` clause and uses frontier injection to take the output of the `MATCH` clause as its list of source nodes: +This is a query integration examples, where `.pageRank` follows a `MATCH` clause and uses frontier injection to take the output of the `MATCH` clause as its list of input nodes: @@ -148,0 +267,42 @@ This query is an example of constraining the results of `.pageRank` based on the +## Query examples for Personalized `.pageRank` + +Personalized PageRank applies the same integration and constraints. Here are some examples that pass personalization-specific configurations. + +This is a query integration example, where .pageRank follows a MATCH clause and uses frontier injection to take the output of the MATCH clause as its input list. We use nodes “101” and “102” as personalization nodes with "1" and "1.5" weights as weights respectively: + + + MATCH (n) + CALL neptune.algo.pageRank( n, { + tolerance: 0.001, + edgeLabels:["route”], + sourceNodes:["101", "102"], + sourceWeights:[1, 1.5] + } ) + YIELD node, rank + RETURN node, rank + +This is an example of where only source nodes is provided. The weights of ”101” and ”102” will be "1" and "1" (same, uniform) respectively. + + + MATCH (n) + CALL neptune.algo.pageRank( n, { + tolerance: 0.001, + edgeLabels:["route”], + sourceNodes:["101", "102"], + } ) + YIELD node, rank + RETURN node, rank + +This is an example where the weights are given as integral numbers. Note that this would yield the same result as the first example in which the weights were ("1" and "1.5"): + + + MATCH(n) + CALL neptune.algo.pageRank( n, { + tolerance: 0.001, + edgeLabels:["route”], + sourceNodes:["101", "102"], + sourceWeights:[2, 3] + } ) + YIELD node, rank + RETURN node, rank +