node2vec | repository provides a reference implementation | Natural Language Processing library

If you check the documentation you can see that the randomSeed parameters is available. However, the results are still non-deterministic as per the docs:

Seed value used to generate the random walks, which are used as the training set of the neural network. Note, that the generated embeddings are still nondeterministic.

I think you need to create some data in the format referred to in the documentation, not just a network diagram. A Visio diagram will not do the job and I know of no way to do a conversion.

node2vec is an unsupervised node embedding method, which is based on Word2Vec. Have a look at the snap documentation for a brief description of the model. It will not use any of your attributes/features to create the embedding. It uses a shallow encoding, which are directly learned using a random walk based objective function. For details look at the paper or check the Stanford Lecture about node embeddings, which covers in detail Node2Vec. Your embedding dimension is currently 512 (for the node embedding of node2vec), which you probably can reduce.

I finally found the solution. It was quite unclear (at least to me) from the documentation but your nodes' labels must be string and not integer. So a simple .astype(str) in my dataframe fixed it. I hope this will help others in the future !

If I understand correctly, Node2Vec is basd on word2Vec, and thus like word2vec, requires a large amount of varied training data, and shows useful results when learning dense high-dimensional vectors per entity.

A mere 7 'words' (country-nodes) with a mere 10 'sentences' of 2 words each (edge-pairs) thus isn't expecially likely to do anything useful. (It wouldn't in word2vec.)

These countries literally are regions on a sphere. A sphere's surface can be mapped to a 2-D plane - hence, 'maps'. If you just want a 2-D vector for each country, which reflects their relative border/distance relationships, why not just lay your 2-D coordinates over an actual map large enough to show all the countries, and treat each country as its 'geographical center' point?

Or more formally: translate the x-longitude/y-latitude of each country's geographical center into whatever origin-point/scale you need.

If this simple, physically-grounded approach is inadequate, then being explicit about why it's inadequate might suggest next steps. Something that's an incremental transformation of those starting points to meet whatever extra constraints you want may be the best solution.

For example, if your not-yet-stated formal goal is that "every country-pair with an actual border should be closer than any country-pair without a border", then you could write code to check that, list any deviations, and try to 'nudge' the deviations to be more compliant with that constraint. (It might not be satisfiable; I'm not sure. And if you added other constraints, like "any country pair with just 1 country between them should be closer than any country pair with 2 countries between them", satisfying them all at once could become harder.)

Ultimately, next steps may depend on exactly why you want these per-country vectors.

Another thing worth checking out might be the algorithms behind 'force-directed graphs'. There, after specifying a graph's desired edges/edge-lengths, and some other parameters, a physics-inspired simulation will arrive at some 2-d layout that tries to satisfy the inputs. See for example from the JS world:

https://github.com/d3/d3-force

Graph embeddings were introduced in version 1.3 and the tutorial you found is for that version and it uses embeddingSize. Then 2nd link you found is the recent documentation for node2Vec and it is meant for >= 1.4 version. Look at the header of your 2nd link and you will see below

The error was due to torch.ops.torch_cluster.random_walk returning a tuple instead of an array/tensor. I fixed it by using replacing the functions pos_sample and neg_sample in the torch_geometric.nn.Node2Vec with these.

You can use a seaborn palette to generate 12 different RGB color values and then create a column called color in your dataframe based on the weight values:

Each call to the Word2Vec() constructor creates an all-new model.

However, runs are not completely deterministic under normal conditions, for a variety of reasons, so results quality for downstream evaluations (like your unshown clustering) will jitter from run-to-run.

If the variance in repeated runs with the same data is very large, there are probably other problems, such an oversized model prone to overfitting. (Stability from run-to-run can be one indicator that your process is sufficiently specified that the data and model choices are driving results, not the randomness used by the algorithm.)

If this explanation isn't satisfying, try adding more info to your question - such as the actual magnitude of your evaluation scores, in repeated runs, both with and without the changes that you conjecture are affecting results. (I suspect the variations from the steps you think are having effect will be no larger than variations from re-runs or different seed values.)

(More generally, Word2Vec is generally hungry for as much varies training data as possible; only if texts are non-representative of the relevant domain are they likely to result in a worse model. So I generally wouldn't expect being choosier about which subset of sentences is best to be an important technique, unless some of the sentences are total junk/noise, but of course there's always a change you'll find some effects in your particular data/goals.)